[Opensim-dev] Upcoming work on alternative client stack

[Ryan McDougall]

On Fri, 2008-08-15 at 06:38 +0900, Mike Mazur 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?

Thanks for the proposal, but I still don't see the point just yet for
disabling C#'s typing system. For better or worse, this project is C#,
and C# is strongly typed, and until we migrate to a different language,
our code should also be strongly typed.

Traditionally in an OO system, one would factor out a dependency on a
specific packet type by creating a base class to inherit from. 

I can buy the argument that packet handling is performance critical, but
in that case I'd rather have Packet being a thin wrapper around byte[],
or even just byte[] itself, than use Object and then cast it about.

Can this work be done on a branch instead of trunk, then merged when the
benefits are obvious? I'm pretty sure that's what branches are for. ;)


> Thank you,
> Mike

Cheers,

> 
> 
> [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