No subject

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 =3D false;
         lock (m_clients)
             tryGetRet =3D 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 =3D false;
         lock (m_clients)
             tryGetRet =3D 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