3 ms·

I just don't see the problem that djb is highlighting. To me the crucial mistake comes in this sentance; "When the generate-data program finishes, the same fd i

I just don't see the problem that djb is highlighting. To me the crucial mistake comes in this sentance; "When the generate-data program finishes, the same fd is still open in the consume-data program, so the kernel has no idea that it should send a FIN." generate-data and consume-data should NEVER share a fd; the two pipes in the "same machine model" are two seperate sets to fds (the pipe() returns both ends of the fd in one call). Likewise the TCP model should use two separate (sets of)sockets. shutdown()'s real use is for poorly implemented protocols where the server has no real time way of initiating a control message to the client apart from "abort"ing the connection; some protocols only allow the client to initiate sending a message. Also note that one end of the connection sending a FIN doesn't preclude the other end from sending more data.

drudru11 13y ago
I'm going to take a stab at interpreting what this article is about. First, the missing background: djb likes unix. the unix philosophy is to compose small programs together to solve problems. djb's own programs illustrate this really well. They are all small, focused tools. This allows each program to focus on their particular task or domain. The primary method of composition in unix is the pipe in a shell. Each pipe has two descriptors. One for read and one for write. It is very easy to create a pipe and handle pipe IO. The article: At some point, djb wanted to have some programs live on the network. This expands the composition beyond a single machine. If you just try to treat a socket as a standard pipe, you encounter the problem he describes. Any program utilizing a pipe requires two file descriptors. If someone built a trivial 'netpipe', they could just 'dup' or 'dup2' the socket file descriptor to make it look like a normal pipe. The problem with that is now the socket won't close until both fds are closed. This means the remote end won't detect EOF. This means the 'netpipe' program has to be very clever in order to detect EOF and do a proper close on both so the remote can see the last bytes and then EOF.

drudru11 13y ago

I'm going to take a stab at interpreting what this article is about. First, the missing background: djb likes unix. the unix philosophy is to compose small programs together to solve problems. djb's own programs illustrate this really well. They are all small, focused tools. This allows each program to focus on their particular task or domain. The primary method of composition in unix is the pipe in a shell. Each pipe has two descriptors. One for read and one for write. It is very easy to create a pipe and handle pipe IO. The article: At some point, djb wanted to have some programs live on the network. This expands the composition beyond a single machine. If you just try to treat a socket as a standard pipe, you encounter the problem he describes. Any program utilizing a pipe requires two file descriptors. If someone built a trivial 'netpipe', they could just 'dup' or 'dup2' the socket file descriptor to make it look like a normal pipe. The problem with that is now the socket won't close until both fds are closed. This means the remote end won't detect EOF. This means the 'netpipe' program has to be very clever in order to detect EOF and do a proper close on both so the remote can see the last bytes and then EOF.