Wird hier die Nachricht auf jeden Fall ankommen wenn ich den PrintWriter und den Client kurz nach dem Output schließe?
Das ist ja eine TCP Verbindung und bei TCP gibt es ja auch manchmal fehlerhafte Packete. Nun stelle man sich vor die Nachricht kommt deswegen nicht an.
Nun würde der PrintWriter es wahrscheinlich so regeln das er die Nachricht nochmal sendet(nehme ich so an =?). Doch hier in diesem Fall habe ich den PrintWriter ja schon geschlossen?
Also wird er dann das fehlerhafte Packet nicht nochmal versenden oder wie muss ich das verstehen? Mein Ziel ist es den Client und PrintWriter sofort nach der Nachricht zu schließen, die Nachricht soll allerdings aber auch 100% ankommen.
PrintWriter out = new PrintWriter(client.getOutputStream(), true);
out.println("Nachricht");
out.close();
if(client!=null) {
client.close();
}
Genau kann ich es nicht sagen aber die Vermutung ist dass close() auch flush() ausführt und letzteres im Falle eines Übertragungsfehlers eine IOException wirft.
Also, nein, die Zustellung der Nachricht ist nicht garantiert, aber Du bekommst dann eine Exception und weist wenigstens, dass es nicht geklappt hat.
Wenn man es genau wissen will muss man aber in der Implementierung von Socket (oder seiner für TCP zuständigen Spezialisierung) nachschauen…
in dem hypthetischen Fall wäre das close() dann ja auch vergessen, oder?
Exception so wie bei normalen flush(), normaler Verwendung,
wenn im Code da kein try/catch usw. steht, dann ist das in jedem Fall ein Problem, close() dazu keine spezielle Frage
hinsichtlich der normalen Vorgänge im Hintergrund, TCP-Verhalten der Netzwerkkarte wie Sende-Wiederholung,
von dem kein Java-Code und manche Ebene dazwischen etwas mitbekommt, ist das close() auch unerheblich,
genauso hat die Gegenseite alle Zeit der Welt zu lesen,
soweit meine Meinung, ich fürchte aber auch nur mehr Vermutung als exaktes Wissen
um sich nicht weiter darum kümmern zu müssen? wie lange warten, wer soll das machen, separater Thread während Hauptprogramm weiterläuft?
und wird überhaupt schon vorher gesendet oder nicht doch erst nach langen unnötigen Warten beim close() dann?
alles erlaubte Fragen
Ich denke mal das geht nicht. Es sei denn, der Empfänger quittiert den Empfang. Üblicherweise lebt man mit dem Problem - wenn keine Ausnahme ausgelöst wird, geht man davon aus, dass die Nachricht angekommen ist.
[QUOTE=mymaksimus]War das nicht so, das solche writer weitgehend automatisch vom system / von java geschlossen werden?
Und selbst wenn nicht, soetwas wie
writeMessage("der request", new Message(){public void ready(){close();}});
koennte doch eine loesung sein[/QUOTE]
wenn man Sockets auf null setzt werden sie vielleicht automatisch geschlossen, meinst du das?
außer der Unsicherheit ob das klappt hat man dann hat man dasselbe Problem:
wann dies dem System gestatten so dass vielleicht unmittelbar geschlossen wird mit den gleichen Fragen,
Message-ready, wie immer das auch exakt implementiert wäre, könnte dieselbe Frage aufstellen:
wann das ready() mit dem potentiellen close() ausführen, vorher Warten oder nicht?
Ich hatte da mal was gebastelt. Das ist quasi ein server request system, man schickt anfragen und bekommt eine antwort, beides hat ne requestid um die antworten den anfragen zu ordnen zu koennen, ne anfrage bekommt auesserdem eine interface implementierung, die dann halt soetwas wie ne ready() methode enthaelt…
Vllt poste ich das mal. Bin im urlaub daher wirds schwierig aber mal schauen ^^
Aber ich wuerde gerne mal ein paar aeusserungen des tos zu den fragen aufgreifen
@OP
Also eigentlich gibts bei TCP keine fehlerhaften Pakete. Wie auf Wikipedia steht:
das Protokoll ist ein zuverlässiges, verbindungsorientiertes, paketvermitteltes Transportprotokoll
. Zuverlässig bedeutet dabei:
alle gesendeten Daten kommen vollständig an
die Daten kommen in der richtigen Reihenfolge an
es gibt keine Duplikate
TCP ist auch Verbindungsorientiert. Das heisst, wenn du die Verbindung per close trennen willst, ist da nicht aufeinmal der Gesprächspartner weg sondern das Protokoll sagt erstmal Tschüss: Transmission Control Protocol – Wikipedia
Die Probleme um die du dir da Sorgen machst treten eher bei UDP auf, bei dem all diese schönen Sachen die bei TCP garantiert sind eben nicht der Fall sind. Sollte z.B dein Gegenüber durch Stromausfall ausfallen, fliegt auf deiner Seite eine Exception die du dann behandeln kannst.
