[vworld-tech] TCP v UDP

[Jim Purbrick]

> Sure, but that's a given -- it's up to the application whether it 
> cares or not.  My point is that stalling delivery of ALL packets 
> because just one arrives out of order is rather bad.

A good example is movement. If a movement update arrives you apply it to an
actor as long as it's newer than the last one applied to that actor. So, if
a movement message arrives out of order, you apply the out of order message,
then throw away the in order message if it arrives. TCP would stall the
newer message until the older message had arrived, creating latency.
 
> > I can't immediately think of anything other than player to player
> > conversation which is not immediately required to be in-order in
> > all but turn based games.

Anything that comes in continuous streams of updates, like the movement
example above is better dealt with in a "don't stall, apply the newest"
approach. In the general case only events that are causally connected need
to be processed in order. If A hits B    and C hits D, the 2 messages can be
processed in either order. If A hits B then C hits B the messages need to be
applied in order. Warhammer uses the sufficient causal ordering from
MASSIVE-3 and PARADE to deal with this, which means we never require
in-order delivery at the network layer.

> Well, there are architectures that don't require in order delivery at 
> all and work very well (Quake 3).

Quake seems to apply the "don't stall, apply the newest" approach on a game
state basis. If you're at state 1 and get the delta between state 3 and 1,
then the delta between 2 and 1, you apply the delta between 3 and 1
immediately and then throw away the second delta.
 
> > The best justification I can give you is; go write a functioning,
> > minimum-feature TCP replacement that performs at least as
> > efficiently as any given TCP implementation out there.  

You can't generally do better than TCP at what it does, but you generally
don't want "give me all the data in order no matter the latency", you want
"give me the data you can deliver in 100ms and ditch the rest", or somewhere
between the 2.
 
> > pretty heavy duty network code.  Sometimes the choice that people
> > make ends up being wrong, and their custom code layered on UDP is
> > worse than TCP.  Of course, if it works 'well enough' then who
> > cares.

Writing code over UDP to provide optional TCP like behaviour isn't that
hard. Lee has done it with ENet and I've done it with JCP. It won't be as
good as TCP at being TCP, but it will be much better than TCP at being UDP
and hopefully will do both quite well.
 
> I'm unaware of any successful real-time networked games that use TCP, 
> I think that's a pretty strong (non)existence proof that TCP is 
> insufficient for real-time networked 3D games.  I stand by that 
> assertion, and I don't many people that disagree.

TCP will give you a bursty game with very spiky latency as TCP stalls data
when packets are lost. In addition the TCP stack will provide an arbitrary
length send buffer that you can't fiddle with. If you send data with TCP
you've got to wait for it to be sent, even if you have fresher data you'd
rather send instead. In some ways TCP is completly backwards for what we
want. Games want to send the freshest data first, TCP will always send the
stalest data first.

> The complaint is that I assert that TCP is inadequate compared to UDP 
> but I didn't give any "technical" reasons for this.  I'll try to 
> address this later, but so far the counterarguments haven't exactly 
> been any stronger.

TCP is more than adequate for it's job, but its the wrong tool for real-time
games and so is completely inadequate for that job.