[Opensim-dev] Does OpenSim need to leave so many packets marked as reliable?

Stefan Andersson stefan at tribalmedia.se
Fri Oct 3 04:53:56 UTC 2008


Guys,
 
for some time now, I've been meaning to propose a quite different approach, of which we've actually already done some tests with good result;
 
the basic idea is to connect reliable packets with two delegates; an ack delegate and a nack delegate - the implication probably obvious:
 
when the packet gets acked, the ack delegate is called, when it's nacked, the nack. The packet is sent as a parameter.
 
what this would let us do, is to use the sent packet to figure out what the right course of action is;
 
for an update, for example, we could look that object up and see if it's there's been another more resent update sent; if so, we can discard this. If not - we can _recreate_ a more recent packet and send that instead.
 
We have done something similar for terrain, a terrain packet watchdog, which keeps track of what patches has been acked, and resends those that haven't after a timeout. This removes the atom bombing.Best regards,Stefan AnderssonTribal Media AB Join the 3d web revolution : http://tribalnet.se/ 



> Date: Thu, 2 Oct 2008 21:00:44 +0100> From: jjustincc at googlemail.com> To: opensim-dev at lists.berlios.de> Subject: Re: [Opensim-dev] Does OpenSim need to leave so many packets marked as reliable?> > Yes, it's possible that the situation is more complicated than simply marking all packets as reliable. It's also > difficult to look at percentages since it does depends heavily on what you do.> > Also, apologies for suggesting I would change trunk earlier. I won't be making any changes there without more > consultation, at least certainly not any change which is non-default. I forgot how complicated an area this is.> > > Melanie wrote:> > Hi again,> > > > there may be some object updates that can be sent unreliable. For > > instance, all that have to do with moving objects (e.g. velocity != > > 0). but the initial object update can't be lost. Any object update > > lost of the login burst is a ghost prim.> > > > Melanie> > > > > > Justin Clark-Casey wrote:> >> Hmm, I then did the obvious thing and compared it (unscientifically) with a couple of sessions on the Linden Lab grid. > >> There, reliable packets appear to compromise approximately 40% of the transfer.> >>> >>> >> -------- Original Message --------> >> Subject: Does OpenSim need to leave so many packets marked as reliable?> >> Date: Thu, 02 Oct 2008 19:32:57 +0100> >> From: Justin Clark-Casey <jjustincc at googlemail.com>> >> To: opensim-dev at lists.berlios.de> >>> >> Hi there,> >>> >> A vast number of the packets that we send out from OpenSim (usually >95% according to the statistics printed to the> >> Linden viewer log on shutdown) are marked as reliable. This requires that the viewer respond with an ack, and it just> >> doesn't appear that this is done very well when a large number of reliables are sent. A lot of acks never come and we> >> often appear to end up resending thousands (or in the worst case tens of thousands) of packets.> >>> >> In a private experiment I've set Header.Reliable = false for the LayerDataPacket and ObjectUpdatePacket (which appear to> >> be the greatest sent by count, and which are currently reliable by default in libOMV). Naturally, this cuts down the> >> vast number of resends (and possibly some of the packet_out_of_order messages that come out on the console log) without> >> any apparant ill effects. However, my testing has been pretty limited so I'm minded to wait until Monday before making> >> any trunk changes, since then I can get a better load test with multiple avatars (this doesn't stop anybody else testing> >> of course :-)> >>> >> Any opinions on this? Is there a good reason for these packets to remain reliable (when resends are probably rare> >> anyway)? libOMV appears to mark every packet as reliable by default... and then OpenSim removes this from a couple of> >> them but not from others.> >>> > _______________________________________________> > Opensim-dev mailing list> > Opensim-dev at lists.berlios.de> > https://lists.berlios.de/mailman/listinfo/opensim-dev> > > > > -- > justincc> Justin Clark-Casey> http://justincc.wordpress.com> _______________________________________________> Opensim-dev mailing list> Opensim-dev at lists.berlios.de> https://lists.berlios.de/mailman/listinfo/opensim-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20081003/6471f1f8/attachment-0001.html>


More information about the Opensim-dev mailing list