On Wed, Nov 07, 2007 at 10:25:37AM -0800, Jeff Haran wrote:
...
> Some other potential differences that come to mind. Don't quote me on
> this, just going from memory.
>
> The flags parameter to send() in linux has some bits that might not be
> there in BSD (e.g. EPIPE).
man 2 send
The EPIPE is possible error value, there is another bit for flags
parameter.
> On linux, the completion of connect()s on non-blocking sockets is
> determined via the write_fds passed to select(). On some Unixi (can't
> remember if it was BSD or System V), that was done via the read_fds.
man 2 connect
Linux:
EINPROGRESS
The socket is non-blocking and the connection cannot be
completed immediately. It is possible to select(2) or
poll(2) for completion by selecting the socket for writing.
After select(2) indicates writability, use getsockopt(2)
to read the SO_ERROR option at level SOL_SOCKET to determine
whether connect() completed successfully (SO_ERROR is
zero) or unsuccessfully (SO_ERROR is one of the usual error
codes listed here, explaining the reason for the failure).
Solaris 10:
EINPROGRESS The socket is non-blocking, and the
connection cannot be completed
immediately. You can use
select(3C) to complete the connec-
tion by selecting the socket for
writing.
OpenBSD:
[EINPROGRESS]
The socket is non-blocking and the connection cannot be
completed immediately. It is possible to select(2) or
poll(2) for completion by selecting the socket for
writing, and also use getsockopt(2) with SO_ERROR to
check for error conditions.
At least that detail works the same way...
> The meaning of the SO_SNDBUF option seems to be different on linux than
> it is on other sockets implementation. On linux, it seems to be the size
> of the internal buffer used by the kernel to manage the send side of the
> connection and includes both user data and internal kernel data used to
> manage it whereas on other sockets its the amount of actual user data
> that is buffered for transmission in the kernel. I posted a question
> about this a couple of weeks ago to this list and never got a response.
Maybe because it really is a FAQ ?
man 2 setsockopt
man 7 tcp
man 7 socket
There are some Linux-specific socket-options, and one divergence from
BSD behaviour:
The maximum sizes for socket buffers declared via the SO_SNDBUF and
SO_RCVBUF mechanisms are limited by the global net.core.rmem_max and
net.core.wmem_max sysctls. Note that TCP actually allocates twice the
size of the buffer requested in the setsockopt(2) call, and so a suc-
ceeding getsockopt(2) call will not return the same size of buffer as
requested in the setsockopt(2) call. TCP uses the extra space for
administrative purposes and internal kernel structures, and the sysctl
variables reflect the larger sizes compared to the actual TCP windows.
On individual connections, the socket buffer size must be set prior to
the listen() or connect() calls in order to have it take effect. See
socket(7) for more information.
> Jeff Haran
> Brocade
/Matti Aarnio
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
