CLOSE_WAIT vs. EOF

Hi all,

I have a program - in java but I want to focus on just tcp/linux - that
makes a socket connection to a smtp server (postfix) on localhost. I've
been using netstat -a to observe. I believe I have the following
sequence:

1) Opening a tcp connection puts the connection into state ESTABLISHED
..
2) Sending "QUIT\r\n" puts the connection state into CLOSE_WAIT .
3) The client now needs to send a command to the smtp server, to
completely terminate the connection.

I'm having a problem with step 3. There are bug reports on this in my
API. I keep on opening file descriptors - which is what I believe
CLOSE_WAIT is, until I run out as I am not closing them.

My API allows another command - shutdownOutput() which may have an
equivalent in C and other languages - that sends an EOF as I believe
-1. netstat -a seems to then not show CLOSE_WAIT. Another collegue does
not believe that a client sending EOF terminates a connection in
CLOSE_WAIT.

My question is, can a client send EOF and completely terminate a socket
connection that is in CLOSE_WAIT, and remove all file descriptors
related to the socket connection? Is 'netstat -a' a good way to
determine this?

Another question: What happens when a connection is in STATE
established and the client sends EOF?

iksrazal

(E-Mail Removed) writes:

>I have a program - in java but I want to focus on just tcp/linux - that
>makes a socket connection to a smtp server (postfix) on localhost. I've
>been using netstat -a to observe. I believe I have the following
>sequence:

>1) Opening a tcp connection puts the connection into state ESTABLISHED
>.
>2) Sending "QUIT\r\n" puts the connection state into CLOSE_WAIT .
>3) The client now needs to send a command to the smtp server, to
>completely terminate the connection.

The client cannot send a command at this point, since the session
is closed.

What you need is to close() the socket.

>I'm having a problem with step 3. There are bug reports on this in my
>API. I keep on opening file descriptors - which is what I believe
>CLOSE_WAIT is, until I run out as I am not closing them.

Normall CLOSE_WAIT indicates that the remote side has closed the
connection, but the local socket is still open. There may be a
few other circumstance, but that's the main one.

You send "QUIT" to postfix. It says "goodbye" (or similar), then
closes its socket. Thus the remote side of the connection is
closed. That's why it is in a CLOSE_WAIT state.

The proper thing to do is to read any input until EOF, then close
the socket.

>My API allows another command - shutdownOutput() which may have an
>equivalent in C and other languages - that sends an EOF as I believe
>-1. netstat -a seems to then not show CLOSE_WAIT. Another collegue does
>not believe that a client sending EOF terminates a connection in
>CLOSE_WAIT.

There really is no such thing as sending an EOF over a network
connection. You just close the connection. The other side of the
connection will treat the closed connection as if an EOF.

>My question is, can a client send EOF and completely terminate a socket
>connection that is in CLOSE_WAIT, and remove all file descriptors
>related to the socket connection? Is 'netstat -a' a good way to
>determine this?

Just close the socket.

>Another question: What happens when a connection is in STATE
>established and the client sends EOF?

Presumably what you are calling "client sends EOF" is really just
closing the socket. That has the effect of closing the socket. If
the other side attempts to read, it will either see an EOF or an I/O
error, depending on how it is coded. If the other side attempts to
write to the connection, it will either see an I/O error, or receive
a SIGPIPE, depending on how it is coded.

>iksrazal

Neil W Rickert <rickert+(E-Mail Removed)> wrote:

> Normall CLOSE_WAIT indicates that the remote side has closed the
> connection, but the local socket is still open. There may be a
> few other circumstance, but that's the main one.

The other circumstance would be that instead of calling close(), the
remote side has called shutdown(SHUT_WR). This would make the TCP
connection unidirectional, from the local to the remote side.

rick jones
--
portable adj, code that compiles under more than one compiler
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

Thanks for the reply - I appreciate the patience with my terminology.
You helped a lot by saying the server side is closed when the client
side socket is in CLOSE_WAIT.

I think I have learned that the EOF I talk about needs to be sent to
the _client_ application on the local machine by the API of the running
application. If I understand correctly, after CLOSE_WAIT there could be
data still in the buffer on the client side, but in this case I have
read all data after the QUIT I send to the server.

Unfortunately I cannot just close the connection via the java
SocketChannel.close() command as that is not enough on linux and other
platforms such as Sun. See this bug report if interested (I didn't file
it).

