Geschrieben April 8, 2016 at 13:158. Apr 2016 soweit ich das durchblicke, gibt die Funktion IpConnection->getConnectionState nur den zuletzt gesetzten Wert der Klassenvariable zurück und führt keinen aktuellen Test durch. die Funktion IpConnection->receive führt regelmässig eine tatsächliche DisconnectProbe durch. Würde es Sinn machen, diese Echtzeit-ConnectionState Funktion von aussen aufrufbar zu machen (z.B. als IpConnection->getCurrentConnectionState()? dann erkennt man den ConnectionVerlust sofort und nicht erst nach diesem DISCONNECT_PROBE_INTERVAL Timeout? (Meine Frage steht in Zusammenhang mit meinem WLAN-Verbindungsproblem, was ich in meinem vorigen Thread beschrieben habe...) - das bringt mich nämlich ECHT ZUR VERZWEIFLUNG :'(
Geschrieben April 8, 2016 at 15:418. Apr 2016 TCP/IP funktioniert so leider nicht. Und auch das Disconnect Probe hilft da leider nicht so richtig. Was unserem TCP/IP Protokoll momentan fehlt ist ein richtiger Heartbeat um Verbindungsverlust in beide Richtungen zu erkennen. getConnectionState() sagt dir ob die TCP/IP Verbindung besteht. Das hat allerdings nicht damit zu tun ob du gerade auch Daten übertragen kannst, bzw. ob eine WLAN Verbindung besteht. TCP/IP ist absichtlich so entworfen worden, dass zwischendurch auch mal keine Daten übertragen werden können, weil die unterliegende Verbindung wie z.B. WLAN gerade nicht besteht. Deine " Echtzeit-ConnectionState Funktion" gibt es schon. du kannst einfach anstatt getConnectionState() abzufragen irgendeinen Getter aufrufen. Wenn dieser einen Timeout liefert, dann besteht die WLAN Verbindung gerade nicht.
Geschrieben April 11, 2016 at 11:0611. Apr 2016 Autor hej, stimmt - irgendeinen simplen Getter aufzurufen ist eine optimale Möglichkeit zur Echtzeitprüfung der Verbindung. Danke!
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.