shutdown vs. close on INET sockets

[gomez18]

I ran into an interesting problem a few days ago and thought I'd come to the monks for guidance.

I was opening sockets with IO::Socket::INET and using them throughout the course of a script. From time to time, these sockets had to be closed and possibly reopened at a later time. I had been closing them with 'shutdown(SOCK, 2)' since shutdown is described as a 'more insistent form of close' in the camel book.

The sockets appeared to be closing as the list of open connections on a 'netstat' didn't climb steadily as I would expect if they were staying open. However, if I did an 'fstat -u userid' I found well over 1000 open files for my script. These files seemed to be open network connections. Changing the script to use close rather than shutdown solved the problem right away.

My question, then, is why did shutdown work this way? Is my understanding of the camel book flawed somehow. Am I using shutdown in an odd way it was not intended? Thanks for any guidance you may have to offer.

An 8 bit man in a 32 bit world.

[ozone]

Well, unfortunately, the IO::Socket hides all the details of what I'm about to say, but you can take a look at the low level socket stuff in the Camel book or the perlfunc man page.

What's happening is that when you establish a connection with IO::Socket, the first thing it does is make a call to 'socket', which opens a socket and attaches it to a filehandle. This is equivalent to a 'open' call on a standard file. It then calls 'connect', which establishes a TCP connection with the remote host.

Now, when you're finished with the socket and you need to close it down, you should call shutdown, as this informs the TCP stack that you'd like to terminate the session nicely. Unfortunately, this only deals with TCP - you still need to break the relationship between the socket and the file handle, which is done with 'close', as it is with any file handle...

If you're looking for more details on how the underlying calls work, the best book I've ever seen is Unix Network Programming, by W. Richard Stevens. It's all related to C programming, but maps quite nicely onto low-level Perl calls (although you should be using IO::Socket).

[tye]

shutdown on a socket is similar to close on a pipe in what information it gives to the program on the other side. But it does not close the file handle.

shutdown(0) is like close on a pipe that you are reading from -- it tells the other side that you will no longer be reading (which will change how select behaves, for example). shutdown(1) is like close on a pipe that you are writing to -- it sends an end-of-file to the reader on the other side. shutdown(2) says both of these things, but doesn't close the handle.

The reason for shutdown(0) and shutdown(1) is easy to see because a socket is two-way and you couldn't use close to send an end-of-file but still continue to read from the socket.

"perldoc -f shutdown" says that shutdown is "a more insistent form of close because it also disables the file descriptor in any forked copies in other processes". It is saying that just closeing the socket doesn't prevent any forked processes that also have the same socket open from deciding to read or write data. But it doesn't free any file handles or file descriptors, in any process, including the current one.

So the basic answer is to close after you shutdown.

I had always assumed that the last close on a socket also did a shutdown(2). However, it now appears that some TCP/IP stacks don't do this (I consider this a bug and I'm rather surprised by it, but it is the simplest explanation I've found for the very high number of incoming web connections that we see that must time out because they never appear to close). So, a good network citizen will shutdown(2) before they close (if the close is meant to end communication rather than just turn communication responsibilities over the some other process).

        - tye (but my friends call me "Tye")

[Anonymous Monk]

I have experienced the same on mainframe systems. Shutdown and close.