<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">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
cite="mid:CAP5hjO2YQeupnhdBGbyMuom=D2L+6u=Vb0n6tBejdL4=+Ut_gg@mail.gmail.com"
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
moz-do-not-send="true" href="mailto:dahliatrimble@gmail.com">dahliatrimble@gmail.com</a>>
wrote:<br>
<blockquote class="gmail_quote" 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 class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Fri, Apr 25, 2014 at 8:17 PM,
Matt Lehmann <span dir="ltr"><<a
moz-do-not-send="true"
href="javascript:_e(%7B%7D,'cvml','mattlehma@gmail.com');"
target="_blank">mattlehma@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" 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
moz-do-not-send="true"
href="javascript:_e(%7B%7D,'cvml','dahliatrimble@gmail.com');"
target="_blank">dahliatrimble@gmail.com</a>>
wrote:<br>
<blockquote class="gmail_quote" 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
for another thread to service is a good
compromise which tends to keep things
working under most load conditions.</div>
<div><br>
</div>
However, if your design seems to improve
things under a wide range of operating
conditions, feel free to submit a patch! But
please don't expect it to be accepted as it
may need a *lot* of testing to show it's
benefit over the current implementation.<br>
<div><br>
<br>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Fri, Apr 25, 2014
at 7:45 PM, Matt Lehmann <span dir="ltr"><<a
moz-do-not-send="true">mattlehma@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex">
<p dir="ltr">As of the last release, the
algorithm for handling udp packets from
clients is as so... </p>
<p dir="ltr"> Start an async read cycle
on the socket, adding packets to a
blocking queue.<br>
Also start a smart thread which waits
on the queue and services the packets. </p>
<p dir="ltr">Wouldn't it be more efficient
to use a single thread that waits on the
socket by looping on a socket.poll
call, immediately servicing packets? </p>
<p dir="ltr">I have tried this locally and
I really think it would improve
efficiency. If you want I can submit a
patch. </p>
<p dir="ltr">Thanks</p>
<span><font color="#888888">
<p dir="ltr">Matt</p>
</font></span><br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a moz-do-not-send="true">Opensim-dev@opensimulator.org</a><br>
<a moz-do-not-send="true"
href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev"
target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
</div>
</div>
</div>
<br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a moz-do-not-send="true"
href="javascript:_e(%7B%7D,'cvml','Opensim-dev@opensimulator.org');"
target="_blank">Opensim-dev@opensimulator.org</a><br>
<a moz-do-not-send="true"
href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev"
target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Opensim-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a>
<a class="moz-txt-link-freetext" href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>