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
form
/etc/inetd.conf,
and the port
number form /etc/services and try doing a pkill -HUP
inetd
>From Giri Sekar:
Use lsof. It is freely available and gives you all
opens and the format
also
can be given as an input to awk or other powerful
programs.
(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
the
unix socket faq
(http://www.landfield.com/faqs/unix-faq/socket/ ,
http://www.ntua.gr/sock-faq/sfaq.html), it states:
**************************************************************************
2.5 How do I properly close a socket?
This question is usually asked by people who try
close(), because they
have
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,
and
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
no
way to be sure that the last ack was communicated
successfully.
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
directions.
Client
Server
======
======
ESTABLISHED
ESTABLISHED
(client closes)
ESTABLISHED
ESTABLISHED
<CTL=FIN+ACK><SEQ=Sc><ACK=Ss>
------->>
FIN_WAIT_1
<<--------
<CTL=ACK><SEQ=Ss><ACK=Sc+1>
FIN_WAIT_2
CLOSE_WAIT
<<--------
<CTL=FIN+ACK><SEQ=Ss><ACK=Sc+1>
(server
closes)
LAST_ACK
<CTL=ACK>,<SEQ=Sc+1><ACK=Ss+1>
------->>
TIME_WAIT
CLOSED
(2*msl elapses...)
CLOSED
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
793).
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
does
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;
TCP
is a reliable rotocol, and must distinguish between
an orderly
connection close where all data is transferred, and
a connection
abort
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
CLOSED,
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,
MCSE, CSA, CCNA
__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/
S
U BEFORE POSTING please READ the FAQ located at
N ftp://ftp.cs.toronto.edu/pub/jdd/sun-managers/faq
. and the list POLICY statement located at
M ftp://ftp.cs.toronto.edu/pub/jdd/sun-managers/policy
A To submit questions/summaries to this list send your email message to:
N sun-managers@ececs.uc.edu
A To unsubscribe from this list please send an email message to:
G majordomo@sunmanagers.ececs.uc.edu
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:
I http://www.latech.edu/sunman.html
S
T
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:14:13 CDT