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

Argent Stonecutter secret.argent at gmail.com
Mon Apr 19 17:07:23 PDT 2010


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.


More information about the opensource-dev mailing list