I'm working on adding networking to my game but I'm running into a major problem. My game was local multiplayer only and now that it is working, I want to add online multiplayer. So I added delayed input on the client based on 1/2 the RTT to the other player so the local and remote hosts would be synced up.
This is working fine for non-contiguous inputs (like attack). But I'm running into problems with movement. My current input design for movement is, while the player is holding move forward, move the player forward. To do this over the network, every frame that the local player is holding forward, I send the remote host the info that the player is holding forward. At 1st, I thought I should disable nagle for doing this. I'm working in XNA (C#) and I've tried disabling nagle, but the socket isn't cooperating. I've tried both
What is odd, is that Wireshark is showing that nagle is enabled for the 1st packet, and the rest it isn't. Each of my commands in the game is an int (so 4 bytes). When I hold forward, I see that the 1st packet to go out has a 4 bytes payload with my forward command in it. As I hold forward down the next packet that goes out (.2 seconds later, which is 12 frame later since I'm running at 60 FPS) has 12 move forward commands in it.
I disable nagle once when the socket is set up and don't touch it again after. If I leave nagle on, I get the exact same behavior. So what's going on here?
P.S. I'm starting to think that having nagle on will lead to other problems in high latency situations, so I want nagle off now, but I also want the 1st packet to go out to have more than just the 1 input command in that case, because .2 seconds is too long for me to wait for the next set of commands.
Disabling Nagle doesn't automatically make the TCP stack use one packet per send call. Any number of situations like dropped packets or frequent send calls can make the TCP bundle multiple sends into a single packet.
Once you've figured out the issue of the network not wanting to send only 4 bytes in a packet, you should severely cut down on network traffic. Send a packet to say the player's moving forward, then another only when the player stops. Instead of sending 60 packets of ~86 bytes (TCP and Ethernet require some bookkeeping per packet) over the wire every second to a computer that already knows the player's moving, you only send one every now and then.
As Firestryke suggested, you're sending WAAAAY to many packets for movement. Just send a velocity for the player when it changes, not a packet every frame.
Once you've figured out the issue of the network not wanting to send only 4 bytes in a packet, you should severely cut down on network traffic. Send a packet to say the player's moving forward, then another only when the player stops. Instead of sending 60 packets of ~86 bytes (TCP and Ethernet require some bookkeeping per packet) over the wire every second to a computer that already knows the player's moving, you only send one every now and then.
The logic for that is a little stranger (as in, fire an event when a key isn't pressed, but only do it once until that key gets pressed again), so I wasn't really thinking in that mindset. I also figured any somewhat modern computer would be able to handle the traffic, so why not? But since I have double tap forward to start running, I can see something like this fixing my current problem where the remote client keeps starting to run when the local client isn't running because it got a delayed move forward packet.
I think I got it to work Reduced network traffic and all. Unfortunately, I don't have a spare machine with 2 NICs that I can use as a delay box to really test it out.
Reduced network traffic and all. Unfortunately, I don't have a spare machine with 2 NICs that I can use as a delay box to really test it out.