http://bugs.sun.com/bugdatabase/view...bug_id=6215050

Some purists say that by calling close(), and not closing the Socket,
it is not a bug, but anyways...

>From a tcp/linux perspective, my questions are:

1) What is the state - on the client side - after CLOSE_WAIT ? Can
reading and discarding any buffered data on the client side and sending
EOF to the client application change the state from CLOSE_WAIT to
something else? Is the socket closed when I no longer see CLOSE_WAIT?

2) If I understand correctly, the are 5 tcp states: SYN, ACK, data,
FIN, and RST . Which of those can I think of when netstat shows
CLOSE_WAIT, and which of those follows the CLOSE_WAIT to the next
state?

iksrazal

(E-Mail Removed) wrote:
>>From a tcp/linux perspective, my questions are:

> 1) What is the state - on the client side - after CLOSE_WAIT ? Can
> reading and discarding any buffered data on the client side and sending
> EOF to the client application change the state from CLOSE_WAIT to
> something else? Is the socket closed when I no longer see CLOSE_WAIT?

When an application calls close() against a connection in CLOSE_WAIT I
believe it then transitions to LAST_ACK as it is now awaiting an
ACKnowledgement of the FINished segment. Sone of the late W. Richard
Stevens' books would undoubtedly have the TCP state transition
diagram, as would RFC 793 (assuming I've remembered my RFC numbers
correctly)

> 2) If I understand correctly, the are 5 tcp states: SYN, ACK, data,
> FIN, and RST . Which of those can I think of when netstat shows
> CLOSE_WAIT, and which of those follows the CLOSE_WAIT to the next
> state?

SYNchnronize, ACKnowledge, data, FINished and ReSeT are not TCP
states. They are types of TCP segments. When you see CLOSE_WAIT it
means the local TCP has received a FINished segment, and the local TCP
is waiting for the local application to call close() against the
socket/connection.

rick jones
--
Wisdom Teeth are impacted, people are affected by the effects of events.
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

<(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ups.com...

> 1) What is the state - on the client side - after CLOSE_WAIT ? Can
> reading and discarding any buffered data on the client side and sending
> EOF to the client application change the state from CLOSE_WAIT to
> something else? Is the socket closed when I no longer see CLOSE_WAIT?

When you see CLOSE_WAIT, the network connection is totally gone. The
socket refers to the totally dead connection and all that's left is to close
the socket handle.

> 2) If I understand correctly, the are 5 tcp states: SYN, ACK, data,
> FIN, and RST . Which of those can I think of when netstat shows
> CLOSE_WAIT, and which of those follows the CLOSE_WAIT to the next
> state?

CLOSE_WAIT is not a TCP state. The TCP connection is totally gone at
this point. If you allocate a socket, make a connection, shut it down on
both ends, and then still don't close the socket, the socket will be in
CLOSE_WAIT state -- this means the socket doesn't refer to a TCP connection
at all. All that's left, and the only thing you can do, is close the socket.
Closing the socket will have no effect on the other end, since there is no
connection left at this point.

DS

On Tue, 21 Jun 2005 18:09:02 -0700, "David Schwartz"
<(E-Mail Removed)> wrote:

> CLOSE_WAIT is not a TCP state. The TCP connection is totally gone at
>this point.

Not really true, CLOSE_WAIT definately is a TCP state. And as the
name implies, the connection is not gone, but is waiting to close.

The specification for TCP can be found in RFC 793. If you look on
page 23, you'll find a good summary of the various TCP states and what
actions trigger a transition from one state to another.

The RFCs can be found at www.ietf.org

Dan

"Dan" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...

> On Tue, 21 Jun 2005 18:09:02 -0700, "David Schwartz"
> <(E-Mail Removed)> wrote:

>> CLOSE_WAIT is not a TCP state. The TCP connection is totally gone at
>>this point.
>
> Not really true, CLOSE_WAIT definately is a TCP state. And as the
> name implies, the connection is not gone, but is waiting to close.

You are correct. If you have sockets stuck in CLOSE_WAIT state, they are
waiting for you to close them.

DS

On 21 Jun 2005 15:36:45 -0700, (E-Mail Removed) wrote:



>Unfortunately I cannot just close the connection via the java
>SocketChannel.close() command as that is not enough on linux and other
>platforms such as Sun. See this bug report if interested (I didn't file
>it).

That seems like a major bug. Is there a newer software revision or
bugfix?

Dan