Karol Skocik <Karol.Skocik@gmail.com> wrote:
+---------------
| It closes the descriptor, so it's not a problem. I have reread what
| exactly shutdown does - it shutdowns in, out or both directions which
| the data moves, so it is generally usefull when the communication is
| going to end. So, things can be done without it of course, it is just
| not that straightforward. Seems like no resouces leak to me...
+---------------

NOTA BENE: Using a uni-directional "shutdown" instead of [or rather,
at some point *before*] a normal CLOSE is sometimes critical to
certain client/server applications, since the server may try to read
the socket until EOF before sending any response. I had this problem
once when writing a CGI script that needed to connect to another
server to forward certain POST transactions. I found that I had to
do a "shutdown(sock, SHUT_WR)" [in C] on the client side before the
server would reliably see an input EOF. One might *expect* that
the "Content-Length" in the request header would have been adequate,
but it wasn't. (*sigh*)

You have to use a "shutdown" rather than a "close" in this case,
since a "close" automatically shuts down *both* directions of the
TCP socket, but if you did that you wouldn't be able to read the
server's response. Hence the need for a uni-directional "shutdown"
in some cases.

AFAICT, CMUCL [and possibly SBCL, but I don't have one to check
that with] does not provide a built-in uni-directional "shutdown"
option on its networking streams [which are LISP::FD-STREAMs].
ISTR having to cons one up manually once using the UNIX::INT-SYSCALL
macro...


-Rob

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607