transmission efficiency of serialized objects

Networking & Multiplayer
#1

I am currently implementing the network layer for my game. I am going to be using Serialization when a client joins the server so that it can get the updated “game state”, ie. a snapshot.

Once a client has the snapshot, they will receieve a constant stream of delta packets, ie. updates containing actions (eg. Player 1 does action X).

I am really loving Serialization, it is quite a powerful tool and one I have not played with before. My question is - is it suitable for the frequent update packets? I guess what I am really asking is - is there much overhead?

The other solution obviously is to encode->send->decode the data using some other protocol (most likely self-defined) but that’s an extra step which Serialization can take out - everything can simply be placed in a ‘Packet’ object and it comes out at the other end. From a coding point of view Serialization would be easiest but is it wasteful of resources?

I am definitally using Serialization to download the snapshot - no doubt about that as the overhead impact is minimal in that case because it happens very infrequentally.

TCP will be what I use for all Server->Client communication, Client to Server actions could be UDP but until I see a real need for it they will be TCP as well. I am following the TCP vs UDP thread with interest.

Cheers,

Will.

#2

Hi
As you say, the initial connection is relativly low frewquency, as as long as you can control what objects are in your game state snapshot you will be ok serialising that. The regular updates are a bit trickier, I would be very cautious about using serialisation there. Best thing I can think of right now is try try knocking up some example messages (just force the data) and try serialising them to disk, see what size you end up with, then try the same with an ‘update message’ type object and dump the bytes to disk, compare the sizes, i’d be interested in hearing the results.
As for the TCP v.s. UDP thing, if your using deltas then you need guarunteed delivery, stick with TCP, and as for the client-server stuff, you definitly need reliability here, so TCP again. The only thing I use UDP for is sending my game state from the server to the client, and I send fresh data every time, not deltas. It sounds like for you TCP is the best bet (IMHO).
Post back with the results of the data sizes if you try it, I would be interested to find out :slight_smile:

Cheers

Endolf

#3

AFAIK, the overhead consists mainly of class names + some protocol. So you get easily >100bytes per message.

My feeling is that for simple data updates (containing ‘small’ objects like a vector3f or so), the overhead will be significant.

If the delta-update is a double[1000], the overhead might be not noticable.

And - if the objects are simple, not complex, not interconnected, not graph-like … using a ByteBuffer e.g. for encoding/decoding is no effort.

#4

Others have said this BUT:

(1) the VM serializes and deserailizes very quickly. Im using serialization to store freeze dried objects in an in memory database system and Im seeing query times including serialization/deserailization in tenths of milliseconds.

(2) In terms of bandwidth, you’ve got a header and then a “tag” per field. Its not insubstantial percentage wise but may not be terribly significant in terms of your over all bandwidth depending on how much you are/aren’t flooding the pipe.

(3) Like any power tool you CAN hurt yourself with serialization. I have some great horror stories about corporate clients who serialized massive (200meg) graphs of objects :slight_smile:

See this chapter of our book for Serialization gotchas and how to avoid them. Keep in mind that it was written for Enterprise developers who tended to over-use the mechanism:

http://java.sun.com/docs/books/performance/1st_edition/html/JPIOPerformance.fm.html#11106

#5

Oh and yes.
I think its one of the most under-rated facilities of Java, right after custom class loaders. i find it much more useful in general practice then the over-vaunted but still cool Reflection.

#6

Thank you all for your excellent responses.

I have done a little bit of testing as suggested.

The class:


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):


srcom.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.

#7

Outside of maybe a bit more memory overhead for DOS at run time i can’t thin kof any reason not to use it.

The big advantage of Serialization is when you don’t actually know the structure of the data being passed. If you know apriori the data youa re pasisng then yeah you can just built packets.

I use Serialization in two places currently:

(1) I pass a UUID type for identification in a numebr of palces. The code that uses the UUID and passe sitr abck and forth does not know how its implemented.

This enables better object oriented code. Granted you could do the same thing by implementing a “communicatable” interface that had a “writeBytesToStream” method but this is built in and thus more convenient.

(2) I have a shared data manager with a generic SharedData wrapper that allows for arbitrary variables of arbitrary types to be coordinated among multipel processes. (Kind od a minimal JSDT.) The wrapper knwos how to coordinate and communciate the values but the actual value is a passed in Serializable that gets serialized using ObjectOutputStream. This allows one wrapper and one class to handle distributing vbirtually any class.

So in general Serialization is msot powerful and useful, IMO, in those cases where you want to communicate the value of an object at run-time where you have no idea at compile time what that object’s actual class will be :slight_smile: