[Opensim-dev] Question about the udp receiver algorithm

[Matt Lehmann]

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 <dahliatrimble at gmail.com> 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 <mattlehma at gmail.com<javascript:_e(%7B%7D,'cvml','mattlehma at gmail.com');>
> > 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 <dahliatrimble at gmail.com<javascript:_e(%7B%7D,'cvml','dahliatrimble at gmail.com');>>
>> 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 <mattlehma at gmail.com>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
>>>> Opensim-dev at opensimulator.org
>>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>>>
>>>>
>>>
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at opensimulator.org<javascript:_e(%7B%7D,'cvml','Opensim-dev at opensimulator.org');>
>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20140425/6ad72d84/attachment.html>