Sign in to follow this  

Re: My experience with networking libraries

This topic is 3783 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

In reply to this retired thread: http://www.gamedev.net/community/forums/topic.asp?topic_id=446263 Specifically, SpaceDude's reported problem of variable pings with Raknet: I don't know if this is relevant to Raknet, but it is at least worth checking. Some network libraries rely on the user's call of some method to 'tick' the network library, and will not processes received packets, reply with acknowledgments etc. until this method is called. This can mean your game's tick rate can significantly effect perceived ping times, as they will include time between the recipient machine receiving the packet and hitting the point in it's main loop where it processes received packets, and the same again on the sending machine for processing the acknowledgment. These periods will almost certainly vary significantly in comparison to the expected low pings on a LAN. A solution to this problem is to put the vital calls to the network library in their own thread. To repeat, I have no experience with Raknet and do not know if this issue is relevant for that library. It certainly has been an issue with commercial network libraries I do have direct experience with. Regards, Ergwun

Share this post


Link to post
Share on other sites
How often is this a problem, though? Majority of the time, nearly all of your time is spent either rendering the screen, or updating the objects to be rendered on the screen. At worst, you're going to be a single frame behind, which at 60 FPS is only ~17 milliseconds. Along with that, I could see more harm than good if you update visual effects mid-way rendering. Lets say you just drew the terrain and characters, and are about ready to draw the shadows when a packet is received saying one of the objects have to be moved. Well now you have the shadow in the right place, and the object in the wrong place, for that frame. That will be more noticeable than if it took an extra 17-or-so milliseconds, which is usually nothing compared to the network lag in the first place.

Share this post


Link to post
Share on other sites
So, you don't know about RakNet, but you're commenting on measurements done by someone who actually looked at it in detail? I'm not sure that's all that helpful, unfortunately.

It seems, from looking at it from the outside, as if RakNet runs networking in a thread of its own already. Another equally possible explanation could be that thread scheduling causes jitter, but until we put the same test harness on our machines and actually measure (or at least read the code), speculation doesn't really help.

Share this post


Link to post
Share on other sites
Without hardcore knowledge of the library or extensive testing you don't really know if it is the libraries fault, even with extensive testing you could be doing something wrong. You don't need a separate thread, just call the tick multiple times per frame between high CPU tasks.

At 60fps your worst case ping isn't 17ms, but *I think* triple that (assuming the client is the same speed), and 51ms of ping is a lot in my book, especially when it is totally by design and not real lag.

client send msg, worst case is we queue the msg just after we do our network tick, delay +17ms
server receive msg and reply, worst case is we get the msg just after our net tick, delay +17ms
client recv msg, worst case we get msg just after our net tick, delay +17ms

Share this post


Link to post
Share on other sites
I was just sharing my experience of a situation where apparent ping time was higher than expected on a LAN and jittery, due to dependence on network library ticking for ping measuring. I emphasize again that I am not talking about Raknet here.

Of course, this is not necessarily a problem if the ping measurement is not used for anything. An example of a problem that could occur would be if ping jitter was used to estimate bandwidth available, leading to unnecessary throttling down of send rate.

Note that processing and acknowledging incoming packets asynchronously of the main game loop does not mean you have to process (i.e. act upon) their payload immediately - this would indeed be problematic! They can, however, be buffered and dealt with during the appropriate moment of the normal game loop.

Ideal communications would still lead to a lag of 3.5 ticks (2.0 client + 1.5 server), compared to 1.5 ticks for a single player local game. See Jonathan Blow's article "A look at latency in networked games" in the July 1998 issue of Game Developer magazine, for a full analysis of this issue.

Humble apologies to all who find my contribution unhelpful.

Share this post


Link to post
Share on other sites

This topic is 3783 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