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_,.-=~''''^''''~=-

No, its not the problem. I''ve already set that option.