Socket#Verbindungsende feststellen

[NetProb]

Hallo!

Ich bin dabei eine Client-Server Anwendung zu schreiben, bin auch schon soweit das zwischen Server und Clients eine Socket-Verbindung zustande kommt und ich Daten austauschen kann.
Der Server ist so programmiert das bei einer Verbindungsanfrage ein Thread gestartet wird, der den Datenaustausch mit dem Client übernimmt.

Das Problem:
Der Thread stoppt nicht wenn der Client die Verbindung schliesst. Als Abbruchkriterium habe ich die Methode isInputShutdown() der Socket-Klasse verwendet. Nach ein wenig Recherche mit google musste ich aber lesen, dass diese nur dann true liefert, wenn quasi vom eigenem Programm die Methode shutdownInput() aufgerufen wird. :?

Nun meine Frage: Wie kann ich feststellen das die Verbdung zum Client unterbrochen wurde?

Ich hoffe ihr wisst da Rat, danke schon mal im vorraus.

 

[Maeher]

Woran soll es denn der Server merken können?
Wenn du normalerweiße ein bisschen Netzwerk-Ping-Pong spielst, kannst du einfach 'nen Timeout definieren der zurückgesetzt wird, wenn ein Packet ankommt (d.h. neu anfangen zu zählen).
Du kannst natürlich auch (zumindest zusätzlich) versuchen, den Client irgendeine Nachricht abschicken zu lassen, die dann bei dir das Schließen der Verbindung auslöst. Das setzt allerdings voraus, dass dieser bei funktionierender Verbindung ordentlich geschlossen wird.

 

[Escorter]

am besten machst du eine mischung aus beidem. und du musst auch bedenken, dass der client bei bestehender verbindung immer wieder mal ne nachricht senden muss, da sonst der timeout die verbindung trennt.

 

[tuxedo]

Du hast doch Input und OutputStreams...
Wenn ein InputStream abreißt weil eine Verbindung nicht mehr da ist, wird bei read() -1 zurückgegeben. Und/oder es gibt eine IOException.

Damit lässt sich das bestens abfangen. Hab im übrigen noch keine IOException gesehen nach der die Verbindung noch benutzbar war.

- Alex

 

[NetProb]

Danke für eure Antworten.

Leider alles keine sehr eleganten Lösungen :cry: , hatte eher auf eine geheime Methode in einem sehr verstecktem Paket gehofft 🙂

Aber na gut habe euer Vorschläge mal umgesetzt. Mit dem Netz-PingPong konnte ich folgenden Effekt erzielen: Beim schreiben auf dem OutputStream fliegt 'ne SocketException (Spezieller Typ von IOException) mit folgenden Möglichen Nachrichten:

Connection reset by peer: socket write error (Bei einem ServerSocket)
Software caused connection abort: socket write error (Bei einem einfachem Socket)
Software caused connection abort: recv failed (Die tritt beim lesen auf, kommt ab und zu auch mal)

Die Exceptions mit diesen Nachrichten fange ich ab und ignoriere sie einfach, bei alle anderen Exceptions gebe ich den StackTrace aus.

Die komplette Schleife in der gelesen/geschrieben wird, liegt in dem try catch block, d.h. wenn nun eine der Exceptions auftritt bin ich aus der Endlosschleife raus und kann alle Sockets/Streams schliessen und den Thread beenden.

@alex0801

...wird bei read() -1...

Joar da haste recht, dass habe ich aber bewusst vermieden, in dem ich vorher mit available() nachsehe ob es überhaupt was zu lesen gibt.

Naja Ente gut, alles gut 😀
Danke nochmal für eure Hilfe.

 

[tuxedo]

>> Joar da haste recht, dass habe ich aber bewusst vermieden, in dem ich vorher mit available() nachsehe ob es überhaupt was zu lesen gibt.

Das entspricht aber nicht so ganz dem Sinne des blockierenden Stream-Ansatzes in der "normalen" Java Socketkommunikation. Hab das Thema schon hier diskutiert. Bei vielen Verbindungen kann es durchaus performanter sein allein das 'eh schon blockierende read() zu verwenden und "available()" komplett weg zu lassen. Einen "Vorteil" hast du durch die Verwendung von available() jedenfalls nicht wirklich. Eher einen "Nachteil".

- Alex