TCP Server und BufferedReader Leerstring im Stream?

[cheat.008]

Hallo zusammen,

ein TCP-Server sendet mir über einen Stream zwei Strings über einen PrintWriter und der Client liest diese mit einem BufferedReader.
Nun lese ich im Client genau 2x den Stream aus mit einem BufferedReader, der ja durch seine .readLine() Methode solange wartet bis die nächsten Daten im Stream ankommen, richtig?

Angenommen es wird nun eine unbekannte Anzahl an Daten vom Server geschickt, wie muss ich einen Reader konstruieren, der in einer Schleife den Stream nur solange liest, bis er leer ist?

Ich hatte versucht die Schleife abzubrechen, wenn der Stream einen Leerstring schickt, aber durch die \r\n ist das wohl nicht leer oder?

Ich hoffe ich konnte es einigermaßen erklärbar machen, bin noch recht am Anfang mit Java und gerade erst bei den Streams angekommen.
Danke für Tipps

 

[httpdigest]

Du kannst selbstverständlich auch den leeren String per PrintWriter schicken und der wird dann auch von https://docs.oracle.com/javase/8/docs/api/java/io/BufferedReader.html#readLine-- als Leerstring zurückgegeben. Kein Problem.

Ich hatte versucht die Schleife abzubrechen, wenn der Stream einen Leerstring schickt, aber durch die \r\n ist das wohl nicht leer oder?

Hast du es denn mal ausprobiert? Falls nicht, schau noch einmal in die JavaDoc von BufferedReader.readLine(): Das \n oder \r\n wird _nicht_ Teil des Strings sein, der von BufferedReader.readLine() zurückgeliefert wird.

 

[cheat.008]

Hast du es denn mal ausprobiert? Falls nicht, schau noch einmal in die JavaDoc von BufferedReader.readLine(): Das \n oder \r\n wird _nicht_ Teil des Strings sein, der von BufferedReader.readLine() zurückgeliefert wird.

Ah ok stimmt. Ich habe das Szenario nun mal wie folgt aufgebaut, ich prüfe nun nicht mehr auf den Leerstring.

Der Server sendet zwei Strings ( "OK1" und "OK2" hintereinander und flusht), der Client liest auch erstmalig beide aus, jedoch verweilt er anschließend in der blockierenden br.readLine().
Ich dachte ich könnte so eine Art Abbruchbedingung für die Schleife schaffen, wenn im Stream nichts mehr übertragen wird aber scheinbar ist dies erst der Fall, wenn der Stream geschlossen wurde.
Wie realisiert man denn einen Abbruch der Schleife, wenn der Stream noch offen ist aber nichts mehr vom Server gesendet wird?

Also meine Schleife im Client sieht folgendermaßen aus:

.
.
.
String fromServer;
while ( (fromServer = br.readLine()) != null )
               {
                   System.out.println(fromServer);
               }
.
.
.

 

[mrBrown]

Man kann zB, von Client-Seite entsprechende Daten senden, die das Ende der Daten signalisieren oder vor den Daten die Länge der zu erwartenden Daten senden.
Automatisch geht das mWn nicht

 

[cheat.008]

Ok, schade.
Dann muss ich mir etwas anderes ausdenken.
Würde ich anstatt eines CharacterStreams einen ByteStream nehmen, könnte ich durch den Rückgabewert -1 der read() Methode zwar das Ende der Nachricht lesen, aber die Zeichenkodierung würde mir verloren gehen oder?

Folgendes funktioniert zwar, ja aber auch eben nur weil ich weiß was als letztes gesendet wird.

String fromServer;
               
               while (true)
               {
                   if((fromServer = br.readLine()).equals("OK2"))
                   {
                       System.out.println(fromServer);
                       break;
                   }       
                   System.out.println(fromServer);
               }

 

[httpdigest]

Du hättest die folgenden zwei Möglichkeiten:

1. Du schließt den Stream und reagierst auf ein null Rückgabewert von BufferedReader.readLine() (was End-Of-File/End-Of-Stream des darunterliegenden Streams signalisiert; also er wurde korrekt geschlossen)
2. Du überträgst und erkennst ein designiertes Zeichen oder eine Zeichenkette, wie etwa den Leerstring (HTTP benutzt z.B. eine Leerzeile '\r\n', um das Ende der HTTP Header zu signalisieren)

Ob du das Ganze nun mit einem BufferedReader auf Zeichenebene oder mit InputStream oder einem anderen Byte-orientierten Reader machst, ist ja dann egal.