UDP vs. TCP (Destiny)

by Cody Miller , Music of the Spheres - Never Forgot, Wednesday, July 01, 2015, 20:52 (3233 days ago) @ Beorn
edited by Cody Miller, Wednesday, July 01, 2015, 20:57

I don't remember Firefight switching the networking code to TCP, but it would make sense in light of the fact that the game was in "lockstep," requiring everyone to pause and re-synchronize when clients fell behind. That sort of thing would be absolutely horrendous in PvP.

I seriously doubt it ever used TCP. A game would be unplayable over TCP. Usually what is done is you send out duplicate packets staggered with the next batch. So if one drops, you have a duplicate arriving shortly. TCP would hang up and try to resend it, sometimes requiring SECONDS of latency.

Good read:

http://www.gamasutra.com/view/feature/131781/the_internet_sucks_or_what_i_.php?print=1

What was actually happening was that a packet would get lost. The TCP protocol specifies that packets will always be delivered, and furthermore, that they will always be delivered in order. TCP uses a system of acknowledgements to verify that packets are successfully delivered, and will re-send packets if they are lost in transmission. The "in order" specification means that if a packet must be re-sent, the packets that follow it are delayed until the lost packet is received. The problem is that when an Internet connection starts dropping packets, it becomes very likely that the re-sent packet will also get dropped. This means it can take several seconds for a packet to arrive at its destination.

Lesson two: TCP is evil. Don’t use TCP for a game. You would rather spend the rest of your life watching Titanic over and over in a theater full of 13 year old girls. First of all, TCP refuses to deliver any of the other packets in the stream while it waits for the next "in order" packet. This is why we would see latencies in the 5-second range. Second of all, if a packet is having a tough time getting to its destination, TCP will actually stop re-sending it! The theory is that if packets are being dropped that it's due to congestion. Therefore, it is worthless to try re-sending because that will only make the congestion worse. So TCP will actually stop sending packets, and start sending occasional little test packets. When the test packets start to get through reliably, TCP will gradually start sending real packets again. This "slow re-start" algorithm explains why we would see latencies in the 50-second range