Yes I agree that the udp service is critical and would need extensive testing.<div><br></div><div>I wouldn't expect you all to make any changes. </div><div><br></div><div><span></span>Still it's an interesting topic. The networking world seems to be moving towards smaller virtualized servers with less resources, so I think it's an important discussion. At my work we are deploying an opensim cluster which is why I have become so interested.</div>
<div><br></div><div><br></div><div>Thanks</div><div><br></div><div>Matt</div><div><br></div><div><br>On Friday, April 25, 2014, Diva Canto <<a href="mailto:diva@metaverseink.com">diva@metaverseink.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>That is one very specific and unique
case, something that happens in the beginning, and that is
necessary, otherwise clients crash. It's an "exception" wrt the
bulk of processing UDP packets. The bulk of them are processed as
you described in your first message: placed in a queue, consumed
by a consumer thread which either processes them directly or
spawns threads for processing them.<br>
<br>
In general, my experience is also that limiting the amount of
concurrency is a Good Thing. A couple of years ago we had way too
much concurrency; we've been taming that down. <br>
<br>
As Dahlia said, the packet handling layer of OpenSim is really
critical, and the viewers are sensitive to it, so any drastic
changes to it need to go through extensive testing. The current
async reading is not bad, as it empties the socket queue almost
immediately. The threads that are spawn from the consumer thread,
though, could use some rethinking.<br>
<br>
On 4/25/2014 9:29 PM, Matt Lehmann wrote:<br>
</div>
<blockquote type="cite">One example of what I'm trying to say.
<div><br>
</div>
<div>In part of the packet handling there is a condition where the
server needs to respond to the client, but does not yet know the
identity of the client. So the server responds to the client and
then spawns a thread which loops and sleeps until it can
identify the client.( I don't really understand what's going on
here,)</div>
<div><br>
</div>
<div>Nevertheless in this case you could do without the new thread
if you queued a lambda function which would check to see if the
client can be identified. A second event loop could
periodically poll this function until it completes.</div>
<div><br>
</div>
<div>You could also queue other contexts which would complete the
handling of <span></span>other types of packets.</div>
<div><br>
</div>
<div>Matt</div>
<div><br>
On Friday, April 25, 2014, Dahlia Trimble <<a>dahliatrimble@gmail.com</a>>
wrote:<br>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>From my experience there are some things that
need to happen as soon as possible and others
which can be delayed. What needs to happen ASAP:<br>
</div>
1). reading the socket and keeping it emptied.<br>
</div>
2) acknowledge any received packets which may
require such<br>
</div>
3) process any acknowledgements sent by the viewer<br>
</div>
4) handle AgentUpdate packets. (these can probably be
filtered for uniqueness and mostly discarded if not
unique).<br>
<br>
</div>
This list is off the top of my head and may not be
complete. Most, if not all, other packets could be put
into queues and process as resources permit without
negatively affecting the quality of the shared state of
the simulation.<br>
<br>
</div>
Please be aware that viewers running on high-end machines
can constantly send several hundred packets per second, and
that under extreme conditions there can be several hundred
viewers connected to a single simulator. Any improvements
in the UDP processing portions of the code base should
probably take these constraints into consideration.<br>
</div>
<div><br>
<br>
<div>On Fri, Apr 25, 2014 at 8:17 PM,
Matt Lehmann <span dir="ltr"><<a>mattlehma@gmail.com</a>></span>
wrote:<br>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">That
makes sense to me.
<div><br>
</div>
<div>If I recall, the packet handlers will create more
threads if they expect delays, such as when waiting
for a client to finish movement into the sim.</div>
<div><br>
</div>
<div>Considering that I have 65 threads running on my
standalone instance, with 4 cores that leaves about 15
threads competing. You have to do the work at some
point. <span><font color="#888888"><br>
<br>
Matt</font></span></div>
<div>
<div>
<div><span></span><br>
On Friday, April 25, 2014, Dahlia Trimble <<a>dahliatrimble@gmail.com</a>>
wrote:<br>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>Depends on what you mean by "services the
packets". Decoding and ACKing could probably
work well in a socket read loop but
dispatching the packet to the proper part of
the simulation could incur many delays which
can cause a lot of packet loss in the lower
level operating system routines as the
buffers are only so large and any excessive
data is discarded. Putting them in a queue
</div></div></blockquote></div></div></div></blockquote></div></div></blockquote></div></blockquote></div>
</blockquote></div>