aspose file tools*
The moose likes Game Development and the fly likes Game Server nio package vs. ObjectOutputStream Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » Game Development
Bookmark "Game Server nio package vs. ObjectOutputStream" Watch "Game Server nio package vs. ObjectOutputStream" New topic
Author

Game Server nio package vs. ObjectOutputStream

Barry Andrews
Ranch Hand

Joined: Sep 05, 2000
Posts: 523

I know this could go in the "I/O and Streams" forum, but since my topic was derived from a Java games book I thought I would try here first.

In chapter 6 of "Developing Games in Java" by Brackeen, there is a whole section on how to write a game server. In the example, the communication is done with the java.nio package. When the client talks to the server he passes a GameEvent object that contains information like type, game name, message, player id, session id, etc. But, this GameEvent is not sent as a whole. So for each of the data types contained in the object, there is a method call on ByteBuffer; for example bb.putInt(1); bb.putStr("player 1"); etc. Then on the server, this data is received and a GameEvent is constructed out of it. But I am scratching my head trying to figure out why ObjectInputStream/ObjectOuputStream was not used instead. Is the nio package really that much better than this method of transferring objects from client to server? I believe the purpose of using nio was so there would not be so many threads on the server, since a regular Socket's read() method blocks. I guess I am just looking for a confirmation that this is correct since I don't necessarily go by everything I read.

Any ideas/comments?
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24187
    
  34

NIO is, by design, fast. It's designed to use your OS's fastest available I/O mechanisms to transfer blocks of data.

Plain old serialization -- i.e., the default serialization you get if you don't write your own writeObject() or externalizeObject() methods -- is slow. Really slow.

In a game server where you need to send lots of data to many clients simultaneously, the difference could be truly enormous.


[Jess in Action][AskingGoodQuestions]
Barry Andrews
Ranch Hand

Joined: Sep 05, 2000
Posts: 523

Thanks for the response! So just to confirm... even though you have to do multiple puts for each member, this is faster than doing a single transfer of the object itself? It seems it would be faster to just send the object all at once.
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24187
    
  34

The ObjectOutputStream also does multiple operations; they're just all done "behind the scenes".

This is an example of a general principle in computer programming, really: the tradeoff between performance and convenience. It's often the case that by doing extra work (as here) you can make your program perform better. Some people get obsessed with performance, spending a week of programmer time to save a few minutes of user time. Always try to make this choice wisely.

You might want to check out Jack Shirazi's book "Java Performance Tuning," which includes a section in which he starts off with a plain Serialization application, and improves the performance by something like two orders of magnitude, a step at a time, by implementing more and more by hand.
Barry Andrews
Ranch Hand

Joined: Sep 05, 2000
Posts: 523

The ObjectOutputStream also does multiple operations; they're just all done "behind the scenes".


Ah... I didn't realize this. Very interesting! Thanks for the help and the book reference!
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Game Server nio package vs. ObjectOutputStream