C：Linux套接字：Recvfrom（）在获取UDP数据包时太慢

Question

I am receiving UDP packets at the rate of 10Mbps . Each packet is formed of around 1109 bytes . So, it makes more than 1pkt/ms that I am receving on eth0 . The recvfrom() in C receives the packet and passes on the packet to Java. Java does the filtering of the packets and the necessary processing.

The bottlenecks are:

1. recvfrom() is too slow:fetching takes more than 10ms possibly because it does not get the CPU.

2. Passing of the packet from C to Java through the interface(JNI) takes 1-2 ms.

3. 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.

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

The possible solutions could be:

1. Exclude the need for C's recvfrom() 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.

2. 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.

3. 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.

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.

Answer 1

How long is this burst going on? Is it continuous and will go on forever? Then you need beefier hardware that can handle the load. Possibly some load-balancing where multiple servers handle the incoming data.

Does the burst only last a short wile, like in at most a second or two? Then have the lower levels read all packets as fast as it can, and put in a queue, and let the upper levels get the messages from the queue in its own time.

Answer 2

It sounds like you may be calling recvfrom() with your socket in blocking mode, in which case it will not return until the next packet arrives. If the packets are being sent at 10ms intervals, perhaps due to some delay on the sending side, then a loop of blocking recvfrom() calls would appear to take 10ms each. Set the socket to non-blocking and use something like select() to decide when to call it. Then profile everything to see where the real bottleneck lies. My bet would be on one or more of the JNI passthroughs.

Note that recvfrom() is not a "C" function, it is a system call. Java's functions just add layers on top of it.