[Opensim-dev] Upcoming work on alternative client stack

[Kyle Hamilton]

I would avoid generating C# and C/C++ code from message_template.msg.
The entire distribution (including that file) is only made available
under GPL; any programmatic derivation from it (and a programmatic
transformation turns it from 'reference' to 'source code') could be
held to place the derivative under the GPL as well.

Maybe someone can ask if they can make an exception for that file?

-Kyle H

On Thu, Aug 14, 2008 at 2:38 PM, Mike Mazur <mmazur at gmail.com> wrote:
> 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
>