[sldev] message_template.msg ordering and packing : attention LL folks

John Plevyak jplevyak at acm.org
Thu Mar 15 11:36:10 PDT 2007


I been been investigating the message_template.msg and binary layout and
have discovered some bugs/issues.   Before I create a patch I would like
to know if there is anything going on inside LL which would invalidate or
make unnecessary any fix.  The change would have to be applied to both
the viewer and the server code.

1. in the wire/binary encoding, blocks and variables are out of order 
   with respect to the message_template.msg file

2. the ordering of blocks and variables depends the implementation of std::map
   and a hash function.

3. the ordering is only semi-stable

   a. it is unstable with respect to the order in which the tokens are inserted.
      changing the order can change the order of elements in gMessageStringTable
      which can result in changes to the wire/binary encoding

   b. it is unstable in the sense that single addition can cause reordering
      of more than one element (owing to the fact that it uses linear hashing
      with wraparound).

4. the hash function has 2 bugs in it

   a. it always ignores the first character, which for tokens like "X", "Y", "Z" ensures
      that they will always be in the first bucket
  
   b. it always returns a multiple of 2, increasing collisions and time spent in lookups


All of these things can be corrected, however

   1. I know there has been talk of using XML for some of the lower frequency messages.
   
   2. If I was going to open up this can of worms I would likely want to at least improve
      the efficiency, make it more reslient to changes to the template file, etc.

john
john at metaversatility.com
jplevyak at sourceforge.net (FOSSL project)

-- 
John Bradley Plevyak, PhD,   jplevyak at acm.org,   PGP KeyID: 051130BD


More information about the SLDev mailing list