Socket Client liest leeres Objekt

[Scarabol]

Hi Leute,

mein "Server" schickt ein Object vom Typ KlasseA an den Client so:

Socket connection;
/* ... */
dataOut = new ObjectOutputStream(connection.getOutputStream());
/* ... */
dataOut.writeObject(InstanzVonA);

connection ist eine bestehende Verbindung und wenn ich bei writeObject einen Breakpoint setze sind alle Member von InstanzVonA gesetzt, wie ich es erwarte.

Nun zu meinem Problem:
Wenn ich auf der Client Seite das Object wie folgt auslese, sind alle Member Variablen "null".

Socket socket = new Socket(hostname, port);
/* ... */
dataIn = new ObjectInputStream(socket.getInputStream());
/* ... */
obj = dataIn.readObject();
if (!(obj instanceof KlasseA)) {
System.err.println("Error");
} else {
KlasseA allesLeer = (KlasseA)obj;
// hier der Breakpoint, aber alles ist leer???

Woran liegt das?

 

[nillehammer]

Java Practices -> Implementing Serializable Dort ist erklärt, wie man bei Implementierung von Serializable mindestens die Methoden "private void readObject" und "private void writeObject" implementiert, damit es klappt. Wichtig ist der Aufruf von defaultReadObject/defaultWriteObject.

 

[Scarabol]

Cool, danke für den guten Link hat meinem Verständnis sehr auf die Sprünge geholfen.

So wie ich das jetzt verstehe muss ich den Konstruktor mehrfach implementieren?
Oder ist eine private init() Funktion sinnvoll?
Gibt es noch eine andere Möglichkeit? Halte beide Lösungen für schlechten Stil, aber korrigiert mich bitte.

Was haltet ihr für den besten Stil?

Gruß
Scarabol

 

[nillehammer]

So wie ich das jetzt verstehe muss ich den Konstruktor mehrfach implementieren?

Nein, das musst Du nicht (zumindest nicht wegen Serialisierung). Manchmal kann kein Konstruktor, der alle (Pflicht-)Felder initialisiert aber recht praktisch sein.

Oder ist eine private init() Funktion sinnvoll?

Auch hier wieder: Nein, nur für Serialisierung ist das nicht sinnvoll. Wenn Deine Instanz einen Lebenzyklus durchläuft (bspw. init, start, stop, destroy wie ein Applet) kann es sinnvoll sein. Bei reinen Datenklassen fällt mir aber im Moment nicht ein, wo das sinnvoll sein könnte.

Was haltet ihr für den besten Stil?

Bei Serializables die Methoden "private void readObject" und "private void writeObject" implementieren und als jeweils erste Zeile defaultReadObject/defaultWriteObject aufrufen. Bei readObject ggf. noch den internen Status der Instanz validieren.

 

[Scarabol]

Bei welchen Member Datentypen muss ich diese extra in writeObject in den Stream schreiben bzw. wann muss ich diese extra mit readObject auslesen?

Also muss ich z.B. LinkedList<>, double oder eine Instanz meiner KlasseB extra in writeObject reinschreiben?

Gruß
Scarabol

 

[Scarabol]

juhu, denke ich habs verstanden. Man muss nur besondere Maßnahmen in der readObject Methode durchführen.

Warum meine Objekte dann leer sind versteh ich trotzdem nicht???

 

[irgendjemand]

könnte daran liegen das die klassen deiner member-objekte nicht Serializable implementieren *was bei primitiven datentypen sowieso nicht der fall ist*

hat allgemein auch was mit dem thema clone and depp-copy zu tun ... da hierbei in etwa das gleiche gemacht wird ... nur das zwischendurch die daten via stream verschickt werden ...

warum du allerdings objekte austauschst ... hmm .. mir würde nur RMI einfallen .. ansonsten sollte sich (fast) alles so implementieren lassen das du lediglich die raw-daten verschickst *alternativ codiert* und auf der anderen seite daraus selbst ein neues objekt baust anstatt dich mit serialisierung auseinander zu setzen

 

[nillehammer]

Also muss ich z.B. LinkedList<>, double oder eine Instanz meiner KlasseB extra in writeObject reinschreiben?

Mit der von mir geschilderten Methode werden alle Membervariablen serialisiert/deserialisiert. Das klappt, solange alle Member auch Serializable sind. Bei primitiven Datentypen (int, double etc.) und ihren Wrappern ist das der Fall, bei Strings auch. Anders kann es bei komplexeren (evtl. selbst definierten) Klassen/Datentypen aussehen.

Konkret zu Deiner Frage, wenn KlasseB nicht Serializable ist, bekommst Du eine Exception beim Versuch, es zu serialisieren. Du musst dann entweder KlasseB selbst Serializable machen oder Du machst das entspr. Member transient und behandelst es speziell.

Bei Klassen aus dem Collections-Framework (List, Set, Map etc.) verwendet man i.d.R. die Interfaces als Datentypen und initialisiert sie mit einer geeigneten Implementierung (z.B. LinkedList als Implementierung von List). Die Interfacetypen sind selbst nicht Serializable, die Implementierungen meistens schon. Hier kannst Du also entweder bequem sein und Dich darauf verlassen, dass Du immer nur eine Serializable Implementierung verwendest. Dann greift der default-Mechanismus. Ein kleines Restrisiko bleibt aber. Wenn Du hier ganz sicher gehen willst, musst Du auch diese Member transient machen und speziell behandeln.

 

[ARadauer]

Zeig einfach mal die Klasse KlasseA

 

[Scarabol]

Hi,

mein Problem war, dass alle Instanzen meiner Objekte im Stream gebuffert wurde, sodass immer das gleiche Object gesendet wurde auch wenn es sich zwischenzeitlich verändert hatte wurde trotzdem das "alte" Object ohne Änderung geschickt. Konnte diese Problem lösen, indem ich einfach ein reset() vor jedes writeObject gesetzt habe, so wird immer das aktuellste Objekt geschrieben.

Neuse Problem ist eine StreamCorruptedException die früher oder später auftritt:

java.io.StreamCorruptedException: unexpected end of block data
	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1369)
	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:369)
	at Client.run(Client.java:30)

