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

Re: [DDL-ML] SRCP 0.8



> und wie sag ichs meiner M* 6021 oder meiner IB? Warum _muss_ ein Dekoder
> überhaupt refreshed werden? Was meinst Du mit "effizienter"? Man muss
> sowieso immer ein brauchbares Signal zum Booster schicken, warum also
> nicht den aktuellen Zustand einer Lok? Ich sehe hier keinerlei Vorteil.


Ich weiss nicht genau wie euer erddcd funktioniert (hab mir bis heute den
Quellcode
nur flüchtig angeschaut) aber ich vermute ähnlich wie bei uns. D.h. alle
Lokdecoder
(implizit bekannt über empfangene "SET GL ..."- Befehle der Clients) werden
in einer
"Refresh-Liste" geführt welche zyklisch abgearbeitet wird. D.h. im Falle,
dass keine Befehle
von Clients eintrudeln schickt der "Server" statt einem nutzlosen (aber
möglichen) 50Hz IDL-Signal
Refresh-Befehle (von Decodern in der Refreshliste) an den Booster.

Jetzt haben aber sicher nicht nur wir Loks mit Decodern, die nicht so
"merkfähig" sind
wie bspw. ein guter Marklin Dekoder.
Ich meine da z.B. den ein oder anderen billigeren Tams-Decoder, die
teilweise recht vergesslich und
störanfällig sind ...
D.h. manche Dekoder vergessen aufgrund ihrer Speicherarchitektur (EPROM)
empfange
Befehle so gut wie nie (Bspw.. gute Märklin MM2 Dekoder), andere (die
billigeren Decoder)
vergessen aufgrund des billigeren Flash-Speichers relativ schnell ihren
letzten Befehl (-> bleiben
evtl stehen, zuckeln, etc..) [Jedenfalls haben wir die Erfahrung gemacht]

So, gesetzt den Fall ich habe eine große Anlage mit bspw. 40 Loks, die alle
in der Refreshliste
stecken, dann dauert es ja eine Weile, bis eine Lok wieder einen
Refresh-Befehl bekommt
(vorsausgesetzt in der zwischenzeit gab es keine Änderung). Hier wollten wir
mit der
Klassifizierung von Lokdekodern eben etwas optimieren. D.h. die besseren
Dekoder, werden
weniger oft refreshed als die "Schlechteren". Daraus resultiert meines
Erachtens ein etwas
bessere Ausnutzung der Übertragungskapazität (zum Booster). Ob sich dass in
der Realität
sonderlich bemerkbar macht kann ich nicht abschätzen, da wir noch keine
Gelegenheit hatten
das zu testen.

Dieser Algorithmus liesse sich sicher auch mit einer M* 6021 oder einer IB
umsetzten.
Die Software, welche die SRCP-Kommandos an die entsprechende Hardware
(via M*6021-Protokoll oder IB-Protokoll) weiterreicht muss eben auch eine
solche
Refreshliste führen und die Decoderbefehle in geeigneter Weise wiederholt an
die
Signalerzeugende Hardware schicken.


Über den Sinn oder Unsinn einer Authentifizierung im SRCP Protokoll kann man
sicher
Streiten, meines Erachtens ist es aber mit wenig Aufwand realisierbar und
schützt vor
ungewolltem Zugriff auf die SRCP-Server-Ressourcen. Ich denke halt auch an
Szenarien wie:
SRCP-Server steht an der FH-Trier und ich möchte von Zuhause aus (via
Internet) darauf zugreifen
(macht natürlich nur Sinn wenn ich Webcams hab, die mir auch zeigen was ich
mache)
Ich gestehe aber, dass für diesen Kommunikationsweg XRCP fast besser
geeignet wäre, hier
aber eine Authentifizierung unvermeidbar wird ...

MFG

Sebastian