I need to connect my networking layer to a version of my game running as an authoritative simulation (both running on the same Linux box)... Am I right in thinking that I should use the same socket protocol (hand rolled reliable, ordered, UDP) my remote players are using to communicate to my network layer and that "localhost" magic will just bypass most the network stack? Or should I be looking at pipes or shared memory?

Cheers,

James.

Don't know the details of inner Linux network stacks, but from what I heard, it shouldn't make a lot of difference between eg pipe and localhost comm.

Since network comm is already existing (or at least definitely needed), it looks to me that re-using that would be the first experiment you should do, as it drops the entire pipe/shared mem code.

Also, it makes having the server at a different machine possible, if you ever want that.

I have found UDP to local sockets on Linux to be very fast and efficient. There IS an upper limit -- if you send more than the total receive buffer size of the receiving socket, you will still drop packets (because it is UDP.) Avoid that and all is well.
You can also use local TCP. This will not drop packets, but if the sender sends more than the receiver can handle, the sender will stat blocking on the send() calls.
The overhead to go through the network stack, compared to pipes, is not really measurable for most normal game networking situations. It is unlikely to show up as a hotspot on any profiler for most game server cases.
Shared memory can be faster, but has a number of other problems (most synchronization methods will end up adding lots of cost and degenerate to the same cost as pipes/sockets.) If you really, really, really, need to get the very last cycle out of your CPU, non-blocking FIFOs in shared memory is the fastest way to do that.

Thanks folks, sounds like reusing my UDP code will work as well as save extra code, testing and potentially debugging 2 different socket types. My UDP implementation should handle dropped packets and the (not yet finished) congestion management at the player-to-network-layer point should start backing off if the network-layer-to-simulation point starts backing up, dropping packets, etc.

Thanks again :)