[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: socket(7) and section 2
In article <20090315185649.4a012a39.jklowden%schemamania.org@localhost>,
James K. Lowden <netbsd-docs%netbsd.org@localhost> wrote:
>It's impossible to program sockets correctly based on the manual. Believe
>me; I tried. Among other things, read(2) doesn't mention that it returns
>zero to indicate the peer has closed the connection.
>Throughout the socket documentation, ERRORS is not exhaustive. write(2)
>for instance doesn't mention that EPIPE is set (or at least *should* be,
>after SIGPIPE) after writing to a closed connection. Nor is ENETDOWN
>mentioned. I could go on.
>The thing is, I have a hard time believing this is an oversight, because
>NetBSD's ancestors practically invented tcp/ip. Am I missing something,
>or does it fall to a nonexpert like me to take at least a swag at getting
>In a similar vein, I'm not aware of anything that serves as a Guide to
>Sockets. I don't mean Sockets for Novices; I mean something that relates
>the API to the TCP/IP protocol. What packets does
>connect/bind/listen/accept/close cause to be sent? What does select(2)
>mean by a "ready" descriptor? (Hint: available data or free buffers is
>only one of four cases.) How will i/o functions behave when the network
>can't transmit data, when the peer crashes, when the peer's host crashes,
>if I down the interface? I propose sockets(7) for the purpose.
>Perhaps some of the ambiguity and vagueness stems from uncertainty in
>flintlock times of what socket domain would be used. All well and good,
>but surely we agree that TCP/IPv4 is commonly enough used nowadays that it
>deserves careful, detailed explication? ;-)
You can start with the opengroup case, but they don't mention the network
related errors either. Perhaps mention that if the file descriptor refers
to a socket, then all the errors from send can be returned.
Main Index |
Thread Index |