First of all, you should see what your platform offers you. Most networking systems will offer some form of non-blocking socket API where the nasty multi-threading is left to the operating system. All you have to do is poll the sockets at one point of your game loop to see if they have received any data. This is really convenient for you, because it prevents a lot of headache resulting from debugging multithreading bugs.
When you can't or don't want to use these APIs (you should!), then you will have to use blocking sockets. In that case you will have to create two threads per client, one for sending data and one for receiving it. The receiving threads should write their results to thread-safe data structures which are then polled by the main game thread each tick. Do not let the receive-threads manipulate the gamestate directly. Manipulating data by multiple threads is a recipe for disaster, because you never know when they are going to do that. Expect weird bugs which only appear very occasionally and are impossible to reproduce, because they depend on rarely occurring microsecond timing conditions.
You might also have to use the "thread-safe receive buffers" in some APIs which handle network messages with callback functions. Check the documentation to verify that these callbacks happen from their own threads (as opposed to a specific point in your game loop which you can specify).
Regarding your question of threads vs. processes: A process can do everything a thread can do, but is more expensive to create and maintain and interprocess communication is more cumbersome than communicating between threads which can simply pass object references to each other. IF you want to use multithreading, use one process with multiple threads. Multiple processes only make sense if you either want to distribute them over multiple servers (which can be very useful to ensure future scalability of MMOs) or when these processes are optional components people might or might not need (like a specialized reverse proxy server).
