[sldev] AppendedAcks

Thomas Grimshaw tom at streamsense.net
Wed Apr 1 15:18:23 PDT 2009


In order for that to be accomplished, it will be massively helpful for 
somebody from the lab to spend some time updating the protocol details 
on the wiki with information on which parameters do what, etc.

While the community (libsecondlife / opensimulator) have deciphered a 
majority of the messages, nothing is certain or definate, and having to 
reverse engineer something which is technically open is a little 
counterproductive.

~T

Philip Rosedale wrote:
> I have a special place in my heart, though, for anyone who spots a 
> case where we are inefficiently sending data.  We need every byte we 
> can get, both in terms of latency and total bandwidth implications.  
> One project I'd love to get to (and perhaps have community help with) 
> is a careful examination of all existing messages to look for bytes we 
> could save. 
>
> Thomas Grimshaw wrote:
>> Yes, you're right. For some reason I was thinking they were 64bit ID's, 
>> when I know they're not.
>>
>> Apologies
>>
>> ~T
>>
>> Brandon Lockaby wrote:
>>   
>>> My thoughts:
>>> * Under the current circumstances a packet ID occupies 4 bytes
>>> * While the packet ID's are below 256 (not for very long), you can 
>>> save one byte for every packet ID
>>> * Once they get into the range of 256-65535, zero coding would save 
>>> nothing
>>> * Once they get into the range of 65536-16777215, zero coding start to 
>>> require 5 bytes for each packet ID
>>>
>>> I wonder if I understand correctly though?
>>>
>>> On Wed, Apr 1, 2009 at 3:49 PM, Thomas Grimshaw <tom at streamsense.net 
>>> <mailto:tom at streamsense.net>> wrote:
>>>
>>>     Hey all,
>>>
>>>     I was just wondering if there was any practical reason why
>>>     AppendedAcks
>>>     are not zerocoded in the packet data?
>>>
>>>     Saving a few bytes means fitting more Acks into each message,
>>>     potentially reducing the number of PacketAck messages being sent,
>>>     which
>>>     means a potentially substantial protocol overhead reduction.
>>>
>>>     This could also be implemented  with backward compatibility by using a
>>>     new flag to indicate zerocoded appendedacks.
>>>
>>>     ~T
>>>
>>>
>>>
>>>
>>>     _______________________________________________
>>>     Policies and (un)subscribe information available here:
>>>     http://wiki.secondlife.com/wiki/SLDev
>>>     Please read the policies before posting to keep unmoderated
>>>     posting privileges
>>>
>>>
>>>     
>>
>> _______________________________________________
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/SLDev
>> Please read the policies before posting to keep unmoderated posting privileges
>>   



More information about the SLDev mailing list