Loosing UDP packets...

Hi all,



My C program needs to send UDP packets in burst. I have the following code:



send_data()

{



err = sendto(sock, &msg1, len1, &add, lenadd);

err = sendto(sock, &msg2, len2, &add, lenadd);

err = sendto(sock, &msg3, len3, &add, lenadd);

err = sendto(sock, &msg4, len4, &add, lenadd);

err = sendto(sock, &msg5, len5, &add, lenadd);

}



I do not get any error

When I look on the network with a sniffer, sometimes, I look packets. but
the missing packets are never put on the network.



How can I loose packets if I have a private network with only to nodes?



I used the

setsockopt(sock,SOL_SOCKET, SO_SNDBUF, &maxsize, sizeof(int));

function to be sure I have enough buffer memory, but that not seams to help.



I have the same result with Windows or Linux.



Does someone have an idea?



Thanks



Maxime

Maxime Barbeau wrote:

> Hi all,
>
> My C program needs to send UDP packets in burst. I have the following code:
>
<snip>
> I do not get any error
>
> When I look on the network with a sniffer, sometimes, I look packets. but
> the missing packets are never put on the network.
>
> How can I loose packets if I have a private network with only to nodes?

Repeat after me: UDP is not reliable. UDP is not reliable......

REALLY! The TCP/IP stack can drop UDP datagrams at ANY time, even if there is
buffer space, even on a loopback address! The sooner you understand and
acknowledge this the less frustration you will experience.

--
Phil Frisbie, Jr.
Hawk Software
http://www.hawksoft.com

Maxime Barbeau wrote:
> Hi all,
>
>
>
> My C program needs to send UDP packets in burst. I have the following code:
>
>
>
> send_data()
>
> {
>
>
>
> err = sendto(sock, &msg1, len1, &add, lenadd);
>
> err = sendto(sock, &msg2, len2, &add, lenadd);
>
> err = sendto(sock, &msg3, len3, &add, lenadd);
>
> err = sendto(sock, &msg4, len4, &add, lenadd);
>
> err = sendto(sock, &msg5, len5, &add, lenadd);
>
> }
>
>
>
> I do not get any error

How do you know if you don't check the value of err?

Robert

> [snip]
>
> Maxime
>
>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Harris wrote:
> Maxime Barbeau wrote:
>> Hi all,
>>
>>
>>
>> My C program needs to send UDP packets in burst. I have the following
>> code:
>>
>>
>>
>> send_data()
>>
>> {
>>
>>
>>
>> err = sendto(sock, &msg1, len1, &add, lenadd);
>>
>> err = sendto(sock, &msg2, len2, &add, lenadd);
>>
>> err = sendto(sock, &msg3, len3, &add, lenadd);
>>
>> err = sendto(sock, &msg4, len4, &add, lenadd);
>>
>> err = sendto(sock, &msg5, len5, &add, lenadd);
>>
>> }
>>
>>
>>
>> I do not get any error
>
> How do you know if you don't check the value of err?

In any case, when the return value from sendto() indicates an error, it
is an error between the user process and the tcp/ip layer, not between
the tcp/ip layer and the transmission medium. So, if the packet gets
dropped after it has been handed to tcp/ip, sendto() won't know and
won't report an error. sendto() will only report if it can't hand off
the packet to tcp/ip.

Additionally, according to the sendto(2) documentation, Linux silently
drops packets if the tcp/ip outgoing buffer is full. It doesn't report
the ENOBUFS that other sockets implementations might.





- --

Lew Pitcher, IT Specialist, Corporate Technology Solutions,
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed here are my own, not my employer's)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEGFH4agVFX4UWr64RAhcHAJ9aXUMBMWY8iV/FbLrVaql7qKgWugCguHky
76i/YAJ+V7ogE/hWYdjDXb4=
=ULHj
-----END PGP SIGNATURE-----

Maxime Barbeau <(E-Mail Removed)> wrote:
> My C program needs to send UDP packets in burst. I have the following code:

> send_data()
> {
> err = sendto(sock, &msg1, len1, &add, lenadd);
> err = sendto(sock, &msg2, len2, &add, lenadd);
> err = sendto(sock, &msg3, len3, &add, lenadd);
> err = sendto(sock, &msg4, len4, &add, lenadd);
> err = sendto(sock, &msg5, len5, &add, lenadd);
> }

> I do not get any error

> When I look on the network with a sniffer, sometimes, I look
> packets. but the missing packets are never put on the network.

> How can I loose packets if I have a private network with only to
> nodes?

Perhaps by overflowing the driver's transmit queue. Just how large
are these UDP datagrams you are sending?

