[sldev] message_template.msg ordering and packing
robla at lindenlab.com
Fri Mar 16 07:57:43 PDT 2007
Zero Linden (Mark Lentczner) is currently holding office hours regularly
in world...see his email from yesterday. A bunch of folks from LL are
working on big protocol improvements, exactly along the lines that you
Hopefully we can bridge the gap between the email discussion going on
here, and the work that he's doing there. Best thoughts on how to do that?
On 3/16/07 2:07 AM, Tleiades wrote:
> 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
>> 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)
>> 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:
>> Click here to unsubscribe or manage your list subscription:
> Click here to unsubscribe or manage your list subscription:
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 249 bytes
Desc: OpenPGP digital signature
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070316/d56fbcff/signature.pgp
More information about the SLDev