Socket readFully()?

[stulleman]

Hallo zusammen!

Ich wollte mich nur mal schnell erkundigen, weil ich dazu echt wenig im Internet gefunden habe, ob readFully(byte[] buffer) eine gute Alternative zur while-Schleife ist, die Daten in kleinen Häppchen vom Socket liest?
Ich mache das, indem ich mir erst die Länge schicken lasse, ein byte[] in dieser größer erstelle, und dann readFully(buffer) damit aufrufe.
Können dabei Probleme enstehen? Macht ihr es anders?
Würde mich über Antworten sehr freuen!

LG Max

 

[Kr0e]

Aus meiner Sicht klingt das sehr gut. Von Hand würde man es nicht anders machen...

Wenn man beim blocking-IO Ansatz bleibt, sollte das eine gute Sache sein.

 

[träät]

ich find solche ansätze immer wieder sehr praxis fern : was passiert wohl bei 100GB payload ?
richtig ... du liest vom HTTP-Header Content-Length 100GB und versuchst das als EIN array in ner VM zu erzeugen ... keine chance !

auch ist es extrem unsicher sich wirklich auf den Content-Length - header zu verlassen ... denn was macht man wenn dieser nicht kommt ? "-1" ? "0" ? "NULL" ?

bei solchen "theoretischen" fragen sollte man sich auch immer gedanken machen ob das so überhaupt praktisch umsetzbar und wenn dann überhaupt sinnvoll ist ... denn 100GB RAM wird sicher so schnell mal keiner eben haben ... also bleibt ja nur schlicht die möglichkeit über einen loop das zu lesen was kommt und dann dabei gleich als file rauszuschreiben eben damit es NICHT im RAM sondern auf der PLATTE landet ...

 

[Bernd Hohmann]

Ich wollte mich nur mal schnell erkundigen, weil ich dazu echt wenig im Internet gefunden habe, ob readFully(byte[] buffer) eine gute Alternative zur while-Schleife ist, die Daten in kleinen Häppchen vom Socket liest? Ich mache das, indem ich mir erst die Länge schicken lasse, ein byte[] in dieser größer erstelle, und dann readFully(buffer) damit aufrufe.

Wenn Du mit readFully die Methode in DataInputStream oä meinst: da ist auch nur eine while-Schleife drin.

Ist also Jacke wie Hose ob Du nun selber die Schleife machst oder das anderen überlässt: es wird dadurch nicht schneller, besser oder schlechter.

Bernd

 

[stulleman]

Danke für eure Antworten!
Da ich sowieso nicht vorhatte so große Dateien zu versenden, stört es mich in diesem Fall nicht, trotzdem danke für den Hinweiß mit den sehr großen Dateien.
Heißt also das uns der RAM begrenzt, was würdet ihr als Grenze vorschlagen? 200 mb?

LG Max

 

[Kr0e]

Pakete > 1 MB sollten sowieso vermieden werden. Wenn es der Datentyp zulässt -> Streamen, ansonsten auf Festplatte speichern und später zu Rate ziehen. Der Hinweiß ist schon gerechtfertigt, aber dachte jetzt nicht , dass du eine 100% sichere und gegen Angreifer resistente App baust. Da gäbe es dann noch ganz andere Hinweise. Klar sollte man vorsichtig sein, aber vlt. auch nicht zuu schwarzmalerisch für den Anfang. Optimieren kann man hinterher immer noch.... Davon abgesehen, gibt es sowieso keine 100% sichere App, iwie kommt man immer rein bzw. kann Schaden anrichten. Wenn man so anfängt, darf man gar keine Netzwerkprogramme schreiben Aber ich stimme meinem Vorredner zu, so einfache Dinge, wie Pufferüberlauf sollte man schon handeln können.

 

[Bernd Hohmann]

Da ich sowieso nicht vorhatte so große Dateien zu versenden, stört es mich in diesem Fall nicht, trotzdem danke für den Hinweiß mit den sehr großen Dateien. Heißt also das uns der RAM begrenzt, was würdet ihr als Grenze vorschlagen? 200 mb?

Durch 64bit Betriebssysteme und dem Preisverfall bei RAM-Bausteinen geht der Trend dazu, solche Daten Serverseitig komplett im RAM zu verarbeiten.

Dummerweise rüsten die Anwender auch nach und wenn hinreichend davon gleichzeitig zugreifen platzt die Applikation auf dem Server weg wie ein Elefantenkondom (200MB sind wenig, 50x200MB schon viel).

Wenn also grosse Brocken zu erwarten sind, dann lies die Daten in Blöcken von 8192bytes in eine temporäre Datei und gut ist oder verarbeite sie gleich ohne dass da irgendwas zwischengespeichert werden muss.

Aber wenns wirklich nur Kleinkram in deinem Anwendungsfall ist, dann rechne es selber aus. Alles kleiner als 1MB würde ich heute als Kleinkram abtun, vor 20 Jahren war 1MB schon die Diskette mit "Wolfenstein 3D" und hat mit 2400er Modem über eine Stunde zum Download gebraucht :lol:

Bernd

 

[trääät]

es sind schöne stichworte gefallen ...

am besten du verarbeitest die daten so schnell wie möglich ...

wenn es also möglich ist das du in dem loop der die daten vom stream liest diese auch dort direkt verarbeiten kannst solltest du lieber so rangehen anstatt erst ALLES lesen zu wollen und dann später durch zu gehen ... das spart nämlich zeit und resourcen ...

sicher waren 100GB jetzt deutlich übertrieben ... aber es war mal so ne anmerkung was passieren KÖNNTE wenn man gegen sowas keine sicherung einbaut ...

man muss sich als beispiel doch nur mal normale webserver oder sogar browser nehemen : die lesen die daten auch über einen buffer erstmal direkt in temp-files bevor sie dann damit weiter arbeiten ... denn wirklich alles im RAM halten (wie es eben readFully() macht) würde kein system wirklich durchhalten ...

 

[stulleman]

Super danke! Werde versuchen alle genannten Aspekte zu berücksichtigen, ist aber nur ein kleines privates Projekt

LG Max