C : Linux Sockets: Recvfrom() too slow in fetching the UDP Packets
<p>I am receiving UDP packets at the rate of <strong>10Mbps</strong>. Each packet is formed of around <strong>1109 bytes</strong>.
So, it makes more than <strong>1pkt/ms</strong> that I am receving on <strong>eth0</strong>. The <code>recvfrom()</code> in C receives the packet and passes on the packet to Java. Java does the filtering of the packets and the necessary processing.</p>

<p>The bottlenecks are:</p>

<ol>
<li><p><code>recvfrom()</code> is too slow:fetching takes more than 10ms possibly because it does not get the  CPU. </p></li>
<li><p>Passing of the packet from C to Java through the interface(JNI) takes 1-2 ms. </p></li>
<li><p>The processing of packet in Java itself takes 0.5 to 1 second depending on if database insertion  or image processing needs to be done.</p></li>
</ol>

<p>So, the problem is many delays add up and more than half of the packets are lost.</p>

<p>The possible solutions could be:</p>

<ol>
<li><p>Exclude the need for C's <code>recvfrom()</code> completely and implement UDP fetching directly in Java (Note: On the first place, C's recvfrom() was implemented to receive raw packets and not UDP). This solution  may reduce the JNI transfer delay.</p></li>
<li><p>Implement multi-threading on the UDP receive function in Java. But then an ID shall be required in the  UDP packets for the sequence because in multi-threading the order of incoming packets is not guaranteed.  (However, in this particular program, there is a need for packets to be ordered). This solution might be  helpful in receiving all packets but the protocol which sends the data needs to be modified to add a  sequence identifier. Due to multi-threading, the receiver might have higher chances to get the CPU and  packets can be quickly fetched.</p></li>
<li><p>In Java, a blocking queue can be implemented as a huge buffer which stores the incoming packets. The  Java parser can then use the packets from this queue to process it. However, it is not sure if the receiver function will be fast enough and put all the received packets in the queue without dropping any packet.</p></li>
</ol>

<p>I would like to know which of the solutions could be optimal or a combination of the above solutions will work. Any help or suggestions would be greatly appreciated.</p>