Thank you all for your excellent responses.
I have done a little bit of testing as suggested.
The class:
1
2
3
4
5
6
7
8
9
10
| package com.removed.game;
public class GameState implements Serializable {
public String mapName = "Test Map";
public String landMass = "Blar";
public int score = 10;
} |
Became (displaying bytes as chars):
1
2
| sr com.removed.game.GameStateﾣ=ﾸￂ￢MￃXIscorelandMasstLjava/lang/String;LmapNameq~xpxterm
tBlarTest Mapt |
That's ~100 bytes and is as Herkules said class and variable names.
However - primitive types are handled differently, in fact near identical to DataOutputStream (except for the occasional byte of overhead).
Jeff, I agree it is very powerful and thank you very much for that link - that was info I was looking for (ie. how to rebuild the data which doesn't need to be sent down the line).
Considering I am going to be targeting dial-up users and am hoping to send several packets per second, I do need to keep overhead to a minimum.
Here are my conclusions so far:
* Any complex graphs of objects are best sent by Serialization, game initialisation snapshots are prime candidates here.
* Simple data storage objects are best just broken down into primitives in the usual way and rebuilt at the other end. Using Serialization creates overhead with little benefit for simple objects.
As almost everything you can do in DataOutputStream you can do in ObjectOutputStream and as efficiently - is there any problem with using an OOS where you would normally use a DOS that I haven't seen? The obvious added benefit of the OOS is that sending an object is as simple as writeObject.
Will.
