[sldev] Why does the simulator do object culling for clients?

[Tateru Nino]

John Hurliman wrote:
> Tateru Nino wrote:
>> Dale Glass wrote:
>>  
>>> On Thu, Jul 19, 2007 at 01:38:02AM +1000, Tateru Nino wrote:
>>>      
>>>> Considering the amount of ghosting we generally see (due to lost
>>>> ObjectKill packets), I'm wondering if it isn't a good idea for the
>>>> viewer to be able to periodically poll 'stale' objects (ones that have
>>>> had no Update for a while) just to verify that they're still present.
>>>> Having avatars and objects that have long since gone hang around in
>>>> your
>>>> viewer for an hour or two - that can be a little odd, or even
>>>> unsettling
>>>> at times.
>>>>           
>>> That sounds like a hack.
>>>
>>> ObjectKill is sent over UDP, I suppose? I haven't looked at networking
>>> code much yet. But if so, polling isn't the right way to do it, the
>>> problem is that the message should be reliable and isn't. So move it to
>>> TCP, ensuring it's always delivered. Then so long the sim and viewer
>>> aren't buggy that should be all that's needed.
>>>
>>> Imagine the amount of extra bandwidth needed for periodically checking
>>> all the objects you can see if you set draw distance to 512M.
>>>
>>>       
>> Many of our most common complaints are caused by dropped messages that
>> should be reliable, but aren't. :)
>>   
>
> Isn't ObjectKill sent as "Reliable"? If there is a problem with the
> ACKing code that's a whole different story, and if the connection
> quality is poor enough that packets are being given up on after the
> minimum five resends or whatever it is then switching to TCP probably
> won't fix the connection. 
There seem to be some things going missing, and I've started to look a
little more closely at the messaging code to try to figure out why.
Symptoms suggest that messages are not turning up at all (avatar
standing up, avatar departing, object removed from simulation, etc) or
are having their parameters zeroed out or mangled somehow (avatar
position, appearance, attachment position).

In recent days I've been starting to wonder if it is possible for the
parameters for one message to be incorrectly interpreted as being part
of an earlier message whose parameters may have been dropped in transit
somewhere, or if there is a data-path with degenerate encoding/decoding
behaviour.

Time to UTSL, and see what can be seen.

-- 
Tateru Nino
http://dwellonit.blogspot.com/