Often processing incoming packets can require exclusive access to scene
data structures. I'd avoid using a threadpool task (FireAndForget) to
process a incoming packet to avoid potential lock contention and threadpool
task exhaustion.
On Thu, Apr 24, 2014 at 9:30 AM, matt lehmann <mlehma...@hotmail.com> wrote:
> Hello,
>
> The current implementation of UDP reception ( as of the latest release )
> is as follows.
>
> -- create an async read cycle on the socket, adding packets to a blocking
> queue
> -- create a smart thread which waits on the blocking queue, servicing new
> packets as the occur
>
> I propose a simpler solution, which will give more control over rate of
> reception, and also eliminate the need for two separate threads in
> reception.
>
> This solution involves polling the udp socket, from within the smart
> thread.
>
> The function IncomingPacketHandler, from within the LLUDPServer class
> changes to this:
>
> private void IncomingPacketHandler()
> {
>
> ....
> IncomingPacket incomingPacket = null;
>
> base.pollReceive();
> while(packetInbox.Count > 0)
> {
> incomingPacket = packetInbox.Dequeue();
>
> ProcessInPacket(incomingPacket);//,
> incomingPacket); Util.FireAndForget(ProcessInPacket, incomingPacket);
>
> if (UsePools)
>
> m_incomingPacketPool.ReturnObject(incomingPacket);
> }
>
> ....
> }
>
> packetInbox is now a standard .NET queue.
>
>
> The method, pollReceive on the base class looks like this:
>
> public bool pollReceive()
> {
>
> if (m_udpSocket.Poll(100, SelectMode.SelectRead))
> {
>
> UDPPacketBuffer buf = new UDPPacketBuffer();
> buf.DataLength = m_udpSocket.ReceiveFrom(buf.Data,
> 0,
> UDPPacketBuffer.BUFFER_SIZE,
> SocketFlags.None,
> ref buf.RemoteEndPoint);
> PacketReceived(buf);
> return true;
> }
> return false;
> }
>
>
> This setup should allow for better throughput, as there will be less
> context switching and reliance on the .NET threading runtime to service the
> async requests. Also, it would now be possible to throttle incoming
> packets under heavy loads.
>
>
>
> * Matt Lehmann *
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev@opensimulator.org
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>
>
_______________________________________________
Opensim-dev mailing list
Opensim-dev@opensimulator.org
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
