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

On May 24, 1:38 pm, "ssuss...@starentnetworks.com" <s...@sussman.net>
wrote:
> 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.

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

On May 25, 12:26 am, David Schwartz <dav...@webmaster.com> wrote:
> On May 24, 1:38 pm, "ssuss...@starentnetworks.com" <s...@sussman.net>
> wrote:
>
> > 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.
>
> 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

On May 25, 4:36 am, "ssuss...@starentnetworks.com" <s...@sussman.net>
wrote:

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

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