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.
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.
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.
On 4/25/2014 9:29 PM, Matt Lehmann wrote:
One example of what I'm trying to say.
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,)
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.
You could also queue other contexts which would complete the handling
of other types of packets.
Matt
On Friday, April 25, 2014, Dahlia Trimble <[email protected]
<mailto:[email protected]>> wrote:
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:
1). reading the socket and keeping it emptied.
2) acknowledge any received packets which may require such
3) process any acknowledgements sent by the viewer
4) handle AgentUpdate packets. (these can probably be filtered for
uniqueness and mostly discarded if not unique).
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.
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.
On Fri, Apr 25, 2014 at 8:17 PM, Matt Lehmann <[email protected]
<javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote:
That makes sense to me.
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.
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.
Matt
On Friday, April 25, 2014, Dahlia Trimble
<[email protected]
<javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote:
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.
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.
On Fri, Apr 25, 2014 at 7:45 PM, Matt Lehmann
<[email protected]> wrote:
As of the last release, the algorithm for handling udp
packets from clients is as so...
Start an async read cycle on the socket, adding
packets to a blocking queue.
Also start a smart thread which waits on the queue
and services the packets.
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?
I have tried this locally and I really think it would
improve efficiency. If you want I can submit a patch.
Thanks
Matt
_______________________________________________
Opensim-dev mailing list
[email protected]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
<javascript:_e(%7B%7D,'cvml','[email protected]');>
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
