[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