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 <[email protected]> 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
