[opensource-dev] ParcelAccessListReply packets have no reliable end of list indication?

Tigro Spottystripes tigrospottystripes at gmail.com
Mon Apr 19 17:14:02 PDT 2010

Hash: SHA1

i believe this is related: http://jira.secondlife.com/browse/VWR-15563
"Client gives up before finishing to load full inventory due to packet loss"

On 19/4/2010 21:07, Argent Stonecutter wrote:
> On 2010-04-19, at 13:46, Joshua Bell wrote:
>> It is certainly the case that several request/response-type messages
>> do not have a way of signaling that all of the data was sent. This
>> arose from thinking of the protocol in a purely viewer-centric way,
>> i.e. if the viewer was  populating a list view, the data in additional
>> packets is simply appended. This imposes unfortunate constrains the
>> design of clients that want to process things differently than the
>> viewer.
>> This varies from message to message and even within message usage,
>> e.g. MapBlockReply has a "end of results" signal when issued in
>> response to to MapNameRequest, but not when issued in response to
>> MapBlockRequest.
>> I took a peek at the sim code that issues ParcelAccessListReply and
>> your analysis appears to be correct; there's a special case for
>> sending a null entry if there are no entries at all, otherwise the
>> data is just sent in as many packets as necessary, with no termination
>> indicator.
> Would that explain why the viewer sometimes appears to lose data (for  
> example, spurious missing inventory), because it's got no way of  
> knowing if some of the packets from the server were lost unless there  
> were later packets? If so, that doesn't seem like a really good design  
> for the viewer itself.
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges
Version: GnuPG v2.0.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


More information about the opensource-dev mailing list