Running both the server and the client within the same process

Question

Question

I have just started working with Lidgren and networking for the first time, and I've come to the realisation that it is possible to run both the server and the client within the same process.

Is this practice discouraged for any reason?

Context

The reason I'm asking is because I theorized that this concept might allow me to treat both singleplayer and multiplayer modes as one and the same, which would be very helpful.

Following my line of thought, this is the distribution I had in mind:

• Singleplayer - 1 server + 1 client in the same process. How fast are the communications?
• Multiplayer - Same as singleplayer for the host + 1 aditional client for each other player.

The execution flow I'm picturing is for clients to recieve user input and send a notification to the server. Then the server validates it, and broadcasts an action to be executed by all the clients. It shouldn't matter if there is only one client (i.e. singleplayer) or multiple clients (i.e. multiplayer).

Answer 1

This is basically a process versus thread question, both aren't too different, sometimes threads are called lightweight processes. The biggest difference is that a separate process has it's own address space but there are other differences (1):

Per process

• address space
• Global variables
• Open files
• Child processes
• Pending alarms, interrupts and signal handlers

Per thread

• Program counter
• Registers
• Stack
• State

Based on these differences it could be handy to have a server and client thread in the same process so that you can share file handles and global variables. This would be an argument for the 'in the same process' approach, another (small) argument would be that you only get one 'Windows Firewall' pop-up per process. An argument for the 'different process' approach would be that a person can run multiple servers without having to run multiple clients. This would be ideal for a dedicated host like set-up and is an approach we commonly see in first person shooters.

Now as for the idea to have a server process or thread even for off-line play (and maybe even for single-player) this is a great idea that is used a lot in practice. You can tell a lot of games do this by looking at the loading screen, small hints like 'receiving' will give it away. It's logical to do this since if you're going to make a multi-player most of the game rules will be governed by the server, so why not have it govern them for single-player? This reduces the code you have to write and gives a clearer separation between client and 'game' which will improve your code quality.

Now how about communicating between processes and threads? Cross process communication can be done in a lot of ways, (named-)pipes, shared memory, COM, it really depends on the technology you're using. However if you're making a server you'll probably want to go with a a networking variant using sockets and something of the likes of TCP, this is of course where LIDGREN will come in handy.

A lot of these techniques are also valid for cross thread communication. But this depends even more on the techniques you're using. You could again go with TCP, but maybe an even simpler system would be events and some marshalling, although this could make your game loop non deterministic (2).

Sources

1. Operating systems design and implementation (the MINIX book), 3rd edition by Andrew S. Tanenbaum
2. Fix your timestep by Glenn Fiedler: http://gafferongames.com/game-physics/fix-your-timestep/