IPConnection.get_connection_state

[jan]

Woran erkenne ich - wenn ich "0" bei IPConnection.get_connection_state zurückbekomme - dass die Verbindung komplett zusammengebrochen ist?? Also im Unterschied zur "0" bei "Verbindung verloren und es wird versucht sich neu zu verbinden".

 

Folgender Ablauf (Ausgabe IPConnection.get_connection_state):

1
1
1
1
0 <--- Verbindung verloren
2 <--- automatischer Reconnect inerhalb IPConnection.set_timeout()
1
1
0 <--- Verbindung komplett verloren, IPConnection.set_timeout(): Zeit ist rum
0
0
0

[AuronX]

Ich weiß noch immer nicht was der timeout mit dem Reconnect zu tun haben soll. Da möge TF intervenieren, wenn ich hier Unsinn verbreite, aber der Timeout bezieht sich nur auf die Zeit die vergeht bis ein Getter abbricht und eine TimeoutException wirft anstatt den Rückgabewert zu liefern. Bei 20 Sekunden ist er einfach nur geduldiger.

 

Das Reconnecten zum Stack ist davon vollkommen unabhängig und wird gemacht sobald die Verbindung weg ist, wird aber nicht vom Timeout begrenzt o.ä.

 

Zur Ursprungsfrage: get_auto_reconnect sagt dir, ob grundsätzlich versucht wird die verbindung wieder aufzubauen.

 

Um welche Sprache ging es hier nochmal? Dann würde ich einmal in die BIndings schauen, um zu sehen ob dort das Verhalten ein anderes ist als das was ich aus C# gewohnt bin

[photron]

AuronX, deine Erklärung ist vollständig richtig so. Das ist auch in allen Bindungs so, außer PHP, weil das keine Threads hat und eh etwas abweicht.

 

Verbindungsverlust wird an Fehlern beim Schreiben/Lesen des Sockets erkannt. Wenn Auto-Reconnect erlaubt ist (set_auto_reconnect(true)), dann versucht der Callback-Thread nach dem Ausliefern des Diconnected-Callbacks die Verbindung wieder aufzubauen. Dies tut er solange bis eines der folgenden Ereignisse eintritt:

 

a) die Verbindung wurde wieder aufgebaut

b) disconnect() wurde aufgerufen, Auto-Reconnect wird abgebrochen

c) set_auto_reconnect(false) wurde aufgerufen, Auto-Reconnect wird abgebrochen

 

Es gibt da keine zeitliche Beschränkung, und set_timeout() hat damit nichts zu tun.

[AuronX]

Bleibt die Frage warum die Verbindung nicht zurückkehrt...

 

@jan: Ich glaube gelesen zu haben, dass die Verbindung die du hier betreibst übers Internet läuft. Es handelt sich bei dem fatalen Disconnect nicht zufällig um den 24h-disconnect des ISP? Genauer gesagt der 24h-disconnect des Stapels den du versuchst zu erreichen?

 

Dabei würde sich nämlich dessen IP ändern... wenn du nur per Hostname die Verbindung aufbaust, dann kann ich mir vorstellen (ich weiß es nciht sicher), dass beim Reconnect der Hostname nicht neu aufgelöst wird und somit fortan versucht wird die Verbindung zur falschen IP aufzubauen.

 

Das wäre natürlich nur eine Erklärung wenn sich die IP-Adresse geändert hat...

[photron]

Die Bindings speichern den originale Hostnamen als String und verwenden den beim Reconnect. Wenn da ein Caching-Problem beim Auflösen existiert, wüsste ich nicht wie wir das auf der Ebene der Bindings verbessern sollten.

[jan]

ja, Verbindung übers Internet -> Script läuft auf Server

Host: per DynDNS

Port: fest -> Weiterleitung im Router auf 4223

 

IP im Ethernet-Extension ist static.

-------------

mit ipcon.set_timeout(10) lege ich die Zeit fest, wie lange im Script versucht wird, Werte von Bricklets abzurufen (z.B.: Temp.)  oder zu setzen (z.B.: Relais). Nach dieser Zeit bricht das Script definitv ab:

Traceback (most recent call last):
  File "xyz.py", line 46, in <module>
    temp = t.get_temperature()/100.0
  File "tinkerforge\bricklet_temperature.py", line 92, in get_temperature
    return self.ipcon.send_request(self, BrickletTemperature.FUNCTION_GET_TEMPERATURE, (), '', 'h')
  File "tinkerforge\ip_connection.py", line 874, in send_request
    raise Error(Error.TIMEOUT, msg)
tinkerforge.ip_connection.Error: -1: Did not receive response for function 1 in time