Heyas just asking for some design pointers. Lets say on an MMO we have a client server architecture (obviously) while the client sends and receives messages on its own personal socket there is no reason why we should limit the server to one socket. My opinion would be to design the server to listen in several ports (thus creating a server for each part of the code), one thread per listening socket. So for example we could have a thread that listens to login requests. This also is responsible for sending pings to ensure client is still connected. Other thread is solely responsible for chatting, receives a message from client, polls game for target of message, sends message to target. And lets just add the final thread: Game thread. This one receives and processes game data. Though im not into multithreading im assuming there is a way to say that the game thread has more priority than the login thread or some other mechanism. This would mean that whenever possible the server would process login requests and chat messages but would focus mainly only on the game. This sounds like a good model for me, please feel free to comment on it and if you find any flaws i would definately appreciate the input. However there is something i particularly dont like about it: Its based solely on one server. There is no way to break the game into more than one computer. I would rather take each thread and stick them into separate processes. If you choose to run them in the same computer, fine it would be similar to using thread, else it would enable you to speed up the game since the game thread wouldnt have to pause once in a while to process chat messages. My biggest problem here is comunication... in a threaded version I can simply call objects from each thread no? its the same program so there shouldnt be any problem. In a multi process however this is probably not possible... RPC calls would be the minimum required no? Or i would simply implement a network TCP or UDP connection based on a lan that would communicate within each server (chat server, login server and game server). So does anyone know a way to comunicate data between different processes? I mean something like Java's serialisation where you can simple send an entire object through the connection (i think). Is it even possible in java? Im thinking CORBA and ORB... i think I did something like this in uni. Anyone knows how big companies do their stuff? im pretty sure they divide zones per server (the famous server boundaries). Am im thinking correctly? should I try to implement different separate servers and link them via LAN (or directly if we are using the same computer). thanks for reading and hopefuly some input will come Yours truly K

If you're building a distributed game server platform, you are right: you need to talk between processes in a reasonable way.

The solution you choose depends on your technology. If you're using Windows, you could try DCOM (and find it sucks for games). If you're using UNIX, you can try CORBA or even good-old SunRPC (and find that it, too sucks for games). With Java, you can try its RMI (and find that it sucks for games). With .NET you can try remoting (and guess what you'll find? It sucks for games!). Oh, there's a few others, too, such as ACE, or MPI, or other technologies (which, by and large, suck for games).

An alternative is to speak your game networking protocol between the server processes, too. If you already implement a game packet protocol with authentication, etc, it makes sense to re-use that for your internal communication needs.

A third alternative is to use a service-based architecture technology (which will make your solution very enterprisey!) such as SOAP or XML-RPC or even good-old HTTP. It all depends on what you already know, what your goals are, and how much pain (of what kind) you're willing to put up with.

The fastest way to communicate between processes in Win32 or Unix is through shared memory and mutex's (Win32 mutex (faster, binary semaphore) or semaphore (more general) object). Also see events and conditions (link below).

More info here,
and here.

Communicating through sockets might also be fast enough (but will be slower than shared memory).

Thanks guys!
I appreciate the input.

Shared memory would only work if the processes where being run in the same machine, right?
that would defeat the purpost of being able to host each server process in its own machine.

i guess sockets are the way to go then... for as long as each server machine is housed in a very fast intranet.

Again thanks!
Yours Truly
K

I use a service architecture for all network connections. A service (or subscriber) runs in its own thread (as far as each application is concerned) and simply generates or responds to network events. Applications can implement as many services as they want, without conflicting ports, and as many subscribers as they want (even to the same service). The services provide a message protocol and operate under either TCP or UDP by choice at startup. Internal protocol is the remit of the user.

Each game process maintains a subscribers to a 'master process' as well as to relevant neighbours (which are validated by the master process, of which there is only one in a cluster). Each game process also maintains a client service (to which client applications have a subscriber).

Quote:Original post by _winterdyne_
I use a service architecture for all network connections. A service (or subscriber) runs in its own thread (as far as each application is concerned) and simply generates or responds to network events. Applications can implement as many services as they want, without conflicting ports, and as many subscribers as they want (even to the same service). The services provide a message protocol and operate under either TCP or UDP by choice at startup. Internal protocol is the remit of the user.

Each game process maintains a subscribers to a 'master process' as well as to relevant neighbours (which are validated by the master process, of which there is only one in a cluster). Each game process also maintains a client service (to which client applications have a subscriber).

Heyas _winderdyne_

I never worked with services before. I know I could google it right now but would you mind giving me a simple paragraph explaining just why use a service instead of a standard network message via sockets?
Hm.... even i can see that the best answer to this post is Giyf... Ill try and do that later on if I have the time and Ill update this thread with any relevant info I might find.

For our system we have several 'tiers' of communication, all of which may have differing protocols and encryption schemes. For example, we intend internal cluster traffic to use TCP for sequentiality and external client traffic to use UDP. Both are modelled as services / subscriber pairs and provide precisely the same interface to the rest of the codebase.

A 'service' or 'subscriber' is simply an interface to a particular message protocol (and all its send queues) (effectively its own network engine), providing an event subscriber or distributor for the rest of your code. They also provide maintenance features like 'I've been idle for 30 seconds' messages, automatic reconnect and reauthentication etc. It really is up to you what you put in there.