[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DDL-ML] SRCP 0.8

Lang-Sebastian@t-online.de wrote:
Hallo zusammen, kann mir jemand vielleicht schon die neusten Unterlagen (falls vorhanden)von SRCP 0.8 zukommen lassen, oder sind die bis zur Veröffentlichungnoch geheim ?
hmm. geheim nicht gerade. Alle bisherigen SRCP Fassungen sind auf meiner Homepage zur
ersten Begutachtung. Dazu kommen die Seiten des srcpd.sf.net (dort allerdings noch der rc2).

Das hat in der Vergangenheit ausgereicht. Sobald eine Version auf der-moba ankam, war sie
gewissermaßen offiziell. Aber der Einwand ist nicht unberechtigt. Torsten: Kannst Du irgendwie
einen Link auf das aktuell in Arbeit befindliche Dokument legen? (wird immer .../srcp-neu.(pdf|html|sgml) heißen.

 Frage dazu:     - habt ihr mal über Authentifizierung nachgedacht
Ja, sehr intensiv sogar. Mit dem Ergebnis: Es gibt keine. Mit
dem LOCKmechanismus kann man in den oberen Schichten
(XRCP) eine Benutzerverwaltung realisieren, aber für einen
lowlevel Server ist das einfach zuviel.
     - macht es evtl. Sinn den SET GL  Befehl um ein Attribut Bspw.      <refresh> zu erweitern (<refresh> : = Klassifikation der Decoder      in  solche die "selten", "häufig", "sehr oft" refreshed werden müssen)      => mit dem Ziel aud SRCP-Server Seite effizienter mit den      Refreshlisten umzugehen
Im neuen SRCP haben wir viele Konfigurationsmöglichkeiten vom SET in den/die INIT
verschoben.

Was soll der refresh bewirken?

Aus Sicht des SRCP ist es vollkommen unerheblich, ob die
Befehle einem refresh unterliegen oder nicht. Es wird ein Befehl abgesetzt und der soll
(salopp formuliert) gefälligst ausgeführt werden, bis ein neuer kommt.
Wenn die Dekoder so blöd sind und erteilte Befehle vergessen, so muß
der Server das eigenständig verhindern. Wenn es Dekoder geben sollte,
die einen unterschiedlichen Refresh erfordern, so stehen drei
Möglichkeiten offen:

 - eine neue Gerätegruppe; ziemlich großer Hammer
 - eine neue Untergrupe bei den GA/GL.
     Die bestehenden M1, N3 usw sind ja nicht nur für die Anzahl der
     Fahrstufen da, sie beziehen sich ja auch auf bestimmte Dekoder,
     die diese Eigenschaften haben. Eher indirekt und von hinten durch die
     Brust ins Auge getroffen.
 - Ausbau des SM Gerätes. Dies kann derzeit direkt mit den entsprechenden
     Registern der Dekoder umgehen, eine "Server-too" Verwendung hätte
     aber auch ihre Reize (die der Server dann natürlich auch persistent ablegen
     müßte, wie auch immer, es könnte auch ein Konfigurationsclient machen).

Letztere Version gefällt mir am besten, wenn es denn überhaupt gebraucht werden
sollte.

Gruß
Matthias

PS: In Deinem Protokoll wird eine Multicastadresse erwähnt. Kannst Du das mal
erklären? Ich habe keine Vorstellungen, was damit erreicht werden kann (in diesem
Kontext, sonst ist mir Multicast durchaus vertraut). 

-- 
http://members.tripod.de/mtrute/