Socket Wechsel von DataOutputStream zu ObjectOutputStream

[H3llGhost]

Hallo Leute,

ich habe eine Server-Client-Applikation.
Mein Problem ist nach dem Wechsel von DataOutputStream zu ObjectOutputStream funktioniert gar nichts mehr.
Sprich es wird nichts gesendet und nichts empfangen.

Zu meiner Vorgehensweise beim Wechsel:
Ich habe einfach alle DataOutputStream's zu ObjectOutputStream verändert.
Dasselbe habe ich dann mit dem DataInputStream analog dazu gemacht.

Im Internet habe ich dann nen Artikel zum ObjectOutputStream gefunden, dass dies sehr langsam ist und deswegen JBossObjectOutputStream nutzen sollten.
Leider hat dies auch keinen Erfolg gebracht.

Habt ihr eventuell eine Idee worauf ich achten soll?

Danke im Vorraus.

 

[Michael...]

Data...Stream kann primitive Datentypen (int, byte, boolean, ...) lesen und schreiben und besitzt entsprechende Methoden zum Lesen und schreiben.
Object...Stream kann neben den primitives Datentypen auch Objekte lesen und schreiben.
Dem entsprechend muss man eben beim Lesen und Schreiben, die richtigen Methoden verwenden. Mehr kann man so pauschal nicht sagen.

 

[tuxedo]

Ein DataOutputStream kann auch Objekte schreiben. Wieso hast du denn diesen seltsamen Wechsel vollzogen? Welchen Mehrwert hast du davon?
In meinen Augen machst du dir da das Leben nur unnötig schwer...

- Alex

 

[H3llGhost]

@Michael...:
Vielen Dank für dein Tipp.
Ich benutze in meiner Applikation writeUTF() und readUTF().

@tuxedo:
Der Hintergrund warum ich das nutzen möchte ist die Möglichkeit serialisierte Arrays zu schicken.
Und eventuell Dateien (später).

 

[tuxedo]

Du kannst mit dem DataOutputStream nicht weniger schicken als mit dem ObjectOutputStream.

Nur bietet der DataOutputStream eine spezielle "serialisierung" für einfachere Datentypen. Bei ObjectOutputStream wird alles als Objekt serialisiert, was bei einfachen Datentypen unnötig Overhead mitbringt.

Ergo: DataInputStream und DataOutputStream sind empfehlenswerter da die mit einfachen als auch "komplexen" Typen effizient umgehen kann.

- Alex

 

[H3llGhost]

Hmm ...
also ich habe eine Message-Array was ich versenden möchte ...
Sprich es kann 5 Zeilen enthalten für eine Nachricht und mehrere Dutzend für mehrere Nachrichten ...
Was würdest du mir da empfehlen?

Bzw. wie kann ich auf die Serialisierung im DataOutputStream zugreifen?

Danke im Vorraus.

 

[tuxedo]

Sorry, muss mich da irgendwie geirrt haben... Die Data*Streams haben doch nix zum senden und empfangen von Objekten

Aber es sollte ja nicht so das Problem sein die Data*Streams zu extenden und Methoden zum lesen und schreiben von Objekten mittels Object*Streams bereit zu stellen.

- Alex

 

[H3llGhost]

Macht ja nichts ...
Ich bin jedem Rat dankbar und Irren ist doch menschlich oder wie heißt noch das Sprichwort?

Wäre es dann nicht einfach gleich die Object*Streams zu nutzen?
Weil dem Erweitern von bestehenden Klassen bin ich nicht so mächtig ...

 

[tuxedo]

Sofern du ausschließlich Objekte senden muss: Ja.
Ansonsten: Nein.

 

[H3llGhost]

Hmm ...
Was macht denn mehr Sinn?

Also ich hatte vor eine Klasse zu machen in der alle Serverantworten stehen und zusätzlich in der Klasse einen Hashwert mitgeben, um zu überprüfen, dass die Nachricht korrekt angekommen ist.

Bis jetzt habe wir pro "Zeile" (Teilstück) einer Nachricht immer die Funktion writeUTF() benutzt.
Es ist uns leider aufgefallen, dass teilweise die Funktion langsamer wird und da wir jetzt wohl auch Dateien schicken wollen sind wir auf den Object*Stream gekommen.

 

[homer65]

Ich benutze für Client Server Anwendungen immer den ObjectOutputStream (ObjectInputStream), da ich es sehr komfortabel finde Objecte zu übergeben. Über die Performance kann ich nicht viel sagen, hatte da noch keine Probleme. Aber es ist sehr bequem so zu programmieren.

 

[tuxedo]

@homer65

Wenn du einen long-Wert schicken willst dann sind das mit DataOutputStream 8 byte. Beim ObjectOutputStream wird dein primitiver Datentyp in ein Long-Objekt gewandelt und als solches übertragen. Das sind dann mehr wie 8 Byte. Hinzu kommt dass von long nach Long "konvertiert" wird und das Objekt "aufwendig" serialisiert werden muss.

Das gilt AFAIK für int, short, byte, long und String.

Wenn du immer nur Objekte schickst, dann gibts da auch nix zu optimieren.

@H3llGhost
Wieso schickst du einen Hashwert mit? Wenn du mit TCP kommunizierst stellt TCP für dich sicher das alles so ankommt wie's gesendet wird. Doppelt prüfen macht die Sache nicht besser.

Dass das schicken von String via DataOutputStream über writeUTF() langsamer wird kann ich nicht bestätigen... Muss an was anderem liegen. Wenn ihr nur Strings schickt würde ich bei Data*Streams beleiben. Das ist effizienter.
Hinzu kommt, dass Object*Streams to geschickten Daten cachen. Wenn du also ständig neue Objekte hast und du den Cache nicht regelmäßig leerst, fliegt dir bald alles um die Ohren. Siehe dazu: [JavaSpecialists 088] - Resetting ObjectOutputStream


- Alex

 

[H3llGhost]

Danke für den Artikel.
Und danke für die Antwort bezüglich des Hashwertes ...

Was halt der Grund ist warum ich den Object*Stream nutzen möchte ist halt die Möglichkeit der Serialisierung.

EDIT:
Fehler behoben.

 

[tuxedo]

Nochmal: DataOutputStream "serialisiert" auch. Aber eben für einfache Datentypen auf einfachere und performantere Weise.

Wenn du also nur einfache Datentypen hast, nimm Data*Stream. Wenn du aber ein tatsächliches Objekt hast, nimm Object*Stream.

Serialisieren (also das zerlegen des typs/objets in einzelne Bytes) und deserialisieren (das umkehren der vorangegengenen Serialisierung) tun beide Klassen.

- Alex

 

[H3llGhost]

Kann ich auch Datentypen wie ArrayList etc. serialisieren mit dem Data*Streams?

 

[tuxedo]

Eine ArrayList ist kein einfacher Datentyp und die Data*Streams bieten dafür ja auch offensichtlich keine Methode an, oder?

Oder einfacher gesagt: Wenn du etwas nicht über die Data*Streams geschickt bekommst: Nimm Object*Stream. Ansonsten Data*Stream. Auskunft über das was Data*Stream kann erteilt die JavaDoc ...

- Alex

 

[H3llGhost]

Oder ein gut konfiguriertes Eclipse ...
Vielen Dank für eure Hilfe.

 

[tuxedo]

Oder ein gut konfiguriertes Eclipse ...

Was ja nix anderes tut als das passende JavaDoc zu konsultieren ...