[sldev] Frequent bugs with difficult repros

Lawson English lenglish5 at cox.net
Fri Feb 29 16:11:05 PST 2008


Tateru Nino wrote:
>
>
> Kelly Linden wrote:
>> Tateru Nino wrote:
>>>
>>>
>>> Soft wrote:
>>>> On Fri, Feb 29, 2008 at 2:51 AM, Callum Lerwick <seg at haxxed.com> 
>>>> wrote:
>>>>  
>>>>>  On Fri, 2008-02-29 at 13:24 +1100, Tateru Nino wrote:
>>>>>  > Double chats in IM groups? That's caused by packet loss between 
>>>>> the
>>>>>  > viewer and the sim, honey. Same as double-chat in local chat, 
>>>>> and in
>>>>>  > person-to-person IMs. It also causes out-of-order chat.
>>>>>
>>>>>  So when is our chat going to be transported by this new-fangled TCP
>>>>>  thing? I hear it deals with packet loss and retains ordering...
>>>>>     
>>>>
>>>> I'm pretty sure TCP is just a fad.
>>>>
>>>> Actually, I thought this had already gone TCP. I'll ask around, but if
>>>> any other Lindens want to chime in...
>>>>   
>>> Depends. Even if it is tcp, application level sequencing and 
>>> controls over messaging flow, acknowledgement and order can still 
>>> duplicate your data - depending on whether you're second guessing 
>>> the transport with your own scheme, and how you've got it implemented.
>>>
>> Those would be what we would call "bugs", I hope.  :D  I'm not the 
>> most up to date (my head is far too deep in havok4 for the past 6 
>> months), but I don't think chat or IM have moved to TCP, I believe 
>> they still use our home brewed "reliable" UDP messaging transport layer.
>>
> I believe that is also the case. Reliable is such an interesting word. 
> Very contextual. :)
>
> That said, the algorithms that govern the UDP transport actually do a 
> surprisingly good job under very trying and harsh circumstances - 
> however circumstances and workloads just aren't what they once were. 
> Something I think we all recognize.
>

As far as I know, the main issues with IM in Second LIfe have nothing to 
do with UDP and would be just as bad if they were implemented using TCP, 
as long as the same underlying design remains unchanged.


Lawson


More information about the SLDev mailing list