[sldev] message_template.msg ordering and packing : attentionLLfolks

Tleiades tleiades at hotmail.com
Fri Mar 16 02:07:30 PDT 2007

There is somethings in your suggestion I really don't understand, I don't 
see 1 as a pre-requisite for 2, alphabetical ordering of parameters won't 
significantly change the results of step 2.

IMO changing the order of pararmeters in a message will not change the size 
of a message. It will change the effect zero coding has on some packets, but 
the law of averages suggests to me that reordering the parameters will not 
significantly change the bandwith requirements of the SL protocol.

Using a checksum to determine versioning of message format does not seem to 
me to be safe, two different versions of a message layout may end up with 
the same checksum, over time, the probability of a conflict rises to 1, or 
is there something I have missed?

I like the idea of versioning individual messages, a simple numbering scheme 
seems to me to be simpler and less error prone, i.e. version 1, version 2 
etc. Unfortunately the message handling code seems to be distributed all 
over the viewer code base, and my guess is that the serverside code is in a 
similar state. Based on that I think there are three choices:

a) Accept the current SL protocol, as is, live with the ideosyncrasies,
b) Slowly migrate to a better protocol design
c) Make a sweeping change, to a more flexible protocol

a is not really a long term solution, c.f. my previous comments about trying 
get the protocol formalized in some standardization body.

Given the increased QA requirements over a protracted period of time caused 
by b, I believe that c is the most cost effective way to move forward. Since 
LL currently are the only ones having a running serverside stack, both a,b 
and c seems to be a moot point.

----- Original Message ----- 
From: "Adam Frisby" <adam at gwala.net>
To: <sldev at lists.secondlife.com>
Sent: Friday, March 16, 2007 8:41 AM
Subject: Re: [sldev] message_template.msg ordering and packing : 

> Here's a curious experiment:
> 1. Use alphabetical ordering on keywords
> 2. Attach a [8/16-bit?] checksum to each packet, with the checksum 
> representing the original msg_template definition for that unique packet.
> End result is, we can spot modified versions of each packet and handle 
> them appropriately (since getting a collision with so little data that is 
> modifyable should be an interesting exercise) with maybe one or two 
> "cemented" standard versions that will always be recognised.
> It leaves room for screwing around and at the same time allows 
> interoperability between different versions of the same packets on the 
> same grid/servers at once (if packet type = X and msg checksum = Y then do 
> Z)
> Adam
> John Hurliman wrote:
>> Tleiades wrote:
>>> I have a hard time accepting this as a bug, I do agree that it really 
>>> isn't elegant, and makes things more complicated than it really needs to 
>>> be, without any gains.
>>> Yes, I agree, it could have been implemented differently, and the 
>>> results would be easier to understand, but is it really a bug?
>> Since we are down to semantics now, lets replace the word "bug" with 
>> "bad" and move on. It would certainly make third party implementations of 
>> the networking library easier to write without the hashing and reordering 
>> mess, and should make clients more resilient to future changes in the 
>> protocol (where adding a single field won't reorder the entire template). 
>> If something like alphabetical ordering was used it would significantly 
>> change the protocol ordering one time, but this probably isn't much 
>> different than a normal protocol-breaking release. Any thoughts?
>> John Hurliman
>> _______________________________________________
>> Click here to unsubscribe or manage your list subscription:
>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev

More information about the SLDev mailing list