[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