The basic Winsock sockets are blocking, both on accept(), recv(), and to a certain extent send(). That means that you can't do more than one thing at a time with a single thread. There are multiple solutions:

- have a master thread which contains the server socket which listens for incoming connections and accept()'s them, and spawn a new thread for each client that connects. The advantages is that it is straightforward and gets the job done, but the downside is that it does not scale with more than a few clients.

- use asynchronous, event driven sockets (available in Winsock with no particular library required) which basically fire an event every time something of interest happens on the network, very comfortable to use as you can put those events into a queue and pick them up in your game loop, without needing threads, and letting Winsock do all the heavy lifting for you (you'll probably need a little network class to parse those raw events into something your game can use, though). It is very flexible as well.

- use IOCP, which is an advanced technique which is very efficient and scales extremely well, unfortunately it is a pain to implement and you will probably want to use a preexisting library. However, IOCP is not really meant for stuff like games where people stay connected for a long time and send lots of data, though it can be made to work - it is more for web services which need to handle up to thousands of simultaneous (lightweight) requests, things like that.

In your case, I would suggest giving event-driven networking a shot. It feels alien if you've only ever done blocking networking, but it can be liberating. Don't just into your game with it, though, get comfortable with it by writing prototypes and samples before.

Winsock with select() is not blocking more than what you tell select() to block.

recv() and send() and accept() are guaranteed to not block the next time you call them if select() says the file descriptor is ready.

Thus, you can easily write a single-threaded program to handle up to 64 sockets (including the listening socket, for TCP) on Windows using select(), and 1024 sockets on UNIX using select(). (the 64/1024 values come from the default sizes of the fd_set structure.)

Windows event-based sockets perform poorly, have gotchas, and are not easily portable. They may have been a good idea on Windows 3.11, but you really shouldn't use them these days.

High-throughput servers on Windows typically use IOCP with the system thread pool, and high-throughput servers on UNIX typically use kpoll or similar (different for each flavor) with manually managed pthreads (at most one per core.)

The main thing to worry about at the initial level is that send() and recv() do *not* deal with packets with TCP -- you have to frame your outgoing packets in a length+data frame, and the incoming recv() code has to first read the length, and then wait until that much data is available until actually acting on an incoming packet. Typically, this includes some kind of application-level buffering.

First, I highly advise against using the event driven sockets on Windows. They are known to be finicky; they perform poorly; they have a bunch of caveats; and they are not portable.

Second, we need to know more to understand what the situation is. Are you and your room-mate both on the same physical network? Do you, or your room-mate, have some kind of firewall running? Is there a router of some sort involved?

The problem you describe sounds like either a problem with Windows Firewall, or with NAT.