views:

41

answers:

1

Dear stackers.

I am developing an application that distributes rendering across several devices (a university project).

Each frame consists of several blocks (16x16 pixels), and each device is "assigned" a number of blocks to be rendered. These blocks, when rendered, are compressed and serialized into a buffer until the max size of this is reached, at which point it will be sent.

My problem is on the receiving end, which needs to recieve several datagrams per frame from several devices. Currently I call recv for each packet, but this requires a context switch for each packet. It would be better to receive many packets with one call. A packet identify which client it is from, so the addresses of these are irrelevant.

I have looked at WSARecv and WSARecvFrom but neither seems to be able to receive several packets from several hosts.

Thanks in advance :)

EDIT

Using a separate thread to fetch packets from the OS layer does not seem to improve the situation. In fact the solution proposed by Amardeep has a performance that is lower than the previous scheme.

Fetching several packets would be nice to try out too, anyone knows how to do that?

+2  A: 

That is probably not the cause of any perceived performance issue you are trying to address. Without seeing your code, I'll take a guess that what you're doing is:

1.  recv a packet
2.  Process a packet
3.  repeat

What you should be doing is:

1.  use one thread to recv packets with a pool of buffers and shove the received buffer pointers into a queue.
2.  use another slightly lower priority thread to pull items from the queue and process them.

This would greatly improve your system's ability to digest the data and miss fewer datagrams.

Amardeep
Don't muck with thread priorities to handle thread synchronization. If anything, the processing thread should run with _higher_ priority (!) When overloaded, don't swamp your internal queue, but leave the UDP packets in the OS buffers and let the OS deal with that. Proper synchronization is achieved by blocking the higher-priority thread when there's nothing in the queue.
MSalters
@MSalters: The thread synchronization is accomplished with the queue, not the priority. The priority I suggest is because the developer has control over the queue depth but not necessarily the OS buffers for UDP packets which are allowed to be tossed. OP does not mention the mechanism for detection and handling lost packets, if any, which could favor a different scheme.
Amardeep
I have implemented a producer/consumer pattern now, but cannot test it before tomorrow.I thought of recv'ing in a separate thread before, but discarded that because I only have one core, and the processing is rather lightweight.Oh well, time will tell ;)
Benjamin