PA multiplayer port and UPnP

The only advantage of using UDP instead of TCP I can think of is that you don't have to worry about window scaling issues. Since PA probably won't use that much bandwidth window scaling probably won't matter that much anyway.

I suppose loosing the ordering behavior of TCP might help but I don't know enough about game network protocol design to really judge that.

In my experience there is very little if any performance difference between TCP and UDP on modern hardware if TCP is working properly. But my experience doesn't extend to games so meh.

The problem isn't performance as far as processor time so much as how fast data can get from point A to point B.

On the other hand, with the client/server model using less bandwidth, would TCP be too slow?

Also, if you're using UDP on a LAN, why not have the option to send updates to the broadcast address? Granted, it wouldn't be good for all cases, but if everybody on the LAN is playing the game, it could mean more data sent with less work.

While supporting LAN is nice and all I doubt it should be the focus of any kind of optimizations. LAN is way faster than normal internet anyway and most games will be played via internet.

TCP and UDP have essentially identical transfer speeds if TCP is working properly.

I doubt it. We are talking millisecond differences here. I can see that meaning something in a twitch style FPS but I am not sure it really counts for much in an RTS.

Home LANs are generally fast enough that it won't matter and anything bigger than a home LAN isn't going to allow broadcasts across the network anyway.

Lets talk a real world issue, explicitly for an RTS like PA.

Lets say you have 1% packet loss.
Lets say you have 100 units.
Lets say you send 100 TCP packets per second and each one is the movement data for an individual unit. (This is grossly inaccurate usage on many levels, but bear with me.)
Lets say the TCP resend for unacknowledged packets is 500 ms.

So, we start sending packets for each unit over the network, one at a time, in order. The movement data in packet #47 fails to be received by the other side.

What happens is the server keeps sending packets to the client for units #48 through #98 over the next half a second and the client computer receives them all, but the game doesn't. It's not until that half a second has elapsed and the server re-sends packet #47 that the client computer then sends that data to the game, along with the other unit data it's received packets of.

The result is about half the units on screen stop moving for a full half a second.

Now lets look at that using UDP with just return acknowledgement but with out in order.

Client fails to receive packet #47, but still sends data from #48 to #98 on. In half a second packet #47 is resent.

In the game all units keep moving and only one stops for half a second before catching up.


Now this doesn't even need to happen because of a lost packet. Due to the awesomeness and complexity of the way the internet works packet #47 could arrive later than the packets that were sent after it; not all packets necessarily take the same path, some might take a detour through China for a few extra milliseconds for example. Same thing happens though; all data sent after packet #47 will be delayed until the client receives it when using TCP.


Alternatively this is also a good case for straight UDP, as most likely the position of that unit will be sent again in the next second. Given the parameters that unit will now stay still for a full second, but the reality is the packet throughput is likely a bit higher (say 150 TCP packets per second) because of the lack of needing the acknowledgement data in the packet and handling the resulting response.