Socket Server: ConnectionError vom Client erkennen

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:

Bleiglanz

Gesperrter Benutzer
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
 

FArt

Top Contributor
Hallo,

Wie kann ich dieses Problem lösen?

Gruß

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.
 

Stroker89

Bekanntes Mitglied
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ß
 
T

tröööt

Gast
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 ...
 

Stroker89

Bekanntes Mitglied
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();
		}
		
	}
 
T

trööt

Gast
ä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 ...
 

Stroker89

Bekanntes Mitglied
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:

Stroker89

Bekanntes Mitglied
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ß
 

Bernd Hohmann

Top Contributor
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.

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

Bernd
 

Bernd Hohmann

Top Contributor
Naja ich find es auch mal nicht schlecht "ganz unten" zu programmieren. Da lernt man gute APIs zu schätzen :)

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

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
 

Stroker89

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

Hab nicht vor nen Übertragungsprotokoll nachzubilden :D

Gruß
 
Zuletzt bearbeitet:
T

tröööt

Gast
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 ...
 

FArt

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

Bernd

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.
 

FArt

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

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

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.
 
T

tröööt

Gast
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 ...
 

FArt

Top Contributor
Ja, das ist nicht von der Hand zu weisen.

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 ...

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.
 

Bernd Hohmann

Top Contributor
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.

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:
 
T

tröööt

Gast
@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 ...
 

Bernd Hohmann

Top Contributor
@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 ...

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
 
T

tröööt

Gast
@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
 

Stroker89

Bekanntes Mitglied
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ß
 

Bernd Hohmann

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

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.
 

Bernd Hohmann

Top Contributor
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 ;)

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();
	}
}
 
T

tröööt

Gast
Was spricht denn generell dagegen auf diese EOFException zu reagieren und den Socket und die Stream zu zu machen?
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 ...
Also ist das in dem fall kein Exception-Missbrauch?
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
 

Stroker89

Bekanntes Mitglied
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ß
 
T

tröööt

Gast
Aber diese AUSNAHME signalisiert ja nur, dass auf dem Stream nichts mehr zu lesen ist

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 ...
 

Stroker89

Bekanntes Mitglied
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ß
 
Ähnliche Java Themen
  Titel Forum Antworten Datum
