Socket Server Anwendung - Empfang eines Byte-Arrays

[tsteinmaurer]

Hallo,

ich stehe vor der Aufgabe eine Socket Server Anwendung zu implementieren, die im wesentlichen das folgende Protokoll verstehen und abarbeiten muss:

Zeile 1 als normaler String\n
Zeile 2 als normaler String\n
Zeile 3 als normaler String\n
Länge des Byte-Arrays als normaler String\n
Byte-Array, der die ZLib komprimierte Fassung eines längeres Textes darstellt (unterschiedlich groß, womöglich mit \n drinnen, usw ...)


Die Socket Server Anwendung als solches (z.B. Multi-Threaded, usw ...) stellt nicht wirklich das Problem dar, das Problem ist vielmehr, wie man die Kombination aus normalen Strings (Zeile1 - Länge des Byte-Arrays) und Byte-Arrays am besten einliest, damit man das Byte-Array wieder als byte[] zur Verfügung hat, um im Server eine ZLib-Dekomprimierung zu machen.

Mit BufferedReader ist z.B. das Einlesen von Zeile 1 - Länge des Byte-Arrays einfach, allerdings vielleicht nicht das geeignete Mittel für das Einlesen des Byte-Arrays.

Habt Ihr da einen Tipp?

Danke,
Thomas

 

[tuxedo]

DataInput und DataOutputStream kann String lesen und schreiben.

Die ganzen "Reader" würde ich möglichst meiden.

- Alex

 

[PollerJava]

oder einfach einen Reader selber schreiben bzw. einen Decorierer für einen Reader:

http://www.oreilly.de/catalog/hfdesignpatger/chapter/ch03.pdf Seite 25

 

[tuxedo]

?? Was hat ein Dekorierer damit zu tun? Es geht ja nicht um die manipulation des Streams. Es geht um's korrekte ein einfache lesen von unterschiedlichen Daten aus dem Stream.

- Alex

[update]

Wenn das Protokoll wirklich fix ist und es keine große Abweichung geben darf, dann würde ich das ganze so im Client realisieren:

		InputStream is = null; // InputStream hier vom Socket holen statt mit null zu initialisieren
		DataInputStream dis = new DataInputStream(is);

		// Protokollaufbau
		//		Zeile 1 als normaler String\n
		//		Zeile 2 als normaler String\n
		//		Zeile 3 als normaler String\n
		//		Länge des Byte-Arrays als normaler String\n
		//		Byte-Array, der die ZLib komprimierte Fassung eines längeres Textes darstellt (unterschiedlich groß, womöglich mit \n drinnen, usw ...)
		
		String line1 = dis.readUTF();
		String line2 = dis.readUTF();
		String line3 = dis.readUTF();
		String dataLength = dis.readUTF();
		int intLength = Integer.parseInt(dataLength);
		
		byte[] data = new byte[intLength];
		dis.readFully(data);

Die Serverseite dazu sieht ähnlich aus.

- Alex

 

[tsteinmaurer]

Hi Alex,

danke schon mal für die Antwort. Dein Code zeigt eigentlich ja die Serverseite oder? Weil ja was eingelesen wird. Erkennt readUTF() eigentlich dann ein \n, d.h. wird mit diesem Aufruf eine komplette Zeile eingelesen? Scheint hier nicht so zu funktionieren.

Welches Gegenstück würdest Du in meinem Fall auf der Clientseite zum Schreiben auf den Stream verwenden, wenn wieder normale Strings und das byte[] Array involviert ist?

Besten Dank nochmal!


Thomas

 

[tuxedo]

Wenn du Client und Serverseite in der Hand hast, dann bist du doch bzgl. des Protokolls ein wenig "flexibel".

Wenn du auf der einen Seite mit

dataOutputStream.writeUTF(line1);

einen String (ob der jetzt ein \n enthält oder nicht ist deine Sache) reinschreibt, dann kannst du exakt diesen String auf der anderen Seite mit

dataInputStream.readUTF()

wieder auslesen.

Würde auf beiden Seiten also mit Data*Stream arbeiten.

- Alex

 

[tsteinmaurer]

Hallo Alex,

wir haben sowohl den Client als auch den Server in der Hand, d.h. solange diese Teile noch nicht in Produktion sind, haben wir quasi freie Hand. ;-)

Allerdings handelt es sich bei der Client-Anwendung um eine C++ Anwendung. Die serverseite wird halt mit Java gemacht. Du hast mir mit dem DataInputStream den notwendigen Schubbs in die richtige Richtung gegeben.

Funktioniert derzeit alles wunderbar.

Besten Dank für Deine Hilfe!

Thomas

 

[Murray]

Wenn die eine Seite in C++ realisiert ist, bist Du mit den Data**putStreams m.E. nicht so gut bedient: ein DataInputStream ist dafür da, Daten zu lesen, die mit einem DataOutputStream geschrieben wurden u.u.; wie das dabei verwendete Protokoll auf der Ebene der einzelnen Bytes aussieht (ob also z.B. ein String mit einem Nullbyte terminiert wird, oder ob stattdessen zu Anfang die Länge übertragen wird) , ist ein Implementierungsdetail.