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