Brickd 2.0 vollständig stateless?

[AuronX]

Hallo,

 

ich meine zwar, dass irgendwo stand, dass es so geplant war, aber zur Sicherheit frage ich nocheinmal nach:

 

der neue brickd wird routing-technisch vollständig stateless arbeiten oder?

Also weder routing-tabellen, noch Merker für die Callback-Zustellung o.ä.

 

Oder gibt es doch State den der brickd sich merken muss? (Die Frage kommt auch daher, dass Planung und Umsetzung ja manchmal divergieren ^^)

 

Viele Grüße

Jan

[photron]

Brick Daemon v2 wird in dem Sinne stateless sein, dass es keine State gibt der zwingend notwendig ist. Du kannst brickd also im laufenden Betrieb neustarten und das ganze funktioniert weiter, es gehen potentiell nur ein paar Packets verloren.

 

Brick Daemon v2 merkt sich immer noch Dinge um effizienter arbeiten zu können. Zum Beispiel merkt er sich (wie ein Switch das auch tut) über welches USB Geräte welche UIDs zu erreichen sind, um gezielt senden zu können. Wenn von TCP/IP Seite ein Packet hereinkommt mit einer UID die brickd nicht kennt, dann wird es an alle USB Geräte gebroadcastet.

 

In die andere Richtung funktioniert das ähnlich. Für über TCP/IP eingehende Packets deren Response Expected Flag gesetzt ist merkt sich brickd, dass an diese TCP/IP Verbindung ein Packet mit der gleichen UID und Sequenznummer zurück gehen wird (im Normalfall). Auch hier wird gebroadcastet wenn von USB ein Packet reinkommt und keine TCP/IP Verbindung darauf wartet.

 

Callback sind hier speziell. Sie haben die Sequenznummer 0, die nur für Callback verwendet wird und werden immer gebroadcastet.

 

Wenn ein USB Gerät abgesteckt wird, dann sendet brickd für alle UIDs die bis zu diesem Zeitpunkt für dieses USB Gerät bekannt waren einen Enumerate Callback mit Disconnected Flag. Dass heißt dann aber auch dass der Enumerate Callback mit Disconnected Flag nicht garantiert werden kann. Wenn niemals mit einer UID kommuniziert wurde oder diese keine Callbacks gesendet hat, dann hat brickd sie nie gesehen und weiss nicht, dass diese zu einem USB Gerät gehört.

 

Alle diese Tabellen werden dynamisch aufgebaut und brickd funktioniert auch ohne sie. In dem Fall wird in beide Richtungen gebroadcastet. Es gibt keinen State in brickd der erst aufgebaut werden muss und dann nicht verloren gehen darf, der für die Kommunikation zwischen TCP/IP und USB nötig wäre. Dass sind alles nur Optimierungen. Abgesehen von der UID-zu-USB Gerät Zuordnung die für den Enumerate Callback mit Disconnected Flag genutzt wird. Das geht hier aber auch nicht besser.

 

Im Gegensatz dazu hatte Brick Daemon v1 sich die Routingtabelle für die Stack IDs gemerkt und auch welche TCP/IP Verbindung welche Callbacks erhält. Beides durfte nicht verloren gehen. Alle diesbezüglichen Probleme gibt es nun nicht mehr.

 

Falls dich C nicht abschreckt kannst du den brickd v2 Code auch schon auf github nachlesen.

[AuronX]

Lesen ist okay, ich schreibe ihn nur ungerne ^^

 

Ich hatte ja damals überlegt einen Brickd zu schreiben der statt USB-Geräten andere brickd's anschließt, um das Problem der mehrfachen IPConnections für diejenigen zu lösen die selbst nur mit einer Verbindung arbeiten wollen. Allerdings war mir das im alten Protokoll zu stressig, da ich es selbst vermutlich nie genutzt hätte. Beim neuen Protokoll scheint das aber sehr leicht realisierbar zu sein.

 

Danke für die Erläuterung.

 

LG

Jan