0
ioctl(socketFd_, SIOCOUTQ, &outstandingBytes);  
getsockopt(socketFd_, SOL_SOCKET, SO_SNDBUF, &sendBuffSize, &buffLen);

I am using these two api to debug the packet drop in my program.
observation:

  1. sendto will always return the packet size so call to sendto is always successful.
  2. when oustandingBytes reaches 2040, packet will be dropped by linux kernel means i am not able to see the packet it in the wireshark. i am capturing the packet on my local eth interface.
  3. my sendBuffSize is 124928 as returned by getsockopt.
  4. the packet size which i am sending will be around 300 to 350 bytes. and i have two socket one raw socket for sending GRE packet and another udp socket and i am seeing the packet drop for both type of protocol, both of the socket are in non blocking mode.
    is sendto is not able to detect the error because packet are being dropped before reaching the sendBuffSize limit?
    How can i increase the limit of 2040 in my system. this value should be 124928 as returned by getsockopt() api.
    I have similar thread for this issue as given below however i am not able to get answer so decided to start a new thread.
    rawsocket sendto() some of the packet are dropped and not seen in the network
Community
  • 1
  • 1
devesh
  • 76
  • 9

1 Answers1

0

UDP and raw sockets don't provide any way to detect dropped packets. Packets can be lost in the network due to router failures or network congestion, or they can be discarded in the kernel. If you need to detect lost packets, you must do it in the application layer, or implement a session layer above UDP.

If the kernel is not able to buffer the packet when you call sendto(), it should return -1 and set errno to EWOULDBLOCK.

Barmar
  • 741,623
  • 53
  • 500
  • 612
  • i have retransmission logic in my program, however the root cause i am looking for is that, sendto is not returning any error and packet are being dropped by linux kernel much before reaching it send buffer size limit. – devesh Feb 22 '14 at 09:14
  • 2
    There is however a big difference between "UDP doesn't provide detection of dropped packets" and "network stack will simply drop packets at rates which are entirely reasonable". 2040 bytes is well within the allowable size of a single UDP diagram and less than 2 ethernet frames (or 1 jumbo frame). While you obviously cannot guarantee what arrives at the other end of the cable, you should very definitively be able to expect that your packets at least reach the network card (even if they're 10 smaller datagrams). – Damon Feb 22 '14 at 13:56
  • I'm skeptical of his claim that packets are discarded when he's queued up only 2040 bytes. I'm sure that high-performance DNS servers are sending many times that number of bytes at a high rate. – Barmar Feb 22 '14 at 13:59
  • *"2040 bytes is well within the allowable size of a single UDP diagram"* -- Please provide a reference. I did write a reliable datagram protocol on top of UDP that is used in a product. And I recall something about uncertainty about the max size for UDP packets. Anyway I kept it to under 640 bytes to be on the safe side, and never had any issues. Well, except for a network driver that had a "rotting packet" issue that I had to patch. – sawdust Feb 24 '14 at 00:27
  • See RFC 768. The UDP length field is 16 bits, which allows for datagrams up to 64K bytes (including the 8-byte header). IP fragmentation and reassembly will be required for such large datagrams, so it's not recommended. But NFS has traditionally sent 8K datagrams. – Barmar Feb 24 '14 at 02:23
  • 2040 is not the size of UDP datagram. my UDP Datagram size will be only 300 to 350 bytes, after sendto() system call kernel will keep the packet into its internal sendbuffer(size 124928 in my case) and packet will be delivered to the network based on availability of resources. and if sendbuffer size reached it's limit the packet will be dropped inside kernel itself. however in my scenario packet are being dropped much before reaching this limit(i.e. 2040). – devesh Feb 24 '14 at 08:50
  • I'm not an expert on the Unix kernel design. My guess is that the limit isn't just the number of bytes, but the number of packets. So having lots of small packets outstanding could cause some of them to be discarded, even though the total buffer space isn't very large. – Barmar Feb 24 '14 at 17:01