[sldev] Re: [ARCH] Certified HTTP Project Update - Oct 25

[Ryan Williams (Which)]

Argent Stonecutter wrote:
> The trick to being clever with UDP is to make sure that what you're
> doing is "being clever with UDP" and not "re-implementing TCP". The
> biggest problem with the current UDP stuff in SL is that a lot of it's
> doing things that should be done in TCP, and the solution to that is
> already underway in the switch to TCP for bulk data transfer. Real-time
> events will need to remain UDP-based, and I doubt very much that LL is
> going to switch completely to TCP, but bulk data transfer really does
> need pretty much all the stuff that TCP does.

Yeah, there's a place for UDP and a place for TCP.  We're definitely not
going to be able to switch everything over to TCP/HTTP, that would be
wrong for much of the real-time things.  I think the genius of Message
Liberation is that it allows us to empirically figure out what messages
can be delivered over TCP versus which ones are better left on UDP.

> Most of the real-time data is truly redundant. You don't need to send
> position updates again, because the next update completely supplants it.

Totally.  I personally think that there is a lot we can learn from
networked games like Quake 3 (open sourced!).  Long-term it should be
possible to boil down the set of data that needs to be updated with UDP
and devise a non-redundant transport that is also very responsive.

> There's a few things that I could think would benefit from a "Certified
> UDP" scheme, though... mostly discrete non-repeated events from the user
> like chat that are still "real time" in nature. 

Actually I think chat is a good TCP application.  E.g. IRC uses TCP.
Think about it: relatively large (> a dozen bytes), unique content every
time, must be uncorrupted, not hair-trigger (i.e. delay of up to 1/10s
is not even noticeable, up to 1s is tolerable).

> I don't think controls
> should be, at least not without an extremely short timeout on the
> certificate, because the user is the best person to know if a control
> needs to be resent and they will already be doing it anyway.

Agreed.  It seems to me that a good rule of thumb is whether or not the
data being sent is trivially self-elided.  I.e. do subsequent data
completely supplant earlier data?  This is true for object updates,
controls, estimates of ping time, and probably a bunch more.  It's great
because you can use a transport that occasionally drops some data, and
you can just wait for the next update to get back in sync.  That's what
UDP is for.  Admittedly it is dumb that we don't take advantage of event
eliding, but we should.

Chat, and pretty much everything else in SL, is not self-eliding, and if
you send two lines of chat, it's not OK if the first one is dropped and
the second one is used in its place; you want both to show up in order.
 TCP has this property.  It takes a little longer for things to get
there than with UDP, but really it's not that much delay in the normal
case.  Whatever you try to do with reliably sending messages over UDP is
almost guaranteed to waste more time and bandwidth than just using TCP
to begin with.  We know this from experience, you see.

-RYaN