Archived

This topic is now archived and is closed to further replies.

Questions + problem using TCP

This topic is 5599 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''ve got several questions on TCP: 1) does using select() automatically mean that you''re using non-blocking sockets? 2) If it does mean that only because the recv()s will always have data on them, therefore you don''t have to wait till they do, what makes a recv() call stall? 3) Can sending a header with a packet size information that is incorrect can make recv() stall? 4) Assuming that is not the problem, what else would make recv stall? 5) Should I use the select() method to check for incoming data? Or can I put the recvs and sends on a different thread and write and read to and from a queue that the main thread uses from? The actual problem: I am using TCP to prototype my game''s multiplayer aspect. I compile both server and client code and run them on a single computer. It lags. So I start timing function calls to find a botteneck. The bottleneck is a recv function. Every 3-4 packet recieves, the function stalls for approx 150ms, making the game extremely jerky. I am only recieving an average of 14 bytes per recv() call. The odd thing is that the server doesn''t lag on any of its recieves. Only the client does. I am using the same code to recv() packets for both programs. Anyone have an theory explaining why this might be happening? -=~''''^''''~=-.,_Wicked_,.-=~''''^''''~=-

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
select() doesn''t automatically make sockets non blocking, you have to use your local ioctl() type function to set it to non-blocking, then when you recv() test for a EWOULDBLOCK (or WSAEWOULDBLOCK) error which means there is no data waiting. select() just tests to see if their is data waiting (recv()) or if a socket has free buffer space for sending (send()). I personally use both methods, select() and then check EWOULDBLOCK on non-blocking sockets as a fail-safe in case select() gives me dodgy data
As for your actual problem, it''s probably a little difficult to diagnose without seeing code or knowing better what you;re doing. Only thing i can think of, is if you are making multiple calls to recv() after a single select(). Like if you were looping on recv() until you received a full message etc.

Share this post


Link to post
Share on other sites