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):
- address space
- Global variables
- Open files
- Child processes
- Pending alarms, interrupts and signal handlers
- Program counter
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).
- Operating systems design and implementation (the MINIX book), 3rd edition by Andrew S. Tanenbaum
- Fix your timestep by Glenn Fiedler: http://gafferongames.com/game-physics/fix-your-timestep/