5

Quick design question: I need to implement a form of communication between a client-server network in my game-engine architecture in order to send events between one another.

I had opted to create event objects and as such, I was wondering how efficient it would be to serialize these objects and pass them through an object stream over the simple socket network?

That is, how efficient is it comparatively to creating a string representation of the object, sending the string over via a char stream, and parsing the string client side?

The events will be sent every game loop, if not more; but the event object itself is just a simple wrapper for a few java primitives.

Thanks for your insight!

(tl;dr - are object streams over networks efficient?)

WATWF
  • 65
  • 1
  • 5
  • 1
    I'd recommend firing up a copy of Wireshark (http://www.wireshark.org/) and testing yourself. – Brad Nov 03 '11 at 21:05

2 Answers2

5

If performance is the primary issue, I suggest using Protocol Buffers over both your own custom serialization and Java's native serialization.

Jon Skeet gives a good explanation as well as benchmarks here: High performance serialization: Java vs Google Protocol Buffers vs ...?

If you can't use PBs, I suspect Java's native serialization will be more optimized than manually serializing/deserializing from a String. Whether or not this difference is significant is likely dependent on how complex of an object you're serializing. As always, you should benchmark to confirm your predictions.

The fact that you're sending things over a network shouldn't matter.

Community
  • 1
  • 1
tskuzzy
  • 35,812
  • 14
  • 73
  • 140
1

Edit: For time-critical applications Protocol Buffers appear a better choice. However, it appears to me that there is a significant increase in development time. Effectively you'll have to code every exchange message twice: Once as a .proto file which is compiled and spits out java wrappers, and once as a POJO which makes something useful out of these wrappers. But that's guessing from the documentation.
End of Edit

Abstract: Go for the Object Stream

So, what is less? The time it takes to code the object, send the byte stream, and decode it - all by hand - or the time it takes to code the object, send the byte stream, and decode it - all by the trusty and tried serialization mechanism?

You should make sure the objects you send are as small as possible. This can be achieved with enum values, lookup tables and the such, where possible. Might shave a few bytes off each transmission. The serialization algorithm appears very speedy to me, and anything you would code would do exactly the same. When you reinvent the wheel, more often than not you end up with triangles.

Mike Adler
  • 1,199
  • 9
  • 24
  • As soon as performance (or small serialization size) is important, going with the native Java implementation is always the wrong decision, really. Protobuf isn't much more complicated anyhow, offers cross language support and is just way, way WAY faster. Not even funny if serialization w/ java intern takes 40ms while protobuf does it in <2.. – Voo Nov 03 '11 at 21:48
  • @Voo is that 40ms a real measured figure? – user207421 Nov 04 '11 at 04:41
  • Have looked into the ProtoBuf doc now. Too bad, that would have been useful nine months ago when I set up the comm infrastructure. As is, the native serialization works like a charm and is sufficiently fast for my purposes (round-trip-time of about 50-100ms for serialization, sending to server in LAN, deserializing, server-side processing, re-serializing and sending back to all clients). Maybe add a couple dozen ms for WAN trips and you're plenty fast enough for most applications. – Mike Adler Nov 04 '11 at 08:54
  • @EJP Yep, obviously not one message but something like 100k or more messages. Your mileage may vary, but assuming a performance difference of at least 1:10 seems reasonable on average - and it can be much worse. [See here for official benchmarks](http://code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking) – Voo Nov 04 '11 at 13:47
  • @MikeAdler Not really. You create the .proto file and the ProtoBuf compiler generates the correct classes for you automatically. The only difference between ProtoBuf and Serialization is then that for one you use a simple bytestream and for the other an ObjectStream. If you have existing classes, you basically have to change your getters/setters to work through the generated file (i.e. instead of `getX() {return x;}` we get `getX() {return storage.x;}` or something). – Voo Nov 04 '11 at 13:58