> I used the
> setsockopt(sock,SOL_SOCKET, SO_SNDBUF, &maxsize, sizeof(int));
> function to be sure I have enough buffer memory, but that not seams
> to help.

It wouldn't if the packets were being dropped by the driver. And
depending on how your Linux stack is "tuned" (sysctl -a) the SO_SNDBUF
setting may have been silently capped. You should always to a
getsockopt() after a setsockopt() to see what size you actually got.

> I have the same result with Windows or Linux.

> Does someone have an idea?

Yeah, don't send such large bursts of packets Flow control is one
of the responsibilities you take-on when you use UDP rather than TCP.

rick jones
--
firebug n, the idiot who tosses a lit cigarette out his car window
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

Lew Pitcher <(E-Mail Removed)> wrote:
> Additionally, according to the sendto(2) documentation, Linux
> silently drops packets if the tcp/ip outgoing buffer is full. It
> doesn't report the ENOBUFS that other sockets implementations might.

Is this the text you were talking about?

ENOBUFS The output queue for a network interface was full. This
generally indicates that the interface has stopped sending,
but may be caused by transient congestion. (Normally, this
does not occur in Linux. Packets are just silently dropped
when a device queue overflows.)

If so, I believe there is a difference between the device queue and
the socket buffer. FWIW, HP-UX 11 and later also will not report
ENOBUFS when the device queue overflows. I suspect the same is true
for Solaris.

I believe though that under Linux, if the UDP socket is "connected"
(and so one is calling send()) that the device queue filling may
trigger intra-stack flow-control. Of course, to rely on that would be
highly unportable...

In the end, as already pointed-out, applications using UDP just have
to "deal" with the very real possibility that their datagrams will
simply vanish into thin ether

rick jones
--
No need to believe in either side, or any side. There is no cause.
There's only yourself. The belief is in your own precision. - Jobert
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

Phil Frisbie, Jr. wrote:
> Repeat after me: UDP is not reliable. UDP is not reliable......
>
> REALLY! The TCP/IP stack can drop UDP datagrams at ANY time, even if there is
> buffer space, even on a loopback address! The sooner you understand and
> acknowledge this the less frustration you will experience.

This is true but a UDP implemntation that decides to drop all packets
without attempting to send is not a UDP implementation ....


--
Paul

Paul Black wrote:
> Phil Frisbie, Jr. wrote:
> > Repeat after me: UDP is not reliable. UDP is not reliable......
> >
> > REALLY! The TCP/IP stack can drop UDP datagrams at ANY time, even if there is
> > buffer space, even on a loopback address! The sooner you understand and
> > acknowledge this the less frustration you will experience.
>
> This is true but a UDP implemntation that decides to drop all packets
> without attempting to send is not a UDP implementation ....

Pardon my ressurection of a week-old thread...

Paul makes a critical point. I have had endless frustration with linux
accepting packets from an application, but never getting (some of) them
to the wire.

Linux has two nasty features here:

1) EWOULDBLOCK never comes up true. The stack is always willing to
take your UDP data, regardless of ability to get datagrams down to the
wire.

2) silent overflows of the txqueue buffer. You can lose data here, and
there's nothing you can do about it, nor can you see it happening.

Solaris has neither of these problems. If the stack accepts your
datagram, it will make it to the wire.

I suspect the OP will have a better result if he cranks up the
txqueuelen metric. Highest I've set it is 4000.

man ifconfig

/chris

Maxime Barbeau wrote:

>
> Does someone have an idea?

Maybe a loose nut behind the keyboard.

I love these people who post for answers then don't come back and
respond to questions. I send tons of UDP packets multicast and unicast
across all kinds of networks and lose very few. If you are just
sending a few and losing them all them you've screwed up elsewhere.

(E-Mail Removed) wrote:
> 1) EWOULDBLOCK never comes up true. The stack is always willing to
> take your UDP data, regardless of ability to get datagrams down to the
> wire.

My netperf-based experience is that for a _blocking_ socket,
intra-stack flow-control gets excerted. I "never" see UDP_STREAM rates
greater than link-rate under Linux.

> 2) silent overflows of the txqueue buffer. You can lose data here,
> and there's nothing you can do about it, nor can you see it
> happening.

Perhaps that is only for a non-blocking socket - per my stuff above?

> Solaris has neither of these problems. If the stack accepts your
> datagram, it will make it to the wire.

Is it _really_ that absolute? I can think of some possible holes:

1) Your send is the first to a given IP and that IP has no ARP entry
and ARP resolution fails

2) There is a transmission error

Is there a check that there is a route to the destination before the
sendto() call completes?

How about if the datagram has to be fragmented - does the Solaris
stack "guarantee" that all fragments of the datagram will be
transmitted?

rick jones
--
oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...