🔒 Locked

Java Networking Directions

Started by Ivan K Apr 8, 2009 at 8:47 PM 3 replies 1.3k views

Original Post

Apr 8, 2009 at 8:47 PM

Hello everyone ! I apologize in advance for my question which is probably going to sound silly to you experienced game developers. I am currently working on a 2D, online, real-time, OGame-like game. The game is developed in Java. I am thinking about the networking aspect of the application, whith the following constraints : - Numerous simultaneous connexions (let's say a hundred, tops) - Web-browser based game, in a JApplet. I have considered the following options : - Sockets : I have some experience with Sockets in Java, since I have already developed a functional LAN game with them. Still, it was a 4-player game and I'm not too sure they are suited for "massive" multi-player games. - Java RMI Protocol : although this theoretically does exactly what I need, it is a real pain to use and I have been unable to set up an extremely simple RMI Server locally (and boy did I try). When I read that setting it up online when the game is finished is just as bad, I gave up. - Sun's Darkstar Project : it seems a little overkill for what I'm trying to do. Moreover, it looked a bit difficult to use. You may find an early version of the game interface at the following address : http://fc.isima.fr/~kwiatkow You'll have to be patient though. Since a new map has to be randomly generated, it may take up to 60 seconds to launch. My aim is to have one of those maps created by the server at the beginning of the game, and then to have multiple players play on it. In the end, my question is : what technology/protocol would you advise me to use ? Thank you in advance for your kind help ! Ivan

hplus0603

Mod

3,014

hplus0603

Apr 9, 2009 at 11:57 AM

RMI is not suitable for games.

Darkstar is mostly a data transaction server system, not a networking system per se. And, evenso, I would want to be able to query my data with SQL, which you can't do in Darkstar (it stores Java objects as key/blob pairs). However, if you want to learn it, there's nothing wrong in trying it.

I would recommend using sockets through the java.nio package.

Ivan K

Author

Ivan K

Apr 9, 2009 at 12:09 PM

Thanks a lot for your answer.
I have another question then : I read in the FAQ that it is generally not a good idea to create a thread for each connected client.
Still, I don't really know how else to do. Let's assume I use an ObjectOutputStream (oos) and an ObjectInputStream (ois) for each client. To receive messages, I have to use the following method : ois.readObject(). But when I do, the application remains locked until I actually receive something, which means that there is no way to listen to everyone at the same time... Unless I create a separate thread for each client.
Is there a way around that ?

Aldacron

208

Aldacron

Apr 10, 2009 at 11:02 AM

Quote:
Original post by Ivan K
Thanks a lot for your answer.
I have another question then : I read in the FAQ that it is generally not a good idea to create a thread for each connected client.
Still, I don't really know how else to do. Let's assume I use an ObjectOutputStream (oos) and an ObjectInputStream (ois) for each client. To receive messages, I have to use the following method : ois.readObject(). But when I do, the application remains locked until I actually receive something, which means that there is no way to listen to everyone at the same time... Unless I create a separate thread for each client.
Is there a way around that ?

Yes, with the java.nio package. You work with Channels (ServerSocketChannel, SocketChannel) and ByteBuffers rather than streams, using Selectors. A single Selector can handle numerous channels in a single thread. There are a handful of books covering all of this and several tutorials online.

Antheus

216

Antheus

Apr 10, 2009 at 11:14 AM

Quote:
Original post by Ivan K

Let's assume I use an ObjectOutputStream (oos) and an ObjectInputStream (ois) for each client. To receive messages, I have to use the following method : ois.readObject().

To send a packet:
- Serialize object to temporary buffer 'a'
- Write size/length of 'a' to network stream
- Copy bytes from 'a' to network stream

To read a packet:
- check how much data is .available() on input stream, and append that data into a temporary buffer
- once at least 4 bytes are in temporary buffer, read length 'l' from it
- keep checking .available() and appending data into temporary buffer until it has at least 'l' bytes in it
- deserialize object from temporary buffer

This method doesn't need threads, regardless of whether plain or NIO sockets are used.

The alternative is to develop custom serialization mechanism, which would also avoid length being stored twice, but the above should get the job done for starters.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.