I''m running my game with a non-dedicated server (ie, client and server) on one machine and a client on the other. It uses winsock2.2. So far I''ve only implemented player movement. This works by each client program sending the server its position, and the server sending it on to all other clients. If I get the client to send its position to the server every frame, the movement is smooth. I''ve noticed though that when I only send data which has changed since the previous frame, the player movement appears jerky, and only updates every couple of seconds. Even more inexplicably, I noticed that if I get a client (call it client A) to send data every frame, and client B to send data only when updating, client A looks perfectly smooth on client B''s machine, but not vice versa. In other words, not sending data every frame causes client to receive data slower. I''ve checked for obvious bugs, but have found none. I''m also checking for errors with every message sent, and I''m not even getting the odd WSA_WOULDBLOCK. I just can''t explain it. I know it''s a long shot, but does anyone have a clue what''s going on? www.elf-stone.com

don''t know if it''s relevant, but the protocol I''m using is TCP, and the two machines are running on a LAN.

www.elf-stone.com

Since you''re using TCP, the problem probably comes from the TCP optimizations. In order to reduce packet overhead, TCP tries to combine several send() calls into a single packet. Since you''re obviously send()ing less often when only changed data is sent, the data is delayed while TCP waits for additional send() calls.

This is a very good example of why you should use UDP rather than TCP

cu,
Prefect

One line of sourcecode says more than a thousand words.

quote: First of all, the server should never rely on data received from the client. You shouldn''t send position to the server, rather you should send state changes to the server, and have the server do the calculations to figure out your actual position. This way the server can send the same data out to all clients during updates, and you will not have huge security problems in your game. For instance, if you implement a /random command like in EQ, you would have to do the rand() calls on the server, else it WILL get hacked by players... this is just one of many real world examples of why you should NOT trust your client, no matter what.

Thanks for the advice. I''ll bear it in mind in future, but at the moment I''m just trying to get a basic network implementation working running on two machines. Security isn''t really an issue unless someone first breaks into my house .

I tried sockoption(NO_DELAY), and I found it improved the situation, however it was still smoother when I sent the player''s position back to the server every frame.

I guess I''ll take Prefect''s advice and use UDP.



www.elf-stone.com

Where do you live?

Dire Wolf
www.digitalfiends.com