Summary: Closing a Socket

From: Pete Hogan (
Date: Thu Aug 03 2000 - 09:28:33 CDT

Thanks to all those who responded, but it looks like
you can't close a socket. My problem turned out to be
that there is a wait time imposed on sockets to stay
active even after the process is closed. However, some
useful items were also mentioned such as:

>From Bruce F. Wilkins:

If the program runs within inetd, try removing the pgm
and the port
number form /etc/services and try doing a pkill -HUP

>From Giri Sekar:

Use lsof. It is freely available and gives you all
opens and the format
can be given as an input to awk or other powerful

(I checked on this and it would work great if you had
a zombie process keeping the port and didn't know what
process was holding the port).

>From Stout Logan:

How long after the program ends is the socket empty? I
ask because in
unix socket faq
( ,, it states:


2.5 How do I properly close a socket?

This question is usually asked by people who try
close(), because they
seen that that is what they are supposed to do, and
then run netstat
and see
that their socket is still active.
Yes, close() is the correct method. To read about the
TIME_WAIT state,
why it is important, refer to 2.7 Please explain the
TIME_WAIT state..


2.7. Please explain the TIME_WAIT state.

  Remember that TCP guarantees all data transmitted
will be delivered,
  if at all possible. When you close a socket, the
server goes into a
  TIME_WAIT state, just to be really really sure that
all the data has
  gone through. When a socket is closed, both sides
agree by sending
  messages to each other that they will send no more
data. This, it
  seemed to me was good enough, and after the
handshaking is done, the
  socket should be closed. The problem is two-fold.
First, there is
  way to be sure that the last ack was communicated
  Second, there may be "wandering duplicates" left on
the net that must
  be dealt with if they are delivered.

 Assume that a connection is in ESTABLISHED state, and
the client is
  about to do an orderly release. The client's
sequence no. is Sc, and
  the server's is Ss. The pipe is empty in both

          (client closes)
          (2*msl elapses...)

  Note: the +1 on the sequence numbers is because the
FIN counts as one
  byte of data. (The above diagram is equivalent to
fig. 13 from RFC

  Now consider what happens if the last of those
packets is dropped in
  the network. The client has done with the
connection; it has no more
  data or control info to send, and never will have.
But the server
  not know whether the client received all the data
correctly; that's
  what the last ACK segment is for. Now the server may
or may not care
  whether the client got the data, but that is not an
issue for TCP;
  is a reliable rotocol, and must distinguish between
an orderly
  connection close where all data is transferred, and
a connection
  where data may or may not have been lost.

  So, if that last packet is dropped, the server will
retransmit it (it
  is, after all, an unacknowledged segment) and will
expect to see a
  suitable ACK segment in reply. If the client went
straight to
  the only possible response to that retransmit would
be a RST, which
  would indicate to the server that data had been
lost, when in fact it
  had not been.

Hope this helps others,

Pete Hogan
Manager of Information Systems
MetaMatrix Inc,

Do You Yahoo!?
Kick off your party with Yahoo! Invites.

U BEFORE POSTING please READ the FAQ located at
. and the list POLICY statement located at
A To submit questions/summaries to this list send your email message to:
A To unsubscribe from this list please send an email message to:
E and in the BODY type:
R unsubscribe sun-managers
S Or
. unsubscribe sun-managers original@subscription.address
L To view an archive of this list please visit:

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:14:13 CDT