In a multiplayer game does the code to get/send info from/to sockets reside in the game loop or does it belong in its own thread?
Most programming languages or network libraries have APIs for asynchronous IO operations where read- and send operations return immediately. Read-operation return only the data which was buffered since the last call and send-operations are executed in background. When you have such an API available, there is usually no reason to add another layer of threading on top of it (these APIs usually use threading behind your back anyway).
But when you don't have any non-blocking APIs available or those which are available are insufficient for some reason, you should definitely write your own asynchronous networking code which uses a separate thread for each network connection.
It is typically in another thread, with some form of lock-free queue passing messages between the network thread and the main thread's game logic. This is almost required in some OSes which have inefficient networking stacks or other limitations making a separate thread required to handle more than a few sockets efficiently, particularly older versions of Windows (which still isn't stellar in this domain). Linux and some BSDs can be made quite efficient without threads, but it can still be advantageous to use threads in games for networking (especially if your network tic rate does not match your frame rate, which usually it won't).