TCP Verbindung überprüfen OHNE daten zu verschicken

[Guest]

Hallo ich wollte mal fragen ob jemand eine Möglichkeit kennt Serverseitig zu prüfen ob eine TCP Verbindung noch funktionstüchtig ist ohne daten zu schicken.

 

[tuxedo]

Was willst du damit bezwecken? Viele Programme senden diesbezüglich ein "KeepAlive". Damit weiß man dann ob die Verbindung noch da ist.

- Alex

 

[Guest]

ich bin leider gezwungen tcp zu verwenden um den Overhead zu minimieren will ich möglichst selten eine neue Verbindung aufbauen um aber mitzukriegen wann mir ein Client weggebrochen ist muss ich die Verbindung überprüfen. Wenn ich aber den Overhead minimieren möchte dann würde ich spätestens bei im Durchschnitt 5 KeepAlive Paketen pro Verbindung besser fahren wenn ich die Verbindung beende und neu aufbaue. Deswegen suche ich nach Alternativen aber ein Zeitstempel gefällt mir auch net wirklich.

Dariusum

 

[tuxedo]

Wie schnell musst du denn auf einen weggefallenen Client reagieren können?

 

[Guest]

nicht wirklich schnell ist halt um zum einen den Speicherbedarf klein zu halten und zum anderen habe ich einen Aufwand weil ich ja bei allen Sockets schauen muss ob was geschickt wurde was bei vielen "toten" Verbindungen viel Overhead bedeutet.

 

[tuxedo]

wie schnell ist "nicht wirklich schnell" ?
Innerhalb einer Minute? Innerhalb 5min? Innerhalb 30min?

Ein Keep-Alive-Paket muss ja nicht groß sein. Theoretisch reicht ja ein einziges Byte.

Wenn du dann 6mal in der Minute testest (alle 10 Sek.) wären das dann 0,1Byte/Sek .. Von Overhead kann man da nicht wirklich sprechen.

Und wenn eine Verbindung wirklich tot ist, dann gibts auch keinen Overhead. Weil dann gibts nur eine IOException.
Selbst bei 10.000 Clients sollten die 0,1byte/sek kein Thema sein (wären am Server immer noch unter 1kbyte/sek).

- Alex

 

[Guest]

praktisch baut TCP aber auf IP Pakete auf und die haben eine deutlich höhree Minimalgröße und eine neue Verbindung aufzubauen ist auch net so teuer.

 

[tuxedo]

?? Du willst mir erzählen dass ein komplett neuer Socket-Verbindungsaufbau weniger bits in anspruch nimmt als ein einziges TCP/IP Paket mit 1Byte Nutzdaten?

Kann ich nicht ganz glauben. Was für eine "krasse" Anwendung hast du denn die sooooo sparsam arbeiten muss dass 0,1Byte/sek TCP-Nutzdaten zu viel Overhead verbraucht? Selbst zu analogmodem-Zeiten mit 14.00 Baud (bei mir ist das über 10 Jahre her), wären 0,1Byte/s TCP/IP Nutzdaten noch okay gewesen...

- Alex

 

[Guest]

Wenn mich nicht alles täuscht ist die minimallänge 64 Byte was bei einmal pro minute checken 3,75 kByte Daten pro Stunde macht da ich damit rechnen muss da eine Verbindung potentiell mehrere Stunden brachliegen kann um dann wiederbenutzt zu werden und ich Handys als Clients habe führt das bei ihnen zu unnötigen mehrkosten. Eine Alternative wäre halt ein Timer und eine Verbindung nach 10 min oder 1 h brachliegen kicken hätte aber lieber ne elegantere Alternative. Würde mal schätzen das die Pakete die bei einem Verbindungsaufbau verschickt werden auch net größer als 64 Byte sind da passen ja schließlich 44byte Nutzdaten rein und da werden auch nur max 3 Pakete versendet

 

[Guest]

Wenn mich nicht alles täuscht ist die minimallänge 64 Byte was bei einmal pro minute checken 3,75 kByte Daten pro Stunde macht da ich damit rechnen muss da eine Verbindung potentiell mehrere Stunden brachliegen kann um dann wiederbenutzt zu werden und ich Handys als Clients habe führt das bei ihnen zu unnötigen mehrkosten. Eine Alternative wäre halt ein Timer und eine Verbindung nach 10 min oder 1 h brachliegen kicken hätte aber lieber ne elegantere Alternative. Würde mal schätzen das die Pakete die bei einem Verbindungsaufbau verschickt werden auch net größer als 64 Byte sind da passen ja schließlich 44byte Nutzdaten rein und da werden auch nur max 3 Pakete versendet

 

[tuxedo]

Die Provider rechnen meist in 100kbyte-Schritten ab. Da wären 3,75kbyte wohl nicht der rede Wert...

Die Sache mit den Handy's als Client hättest du ja auch gleiuch zu Anfang schreiben können ;-)

Wenn die Cleints mehrere Stunden vor sich hinvegetieren können, dann würde ich auch nicht im Minutenrhytmus prüfen ob der Client noch da ist. Bei Mehreren Stunden sind 15min oder so wohl eher angebracht. Und das würde nach deiner Rechnung nur noch 0,25kbyte/Stunde betragen. Also ein wirklich lächerlicher Wert.

Die Idee mit dem Timer ist keine so schlechter Alternative. Für den Client kannst dud as ja transparent machen: Der kann sich, wenn er ne Stunde inaktiv war und die Verbindung Serverseitig getrennt wurde, stillschweigend wieder einloggen. Geht ja recht fix.
Du könntest auch den Testrhythmus sukzessive verlängern... Zuerst alle 1min, dann nach 15min alle 15min und nach einer Stunde nur noch einmal pro Stunde.

Alles in allem würde ich diese Zwei Dinge kombinieren:

- KeepAlive alle X Minuten (15 wären vermutlich ein guter Anfang wenn man bedenkt dass die Verbindung mehrere Stunden brach liegen darf/kann)
- nach 2h den Server die Verbindung kappen lassen und dem Client die Möglichkeit geben sich sofort und ohne Stress für den Anwender erneut einzuwählen.

Gruß Alex

 

[Dariusum]

also komm ich wohl net herum, schade finde es immer etwas unelegant mit timern und keepalives aver danke für die hilfe