[Opensim-dev] Upcoming work on alternative client stack

[Mike Mazur]

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