F http Post auf einen Grafana Server Netzwerkprogrammierung 3
W Socket Server -> lesen von / schreiben zu php-script Netzwerkprogrammierung 6
E Server mit GUI Netzwerkprogrammierung 4
E FTP FTPS Server gibt Fehlernachricht "522 SSL/TLS required on the data channel" zurück Netzwerkprogrammierung 1
I Performanteste Kommunikationsmethode zwischen Client u. Server Netzwerkprogrammierung 4
L Socket Automatische Zuweisung von Server und Client Rolle Netzwerkprogrammierung 12
Eigenen Rechner als Server? Netzwerkprogrammierung 16
FrankenDerStein HTTP Https Server Bibliothek für Linux und Android gesucht. Netzwerkprogrammierung 7
ExceptionOfExpectation Server/Client-Kommunikation Netzwerkprogrammierung 34
M Server-Client-System für Browsergame Netzwerkprogrammierung 5
J Datei Download vom Server Netzwerkprogrammierung 8
izoards Mehrere TCP Verbindungen auf einen Server [alles Local] Netzwerkprogrammierung 2
Yonnig Threads mit Client/Server und GUI (laufend bis button-click) Netzwerkprogrammierung 9
J Client-Server und SOAP Netzwerkprogrammierung 23
K Threads/Server/telnet Fehler Netzwerkprogrammierung 2
J Multithreaded-Server Netzwerkprogrammierung 21
JaXnPriVate Java HTTPS Server (Secure Sockets) Netzwerkprogrammierung 15
L30nS RMI RMI-Server kann Dialog nicht volkommen anzeigen Netzwerkprogrammierung 2
L30nS RMI Aufruf einer Client-Methode von einem RMI-Server Netzwerkprogrammierung 3
L Server-Socket liest Input-Stream nicht Netzwerkprogrammierung 5
T String von Client zu Server kommt nicht an Netzwerkprogrammierung 92
D WebSocket Server mit HTML Client und Java Server Netzwerkprogrammierung 5
S Von Java auf passwortgeschützten Server zugreifen + Umgang mit Ports Netzwerkprogrammierung 28
S Probleme bei Java-Installation auf Server (Linux/Shell/Terminal) Netzwerkprogrammierung 6
S Java: Anbindung an einen realen Server? (+ Portfreigabe) Netzwerkprogrammierung 8
D Server - Client Informationsaustausch, Möglichkeiten Netzwerkprogrammierung 3
H Socket Kann ein Socket server 2 dimensionale Arrays empfangen und versenden? Netzwerkprogrammierung 3
H Socket Chat entwickeln mit Java Server Client Netzwerkprogrammierung 4
X Kann ich einen Client/Server verbindung hinkriegen die mir alle paar Sekunden die aktuellen Daten per Realtime zuschickt ? Netzwerkprogrammierung 9
Z Kann nicht Daten vom Server lesen Socket Netzwerkprogrammierung 10
S HTTP Post?!? - Java Server Netzwerkprogrammierung 7
F Verbindung zu einem LDAP Server über Java Netzwerkprogrammierung 4
D Slf4j - Logging - Client-Server Architektur Netzwerkprogrammierung 3
F NodeJs-Server auf Firebase hosten ? Netzwerkprogrammierung 3
J client server mit nur einem PC Netzwerkprogrammierung 33
M Socket Nachricht von TCP-Client an Server schicken Netzwerkprogrammierung 12
M Socket Verbindung Matlab(Server) Java(Client) Netzwerkprogrammierung 1
H HTTP Glassfish (v5) Application Server - Bibliothek zur Verfügung stellen Netzwerkprogrammierung 4
B HttpClient - Server (Jetty) - getInputStream - EOF Netzwerkprogrammierung 3
P TCP-Server Netzwerkprogrammierung 1
R Socket FATAL EXCEPTION MAIN bei Socket based client/server app Netzwerkprogrammierung 2
F Server für Java Applikationen Netzwerkprogrammierung 16
H Einfacher Server funktioniert nicht Netzwerkprogrammierung 1
G Server-Client IO Problem Netzwerkprogrammierung 6
T Mikrofonaudio über Java Server an Webbrowser streamen Netzwerkprogrammierung 13
I Socket Das erste Server-Client Programm Netzwerkprogrammierung 16
T HTTPS-Requests an Server: POST-Parameter kommen nicht an Netzwerkprogrammierung 5
L Socket Wie kann ich checken ob ein User eine Nachricht per Outputstream an den Server gesendet hat? Netzwerkprogrammierung 1
T Jetty Server LOGGING Netzwerkprogrammierung 1
L Strings an Server senden und in MYSQL speichern? Netzwerkprogrammierung 3
Aruetiise Socket Java Programm auf Server Netzwerkprogrammierung 3
T server empfängt nur 1 Buchstaben vom String Netzwerkprogrammierung 1
S Spiel mit Server programmieren Netzwerkprogrammierung 2
N Post u Head Request an Server Netzwerkprogrammierung 4
J Socket Ein Chat Server Tutorial Netzwerkprogrammierung 8
M Socket Server antwortet dem Client nicht Netzwerkprogrammierung 6
J Socket Tutorial zu Multiplayer Server schreiben? Netzwerkprogrammierung 5
S Java Chat Server Netzwerkprogrammierung 8
E Kurze Textnachrichten über einen Server von meinem Handy auf den Computer laden. Netzwerkprogrammierung 9
I Client/Server Kommunikation bei einem Spiel Netzwerkprogrammierung 4
E Objekte versenden, Client-Server Netzwerkprogrammierung 25
C Mini Client-Server-Anwendung funktioniert nicht Netzwerkprogrammierung 8
D Socket Message an einen Server senden? Netzwerkprogrammierung 8
J FTP FTP Zugriff über Proxy Server Netzwerkprogrammierung 1
KaffeeFan Programmierung mit Cloud-Server Netzwerkprogrammierung 0
L Socket Problem mit Server Netzwerkprogrammierung 1
cezary Socket Paralleler Server ? Netzwerkprogrammierung 1
I Socket Leicht zu DDosender Server Netzwerkprogrammierung 4
agent47 HTTPs Server Netzwerkprogrammierung 5
J Chat Server starten über GUI problem Netzwerkprogrammierung 4
J Prüfen, ob remote UDT Server erreichbar ist Netzwerkprogrammierung 0
P Server als Client nutzen Netzwerkprogrammierung 8
S Server Kommunikation Netzwerkprogrammierung 1
V einfaches hin und her von Text über Server Netzwerkprogrammierung 2
D Socket Run Args Client/Server Socket Netzwerkprogrammierung 1
Cromewell Socket Multithreaded Server und Client Netzwerkprogrammierung 1
Y Client/Server/DB communication Netzwerkprogrammierung 3
JavaWolf165 Socket mit .writeUtf etwas vom Client zum Server schicken Netzwerkprogrammierung 13
P RMI Client Server Programm über Internet Netzwerkprogrammierung 2
brainless Client Server Kommunikation verschlüsseln Netzwerkprogrammierung 13
gamebreiti Socket Server / Client Anwendung Manipulation von Objekten durch Server Netzwerkprogrammierung 9
T Socket Server/Client Kommunikation Netzwerkprogrammierung 8
S Webservice - Server Netzwerkprogrammierung 0
M Java Eingabe auf FTP Server übergeben Netzwerkprogrammierung 4
F Server Client Anwendung mit UDP Netzwerkprogrammierung 2
A RMI Wo treten Exceptions bei RMI Aufrufen auf? Auf Client oder auf Server? Netzwerkprogrammierung 3
M Socket Java Server: NullPointerException Netzwerkprogrammierung 4
A ByteBuffer - Client/Server Netzwerkprogrammierung 9
J Java Server empfängt php inhalt nicht Netzwerkprogrammierung 1
K C# Server - Android Client Netzwerkprogrammierung 0
J Framework mehrere Clients/ Server-Broadcast/oracle XE/ XML Netzwerkprogrammierung 1
D Mit Server Daten austauschen Netzwerkprogrammierung 4
V Server / mehrere Clients / MySQL / Konzept Netzwerkprogrammierung 2
P HTTP Bild von einem Server per http kopieren Netzwerkprogrammierung 1
F Verbindung zwischen Server und handy Netzwerkprogrammierung 1
P MIME-TYPE Erklaerung, Kommunikation zwischen Client und Server Netzwerkprogrammierung 3
J Sichere Kommunikation bei Server Client Netzwerkprogrammierung 3
R RMI Server RMI Netzwerkprogrammierung 1
X Mit Java eine Applikation auf einem anderen Windows Rechner (Windows Server 2008) starten Netzwerkprogrammierung 1
T Frage zu Client-Server Applikation Netzwerkprogrammierung 2

Ähnliche Java Themen

Neue Themen


Oben