Client/Server and jME?

I've heard something about using headless applications for making servers. Is there somewhere a tutorial that can explain me how to use a client/server model (for MMORPG's , FYI)?

Thanks in advance,

  • SeySayux

You can try to use Java Game Networking through the jME-Networking connector.

Thanks for the tutorials, but… I was actually looking for a jME specific tutorial, about the HeadlessGame class. I'm using my own implementation of client/server (just normal


What kind of game are you developing?

an MMORPG (see first post)

Please tell me it's not another space game?  :stuck_out_tongue:

No, I personally don't like space games. It's a fantasy themed game (although I'm planning to add some sci-fi themes later on)

darkfrog just doesnt want the competition  :stuck_out_tongue:

StandardGame has support for running in headless mode.  That's what I'd recommend there.

I pity you if you decide to write a MMO using Sockets.  Sockets are blocking and thus require a thread per connection.  This means it will not scale well.  JGN is non-blocking IO and has support for TCP and UDP so everything can be run in a single thread or in multiple threads, it doesn't really care.

I've personally a lot of experience writing client/server models with sockets. I've used, modified and wrote a lot of software using sockets, so I'm very used to sockets. I don't want to start learning a new way again, restructuring my whole development plan. But thanks for pointing me to StandardGame – I'll take a look on it.

EDIT: I've just looked at a tread about JGN – it seems very promising. So, if something changes on a client (i.e. character moves, …), it will automatically be updated on all servers and clients? That would reduce me a lot of work, indeed (so I don't have to implement these things using sockets… a lot of sockets…)

JGN has an extension API called jME-Networking that provides synchronization of spatial objects.  That gives you very easy capabilities to synchronize your scenegraph objects throughout your game.

JGN is extremely simple an really easy to learn since it's all about sending Message objects back and forth (which are basic beans) and adding listeners to deal with those messages appropriately when they are received.

If you have a lot of experience with Sockets you know that you'll need a thread for every connection to the server and in a massively multiplayer game you've hundreds if not thousands of people potentially connected at a time.  Sure Sockets are fine for most web sites, but that's because 1) they connect to download their data and drop the connection and 2) are not constantly sending lots of data back and forth that needs to be as close to real-time as possible.

It is for scenarios like this that non-blocking IO exists.  Whether you use JGN or not you should be using NIO if you're going to be developing a MMO.

I think I'm going to use JGN. Do you have a good tutorial for it, except for those code examples?

There are a ton of tests in the JGN source itself, but that's about it.  I've been sidetracked on another project and haven't had time to write anything for it lately.  Drop a message in the forum if you have any questions for now and if you find the API useful consider writing a tutorial as you're getting going on your project.

OK, thank you very much for the information, I'm going to use it as soon as I get my character movements  & gui working properly

All sockets in Java do block, but there are more efficient ways than making a thread per socket.  :stuck_out_tongue:

But, this comes down to making a good client/server architecture, so you can modify the innards without worrying about changing the using classes.  For my architecture, I'm currently using sockets, but it'd be just as easy to change it to use nio and Channels…which is a bit overcomplicated imo.

I was referring to SocketChannel actually, which is what JGN uses, which is entirely non-blocking.  I definitely agree that NIO is overly complicated (to do right).  Such is why JGN exists. ;)  It provides all the power of NIO without the hassle of figuring out the mess of it.

Where did those examples go  :?

Another thing you may want to look into is NOT using TCP. That is just asking for network latency…

Adore said:

Another thing you may want to look into is NOT using TCP. That is just asking for network latency...

Yes, but UDP brings the issues of non-guaranteed delivery and potentially getting messages out of order. In my opinion, a well developed game will utilize both TCP and UDP where they make sense gain the benefits of each.

Exactly what Darkfrog said.  You don't want parts of messages disappearing in transit, do you?  However, you can afford losing a few updates of player positions, as it'll be corrected over time.  Both TCP and UDP are useful…

However, if you want the most robust system you'll have to do a modified UDP to re-invent the wheel for some of TCP's functionality, or use a networking engine that can - Darkfrog + JGN might be your path :wink:

If you're interested in some info about latency and client/server concerns, here's an article to read:

I know, it's not the best of papers, but it might help.