Senden große Datei über FileInputStream/ObjectOutputStream
Brauche ich Hilfe auf meine Hausaufgaben, jede Hilfe wird sehr geschätzt. Ich kann senden, kleine Dateien, ohne ein problem. Aber wenn ich versuche zu senden, sagen wir mal eine 1GB Datei byte-array sendet OutOfMemoryError, so brauche ich eine bessere Lösung zum senden einer Datei vom server zum client. Wie kann ich diesen code und senden Sie große Dateien, bitte helft mir.
Server-Code:
FileInputStream fis = new FileInputStream(file);
byte[] fileByte = new byte[fis.available()]; //This causes the problem.
bytesRead = fis.read(fileByte);
oos = new ObjectOutputStream(sock.getOutputStream());
oos.writeObject(fileByte);
Client-Code:
ois = new ObjectInputStream(sock.getInputStream());
byte[] file = (byte[]) ois.readObject();
fos = new FileOutputStream(file);
fos.write(file);
"sendet die out-of-memory-exception" Keine solche Sache in Java, DYM
BTW - der erste code scheint zu implizieren, die Eingabe-Datei enthält die serialisierten Objekte. Ist das hier der Fall?
Oh, im sorry, es ist OutOfMemoryError nicht die Ausnahme. Und ich weiß nicht, was du meinst, wenn die Datei enthält serialezed Objekte, server sendet alle Datei der client anfordert.
Ok ich werde es so machen dann, danke, ich bin neu hier.
OutOfMemoryError
? Wenn dem so ist, werden spezifische, wenn nicht dann bitte erklären, (auch speziell).BTW - der erste code scheint zu implizieren, die Eingabe-Datei enthält die serialisierten Objekte. Ist das hier der Fall?
Oh, im sorry, es ist OutOfMemoryError nicht die Ausnahme. Und ich weiß nicht, was du meinst, wenn die Datei enthält serialezed Objekte, server sendet alle Datei der client anfordert.
ObjectOutputStream
und ObjectInputStream
verwendet werden, für die serialisierten Objekte. Wenn der Inhalt 'alle alten bytes' den code nicht benutzen sollten.Ok ich werde es so machen dann, danke, ich bin neu hier.
InformationsquelleAutor Ozzy | 2012-05-30
Du musst angemeldet sein, um einen Kommentar abzugeben.
Teilt das array in kleinere Stücke, so dass Sie nicht brauchen, um zugeordnet werden keine große Auswahl.
So können Sie zum Beispiel split das array in 16Kb Blöcken, zB
new byte[16384]
aus und senden Sie Sie eins nach dem anderen. Auf der Empfängerseite müsste man warten, bis ein chunk vollständig Lesen, und dann speichern Sie Sie irgendwo, und starten Sie mit dem nächsten chunk.Aber wenn Sie nicht in der Lage, reservieren Sie ein ganzes array von der Größe, die Sie brauchen auf der server-Seite werden Sie nicht in der Lage, um zu speichern alle Daten, die Sie gehen zu empfangen sowieso.
Könnte man auch komprimieren Sie die Daten vor dem senden, um Bandbreite zu sparen (und Zeit), nehmen Sie einen Blick auf
ZipOutputStream
undZipInputStream
.InformationsquelleAutor Jack
Nicht Lesen Sie die ganze Datei in den Speicher, mit einem kleinen Puffer und schreiben, während Sie Lesen gerade die Datei:
Gepufferten* optimieren das schreiben und Lesen von Streams
InformationsquelleAutor ErikFWinter
Hier ist, wie ich es gelöst:
Client-Code:
Server-Code:
InformationsquelleAutor Ozzy
Je nachdem, ob oder nicht Sie haben den code selbst schreiben, gibt es Bibliotheken, die dieses problem lösen, z.B. rmiio. Wenn Sie nicht über das RMI, einfach nur java-Serialisierung verwenden, können Sie die DirectRemoteInputStream, das ist wie eine Art von Serializable InputStream. (diese Bibliothek hat auch Unterstützung für Dinge wie auto-magisch Komprimierung der Daten).
Eigentlich, wenn Sie nur sendende Datei Daten, Sie wäre besser dran, Notwasserung die Objekt-streams und die Nutzung DataInput/DataOutput-streams. zuerst schreiben Sie einen integer, der angibt, die Länge der Datei, dann kopiere die bytes direkt in den Bach. auf der empfangenden Seite, Lesen Sie den Ganzzahl-file der Länge, dann Lesen genau so viele bytes.
beim kopieren der Daten zwischen den Bächen, verwenden Sie eine kleine, Feste Größe byte [], um Stücke von Daten zwischen der Eingabe-und Ausgabe-streams in einer Schleife. es gibt zahlreiche Beispiele dafür, wie dies zu tun, richtig online verfügbar (z.B. @ErikFWinter Antwort).
InformationsquelleAutor jtahlborn