[sldev] message_template.msg ordering and packing : attention LLfolks

Tleiades tleiades at hotmail.com
Thu Mar 15 15:09:40 PDT 2007


I don't think there are any real bugs in the message codec subsystem, it is 
a little illogical, a little in efficient and a little over engeneered.

> 1. in the wire/binary encoding, blocks and variables are out of order
>   with respect to the message_template.msg file
This may be a little confusing, but it is not really a bug, a number 
wellknown codecs have similar mismatches. E.g. PER and DER ASN.1 encoding.

> 2. the ordering of blocks and variables depends the implementation of 
> std::map
>   and a hash function.
The hashfunction/hash table lookup ensures cosistent numbering of parameters 
server and client side given that the structure of the message_template.msg 
is identical.Consistency between client side and serverside layout of the 
template file is built into the logon sequence.

3. the ordering is only semi-stable
I think this is a variation of 2

> 4. the hash function has 2 bugs in it
The codec is inefficient in so many ways, that I don't think the performace 
hit on this one is significant in any way, especially since the bucket issue 
only occurs during initialization.

Having said that, I do believe that the network protocol is a mess, 
introducing one more variant - partially implemented in some packages and 
not in others - will not improve anything.

Currently we have a mix of XML-RPC and a hand crafted codec, adding XML 
encoding into that will make the SL protocol even more confusing.

The message template contains a mixture of syntax and semtic descriptions, 
which ideally should be split.

A lot of CPU cycles are used handling dynamic message layout, but for the 
reasons you mention and because of login procedure starts with a 
SecuredTemplateChecksumRequest, this flexibility cannot be taken advantage 
of..

Part of the messages contain variable encodings of any type, e.g. 
essentially the same as Xml Schema ANY. Examples of such messages would be 
ObjectUpdateCompressed and ObjectUpdate.

IMO the protocol could be improved upon

Tleiades
ps. Having said that the syntax is a little inconsistent, in line 468 the 
words "sim -> dataserver" isn't marked as a comment. Luckily the viewer 
parser handles this inconsistency without screwing up :-)



More information about the SLDev mailing list