Seeing large amounts of data on udp recv-q, only sending 1 byte of data

Hi all,

I have 2 simple little apps, running on 2 different dell 1950's both
running 2.6.18 debian linux kernel. The first app sends a user defined
size of data on a udp socket and the other app recvs it. The strange
thing I am seeing is that on the receive side if I comment out the
actual recvfrom and let that 1 packet sit in the recv-q buffer the
netstat screen shows a total of 272 bytes on the queue. When I
reenable the recvfrom and dump how much data i received from the call
it matches what I requested to be sent. I also put up a sniffer on the
recv side and the udp packet there had just the data I sent. So where
is this extra data coming from? Has anyone else seen anything like
this before that might have a clue for me.

thanks,

Scott

 

The extra data is the source of the payload. When you call 'recvfrom',
you get more than just the payload, you get the source IP, source
port, and so on. More than one byte of the receive buffer is needed to
contain this datagram even though it only contains one byte of data.

DS

 

I had that thought as well, but even the headers wouldn't account for
the extra data.

IP Hdr - 20 bytes
UDP Hdr - 8 bytes
payload - 1 byte

272-29 = 243 bytes remaining.

also if I up the payload to 10 bytes the amount of data on the recv
queue doubles to 544 bytes. The amount of overhead data should not
increase with a minimal amount of payload increases.

Scott

 

You would have to look at the specifics of how your particular
operating system stores datagrams internally. Many of them have a
surprisingly large amount of additional information that they store
along with the data. There is no generic way to figure out how much
input queue space a particular datagram will take.

Oddly, even for TCP data, some kernels allocate control structures and
count them against the receive buffer. The receive buffer is measured
in bytes, but what counts as a byte is far from clear.

DS