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 <[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 >> _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges
