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

[Bruce Mitchener]

Brian Hook wrote:
>>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.

I hadn't mentioned SCTP last night, but it is perhaps interesting as 
well, perhaps more than DCCP.

The various RFCs and implementations of SCTP are linked from:

     http://www.sctp.de/sctp.html

It supports multiple channels over a single connection, and it allows 
you to turn off the ordering guarantees, but not the reliability.

RFC 3257 (http://www.ietf.org/rfc/rfc3257.txt) lays out how it differs 
from TCP and UDP without requiring that you know too much about SCTP 
already (IMO).

There's also a draft extension to SCTP for partial reliability that is 
interesting:

   http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-prsctp-02.txt

  - Bruce