You mentioned it's a roguelike, will it be turn-based or real time ? Generally if you are going for a real-time game with timing critical elements, you should be placing the commands player make slightly to the future to compensate for the latency. This can be few hundred milliseconds at most.
Typically each client on the server has a thread. This thread handles reading the data and sending the response to the particular client. If you're planning on storing game logic on the server, then you'll need a common data storage with concurrency handling. Look into mutex/semaphore for more information on how to do this.
Another option is to have the server merely as a message conveying service. This means that you should encode your player movements into actions that will be sent, through the server, to the other players in the game. The games themselves are then responsible for maintaining a synced state.
Both of these approaches are valid and it really depends on how you want to do it. If you want to have a master process besides the server but on the clientside, you could set it so that the creator of the game has "additional privileges" such as spawning the monsters to a dungeon. Something a server would randomly do, but assuming you want to have a generic message delivery server and include all the game specific stuff on the side of the game.
As for receiving the data on the server side, depending on whether you're using UDP or TCP, you could simply have the thread listen to the socket all the time and attempt to read a packet (Åin the format you define) and react to it when it arrives.
A good thing to realize is that you generally don't have to sync up all the data, but only the stuff that has changed. If timing is not critical, you could simply be transmitting deltas (i.e. what has changed) all the time.
One thing to consider in a design like this is that sometimes someone is late due to network lag or something. If a command is missed, how will this be fixed. You should design your game so that a) the actions can be calculated from the past or b) implement a resync (i.e. send all objects across to all players; pause the game for a short while meanwhile).
And then there's the approach I first encountered in Unity was to divide the communication into delta updates and RPC calls. Big stuff like killing a monster, picking up an item, etc. will go through RPCs. However, stuff like exact player movement uses delta updates and movement prediction (the latter one means that the drawing thread can use the previous movement to interpolate to the direction it assumes the entity is moving to).
As for the communication itself, you could either use polling or simply listen to the server socket all the time for updates. In this case, you might want to utilize non-blocking IO in C++ (full duplex). Here's a thread from StackOverflow: http://stackoverflow.com/questions/4675824/how-to-implement-a-full-duplex-channel-over-tcp-with-a-single-thread)
I know a lot of this is vague but your question is a bit broad as well. I recommend you try to narrow your question down a bit by providing more detail in the future.