Socket Server: ConnectionError vom Client erkennen

S

Stroker89

Bekanntes Mitglied
Hallo,

Meine Client-Server Anwendung läuft über Sockets (Thread per Client).
Daten werden mit ObjectStreams verschickt und empfangen.
Wenn der Client ordnungsgemäß die Verbindung schließt, fliegt auf dem Server eine Exception, die dann dem entsprechend behandelt werden kann und die Threads sich schön sauber beenden.

Wenn allerdings die Verbindung abbricht (zum Testen schalte ich einfach mal das WLAN ab), merkt der Server überhaupt nichts davon. Die Threads bleiben offen und er versucht weiter Daten zu empfangen.

Wie kann ich dieses Problem lösen?

Gruß
 
Zuletzt bearbeitet:
1. gar nicht

2. mit Time-Outs: "wenn du in 10s nicht antwortest mach ich zu"

3. mit "Bist du noch da"-Pings

hängt von deiner Anwendung ab
 
Stroker89 hat gesagt.:
Hallo,

Wie kann ich dieses Problem lösen?

Gruß
Zum Vergrößern anklicken....

Es gibt gute APIs, die dir die Arbeit in den Niederungen der Verbindung abnehmen. Damit kann man sich dann auf die eigentliche Problemaktik konzentrieren. Verbindungsmonitoring, verwendetes Protokoll usw. sind konfigurierbar. Schau dich mal ein wenig um, z.B. bei JBoss Remoting, Apache Mina oder Netty.
 
Leider muss ich Raw-Sockets verwenden. Kommuniziert wird über ein eigenes XML-Protocol. Ja ich weiß, dass das nicht das tollste ist, aber leider ist das die Anforderung...

Gruß
 
moment mal ...

wenn man die verbindung sauber trennt fliegt ne exception ? also alleine DAS kann schon nicht richtig sein ... das ist missbrauch von exceptions und sollte vermieden werden ... poste mal code ...

und bei abbruch passiert "nix" ? ... kann ich mir nicht vorstellen ... irgendwann fliegt da was ... zeig mal code ...
 
Wenn man mit in.readObject auf ankommende Nachrichten wartet und der Client schließt die Verbindung (sauber), dann fliegt die IOException. Ich fand das am Anfang auch recht komisch, aber nach langem suchem im Netz, fand ich herraus, dass das wohl normal sei...

Wenn nicht dann verbessere mich bitte. Ich lerne gerne dazu 🙂

Server: sehr stark gekürzt!

Daten werden in der While in einen Queue gesteckt, der dann widerrum von einem anderen Thread ausgelesen wird.

