[Opensim-dev] Upcoming work on alternative client stack

Teravus Ovares teravus at gmail.com
Sun Aug 17 16:44:14 UTC 2008


There are two places that OutPacket needs to be factored out of the OpenSim
core still.   In the Texture sender..  (still uses outpacket!) and
ClientManager...   There's one packet type called 'viewereffectpacket'.
Refactor those into the client stack and the below refactorings will be
possible.

Best Regards

Teravus


On 8/14/08, 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20080817/cc4751e3/attachment-0001.html>


More information about the Opensim-dev mailing list