Socket Datei nur stückweise über Socket verschicken

[DougUndPizza]

Hallo,

ich möchte die Möglichkeit anbieten einen InputStream zu einer über Netzwerk verfügbaren Datei zu öffnen.

Der FileInputStream wird auf Serverseite ausgelesen und in den OutputStream eines Sockets geschrieben, der zum Client führt. Der Client hat dann quasi im InputStream des Sockets auf seiner Seite eine Kopie des Inhaltes des ursprünlichen FileInputStreams.
Hier ein Ausschnitt der Methode auf Serverseite:

InputStream sourceFileIn = new FileInputStream(fullPath);
/* client ist ein Socket */
OutputStream clientOut = client.getOutputStream();
int bytesReadCount = 0;
while (true)
{
	bytesReadCount = sourceFileIn.read(copyBuffer);
	if (-1 == bytesReadCount)
	{
		break;
	}
	clientOut.write(copyBuffer, 0, bytesReadCount);
}

Das funktioniert auch so. Allerdings gefällt mir daran nicht, dass direkt immer die komplette Datei in den Strom geschrieben wird. Ich vermute, die TCP Pakete kommen dann beim Client an und werden solange irgendwo gepuffert, bis der Strom ausgelesen wird.

Auch wenn der Client nur den Anfang der Datei bräuchte, würde trotzdem Alles übertragen.

Ich möchte nun folgendes erreichen: Es soll immer nur soviel rübergeschickt werden, wie tatsächlich gebraucht wird.
Also in etwa: "Client ruft read auf -> Server ruft read beim FileStream auf und schreibt das in den Socket Stream.
Oder, dass immer eine bestimmte Anzahl Bytes geschickt werden, bis die auf der Gegenseite ausgelesen sind, und erst dann wird neu aus der Datei gelesen und in den Socket Stream geschrieben.


Meine Frage ist nun: Gibt es eine Möglichkeit das ohne zusätzliches Protokoll zu erreichen? - Vielleicht kann man FileInputStream und SocketOutputStream irgendwie koppeln.

 

[irgendjemand]

tja ... das wirst du selbst implementieren müssen ...

der client müsste eigentlich nur dem server die info schicken wie viele bytes er haben will ... und der server liest dann so viele bytes ein und schreibt diese auf den socket ... alternativ natürlich auch in nem loop ...

while(true) -> EVIL !
lieber durch ein flag oder eine andere expression ersetzen

 

[Spacerat]

Wenn das nicht schon per BS so geht, würde ich sagen, du benötigst 'ne Pipe. Diese koppelt einen Input über einen Puffer mit einem Output. In den Input können nun solange Daten fliessen, bis der Puffer voll ist, der Input (Thread1) wird dann blockiert. Aus dem Output können natürlich auch nur so lange Daten gelesen werden, bis der Puffer leer ist, der Output (Thread2) blockiert sonst ebenfalls. Daraus folgt, dass für so eine Konstellation zwei Threads erforderlich sind. Glücklicherweise gibt es für Streams in Java bereits diverse Klassen dafür - PipedInputStream und PipedOutputStream. Das Ganze geht im übrigen auch ohne dass irgendjemand, irgendwo, irgendwelche Daten insbesondere Anzahl der erwarteten Bytes benötigt.

 

[DougUndPizza]

Wenn das nicht schon per BS so geht...

Oder, dass immer eine bestimmte Anzahl Bytes geschickt werden, bis die auf der Gegenseite ausgelesen sind, und erst dann wird neu aus der Datei gelesen und in den Socket Stream geschrieben.

Also ich hab die obige Version mal mit Konsolenausgaben der Anzahl der in den SocketStream geschriebenen Bytes auf Serverseite laufen lassen und es scheint so, als ob diese Version bereits genau das macht, was ich erreichen wollte.

System.out.println("Server before writing");
clientOut.write(copyBuffer, 0, bytesReadCount);
System.out.println("server written bytes: "+bytesReadCount);

clientOut.write() wird 3 bis vier mal ausgeführt und blockiert dann. Sie blockiert solange, bis der Client auf der Gegenseite des Sockets eine bestimmte Menge bytes ausgelesen hat.

Leider kann ich hier Client und Server beide nur auf localhost laufen lassen und kann daher nicht ausprobieren oder mit Wireshark mitschneiden, wie es sich über Netzwerk verhält.

Ich vermute, dass der Client die Fenstergröße in den TCP Antwortpaketen auf 0 setzt, sodass der Server keine neuen Pakete mehr schickt. Wenn der Client dann aus dem Stream liest, wird die Fenstergröße wieder erhöht und der Server sendet neue Daten.
Möglicherweise ist dieses Verhalten auch generell bei Sockets (nicht nur Java) so definiert.
Das BS bestimmt quasi, wieviel Bytes gepuffert werden, bevor das Fenster auf 0 gesetzt wird.
Bei WinXP und Ubuntu sind die Werte unterschiedlich, aber jeweils immer reproduzierbar.

Stimmt meine Vermutung?

 

[Spacerat]

Tja... Die Vermutung, dass es bereits per BS so implementiert ist, liegt ja nahe und faktisch passt es auch. Was passiert denn, wenn kein Client connected um sich die Daten zu holen? Gibt's dann ein SocketTimeOut? Die Werte von denen du sprichst, sind die jeweiligen Puffergrössen der Pipe und können durchaus unterschiedlich sein, die Fenster, jeweils die verbleibenden Bytes beim Schreiben bzw. die im Puffer vorhandenen Bytes zum Lesen.
Wenn du keinen 2. Rechner zur Verfügung hast, kannst es ja mal mit virtuellen Netzwerken (VirtualHostAdapter oder VirtualMaschine) ausprobieren.
[EDIT]Ach ja... nicht der Client bestimmt die Grössen des Servers sondern der Server weiss selbst, wann der Sendepuffer voll ist. Andersrum: Der Client kennt die Daten seines Empfangspuffers auch selber.[/EDIT]

 

[irgendjemand]

hmm ... es wäre einfacher dem server nicht nur mitzuteilen welches file man will sondern auch wie viel davon ... wäre auf jeden fall unkomplizierter als sich auch irgendwelche OS sachen verlässt *BS ... da fehlt das E ...*

 

[jule37]

wenn ich es richtig verstehe verwendest du tcp - in dem fall brauchst du dir um fenster und puffergrößen keine gedanken machen, weil das protokoll garantiert, dass alles ankommt. wenn irgendwelche puffer voll sind wird automatisch nochmal gesendet.

was dein problem mit teilweise übertragen der datei angeht: du musst ja nicht sofort die ganze datei versenden. schau dir das javadoc von input stream genau an. du kannst im stream herumspringen und auch bestimmte mengen an bytes auslesen und über dein socket rausschicken. allerdings musst du dann aufpassen, dass du es auf empfängerseite wieder richtig zusammensetzt.