Sign in to follow this  

IPC between network layer and authoritative simulation.

This topic is 397 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Edited by Guns Akimbo

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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  :)

Share this post


Link to post
Share on other sites

This topic is 397 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this