[Opensim-dev] Upcoming work on alternative client stack

[Melanie]

Hi,

it's just the concept or partial or incremental or lazy decoding i 
have a bed feeling about.
As jhurliman stated, there is really no way to make a partial 
unpacking less expensive than a full one, you might wind up 
repeating the operation if you find out you need more data than 
initially requested and I believe that will eat up all benefits. 
Complete unpack on reception is the way to go, IMHO. That could be 
done in another thread, for makeing it more responsive to the 
client, but that is a look & feel thing, it doesn't change the 
principle of a single unpack run being preferable to multiple ones. 
 From most packets, all data is needed. Not all of it is used, 
because we have so many unimplemented features, but if we were 
feature complete, we would pretty much use every field in every packet.

Melanie




Hurliman, John wrote:
> 
> -----Original Message-----
> From: opensim-dev-bounces at lists.berlios.de
> [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Mike Mazur
> Sent: Monday, August 18, 2008 5:16 PM
> To: opensim-dev at lists.berlios.de
> Subject: Re: [Opensim-dev] Upcoming work on alternative client stack
> 
> Hi,
> 
> On Mon, 18 Aug 2008 16:07:45 -0700
> "Hurliman, John" <john.hurliman at intel.com> wrote:
> 
>> From my testing, any time you deal with a P/Invoke wall you need to
>> seriously evaluate whether it is worth it.
> 
> I'd just like to clarify a few things.
> 
> First, I'm not trying to do any P/Invoke stuff. The funsl stack I'm
> working on is strictly C# managed code. The C/C++ files generated by
> the compiler can be used in other projects if they are developed in C
> or C++.
> 
> Second, the performance bottlenecks were mainly with the GC. We found
> that during login the number of GC events increased dramatically. The
> solution for this is a working PacketPool. There's also the issue of
> unpacking the entire packet every time it comes in, immediately as it
> comes in, when all that's needed is a subset of the data. The solution
> to this is lazily extracting the data right before the client stack
> calls out to the core.
> 
> Thanks,
> Mike
> 
> 
> Ahh, I misunderstood and thought this was an unmanaged/managed hybrid.
> Anything that reduces heap allocations / fragmentation is going to be a
> big win. That's what my work with the types has been focusing on. Let me
> know if you start looking at the PacketPool, I don't have free cycles to
> dedicate to it right now but I have drafted some ideas out on paper. As
> far as unpacking the entire packet, I made the design assumption that
> you want to access all of the data in a packet at some point, or at
> least enough of it that it makes sense to decode the entire thing in a
> single pass. The way SL packets are laid out means you have to parse
> through the entire thing up to the field you are interested in, because
> of variable field and block sizes. Stuffing the incoming UDP buffers in
> a queue and delaying decoding could address your latter issue.
> Regardless, I'm interested in any possible new methods of handling
> packet decoding/encoding and will lend a hand to profiling and
> comparison when the code is ready.
> 
> John
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> 
>