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

[Argent Stonecutter]

On 26-Oct-2007, at 16:24, Ryan Williams (Which) wrote:
> 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,

I thought object updates could be partial, and if the object isn't  
physical they won't be repeated... how often do "routine" object  
updates happen then?

Now that you mention it, object updates would be a good application  
for something like this. You'd send a nonce with each update, and  
with each partial update the nonce for the last update of the object,  
and if it doesn't match you request a full update. Send a sequence  
number with the update and you can tell if you missed one, and  
periodically send back a "mass ack" with a list of missed sequence  
numbers since the last mass ack, with some kind of RLL coding for big  
gaps. The sim would only need to keep track of a small number of  
sequence numbers for each object for each client... if they overflow  
it can just switch to full updates for the object until it gets an  
ack that'll let it clear them.

Or do you already do something like that?

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

Partly true. Control chat doesn't need to be in order, and does need  
to be timely. I don't know how to distinguish that, though, and  
having some kind of "user control" mechanism for the future would be  
a better fix than some kind of "negative channels are UDP" hack.

>  TCP has this property.  It takes a little longer for things to get
> there than with UDP

It *may* take a little longer. If there's nothing pending and you do  
a PUSH it's pretty much identical.

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

Yah, I have mentioned that once or twice or a million times. ^^

>   We know this from experience, you see.

I'm lucky, I learned it from reading horror stories. I'm sure you've  
got a few we don't know about, but this is probably not the place.