UDP Server Buffer Overflow

I am writing a C ++ application on Linux. My application has a UDP server that sends data to clients on some events. The UDP server also receives feedback / acknowledgment from clients.

To implement this application, I used one UDP socket (for example, int fdSocket ) to send and receive data from all clients. I connected this sock to port 8080 and set the socket to NON_BLOCKING mode.

I created two threads. In one thread, I wait for an event to happen, if an event occurs, I use fdsocket to send data to all clients (in a for loop).

In another thread, I use fdSocket to receive data from clients ( recvfrom() ). This thread is scheduled to run every 4 seconds (that is, every 4 seconds it is called by recvfrom() to retrieve data from the socket buffer. Since it is in UNLOCKED mode, recvfrom() will immediately return if no UDP data is available then I will go to sleep for 4 seconds).

UDP feedback / acknowledgment from all clients has a fixed payload of 20 bytes in size.

Now I have two questions related to this implementation:

  • Is it correct to use the same socket to send / receive UDP data with Mulitiple clients?
  • How to find the maximum number of UDP Feedback / Acknowledge packets that my application can process without overflowing the UDP buffer (since I read every 4 seconds if I receive a lot of packets in these 4 seconds. I may lose some packet, i.e. me need to find the speed in packets / sec, which I can safely handle)?

I tried to get the Linux buffer size for the socket ( fdSocket ) using the getsockopt(fdsocket,SOL_SOCKET,SO_RCVBUF,(void *)&n, &m); function getsockopt(fdsocket,SOL_SOCKET,SO_RCVBUF,(void *)&n, &m); . From this function, I found that my Socket buffer size is 110592. But I do not understand what data will be stored in this socket buffer: will it only save the UDP payload or the entire UDP packet or event for the entire Ethernet packet? I referred to this link to get an idea, but got confused.

My code is currently a bit dirty, I will clean and publish it soon here.

Below are the links that I mentioned before posting this question.

+4
source share
3 answers

Reading sockets at a fixed interval of four seconds definitely sets you up for packet loss. The usual reliable approach to non-blocking I / O is a system call to the select(2) / poll(2) / epoll(7) demultiplexer. See if you can use them to capture / respond to other events.

On the other hand, since you are already using threads, you can simply block recv (2) without this four second sleep.

Read Stevens for an explanation of SO_RCVBUF .

+3
source

Q: Is it correct to use the same socket to send / receive UDP data with Mulitiple clients?

A: Yes, that’s right.

Q: How to find the maximum number of UDP Feedback / Acknowledge packets that my application can process without overflowing the UDP socket buffer (since I read every 4 seconds, if I receive many packets during these 4 seconds, I may lose some packet, etc. e .., I need to find the speed: noofpackets / sec, which I can handle safely)?

A: The bottleneck could be network bandwidth, or processor, or memory. You can simply test using a client that sends an ACK to a server with a serial number and checks to see if there is packet loss on the server.

+2
source

You can see the maximum allowed buffer size:

 sysctl net.core.rmem_max 

You can set the maximum buffer size you can use:

 sysctl -w net.core.rmem_max=8388608 

You can also set the size of the buffer at runtime (without exceeding the maximum value) using setsockopt and changing SO_RCVBUF. You can see the buffer level by looking at / proc / net / udp.

The buffer is used to store UDP headers and application data, the rest belong to lower levels.

+2
source

All Articles