TCP: PingPong

06/05/2010 - 12:46 von Curtis Newton | Report spam
Hallo,

ich habe eine Client/Server-Anwendung, die sich per TCP/IP unterhàlt. Da
bekomme ich ja nicht mit, wenn ein Router zwischen den Rechner klemmt
oder das Gesamtsystem auf der anderen Seite abstürzt. Also höchstens mit
der KEEPALIVE-Option, bei dem aber der Timeout mit ~2h weit über dem
gewünschten liegt.

Nun habe ich schon ein bißchen gegoogelt. Da nimmt man dann wohl sowas
wie jeweils einen zusàtzlichen Thread auf beiden Seiten, die gegenseitig
PingPong spielen. Damit wird überprüft, ob der Rechner auf der anderen
Seite noch erreichbar ist.

Ist das die einzige Möglichkeit, die man hat? Und wie genau macht man
das mit dem PingPong? Ich kann ja z.B. mit select schauen, ob innerhalb
von 5 Sekunden was ankommt. Und wenn nicht, dann? Schießt man dann mit
pthread_cancel einfach den anderen Thread, in dem die eigentliche
Kommunikation làuft, ab? Das sieht mir so unsauber aus.

C.

Bye
 

Lesen sie die antworten

#1 Edzard Egberts
06/05/2010 - 14:55 | Warnen spam
Curtis Newton schrieb:
Client/Server-Anwendung, die sich per TCP/IP unterhàlt. Da
bekomme ich ja nicht mit, wenn ein Router zwischen den Rechner klemmt
oder das Gesamtsystem auf der anderen Seite abstürzt.



Du bist Anwendungsschicht. Die Transportschicht bekommt zwar mit, dass
Pakete verloren gehen (ACK fehlt), reicht das aber nicht weiter.

PingPong spielen.
Ist das die einzige Möglichkeit, die man hat? Und wie genau macht man
das mit dem PingPong? Ich kann ja z.B. mit select schauen, ob innerhalb
von 5 Sekunden was ankommt. Und wenn nicht, dann? Schießt man dann mit
pthread_cancel einfach den anderen Thread, in dem die eigentliche
Kommunikation làuft, ab? Das sieht mir so unsauber aus.



Bei der Anwendungsschicht kommt es auf die Anwendung an, ohne Details
làsst sich da nicht viel sagen. Grundsàtzlich solltest Du IMHO in diesem
Fall die Verbindung als Interface sehen, mit den Funktionen Öffnen,
Schreiben, Lesen, Schließen und die Timeoutkontrolle außerhalb ansiedeln:

Wenn der Server z.B. einen Remote Procedure Call für den Clienten
bedient (Datenbankabfrage oder so etwas), wird der Timer im Client bei
Befehlsausgabe (Schreiben) angeworfen und bei Empfang der Antwort
(Lesen) wieder gestoppt. Bei Timeout wird dann eben die Verbindung
geschlossen. Das spielt sich dann alles im RPC-Interface ab und hier
setzt dann auch die erweiterte Fehlerbearbeitung auf. Der Client soll
möglicherweise nicht einfach beenden, sondern z.B. eine Fehlermeldung
ausgeben und einen erneuten Verbindungsaufbau anbieten, oder auch nicht
direkt bei Timeout schließen, sondern warnen, dass es gerade dauert, das
ist aber alles die Anwendungsseite. Den Server braucht das alles in
diesem Fall nicht zu interessieren, der ràumt dann alle zwei Stunden mal
über KeepAlive tote Leitungen auf, damit sich da nicht zu viel ansammelt.

Bei anderen Anwendungen sind möglicherweise andere Ablàufe erforderlich
und man könnte natürlich auch, wie von Dir angedacht, direkt auf der
"Leitungsebene" den Timeout implementieren, z.B. über blocking read mit
timeout beim Warten auf eine RPC-Antwort. Wie gesagt, halte ich das aber
nicht für empfehlenswert und würde hier sauber trennen.

Ähnliche fragen