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
