Basic Multi-threaded networking question

I see two basic options that would work well for your situation.

One is to simplify everything drastically by not multithreading at all. Simply check the socket via select() or similar mechanism when you have time to process network events in the main game loop. There's really no benefit in buffering a bunch of network events to process if you don't have the CPU time to do it anyways, and the OS will typically buffer things satisfactorily in any case, so adding your own buffering mechanism is just another point of failure.

The other option would be a simple double-buffering scheme. Maintain two vectors, and a pointer to each vector. When your network logic receives an event, store it in the (arbitrarily designated) "back" buffer. When the game loop becomes available to process network events, swap the two pointers, effectively making the "back" buffer become the "front" buffer. From then on, the game loop does all of its processing on the "front" vector. This ensures that your two threads never stomp on each others' vectors. Note that you will need to either provide an atomic exchange of the pointers (usually via OS or CPU intrinsic functions) or you will need to protect the buffer swap (on the game loop thread) and all accesses to the back buffer in the network thread via critical section.

...
There's really no benefit in buffering a bunch of network events to process if you don't have the CPU time to do it anyways, and the OS will typically buffer things satisfactorily in any case,
[/quote]
Times are gone where a standard PC has a single core to process events of any sort. And while using UDP sockets the OS definitely throws away packets in case of an overflow. Should be no problem for the OS because UDP has no guarranty that packets gets delivered and so it would be expected that the application can handle such loss of data.

so adding your own buffering mechanism is just another point of failure.
[/quote]
You are absolutly right here. But any added code adds a point of failure.

Having a thread to process incoming network events adds the benefit of validating and pre-processing the events for the game thread. This way you lower the complexity of the game-thread. If you "know" that all incoming data are perfect you can remove lots of validation code off the game loop.

Another good reason to process the network events yourself is that you can define your own rules to detect and handle flooding situations.

How does a multicore environment affect my argument?

My point is this: suppose we have N cores. N-1 cores are dedicated to "game logic", and 1 core is dedicated to simply buffering (and possibly doing some validation for) network traffic.

If the N-1 "game logic cores" are all busy to the point that they cannot handle additional network event simulation, having a spare core buffering the data does nothing. It actually can compound the problem, because you can't guarantee that the workload will ever decrease to the point where the simulation cores can catch up with the backlog.

My proposal is to have N game logic cores instead, where each can synchronize access to the network stream and pull events directly from the OS buffers as desired, and process them. Of course, if you already are using N game logic cores where N > 1, you probably have a very sophisticated threading model to deal with, so the question rapidly becomes one of how you distribute simulation work across cores in the first place. Typically an N-core simulation has a synchronization phase somewhere in each tick (beginning or end typically) and that synchronized time span is perfect for harvesting network traffic and distributing it across cores for simulation purposes. No need to inject another thread into the mix.

Most realtime networking models are designed to discard events that can't be processed, and rely on more up-to-date information from the network to resume simulation. This is standard practice in any network model that relies on UDP; you don't send transactional commands, but rather state snapshots. If snapshot S can't be processed or is lost on the network, you wait for snapshot S+1 and move along as before.

Unless you're trying to write a very high scalability IOCP-based server, adding this kind of threading to network logic is unnecessary complication and has many difficult pitfalls. The OP is by his own words a "newbie" in multithreaded netcode, and therefore probably not equipped to safely architect a more complex solution. I'm simply offering alternatives that minimize the chances of something getting overly messy.

Most realtime networking models are designed to discard events that can't be processed, and rely on more up-to-date information from the network to resume simulation.
[/quote]
The problem is that the OS network buffer does the opposite, it drops recent packets in favour of older ones. By pulling them from the OS A.S.A.P; the application gets the choice of which events to process/drop.

That said, I wouldn't necessarily use this argument to decide on a multi-threaded solution. In any case, such a networking thread could be added later if it turns out to be necessary. It isn't necessary to prematurely optimise this. For a newbie - they are unlikely to ever need this optimisation.

So, everybody talked about the threading, and nobody answered the question? :-)
Yes, a thread for networking generally just means you're doing it for the first time, but assuming that's easiest for the OP, here's what I would do in that case:
I would use a CRITICAL_SECTION on Windows, or a pthread_mutex_t on Linux, to guard access on the vector. Lock it to push_back a packet. Lock it to check the size of the vector (note: size() is *not thread safe*) and if the size is what you want, swap it with the contents of an empty vector to "dequeue" all items at once. Then work on the dequeued vector.
The time spent holding the lock is so small, and so infrequent (at most, one packet per player per tick), that it really doesn't matter, compared to all the other issues you'll have to work out.