jan Posted August 1, 2013 at 04:24 AM Share Posted August 1, 2013 at 04:24 AM 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 Quote Link to comment Share on other sites More sharing options...
AuronX Posted August 1, 2013 at 07:05 AM Share Posted August 1, 2013 at 07:05 AM 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 Quote Link to comment Share on other sites More sharing options...
photron Posted August 1, 2013 at 07:49 AM Share Posted August 1, 2013 at 07:49 AM 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. Quote Link to comment Share on other sites More sharing options...
AuronX Posted August 1, 2013 at 08:10 AM Share Posted August 1, 2013 at 08:10 AM 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... Quote Link to comment Share on other sites More sharing options...
photron Posted August 1, 2013 at 08:50 AM Share Posted August 1, 2013 at 08:50 AM 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. Quote Link to comment Share on other sites More sharing options...
jan Posted August 1, 2013 at 07:23 PM Author Share Posted August 1, 2013 at 07:23 PM 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 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.