Ich war gerade dabei die Reconnect-Funktionalität in die LabVIEW-Bindings einzubauen und dabei ist mir folgendes aufgefallen:

 

Wenn ich die Phyton-Bindings korrekt verstehen wird bei auftretendem Socket Error in der Receive Loop solange ein Reconnect versucht bis entweder die Connection wieder steht oder der Thread gekillt wurde. Daraus ergeben sich meiner Meinung nach folgende Fragen:

 

1. Hab ich die Funktionsweise des Reconnect an der Stelle überhaupt korrept verstanden?

2. Es erfolgt keine Unterscheidung ob eine Connection zu einem WLAN-Stack besteht oder zu einem brickd mit USB-Stack, korrekt?

3. Wie verhält sich der WLAN-Stack bei Reconnect hinsichtlich der Callbacks?

 

Warum die ganzen Fragen:

 

Da meine WLAN-Extension noch unterwegs ist habe ich das ganze mit dem brickd getestet indem ich einfach den Dienst beendet und erneut gestartet habe. Meine Bindings haben sich auch sauber wieder verbunden nur kommen da natürlich keine Callbacks mehr! Die muss ich, da neue Verbindung zum brickd, ja erneut scharf schalten.

 

Verhalten sich die Phyten,C ... Bindings an der Stelle auch so oder hab ich hier einfach nur was vermurkst?

Reconnect ist für den Fall gedacht, dass die Association der WIFI Extension zum Access Point abreist und die Chance besteht das sie wiederkommt. Dabei tritt dann ein ECONNRESET Fehler (das ist der C Error Code) auf. Daraufhin versucht sich die IP Connection neu zu verbinden. Abgesehen von ein Paar Timeouts ist das für den Benutzer der API transparent.

 

Das da nicht zwischen brickd und WIFI unterschieden wird liegt daran, dass die IP Connection das nicht unterscheiden kann. Das Protokoll ist dahingehend transparent.

 

Dein Problem mit brickd ist, dass Callbacks nicht automatisch an alle ausgeliefert werden, sondern nur an die die es potentiell interesiert. Wer das ist erkennt brickd an den GetStackID Aufrufen. Wenn du brickd jetzt neustartest hat er das vergessen. Die Bricks versenden immer noch Callbacks nur stellt sie brickd nicht mehr zu.

 

http://www.tinkerforge.com/doc/Low_Level_Protocols/TCPIP.html#callbacks

 

Daher ist brickd hier ein schlechter Test für Reconnect. Bei der WIFI Extension passiert das nicht

Dann stellt sicher meiner Meinung nach die Frage was passiert wenn man einen entfernten brickd abfragt und die Connection stirbt. Reconnected die IP Connection dann automatisch und wir haben geschildertes Problem? Sobald der brickd mal nicht lokal läuft wäre das ja vorstellbar.

Ja, genau das passiert dann. Der Unterschied bei der WIFI Extension ist, dass diese Callbacks immer an alle verschickt.

Ist das nicht als problematisch einzustufen? Es ist dann ggf. ja möglich das ein Anwendungsprogramm, was primär Callbacks nutzt, zwar eine aktive Verbindung hat aber keine Daten mehr bekommt und hierbei, bei periodischen Callbacks, nichtmal unterscheiden kann ob nun einfach ein Reconnect zum entfernten brickd stattgefunden hat oder einfach die Werte sich nicht geändert haben (da wird ja dann auch keine Callback geschickt).

Krass... da gebe ich Holy vollkommen recht, das ist furchtbar. Insbesondere weil die Bindings den reconnect ja transparent gestalten. Ich bemerke nichtmal, dass es ab jetzt kaputt ist.

Der reconnect sollte nur auftreten wenn die Verbindung gewaltsam getrennt wird.

 

Die einzige alternative wäre hier, die Callbacks immer an alle Sockets zu schicken. Das ist auf dem PC vermutlich ziemlich egal. Auf dem Raspberry PI macht das aber z.B. einen riesen Unterschied!

Über einen langen Zeitraum kann jede Connection wegsterben.

Ich denke man muss das nicht zwingend in der API handhaben. Wenn man z.B. auslesen könnte ob die Connection automatisch reconnected wurde könnte die Anwendung entsprechend die Callbacks neu setzen.

Eine andere Variante wäre sicher eine Art Session einzuführen. Die bei einem Connect vom brickd an den Client mitgeteilt wird und er beim reconnect auf diese Session reconnecten kann. Wäre aber denke ich problematisch da Protokolländerung, mal abgesehen vom Aufwand in den Bindings und dem brickd.

Also für alle nicht-Nutzer der WLAN-Extension hilft es ja schon den Reconnect abschalten zu können. Dann kann ich mich da selsbt drum kümmern.

Ansonsten teile ich Holys Vorschlag, dass es zumindest in der API signalisiert werden sollte. Exceptions, Status-Flags, Events...

Ich habe gestern abend schon drüber nachgedacht, da kam mir aber die Idee des Events (Callbacks) nicht. Möglicherweise wäre das die Beste Lösung. Weil Exceptions scheren sich nicht darum, ob es den Nutzer interessiert und das Status-Flag ist zu passiv... Man müsste es pollen.

Callbacks könnte es zwei geben: ConnectionLost und Reconnected. Der erste wird nach Verlust der Verbindung ausgelöst, der zweite wenn sie wieder da ist.

 

LG

Jan

Mit dem neuen Protokoll wird das Erstellen der Socketverbindung etwas anders. Daraus ergibt sich, dass die IPConnection dann connect und disconnect Funktionen bekommt, das Autoreconnect einstellbar wird und dem Benutzer über connected und disconnected Callbacks der Zustand der Verbindung mitgeteilt wird.

 

http://www.tinkerforge.com/doc/Protocol_20.html#connection-handling