* Re: man sendto ENOBUFS desc. wrong
2005-07-05 17:16 man sendto ENOBUFS desc. wrong Karel Kulhavy
@ 2005-07-05 18:08 ` Richard B. Johnson
0 siblings, 0 replies; 2+ messages in thread
From: Richard B. Johnson @ 2005-07-05 18:08 UTC (permalink / raw)
To: Karel Kulhavy; +Cc: linux-kernel
On Tue, 5 Jul 2005, Karel Kulhavy wrote:
> man send(2):
>
> " ENOBUFS
> The output queue for a network interface was full. This
> gener- ally 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.)"
> ^^^^^^^^^^
>
> Which is not true, because just happened to me with kernel Linux version
> 2.6.11-gentoo-r9.
>
> Where should I report?
>
> CL<
The `man` pages concatenate send() sendmsg() sendto(), etc. So, what
are you trying to do? If you are using a CONNECTED STREAM socket,
the end-points get perfect data-buffers with nothing dropped, even
if you disconnect the physical wire for quite some time (hours).
In that case, the errors returned are EAGAIN, EBADF, ECONNRESET,
EFAULT, EINTR, EINVAL, ENOTCON, etc. No errors about the interface
are returned because the kernel transparently retries those errors.
Data-grams can be dropped on the floor for any number of reasons
including the phase of the moon. If you are not prepared to handle
this, you must use a CONNECTED STREAM socket. You can't have it
both ways. You either have a perfect data-transmission path with
its associated overhead, or you get a faster transmission but
are not guaranteed anything, including the even one packet gets
to the end-point.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
^ permalink raw reply [flat|nested] 2+ messages in thread