reinweb Posted April 8, 2016 at 01:15 PM Posted April 8, 2016 at 01:15 PM 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 :'( Quote
photron Posted April 8, 2016 at 03:41 PM Posted April 8, 2016 at 03:41 PM 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. Quote
reinweb Posted April 11, 2016 at 11:06 AM Author Posted April 11, 2016 at 11:06 AM hej, stimmt - irgendeinen simplen Getter aufzurufen ist eine optimale Möglichkeit zur Echtzeitprüfung der Verbindung. Danke! Quote
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.