[vworld-tech] Some resources for ... TCP UDP

[Patrick Dughi]

> By "channel" I mean "segregation by functionality".  For example,
> let's look at a typical UDP stream coming from a client, and say it
> consists of:
> 
> 1 - move
> 2 - move
> 3 - move
> 4 - talk
> 5 - move
> 6 - move
> 7 - inventory
> 8 - move
> 
> Those packets are transmitted, but for some reason the underlying TCP
> layer can't get #4 across successfully (yes, that's a simplification
> of how TCP works, but bear with me).  Now, 5/6/7/8 have arrived, but
> they're held up (ideally they're buffered, but maybe a TCP
> implementation doesn't even do that) until 4 is resent and comes back.
> 
> Should movement and inventory checks be held up because of a missing
> speech packet?  No.  In a UDP based implementation that supports
> multiple channels, e.g. enet, this isn't a problem, because you could
> have a movement channel, chat channel, character-query channel, etc.
> all which are logically embedded in the same stream.  A few dropped
> packets on one channel don't delay delivery of unrelated packets.
> 
	Of course, you missed out on one niggling point; with UDP, you
may get the aforementioned packets in any given order.  If you're on a
large featureless 2-D plain, it probably wouldn't make a difference if
you got 'move up 1 unit' and 'move right 1 unit' out of order.  If you
were on the edge of a cliff in an FPS however, I think you're going to
want to order your packets.  Depends entirely on the scenario.

	Granted you may not affect other channels, but if, for example,
the command to equip your jump boots arrives after you've gotten the
jump command, well.. you better hope it's not too deep of a pit.

	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.  Communication could conceivably be easily
implemented on a p2p basis by the client anyway, using separate sockets,
of course.

	I'm sure there are examples I can't think of right now, but it
seems to be in the minority, though I have no statistics on that.

> > 1. "Guaranteed delivery" is absolute hell to implement properly.
> 
> ...assertion without justification.

	I don't know what justification you'd need for this - but
writing a decent sequencer for UDP packets is easy to do poorly, and
more difficult (I wouldn't say 'hell'-ish) to do well.  At least, if
you're trying to insure the benefits of UDP over TCP in the first place.
Since the multiple-channel value is potentially lost (aside from a
developer perspective of the system model) if you have to require
in-order retrieval of the packets for a given channel, it gets rough to
squeeze all the other things out of UDP that made you want to use it
over TCP in the first place.

	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.  Come back when
you're done and tell us whether it was easier to write it or just use
TCP directly, or more tellingly, if the potential gain from a stripped
down version are worth the trouble of writing it.  

	As far as I've seen, it CAN be worth it, but it does require a
certain set of specialized knowledge and devotion before the time&effort
vs. gain becomes practical.
 
> > 5. Lastly, there ARE alternatives to TCP and UDP. Not surprisingly,
> > since almost every game finds that neither is really good enough
> > (the games that just go TCP only suffer weird stuttering, the ones
> > that are UDP only often get players freezing, or their guns not
> > firing because of lost packets).
> 
> Games don't use UDP blindly, at least no good game that I have ever
> heard of does.  UDP is used as the transport layer for a higher level
> application implementation that adds the in-order/guaranteed portions
> as necessary.

	Here's the end truth of things; if people don't see writing the
TCP-specific functions as difficult, they will do it.  Some who don't
may buy a replacement that meets their needs, and others will inevitably
make do with TCP or UDP modified as best as they can to fit their needs.
The big difference is relative experience writing 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.

	PjD