Java: 
public void run() {
		try{
		    out = new ObjectOutputStream(this.clientSocket.getOutputStream();
		    in = new ObjectInputStream(this.clientSocket.getInputStream());
			
		    String strInput = null;

	        while((strInput = (String) in.readObject()) != null){
				sendQueueMessage(strInput);
		    }	
		} catch (IOException e) {
			try {
				out.close();
				in.close();
				this.clientSocket.close();
			} catch (IOException e1) {
				e1.printStackTrace();
			}
		} catch (ClassNotFoundException e) {
			e.printStackTrace();
		}
		
	}
 
ähm nein .. das ist ganz und gar nicht normal ..

ein SAUBERER verbindungsabbu würde in etwa so aussehen

Java: 
public void run()
	{
		try
		{
			in=new BufferedReader(new InputStreamReader(socket.getInputStream()));
			out=new PrintStream(socket.getOutputStream());
		}
		catch(Exception e)
		{
			System.out.println("cant get client-streams");
			e.printStackTrace();
			return;
		}
		String line="";
		while(true)
		{
			try
			{
				line=in.readLine();
				if(line==null)
				{
					break;
				}
				if(line.equals(""))
				{
					continue;
				}
				if(line.equals("DC"))
				{
					break;
				}
				server.broadcast(line);
			}
			catch(Exception e)
			{
				System.out.println("failed to read message");
				e.printStackTrace();
			}
		}
		try
		{
			in.close();
			out.close();
			socket.close();
		}
		catch(Exception e)
		{
			System.out.println("cant close streams/socket");
			e.printStackTrace();
		}
		server.disconnect(this);
	}
der server sollte also erstmal gucken was in dem objekt drin steht bevor er es einfach in ne liste steckt und sich nicht weiter drum kümmert ...
und der client sollte dann beim sauberen trennen ein objekt schicken was dem server sagt : endlos-loop beenden und kein erneutes read() sowie trennen der verbindung ...

DAS wäre ein SAUBERER verbindungsabbau ...

das was du da hast ist exception-missbrauch ...

und das bei "abgerissener" verbindung gar nichts passiert kann man beheben in dem man mit timeout arbeitet ... sieht dann so aus

Java: 
public void run()
			{
				while(true)
				{
					try
					{
						Socket client=serverSocket.accept();
						client.setSoTimeout(2000);
						ClientRunnable clientRunnable=new ClientRunnable(server, client);
						(new Thread(clientRunnable)).start();
						clients.add(clientRunnable);
					}
					catch(Exception e)
					{
						System.out.println("failed to accept client");
						e.printStackTrace();
					}
				}
			}

ein timeout von 2sec sollte reichen ... kann nach belieben angepasst werden ...
mit timeout fliegt dann nämlich definitiv ne IOException ...
 
Bei nem InputStreamReader schaut die ganze sache auch schon wieder anders aus.
Das hatte ich vorher und hat auch genau so funktioniert wie du es sagst.

Ich möchte aber ObjectStreams benutzen und da ist es so wie ich es beschrieben hab.

Kannst es ja gerne probieren.

Danke für deinen Code.

Gruß
 
Zuletzt bearbeitet:
Ok das mit dem der "Close"-Nachricht vom Client hört sich sehr gut an.
Ich war es nur gewohnt, dass bei einem read auf einen "normalen" InputStream schön von selber aus der while-Schleife beendet wird, sobald der Client den Stream Schließt.
Bei einem ObjectStream ist das nicht der Fall, somit ist die Lösung mit der "Close"-Nachricht wohl das "sauberste".

Ham wa wieder was gelernt 🙂

Schade das überall anders einem was falsches erzählt wird...

Aber Danke für die tolle Aufklärung 🙂

Gruß
 
FArt hat gesagt.:
Es gibt gute APIs, die dir die Arbeit in den Niederungen der Verbindung abnehmen. Damit kann man sich dann auf die eigentliche Problemaktik konzentrieren. Verbindungsmonitoring, verwendetes Protokoll usw. sind konfigurierbar. Schau dich mal ein wenig um, z.B. bei JBoss Remoting, Apache Mina oder Netty.
Zum Vergrößern anklicken....

Wenn er nach mehreren Wochen Einarbeitung die APIs verstanden hat wird er feststellen, dass die auch nur ServerSocket#setSoTimeout(int miliseconds) setzen 🙂

Bernd
 
Stroker89 hat gesagt.:
Naja ich find es auch mal nicht schlecht "ganz unten" zu programmieren. Da lernt man gute APIs zu schätzen 🙂
Zum Vergrößern anklicken....

"Ganz unten" ist gut - Du bist bei ServerSocket schon Meilenweit von den Innereien des TCP/IP-Stacks wech 😀

Bei vielen APIs (oder besser gesagt Toolboxen) werden Dreizeiler schon als Innovation angepriesen. Gerade im Apache-Fundus ("Begrabt meinen Code an der Biegung des Flusses") ist an den unpassensten Stellen Zeug dabei, was schon seit Jahren nicht mehr gepflegt wird. Da sollte man in den Source schauen und überlegen ob es sich lohnt den gesamten Berg an Abhängigkeiten einzubinden.

Bernd
 
Das ist mir schon klar 😀 ich meinte damit auch nicht, dass ich hier auf Protokollebene bin sondern was man halt in Java eben als "Unten" nennen kann 😀

Hab nicht vor nen Übertragungsprotokoll nachzubilden 😀

Gruß
 
Zuletzt bearbeitet:
also ich arbeite eigentlich so gut wie nie mit ObjectStream ... aber intern wird irgendwo "native InputStream.read0()" gecallt ... und diese methode wirft die IOException ... egal was da oben drauf sitzt ...
 
Bernd Hohmann hat gesagt.:
Wenn er nach mehreren Wochen Einarbeitung die APIs verstanden hat wird er feststellen, dass die auch nur ServerSocket#setSoTimeout(int miliseconds) setzen 🙂

Bernd
Zum Vergrößern anklicken....

Das ist m.E. beides so nicht richtig.

Die Einarbeitung ist für ausreichend ausgebildete Entwickler sehr gering, die Lernkurve nicht sehr hoch, besonders wenn sie mit Netzwerkkommunikation auf Socketebene bereits Erfahrung haben.

Nur das Setzen von soTimeout bringt einen nicht viel weiter. Interessanter ist die Fehlerfallbehandlung. Die kann (wenn das ganze sauber funktionieren soll) sehr aufwendig werden. Wenn ich frühzeitig Netzwerkabbrüche erkennen möchte (bevor aktiv Nutzlast gesendet wird) und evtl. ein kurzzeitiger Verbindungsabbruch ohne Fehlermeldungen geheilt werden soll, dann nutze ich lieber eine API, die das schon bietet. Ebenso verhält es sich, wenn ich mehrere Protokolle für die Kommunikation anbieten muss oder möchte und/oder wenn ich vieles davon (und auch noch andere Sachen) nicht programmatisch sonder konfigurierbar haben möchte.
 
Bernd Hohmann hat gesagt.:
"Ganz unten" ist gut - Du bist bei ServerSocket schon Meilenweit von den Innereien des TCP/IP-Stacks wech 😀

Bei vielen APIs (oder besser gesagt Toolboxen) werden Dreizeiler schon als Innovation angepriesen. Gerade im Apache-Fundus ("Begrabt meinen Code an der Biegung des Flusses") ist an den unpassensten Stellen Zeug dabei, was schon seit Jahren nicht mehr gepflegt wird. Da sollte man in den Source schauen und überlegen ob es sich lohnt den gesamten Berg an Abhängigkeiten einzubinden.

Bernd
Zum Vergrößern anklicken....

Troztdem ist es m.E. ein falscher Ansatz, bewährte APIs und Implementierunge nur wegen der Abhängigkeiten nicht zu verwenden. Der Entwicklungs-, Weiterentwicklungs- und Wartungsaufwand einer Eigenentwicklung sollte dagegengerechnet werden.

Meine Erfahrung sagt, dass die Kosten auch hier exponentiell wachsen und sich eine Eigenentwicklung selten rechnet. In der Regel nur für sehr einfach gehaltene Systeme.

Eine Implementierung wie die von Apache wird nicht mehr gepflegt, wenn sie nicht mehr verwendet wird. Wer sie verwendet, darf gerne seine eigenen Ideen darin umsetzen und der Gemeinschaft zur Verfügung stellen. Hier hat man dann seine Eigenimplementierung, aber mit Feedback und Support durch die Community.
 
ich bin aber auch gegen große "libs" ... denn viele verlangen wie gesagt eine unzahl an abhängigkeiten die man so in seinem projekt vielleicht gar nicht haben will / nutzen möchte ...

hinzu kommt noch das man ein gutes build-tool braucht um versionskonflikte aufzulösen .. was ja auch gerne mal ne stolperfalle ist ...

und wenn halt z.b. code nicht mehr gepflegt wird weil der entwickler der meinung ist das dieser nicht mehr gebraucht wird sollte man ihn komplett aus der main-distribution entfernen und zusammen mit seinen abhängigkeiten entweder als eigene lib oder in eine art "legacy"-pack stecken was dann wahlweise zur aktuellen main-distribution zusätzlich eingebunden werden kann ... aber einfach legacy-code in der lib belassen ... und dann am besten nicht mal als "deprecated" makieren ... DAS ist meiner meinung nach viel unverantwortlicher als wenn man sich den aufwand machen würde und sich nur das nötige aus der lib rauskramt ...

das beste beispiel ist doch eigentlich logging : jede lib schleppt ihre eigene logging-abhängigkeit mit ... mag ja auch für alles v6 und abwärts sinnvoll sein ... aber man sollte auch mal aktuelle v7+ versionen rausbringen die die in der SE-api vorhandene logging-struktur nutzen ...
nicht nur das man dmit versions- und kompatibilitäts-probleme lösen könnte ... sondern den overhead um die lib ans laufen zu bekommen deutlich minimieren könnte ...


und gerade für anfänger ... sei es allgemein oder nur auf einem bestimmten teilgebiet ... finde ich es persönlich nicht gerade positiv diese immer gleich mit ner tonne an libs und großen IDEs vollzuquatschen anstatt ihnen zeit zu geben die grundlagen "zu fuß" ohne IDE und ohne 3rd-party-libs zu lernen ... denn es bringt einem nichts wenn man zwar das ergebnis hat aber nicht versteht was intern abläuft weil man es nicht weis ...
 
Ja, das ist nicht von der Hand zu weisen.

tröööt hat gesagt.:
und gerade für anfänger ... sei es allgemein oder nur auf einem bestimmten teilgebiet ... finde ich es persönlich nicht gerade positiv diese immer gleich mit ner tonne an libs und großen IDEs vollzuquatschen anstatt ihnen zeit zu geben die grundlagen "zu fuß" ohne IDE und ohne 3rd-party-libs zu lernen ... denn es bringt einem nichts wenn man zwar das ergebnis hat aber nicht versteht was intern abläuft weil man es nicht weis ...
Zum Vergrößern anklicken....

Hier muss man aber grundsätzlich unterscheiden, ob das zu Lernzwecken gemacht wird oder ob hier produktiver Code entsteht. Zweiteres hat oft fatale Folgen ... in der Regel nicht zur Entwicklungszeit und auch nicht in der QS.
 
FArt hat gesagt.:
Wenn ich frühzeitig Netzwerkabbrüche erkennen möchte (bevor aktiv Nutzlast gesendet wird) und evtl. ein kurzzeitiger Verbindungsabbruch ohne Fehlermeldungen geheilt werden soll, dann nutze ich lieber eine API, die das schon bietet.
Zum Vergrößern anklicken....

Nennt sich TCP/IP und ist in Plain-Java schon seit 1.1 "implementiert".

Aber wenn Du sowas wie RFC3093 benötigst sei es Dir unbenommen :bloed:
 
@Bernd
darauf war ja auch meine antwort bezogen das dies bereits durch TCP selbst implementiert ist und in der native read() methode so oder so zu ner exception führen müsste ... wenn ObjectStream diese allerdings einfach schluckt und somit SoTimeout "wirkungslos" macht müsste man das noch mal genauer untersuchen und eventuell als BUG melden ...
 
tröööt hat gesagt.:
@Bernd
darauf war ja auch meine antwort bezogen das dies bereits durch TCP selbst implementiert ist und in der native read() methode so oder so zu ner exception führen müsste ... wenn ObjectStream diese allerdings einfach schluckt und somit SoTimeout "wirkungslos" macht müsste man das noch mal genauer untersuchen und eventuell als BUG melden ...
Zum Vergrößern anklicken....

Das muss dann aber ein frischer Bug sein. Als ich das letzte Mal (Java 1.2 oder 1.3) was damit gemacht habe wurden Timeouts auch in den Object- bzw. darin liegenden Data-Streams ordentlich nach oben durchgereicht.

@TO zum Verständnis: Ein .close() auf den Stream wird bei TCP/IP über die gesamte Strecke signalisiert. Wenn die Verbindung aus anderen Gründen abbricht (Router kaputt oder Du schaltest WLAN aus) ODER es werden schlichtweg keine Daten gesendet, dann bestimmt der Socket-Timeout wann eine Exception geworfen wird.

Zeitnaher kannst Du eine kaputte Übertragungsstrecke erkennen wenn Du am Socket das "keep-alive"-Flag setzt. Dann sendet der Stack selber sporadisch ein Datenpaket und wartet auf Antwort. Das hat den Vorteil, dass auch inaktive Verbindungen nicht in ein Timeout laufen und Verbindungsabbrüche schneller erkannt werden.

Damit erkennst Du allerdings nicht, ob die Applikation auf der anderen Seite noch lebt. Typischer Fall: der Socket wird aufgemacht und dann ein Verarbeitungs-Endlosthread gestartet der wegen Fehler aus run() herausfällt. Dann ist der Socket zwar noch da, aber niemand interessiert sich dafür. Für sowas sendet man selber sporadisch einen Datensatz der von der Applikation auf der Gegenseite quittiert werden muss. Dafür gibts bestimmt im Netz sowas wie einen Heartbeat-Socket, aber die 5 Zeilen kann man auch selber programmieren wenn man Lust hat.

Siehe auch socket : Java Glossary

Bernd
 
@Bernd
naja ... TO beschreibt ja nur das halt "nichts passiert" wenn er es so wie er hat ausführt ... ob "setSoTimeout()" etwas daran geändert hat hat er ja noch nicht geschrieben ... wesshalb ich mal von ausgegangen bin das ObjectInputStream hier etwas verschlucken könnte ...
kann ich mir zwar nicht vorstellen ... aber von TO kam ja weder ein änderungs-versuch noch ein feedback
 
Ich hab hier schon eifrig eure Diskussion mitverfolgt, keine Angst 🙂.
Fest steht, dass ObjectInputStream anders auf ein Disconnect reagiert als ein BufferedReader.
Nämlich mit einer EndOfFileException.

Der Vorschlag mit dem KeepAlive auf der ClientSeite und dem SocketTimeout ist natürlich schonmal nicht schlecht, da man somit abgeschmierte Verbindungen auf der Serverseite recht Zeitnah verwerfen kann und somit die dazu gehörigen Threads schließen kann. Dann lungern die nicht die ganze Zeit unbenutzt auf dem Server rum.

Was spricht denn generell dagegen auf diese EOFException zu reagieren und den Socket und die Stream zu zu machen?

Gruß
 
Stroker89 hat gesagt.:
Was spricht denn generell dagegen auf diese EOFException zu reagieren und den Socket und die Stream zu zu machen?
Zum Vergrößern anklicken....

Ich hab mal grob durch die Sourcen der Runtime geschaut: soweit wie ich das sehe wird die EOFException genauso wie eine IOException geworfen. Der Kommentar zur EOFException sagt "This exception is mainly used by data input streams to signal end of stream."

Passt also.

Bernd

PS: Was die EOFException allerdings im RandomAccessFile zu suchen hat erschliesst sich mir nicht.
 
nillehammer hat gesagt.:
Ich würde schätzen, dass sie geworfen wird, wenn man durch ungeschicktes read über das Ende des Files hinauslesen würde. Ok, ich hab in der Doku (RandomAccessFile.html#read(byte[], int, int)) gelinst 😉
Zum Vergrößern anklicken....

Eben das ist in einem Random-Access File nicht möglich (war schon zu DOS-Zeiten so). Wenn man "hinter" der Datei liest, bekommt man einfach -1 als "anzahl gelesene bytes" zurück (oder im alten BASIC den Datenmüll, der gerade an dieser Stelle auf der Platte herumlag). Darum war ich da jetzt etwas verwundert ???:L

Java: 
import java.io.*;

public class RandomAccess {

	public static void main(String[] args) throws Throwable {

		File flDummy = new File("dummy");
		byte buffer[] = new byte[20];
		int i;

		RandomAccessFile raf = new RandomAccessFile(flDummy, "rw");

		raf.seek(100);
		i = raf.read(buffer, 0, buffer.length);
		System.out.println("1 Read: " + i + "bytes");

		raf.seek(100);
		raf.write(buffer);

		raf.seek(100);
		i = raf.read(buffer, 0, buffer.length);
		System.out.println("2 Read: " + i + "bytes");

		raf.close();
		flDummy.delete();
	}
}
 
Stroker89 hat gesagt.:
Was spricht denn generell dagegen auf diese EOFException zu reagieren und den Socket und die Stream zu zu machen?
Zum Vergrößern anklicken....
die tatsache das man sich , wenn man es SAUBER macht , nicht um irgendwelche Exceptions kümmern muss ... weil man eben die möglichkeit hat einen SAUBEREN verbindungsabbau von der jeweiligen seite die die verbindung beenden möchte VORHER sauber dem gegenüber zu signalisieren was darauf dann entsprechend SAUBER reagieren kann ...
Stroker89 hat gesagt.:
Also ist das in dem fall kein Exception-Missbrauch?
Zum Vergrößern anklicken....
in meinen augen ist es das schon ...

ich versuch dir mal meine sich von "exception-missbrauch" an hand dieses beispiels hier zu erklären


FALL 1 : abbruch mit exception

der client will die verbindung trennen ... und macht dazu das einfachste der welt : die verbindung "gewaltsam abwürgen" ...
die probleme die hierbei entstehen können ist das es die tiefer liegenden netzwerkschichten so nicht ganz begreifen um entsprechend dem protokoll der gegenseite eben dieses "gewaltsame abwürgen" der verbindung zu signalisieren ...
falls das funktioniert kann man auf der gegenseite noch mit ner fehlermeldung "rausspringen" ... muss dann aber seinen code so anpassen das irgendwie in jedem fall noch versucht wird irgendwas aufzuräumen ... falls man hier nicht genau so mit offenen resourcen umgeht ... was zu einer kettenreaktion führen kann die das gesamte programm abstürzen lassen kann ..
versagen eingebaute sicherheitsmechanismen jedoch bleibt viel an ungenutzen resourcen offen und gesperrt ... bedeutet höhere system-auslastung und deadlocks ...

EXCEPTIONs bedueten das ein FEHLER aufgetreten ist ... "checked" exceptions sind dabei fehler auf die man reagieren MUSS ... "unchecked" exceptions ... also RuntimeException und alles was davon erbt sind die sog. "unerwarteten Fehler" ... die meist schwere systemschäden zur folge haben ...

folgend dieser beschreibung darf man exceptions wirklich nur für fehlerfälle nutzen ... also wenn halt eine verbindung "abreist" ... und nicht von einem der beiden seiten "gewaltsam abgewürgt" wird ...


FALL 2 : sauberer abbau mit signalisierung

der client will wie oben wieder die verbindung trennen ... schickt dem server aber vorher erstmal eine nachricht : "hey, du, ich will die verbindung trennen" ...
der server reagiert auf diese nachricht und prüft erstmal ob dieser vorgang jetzt gerade im momment überhaupt zulässig ist ... oder ob der client noch in einer transaktion hängt für die er benötigt wird und die verbindung daher nach möglichkeit nicht trennen sollte ...
das ergebnis dieser auswertung kann dann wieder zum client geschickt werden der dies auswerten kann um darauf zu reagieren ... und falls halt noch daten zu senden sind diese liefern oder daten vom server noch verarbeiten und speichern ...
nach dem nun beide seiten sich auf die freigabe der verbindung geeinigt haben beginnen sie gegenseitig ihre resourcen freizugeben und die kommunikations-kanäle zu schließen ... und zum schluss die socket-verbindung sauber zu trennen ...

im einfachsten fall sieht das dann so aus das der client zum server sagt : "trennen" ... der server antwortet : "ok" ... und beide dann einfach auf die streams und den socket "close()" callen ...

der vorteil liegt auf der hand : beide seiten können der anderen noch sagen das der verbindungsabbau zur zeit eventuell noch ungüstig ist oder halt noch die letzten daten senden ...
außerdem können resourcen sauber aufgeräumt und wieder an das system freigegeben werden ... vorrausgesetzt man geht mit seinen resourcen gewissenhaft um ...


und genau DIESEN unterschied bezeichne ich als "exception-missbrauch" ... da ein "fehlerfall" dafür "missbraucht" wird einen "gewollten zustand" zu signalisieren ...

bestes beispiel stellen eigentlich alle read-operationen dar : es kommt einfach "-1" zurück wenn der stream zu ende ist ... eine EOF(EndOfFile)Exception sollte (und wird) nur dann geworfen wenn der datenstrom früher als angenommen zuende ist ... wobei sich die entwickler keine mühe gemacht haben EndOfFile und EndOfStream zu unterscheiden ...

ich hoffe ich konnte dir das problem etwas näher bringen ...


was mich allerdings immer noch wundert ist das bei dir "ObjectInputStream.readObject()" NICHT auf "Socket.setSoTimeout()" reagiert ... denn genau das sollte es eigentlich und wie bernd und ich schon sagten eingentlich eine IOException werfen ... das ist auf jeden fall was für den bug-tracker
 
Hast schon Recht! Aber diese AUSNAHME signalisiert ja nur, dass auf dem Stream nichts mehr zu lesen ist...man könnte wenn man die Close Nachrichten hin und her schickt lediglich alle "fehlerhaften bzw. erzwungenen" Verbindungsabbrüche erkennen. Was mich momentan aber Recht wenig auf Serverseite recht wenig interessiert, da in beiden Fällen alle Ressourcen wieder frei gegeben wird.

Aber trotzdem werde ich die Nachrichten einbauen. Gleichzeitig werde ich den Code aber auch in dem Catch-Block lassen, denn selbst wenn die Verbindung "fehlerhaft" abbricht, soll der Socket ja zu gemacht werden.

Gruß
 
Stroker89 hat gesagt.:
Aber diese AUSNAHME signalisiert ja nur, dass auf dem Stream nichts mehr zu lesen ist
Zum Vergrößern anklicken....

du hast meine aussage nicht verstanden ...

auch wenn bestimmte exceptions mit unter einen solchen sinn haben ... ist dies jedoch meist nur eine zusatzinfo WARUM überhaupt diese ausnahme ausgelöst wurde ... aber das auslösen einer exception ist und bleibt immer ein FEHLER ... und da ist es völlig gleich ob man aus der FEHLER-nachricht den grund rauslesen kann und entsprechend reagiert ... FEHLER bleibt FEHLER ... und das widerspricht halt einem "sauberen verbindungabbau" ... sondern ist nur eine verbindungsstörung ...

und desshalb signalisiert diese ausnahme eben nicht "nur" das auf dem stream nichts mehr kommt ... sondern sie sagt klar das es einen allgemeinen FEHLER beim lesen gegeben hat ... der fehlertext und teilweise der exception-name sind nur hinweise für den entwickler WARUM eben dieser FEHLER aufgetreten ist ...
 
Doch ich hab es Verstanden 🙂 deine Erklärung sind ja auch immer gut 🙂

Ich werde die Nachrichten einbauen 🙂

Das mit dem SocketTimeout und dem KeepAlive werde ich nochmal ausgiebig testen 😉

Gruß
 

Aktuelle Jobs

Neue Themen

Ähnliche Themen

Warum wird mir "Empfangen vom Client:" nicht sofort ausgegeben(Server/Client)
Antworten: 3
Chat-Client empfängt nichts vom Server
Antworten: 3
[Game-Multiplayer] Welt vom Server zum Client senden.
Antworten: 0
mit .writeUtf etwas vom Client zum Server schicken
Antworten: 13
Client Request vom Server aus.
Antworten: 2

Zurück
Oben