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).

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).

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