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!

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.

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?

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

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

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.