No subject

seriously evaluate whether it is worth it. Creating new Packet classes<br>
is something that can be solved in managed code with an object pool that<br>
is aware of packet types. libomv had a huge success by using an object<br>
pool for incoming udp buffers and zero(en/de)coding buffers. The Packet<br>
class has already been re-factored in such a way that would allow object<br>
reuse.<br>
<br>
This is from my own personal testing, and more data on the topic would<br>
be greatly appreciated. Do you think it will be possible to empirically<br>
compare performance of funsl vs. the libomv wrapper?<br>
<font color="#888888"><br>
John<br>
</font><div class="Ih2E3d"><br>
<br>
-----Original Message-----<br>
From: <a href="mailto:opensim-dev-bounces at lists.berlios.de">opensim-dev-bounces at lists.berlios.de</a><br>
</div><div class="Ih2E3d">[mailto:<a href="mailto:opensim-dev-bounces at lists.berlios.de">opensim-dev-bounces at lists.berlios.de</a>] On Behalf Of Mike Mazur<br>
Sent: Thursday, August 14, 2008 2:39 PM<br>
To: <a href="mailto:opensim-dev at lists.berlios.de">opensim-dev at lists.berlios.de</a><br>
</div><div><div></div><div class="Wj3C7c">Subject: [Opensim-dev] Upcoming work on alternative client stack<br>
<br>
Hello,<br>
<br>
(Could it be? Are the mailing lists working again? I wanted to send<br>
this message last weekend.)<br>
<br>
Some of you may already know, I've started working on an alternative<br>
client stack. This alternative stack does not use libomv's Packet<br>
class to move packets around. The buffers which are written to by<br>
socket functions are passed around instead, with functions available<br>
for extracting or writing data to the buffers.<br>
<br>
These functions are provided by a package currently codenamed "funsl".<br>
Johan has written a compiler[1] which generates C# and C/C++ code from<br>
LL's message_template.msg file[2].<br>
<br>
We're doing this because we believe the creation of a Packet object<br>
for each transferred packet impacts performance, particularly when GC<br>
events occur.<br>
<br>
As I'm working on this I found that libomv's Packet class is used<br>
outside the client stack, namely in OpenSim/Framework/ClientManager.cs<br>
and OpenSim/Framework/IClientAPI.cs (among other places). Since our<br>
client stack needs to implement these interfaces too, and needs to<br>
call ClientManager methods, those libomv Packet references get in the<br>
way. I would like to factor them out.<br>
<br>
Please allow me to give you an example, inspired by changeset r5785.<br>
ClientManager had a method, InPacket(), defined as below:<br>
<br>
     public void InPacket(uint circuitCode, Packet packet)<br>
     {<br>
         IClientAPI client;<br>
         bool tryGetRet = false;<br>
         lock (m_clients)<br>
             tryGetRet = m_clients.TryGetValue(circuitCode, out<br>
client); if (tryGetRet)<br>
         {<br>
             client.InPacket(packet);<br>
         }<br>
     }<br>
<br>
This method receives a circuit code and passes the packet to the<br>
IClientAPI instance associated with said circuit code.<br>
<br>
Why should the ClientManager have knowledge of Packet? It's not in the<br>
client stack, it only provides access to the clients. Therefore I<br>
changed the method as follows:<br>
<br>
     public void InPacket(uint circuitCode, object packet)<br>
     {<br>
         IClientAPI client;<br>
         bool tryGetRet = false;<br>
         lock (m_clients)<br>
             tryGetRet = m_clients.TryGetValue(circuitCode, out<br>
client); if (tryGetRet)<br>
         {<br>
             client.InPacket(packet);<br>
         }<br>
     }<br>
<br>
Instead of expecting a Packet object for the second argument, we<br>
expect any object. Naturally the signature of the InPacket() method in<br>
the IClientAPI interface has also changed. The cast from object to<br>
Packet (or byte[] in my case) is done in the class which implements<br>
IClientAPI, namely<br>
OpenSim/Region/ClientStack/LindenUDP/LLClientView.cs, where InPacket()<br>
has been changed as follows:<br>
<br>
-        public virtual void InPacket(Packet NewPack)<br>
+        public virtual void InPacket(object NewPack)<br>
     {<br>
-            m_PacketHandler.InPacket(NewPack);<br>
+            // Cast NewPack to Packet.<br>
+            m_PacketHandler.InPacket((Packet) NewPack);<br>
     }<br>
<br>
InPacket() is the first method that has been changed so far, but<br>
others will need to follow (OutPacket(), SendSimStats(),<br>
ProcessInPacket(), etc).<br>
<br>
Please rest assured these changes don't break existing functionality,<br>
just factoring out some libomv Packet references which currently live<br>
outside the client stack.<br>
<br>
Any thoughts or concerns?<br>
<br>
Thank you,<br>
Mike<br>
<br>
<br>
[1] If you are interested in the source for the compiler, written in<br>
LISP, just ask ;)<br>
[2]<br>
<a href="http://svn.secondlife.com/trac/linden/browser/release/scripts/messages" target="_blank">http://svn.secondlife.com/trac/linden/browser/release/scripts/messages</a><br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev at lists.berlios.de">Opensim-dev at lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev at lists.berlios.de">Opensim-dev at lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
</div></div></blockquote></div><br></div>

------=_Part_202769_7029875.1219103441814--