I've been wondering what would be a good approach to cluster and can't seem to find a good solution.
Very basically the design of my game will look like this:
The server side has 1 main running program. Clients connect to it to enter the lobby. Whenever a client wants to start a game the main server program will start a sub-program which handles the game. You should imagine that a lobby holds for instance hundreds of players and that ten's of games are played simultaneously. To scale this with a cluster each sub-program needs to be a seperate process. With other words, you need to start multiple JVM instances where each JVM runs its own sub-program. To make it even more complicated, the main server program will need to have access to the sub-program. For instance to exchange scores etc.
Till now I've found 3 possible solutions.
Looking on google gave me 2 hits: the Process builder (which was introduced with Java1.5) and the older method of creating a runnable process. This actually is used to run external programs (ie. Notepad/IExplorer etc.) but could also be used to run a Java class I would suppose. Communication between the two processes would be a bit ugly though. You'd have to use Input and Output streams.
While writing this however I suddenly got the idea of using JGN to handle the communication between the two processes. Uncertain if it would work but it sure is cleaner than messing arround with streams.
A VM that takes away all the troubles of clustering. For some reason though it was cancelled in 2000.I am unsure why because It seemed like a good solution in comparison with the other possible approach mentioned above.
However a solution as cJVM would also meaning having to use a JVM that might not be supported really well.
I am still thinking what would be the best way, im hoping for some input here as a fresh new perspective on this is always welcome!
There's a lot of potential problems with something like cJVM. I've looked at similar systems in the past and decided that they were potentially too much of a hassle to use.
JGN would be a really easy to to handle that and doing socket level communication is a common way for applications to communicate these days (particularly if they are multi-platform).
Sounds to me like it would also fit within project darkstar. Thats designed to work in a clustered environment, designed to be able to split off areas of the data model for processing separately. It also handles failover. You don't mention if the game is a real time twitcher (quake/doom style), or more of a board/card/rpg style game. That may influence the advice given here.
Sounds to me like it would also fit within project darkstar. Thats designed to work in a clustered environment, designed to be able to split off areas of the data model for processing separately. It also handles failover. You don't mention if the game is a real time twitcher (quake/doom style), or more of a board/card/rpg style game. That may influence the advice given here.
Endolf
Is Darkstar really an option? Given the licence it's being released under? In the end I hope to go commercial which might bring difficulties. Besides that, after reading some posts about it on the forum, Darkstar is pretty complex and brings a large overhead.
And about the games.. they'll more or less be simple games. Like chess or snooker. Definatly not in the regions of MMORPG complexity.
I appreciate your advice though about Darkstar, it has been a possibility but for now I've decided to stick with JGN as networking. As far as I can remember Darkstar is only interesting when making big/large games. I've actually asked this question before (JGN vs Darkstar) unfortunately I can't find the topic since the forum search is letting me down
Edit:
Found it:
http://www.jmonkeyengine.com/jmeforum/index.php?topic=3298.0
Yea, more or less came to the same conclusion even though I didnt get too deep into it.
JGN could handle it perfectly I would think since the data that needs to be acessible are only a few numbers and strings. Im wondering though how it would work on a cluster environment. For instance, say you have the lobby which has a messageserver on port 2000. Then you have 5 game processes with their own MessageServers running on port 2001 to 2010 (5x UDP and TCP). Now whenever I create a JGNClient on a game process, to communicate with the lobby's messageserver, you have to assign a port that will be used by the JGNClient. However, this would eventually mean that I would have to use 3 ports for one game process. Since there are "only" 65K ports, isn't this bad design from a scalability point of view?
I've done clustering tests with JGN and it works fine.
Well, if you're ever running 65k ports you've got bigger issues anyway, so no, I don't think it matters much. :o
Yea, more or less came to the same conclusion even though I didnt get too deep into it.
JGN could handle it perfectly I would think since the data that needs to be acessible are only a few numbers and strings. Im wondering though how it would work on a cluster environment.
Its a very good network-api written in Java and used by JBoss.org for clustering the jboss application server. Im using jgroups for communication between my clients and the server (p2p, p2s). It's fast and simple to use.
BlackBlue, any reason you didn't consider JGN instead?
I've looked at JGroups before and there were various reasons I chose not to use it, but it's not a bad API. The biggest gain you'd likely see in comparison is that JGN is designed specifically for game development.
BlackBlue, any reason you didn't consider JGN instead?
I've looked at JGroups before and there were various reasons I chose not to use it, but it's not a bad API. The biggest gain you'd likely see in comparison is that JGN is designed specifically for game development.
our game it not realtime oriented. the backend is a jboss apllication server that hold the whole buisinesslogic. jgroups is a part of jboss, so we use this ;)
i will try a look at JGN for a little realtime game soon ;).