Wann/Warum bekomm ich eine StreamCorruptedException?
Wenn Client und Server gleichzeitig in den Stream schreiben ohne das jemand liest?
Wenn ein Object nicht komplett in den Stream geschrieben wurde? (sollte doch eiglt. von Java ausgeschlossen sein, oder?)
Durch den übermäßigen (Miss/Ge)brauch von reset()? (Also vor jedem writeObject bzw. readObject())
Da die Exception oft schon am Anfang fliegt: Speichert die VM Teile der Verbindung zwischen? Sodass "Reste" des alten Versuchs zu beginn eines neuen übertragen werden?

Ziel des ganzen ist es, dass sich die Spielfigur bei SpielerA synchron mit ihrer Kopie bei SpielerB bewegt.

Vielen Dank für eure Hilfe
Scarabol

 

[Scarabol]

Juhu!

Ich konnte auch das StreamCorruptedException Problem lösen. Es lag einfach daran, dass das Timeout bei Lesen aktiviert wurde auch wenn der Socket gerade dabei war ein Object einzulesen.

Zusammenfassung:
"leere" Objekte:
Die Objekte in einem ObjectOutputStream werden gecached daher immer, wie folgt schreiben:

out.reset();
out.writeObject(obj);
out.flush();

StreamCorruptedException:
Außerdem sollte (vor allem wenn "große" Objecte gesendet werden) ein nicht zu kleines Timeout (< 10ms) gewählt werden, sondern ausreichend Zeit eingeplant werden (> 20ms) bzw. gar keine Timeout benutzt werden. Da die Zeiten je nach Hardware und Performance stark variieren können.

socket.setSoTimeout(20);

Gruß
Scarabol