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

[Brian Hook]

> I'm a bit confused by the "does not support multichannel": that's
> what sockets were invented for, no? 

Not in this context, no.  You _could_, if you so desired, open up a 
port for each kind of traffic type, but I doubt that's the recommended 
method.

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.

> "TCP is not inefficient, it just has extra features that many games
> developers don't use and don't want. If it had two flags
> "disableInOrderDelivery" and "disableGuaranteedDelivery" it would
> probably be used for all game protocols  - most people enjoy the
> other features of TCP that UDP lacks."

Okay, not to get defensive, but the above is basically assertion 
without verification of any type as well.

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

...assertion without justification.

> remove the "in-order arrival". Whenever you hear about "TCP is
> sloooow" or "TCP has high latencies", you are listening to someone
> who is 99% likely to have bitten by this problem but not understood
> it.

...or they're just generalizing.

> The problem is that if you send 30 packets, and the fifth one gets
> dropped, but packets 6-10 arrive OK, your network stack will NOT
> allow your application to see those last 5 packets UNTIL it has
> received a re-transmitted packet 5.

Exactly.  UDP A.) doesn't do this and B.) allows an application or 
library level layer to prioritize packets based on logical groups 
(channels).

> 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.

Brian