Jump to content
  • Advertisement
Sign in to follow this  
NQ

Quick question about SDL_Net and its speed

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

Hey, I've got a really odd "bug" which makes all my SDLNet_TCP_Send() sends arrive very late. The fastest ones lag half a second, but occationally there's a 20 second gap between send and recieve. I'm not quite sure what goes on behind the curtains, so I'm having difficulty figuring out what could be the issue. I've heard TCP is slower than UDP, but this is ridiculous. There must be something I'm doing wrong. As I said I'm using TCP sockets, and I'm only sending a very few bytes at a time. Since I'm making an action game, speed is important and therefore I try to send as little as possible. I've tested between me and two different friends, AND between several clients running on localhost. Same lag all the time. Theories: - TCP sucks harder than I could have suspected. - I just happened to test between computers which suck at connecting to eachother. - SDL_net it waiting for me to send more data, so it can fill up the minimum size before it sends anything (does it do this???). - I am an idiot. Is it possible that TCP really is this slow? Should I step over to UDP instead? Could I really cause this lag with some strange bug of my own? Thanks!

Share this post


Link to post
Share on other sites
Advertisement
SDL_Net is a very thin wrapper over the platforms socket API. I can't see it doing any additional buffering that wouldn't be done at OS level anyway.

What SDL_Net doesn't provide (AFAIK) is a function to set a socket to non-blocking mode. Without disabling Nagle's algorithm the OS will buffer data hoping to send a few large packets rather than many small fragments.

With TCP, the other issue is that if your network is lossy then TCP will hold back the stream elements that have arrived quickly while waiting for the resent packets. This introduces an artificial latency that using UDP would not have. However using UDP places ordering and reliability in your hands.

It could depend on how you are sending and receiving data. A call to recv that is blocked will cause your application to stop sending data until it receives something.

Share this post


Link to post
Share on other sites
Thanks for your info.
About the blocked recv calls... do you mean that further sends are blocked until the sender gets notice that a recv have been performed on the last send?

And the OS Nagle's algorithm you mentioned, do you think it could cause several seconds of delay? Is it worth looking into disabling it?

Share this post


Link to post
Share on other sites
Oh, thanks for your help, the problem is "solved" now.

There never really was one. Theory number 2 was correct. There was some kind of issue with the friends I tested with. Also, it lagged on localhost because of my processor speed. I didn't have a bug. Oh, I'm so happy now! =D

Share this post


Link to post
Share on other sites
Quote:
Original post by NQ
Thanks for your info.
About the blocked recv calls... do you mean that further sends are blocked until the sender gets notice that a recv have been performed on the last send?


Not really. What I mean is, imagine your server sends data every "network tick". The client only sends player input. If coded incorrectly, the server could block on the call to recv from a client. All the other clients experience an artificial lag because the server isn't sending the data every tick while blocked. I imagine that you aren't doing this though.

Quote:

And the OS Nagle's algorithm you mentioned, do you think it could cause several seconds of delay? Is it worth looking into disabling it?


For real time data you would. Since you defined your game as an "action game", you should consider UDP too (or a reliable UDP library).

Share this post


Link to post
Share on other sites
Quote:
Original post by NQ
And the OS Nagle's algorithm you mentioned, do you think it could cause several seconds of delay? Is it worth looking into disabling it?


I've been looking into "fixing" that with SDL_net before. In SDL_net.h you can add the line "#define TCP_NODELAY 1" for the algorithm to be disabled - I got some really good results after that, so I recommend that if you want to sacrifice throughput for latency.

Share this post


Link to post
Share on other sites
I recommend looking at the net2 library. It introduces threading to the mix but will improve performance in a situation like this as well as making networking event driven instead of poll based.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!