Date: Thu, 15 Sep 2005 14:37:04 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Maxim Konovalov <maxim@macomnet.ru> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern uipc_socket.c Message-ID: <20050915143344.P75005@fledge.watson.org> In-Reply-To: <20050915165142.F20393@mp2.macomnet.net> References: <200509151145.j8FBjbAU070614@repoman.freebsd.org> <20050915130901.R75005@fledge.watson.org> <20050915165142.F20393@mp2.macomnet.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 15 Sep 2005, Maxim Konovalov wrote: >> Are you sure this is the right thing to do? I've seen shutdown used in >> several applications on non-connection-oriented sockets in order to >> indicate no messages will be received, so not to allow received packets >> to consume space. Typical use is in the context of a raw IP or IPv6 >> socket, where raw packets will be sent but never received, and the >> socket will otherwise collect the normal random network detrious. >> >> For example, rtsold(8) uses shutdown(2) on its IPv6 raw socket to >> indicate it is send-only, so received packets should not be stored in >> the socket buffer since they will never be read. It does, however, >> contain the not unusual bug that it is called with an argument of 0, >> assuming that that will be the value SHUT_RD. I'm fairly sure we used >> to have other examples of shutdown(2) being used in this way in the >> tree but don't see any others in a casual glance. >> >> While POSIX mentions behavior for full-duplex connections, it does not >> specify for sockets that are not connection-oriented, so as I read it, >> the behavior we provide is permitted. > > Linux 2.4.21 return ENOTSUP for SOCK_RAW and ENOTCONN for non-connected > SOCK_DGRAM. Solaris 9 returns ENOTCONN for non-connected SOCK_RAW and > they don't allow shutdown(2) on non-connected sockets. Anyhow, I'll > backout this code. I suspect that where we sit today is that the specification is based on the least common denominator of the API's derived from the Berkeley sockets implementation. The good news is that POSIX doesn't appear to prohibit our useful behavior... The trick is going to be for us to define the behavior we guarantee vs. the behavior that is an accident of our implementation. For example, in the case of the fifo code, we permitted a broad range of socket and network stack ioctls on fifos, even though the fifo API specification is really derived from the behavior of pipes.. :-) Robert N M Watson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050915143344.P75005>