Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (536)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  transmission efficiency of serialized objects  (Read 1565 times)
0 Members and 1 Guest are viewing this topic.
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Posted 2003-11-25 11:23:52 »

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.

Offline endolf

JGO Coder


Medals: 7


Current project release date: sometime in 3003


« Reply #1 - Posted 2003-11-25 11:37:10 »

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 Smiley

Cheers

Endolf

Offline Herkules

Senior Member




Friendly fire isn't friendly!


« Reply #2 - Posted 2003-11-25 11:41:19 »


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.


HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Jeff

JGO Coder




Got any cats?


« Reply #3 - Posted 2003-11-25 22:26:03 »

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 Smiley

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


Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline Jeff

JGO Coder




Got any cats?


« Reply #4 - Posted 2003-11-25 22:27:07 »

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.

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #5 - Posted 2003-11-26 04:54:57 »

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

Offline Jeff

JGO Coder




Got any cats?


« Reply #6 - Posted 2003-11-26 05:45:53 »

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 Smiley



Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

CogWheelz (15 views)
2014-07-30 21:08:39

Riven (21 views)
2014-07-29 18:09:19

Riven (14 views)
2014-07-29 18:08:52

Dwinin (12 views)
2014-07-29 10:59:34

E.R. Fleming (32 views)
2014-07-29 03:07:13

E.R. Fleming (12 views)
2014-07-29 03:06:25

pw (42 views)
2014-07-24 01:59:36

Riven (42 views)
2014-07-23 21:16:32

Riven (30 views)
2014-07-23 21:07:15

Riven (31 views)
2014-07-23 20:56:16
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!