[sldev] AppendedAcks
Philip Rosedale
philip at lindenlab.com
Wed Apr 1 15:15:14 PDT 2009
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090401/43bff90f/attachment-0001.htm
More information about the SLDev
mailing list