[Opensim-dev] Upcoming work on alternative client stack

[James Greensky]

+1 on being careful when P/Invoking into unmanaged code.  It is a very heavy
operation and unless the computation done in unmanaged code can be shown to
be *magnitudes* faster, it is not worth it.

+1 on using unsafe code over a P/Invoke method.  As Melanie pointed out two
operation are two operations, but in managed code an array access also pays
a bounds checking penalty, where an array access in unsafe code does not.

On Mon, Aug 18, 2008 at 6:07 PM, Hurliman, John <john.hurliman at intel.com>wrote:

> +1 on the direction this thread is moving, factoring away specific
> client implementations from the OpenSim core. However I wanted to come
> back and touch on the funsl implementation.
>
> From my testing, any time you deal with a P/Invoke wall you need to
> seriously evaluate whether it is worth it. Creating new Packet classes
> is something that can be solved in managed code with an object pool that
> is aware of packet types. libomv had a huge success by using an object
> pool for incoming udp buffers and zero(en/de)coding buffers. The Packet
> class has already been re-factored in such a way that would allow object
> reuse.
>
> This is from my own personal testing, and more data on the topic would
> be greatly appreciated. Do you think it will be possible to empirically
> compare performance of funsl vs. the libomv wrapper?
>
> John
>
>
> -----Original Message-----
> From: opensim-dev-bounces at lists.berlios.de
> [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Mike Mazur
> Sent: Thursday, August 14, 2008 2:39 PM
> To: opensim-dev at lists.berlios.de
> Subject: [Opensim-dev] Upcoming work on alternative client stack
>
> Hello,
>
> (Could it be? Are the mailing lists working again? I wanted to send
> this message last weekend.)
>
> Some of you may already know, I've started working on an alternative
> client stack. This alternative stack does not use libomv's Packet
> class to move packets around. The buffers which are written to by
> socket functions are passed around instead, with functions available
> for extracting or writing data to the buffers.
>
> These functions are provided by a package currently codenamed "funsl".
> Johan has written a compiler[1] which generates C# and C/C++ code from
> LL's message_template.msg file[2].
>
> We're doing this because we believe the creation of a Packet object
> for each transferred packet impacts performance, particularly when GC
> events occur.
>
> As I'm working on this I found that libomv's Packet class is used
> outside the client stack, namely in OpenSim/Framework/ClientManager.cs
> and OpenSim/Framework/IClientAPI.cs (among other places). Since our
> client stack needs to implement these interfaces too, and needs to
> call ClientManager methods, those libomv Packet references get in the
> way. I would like to factor them out.
>
> Please allow me to give you an example, inspired by changeset r5785.
> ClientManager had a method, InPacket(), defined as below:
>
>     public void InPacket(uint circuitCode, Packet packet)
>     {
>         IClientAPI client;
>         bool tryGetRet = false;
>         lock (m_clients)
>             tryGetRet = m_clients.TryGetValue(circuitCode, out
> client); if (tryGetRet)
>         {
>             client.InPacket(packet);
>         }
>     }
>
> This method receives a circuit code and passes the packet to the
> IClientAPI instance associated with said circuit code.
>
> Why should the ClientManager have knowledge of Packet? It's not in the
> client stack, it only provides access to the clients. Therefore I
> changed the method as follows:
>
>     public void InPacket(uint circuitCode, object packet)
>     {
>         IClientAPI client;
>         bool tryGetRet = false;
>         lock (m_clients)
>             tryGetRet = m_clients.TryGetValue(circuitCode, out
> client); if (tryGetRet)
>         {
>             client.InPacket(packet);
>         }
>     }
>
> Instead of expecting a Packet object for the second argument, we
> expect any object. Naturally the signature of the InPacket() method in
> the IClientAPI interface has also changed. The cast from object to
> Packet (or byte[] in my case) is done in the class which implements
> IClientAPI, namely
> OpenSim/Region/ClientStack/LindenUDP/LLClientView.cs, where InPacket()
> has been changed as follows:
>
> -        public virtual void InPacket(Packet NewPack)
> +        public virtual void InPacket(object NewPack)
>     {
> -            m_PacketHandler.InPacket(NewPack);
> +            // Cast NewPack to Packet.
> +            m_PacketHandler.InPacket((Packet) NewPack);
>     }
>
> InPacket() is the first method that has been changed so far, but
> others will need to follow (OutPacket(), SendSimStats(),
> ProcessInPacket(), etc).
>
> Please rest assured these changes don't break existing functionality,
> just factoring out some libomv Packet references which currently live
> outside the client stack.
>
> Any thoughts or concerns?
>
> Thank you,
> Mike
>
>
> [1] If you are interested in the source for the compiler, written in
> LISP, just ask ;)
> [2]
> http://svn.secondlife.com/trac/linden/browser/release/scripts/messages
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> _______________________________________________
> 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/20080818/46a77cfd/attachment-0001.html>