Input/Output Streams

[minzee]

Hi

Mich verwirrt ein Buch etwas. Es geht um Streams und Sockets.

FileOutputStream fout = new FileOutputStream("x.y");
BufferedOutputStream bout = new BufferedOutputStream(fout);
DataOutputStream dout = new DataOutputStream(bout);
dout.writeln(4711);

In dem Buch heißt es, dass die Bufferung bout zwischen fout und dout reingehört. Hier passiert folgendes: int-Wert einlesen -> konvertieren -> buffern -> ausgeben (in Datei speichern)

Auf der nächsten Seite im Buch steht aber folgendes:

Socket s = ...
OutputStream os = s.getOutputStream();
OutputStreamWriter osw = new OutputStreamWriter(os);
BufferedWriter bw = new BufferedWriter(osw);
bw.write("Hallo Welt");

Hier passiert folgendes: string einlesen -> buffern -> konvertieren -> ausgeben (via Socket an Gegenstelle übertragen)

Jetzt haben plötzlich buffern und konvertieren die Plätze getauscht.

Ist das doch komplett egal, was man in welcher Reihenfolge macht?

 

[lawila]

nein, ist es nicht

buffering wird in der regel beim lesen genutzt ... beim schreiben wenn überhaupt dann nur bei file-io um die platte zu schonen

der grund warum hier die plätze getauscht werden ist einfach das beim file-example auf den nakten file-stream erstmal der buffer gelegt wird um wie gesagt bei häufigen schnell kleinen schreib-operationen die zugriffe zu buffern um die platte zu schonen da die daten so dann erst gesammelt und dann in einem rutsch auf die platte geschrieben werden können

was dann da noch oben drauf kommt (in dem fall ein DataOutputStream) ist völlig egal



beim socket-example macht die bufferung dann schon mal überhaupt gar keinen sinn mehr

man hat den socket, darauf den output-stream und darauf einen writer kleben
jedoch will man eigentlich bei einer socket-kommunikation schnellst-mögliche verarbeitung, wo hier das buffering genau das gegenteil bewirkt

außerdem : durch den sog. TCP-Nagle-Algorithmus sorgt die TCP-implementierung des OS für die nötige (oder meiner meinung nach eigentlich überflüssige) bufferung um halt nicht sinnfrei packete senden zu müssen die vielleicht ein oder zwei bytes nutzdaten enthalten und sonst nur aus header und padding bestehen (hier wirkt der Nagle-algo entgegen in dem er zumindest soweit die daten cachet bis die mindest-größe des TCP-paketes erreicht ist)

zusätzliches buffering auf seiten java macht IMO zumindest in diesem konkreten beispiel absolut gar keinen sinn

 

[minzee]

Wennst selbst bufferst, kannst auch selbst bestimmen, wann das Versenden der Daten starten soll. Ob die Daten dann fürs Versenden zerstückelt werden, ist dann Sache von TCP.

Bufferst aber nicht selbst und überlässt alles TCP, werden die Daten halt irgendwann übertragen.

So hab ich das verstanden. Ist das richtig so?

 

[lawila]

nur teilweise richtig ... das hängt nämlich von der buffer-größe ab
ist diese erreicht wird der buffer automatisch geflusht (was bei korrekter implementierung einen kaskaden-effekt zur folge hat und sich bis zum native des socket-streams durchzieht)

wie gesagt : ich persönlich find es sinnfrei irgendwas was über einen tcp-stream rausgehen soll noch mal extra zu buffern

entweder reicht mir halt das auto-buffern vom tcp-stack und ich call halt flush() ... oder ich nehm den Nagle-algo komplett raus und hab damit (das von mir erwünschte) gar kein buffering mehr

warum ich absichtlich daten die am ende eh über den stream gehen erst noch in nem buffer zurückhalten soll ... vor allem wenn mein ziel ja die "schnellstmögliche kommunikation" ist ... sorry, fällt mir nichts weiter zu ein



aber : es gibt wie gesagt anwendungsbeispiele wo buffering IMO durch aus sinn macht

ganz großer punkt z.b. file-io auf der platte
hier wähle ich einen möglichst großen buffer (in der regel ein vielfaches der cluster-größe) um halt größere daten in einem rutsch sequentiell von der platte zu lesen ... und auch beim schreiben dann wieder un-fragmentiert rauszuschreiben

oder z.b. auch bei RS232, weil hier kommt es dann z.b. darauf an auf das "ready" vom gegenüber zu warten
denn bei RS232 kann man zwar durch aus daten auf den kanal schreiben ... bringt einem aber nichts wenn die gegenstelle noch nicht bereit dazu ist diese dann auch zu lesen und zu verarbeiten ... dann schreibt man nämlich in dem sinne ins "nichts" und die daten sind dann erstmal weg
macht vor allem beim de-buggen einen riesen spaß sowas rauszufrimeln

wo es bei einer socket-verbindung sinn macht zu buffern ist beim inputstream
sinn kann hier sein das man z.b. nicht zeichen-weise sondern zeilen-weise einlesen möchte (Reader statt InputStream)
nun ist es wichtig erstmal soweit daten vom Stream zu lesen bis man ein \n findet an dem dann gesplittet werden kann
oder auch bei allem anderen was block-weise arbeitet (z.b. komprimierung und verschlüsselung) ... denn mit einzelnen bytes kann hier nicht gearbeitet werden, es muss immer mindestens der nächste block vollständig sein

 

[minzee]

Ok. Nur ein Satz verwirrt mich jetzt:

entweder reicht mir halt das auto-buffern vom tcp-stack und ich call halt flush()

flush kann ich doch nur machen, wenn ich selbst ein buffering programmiere, oder?

 

[lawila]

nein ... ein flush() ist grundsätzlich immer möglich da von OutputStream vorgeschrieben

flush() wird in der regel so implementiert das die interne verarbeitung bis zum block gepadded und dann abgeschlossen, die daten auf den gekapselten stream geschrieben und anschließend auf diesem auch flush() gecallt wird bis das ganze in irgend nem native flush0() endet