If shutdownOutput() doesn’t cause other end to start TCP close

[Srubys]

Hiya

I’m learning about TCP/IP and this stuff is just overwhelming


1. As far as I understand, when the passive-close end receives the
FIN, it doesn’t know whether the other end wants to stay in half-close
state ( in this case it should send data ) or to do full close( in
this case, it should send FIN )

We use shutdownOutput() to achieve half close, and close() to fully
close the connection. Now if none of the two methods force the passive-
close end to start TCP close sequence, why do we then use shutdown()
for half close connection? Why not just use close(), since it looks as
if both methods basically do the same thing ( terminating socket’s
output stream )?



2. If app does complete close, then TCP prevents infinite wait in
FIN_WAIT_2 state with setting the timer to aprox 10 minutes and if
connection is idle for that time period, TCP moves connection to
closed state.

a) But if app does half close, then this timer is not set and TCP
could be in FIN_WAIT_2 state for a very long time?




3. If linger on close is set to false, does on close() socket enter
FIN_WAIT_1 and from there to CLOSING state, or does it enter
FIN_WAIT_1 and from there to FIN_WAIT_2 state?



4. If client performs active open, but for some reason server doesn’t
receive none of client’s acknowledgements of server’s SYN, then:

a) I’m assuming that client is in established connection state, but
server is not?

b) does server go to close state and thus sends FIN or does it go to
listening state?
If the latter is true, then we have half open connection?


thank you

 

[Gordon Beaton]

I?m learning about TCP/IP and this stuff is just overwhelming

Your questions belong in e.g. comp.protocols.tcp-ip, not in
comp.lang.java.programmer.

/gordon

--

 

[EJP]

1. As far as I understand, when the passive-close end receives the
FIN, it doesn’t know whether the other end wants to stay in half-close
state ( in this case it should send data ) or to do full close( in
this case, it should send FIN )

It knows whether or not it is specified in the application protocol that
the peer will shutdown the output and continue reading.

2. If app does complete close, then TCP prevents infinite wait in
FIN_WAIT_2 state with setting the timer to aprox 10 minutes

Four minutes.

and if connection is idle for that time period, TCP moves connection to
closed state.

No. Idleness has nothing to do with it. There can be no activity on a
port in this state. At the end of the four minutes TCP will move the
*port* to state CLOSED. This is required to prevent wrong delivery of
TCP segments to a new connection using that port number.

a) But if app does half close, then this timer is not set and TCP
could be in FIN_WAIT_2 state for a very long time?

No, see above.

3. If linger on close is set to false, does on close() socket enter
FIN_WAIT_1 and from there to CLOSING state, or does it enter
FIN_WAIT_1 and from there to FIN_WAIT_2 state?

Neither. THe socket is reset instead of being closed, and goes directly
to the CLOSED state. *Do not do this*. It is *insecure*.

4. If client performs active open, but for some reason server doesn’t
receive none of client’s acknowledgements of server’s SYN, then:

a) I’m assuming that client is in established connection state, but
server is not?
Correct.

b) does server go to close state and thus sends FIN or does it go to
listening state?

The *accepted socket* never gets out of SYN_RECEIVED, unless it times
out somewhere, when it will go to closed. The original listening socket
remains in LISTEN state.

If the latter is true, then we have half open connection?

No. (a) You are confusing the accepted socket with the listening socket.
They are distinct. (b) The server application will never see a
connection in SYN_RECEIVED state. (c) Any data that arrives for that
connection from the peer will cause a connection reset (RST) to be
issued to the peer.

 

[Srubys]

hiya

Four minutes.

No. Idleness has nothing to do with it. There can be no activity
on a port in this state. At the end of the four minutes TCP will
move the *port* to state CLOSED. This is required to prevent
wrong delivery of TCP segments to a new connection using that
port number.

But Stevens writes in his book:

“ … Only when the process at the other end does this close will our
end move from FIN_WAIT_2 state to the TIME_WAIT state. This means our
end can remain in this state forever. The other end is still in
CLOSE_WAIT state and can remain there forever, until the app decides
to issue its close. Many Berkley derived implementations prevent this
infinite wait in the FIN_WAIT_2 state as follows. If the application
that does the active close does a complete close, not a half close
indicating that it expects to receive data, then a timer is set. If
the connection is idle for 10 minutes and 75 seconds, TCP moves the
connection into CLOSED state ”

No, see above.

But half close enables for one end to close its output and still
receive data. If socket ( which caused half close connection by
terminating its output ) in FIN_WAIT_2 state can’t receive any data,
then what would be the point of having half close?!

Neither. THe socket is reset instead of being closed, and goes
directly to the CLOSED state. *Do not do this*. It is
*insecure*.

But my book on Java networking claims that if linger is set to false
( which is default ):

“When the socket is closed, the closing thread is not blocked but the
socket is not destroyed immediately: it first enters a CLOSING state
while any remaining data is transmitted and the FIN-ACK close protocol
is exchanged with the other end. The socket then enters TIME-WAIT
state, which last for twice the maximum lifetime of a TCP segment”

I was confused why Stevens would argue that normally socket would go
from TIME_WAIT_1 to TIME_WAIT_2, while the other author claims
otherwise. But you are arguing that none of the two claims are true
for Java sockets?

The *accepted socket* never gets out of SYN_RECEIVED, unless it
times out somewhere, when it will go to closed. The original
listening socket remains in LISTEN state.

a) I assumed that until connection between client and server is
established, the connection is formed between the listening socket and
a client socket. Only when listening socket manages to completely
establish this connection, does it pass this connection to some Socket
object. Else, why wouldn’t ServerSocket just pass this connection
request to some Socket object and return immediately from accept()?!
Afterall, java docs say that ServerSocket only returns from accept()
when connection is made.


b) To which socket are you refering to by “accepted socket”? The
Socket object which ServerSocket creates and gives it the newly
established connection?


thank you

 

[EJP]

But my book on Java networking claims that if linger is set to false
( which is default ):

Sorry, I got that wrong. linger on false is indeed the default. What I
was referring to was linger = true, timeout = 0, which causes an RST to
be issued. Different thing. My mistake.

I was confused why Stevens would argue that normally socket would go
from TIME_WAIT_1 to TIME_WAIT_2, while the other author claims
otherwise. But you are arguing that none of the two claims are true
for Java sockets?

No, I was confused. Anything it says in Stevens is correct. If the other
book disagrees, it is wrong. If I disagree, I am wrong too.

a) I assumed that until connection between client and server is
established, the connection is formed between the listening socket and
a client socket.

Not exactly. The half-formed connection is placed in some internal form
in an internal queue in the server-side TCP stack. When and if the final
ACK is received, it is then moved to the listen backlog queue. It really
only becomes a socket, or a Socket, when returned by accept(). The
connection is between the client IPaddressort and the server
IPaddressort. The server-side socket, when created, is essentially the
local representation of that 4-tuple, but it's the 4-tuple itself that
defines the connection.

Only when listening socket manages to completely
establish this connection, does it pass this connection to some Socket
object.
Correct.

b) To which socket are you refering to by “accepted socket”?

The Socket returned by accept(). This seems perfectly clear to me.

The Socket object which ServerSocket creates and gives it the newly
established connection?

Yes.

 

[Srubys]

hiya

1.

Sorry, I got that wrong. linger on false is indeed the default.
What I was referring to was linger = true, timeout = 0, which
causes an RST to be issued. Different thing. My mistake.

So then it is true that if app does half close, then the TCP doesn’t
set the timer and thus TCP could be in FIN_WAIT_2 state for a very
long time ( and in that state it would also somehow be able to receive
data from other end )?


2.Wouldn’t it be useful if passive close end knew whether the other
end wants to stay in half-close state or do a full close? That way
passive-end would know whether to also send FIN or keep on sending
data?! I’m guessing there is a reason why TCP protocol developers
didn’t enable that option?

thank you for helping me out

 

[EJP]

So then it is true that if app does half close, then the TCP doesn’t
set the timer and thus TCP could be in FIN_WAIT_2 state for a very
long time
Sure.

( and in that state it would also somehow be able to receive
data from other end )?

No 'somehow' about it. Just call read(), or readLine(), or readXXX for
some other X. TCP does the rest. Somehow ;-)

2.Wouldn’t it be useful if passive close end knew whether the other
end wants to stay in half-close state or do a full close? That way
passive-end would know whether to also send FIN or keep on sending
data?! I’m guessing there is a reason why TCP protocol developers
didn’t enable that option?

I don't think it makes much sense in the abstract. It's an aspect of a
specific application protocol.

 

[Srubys]

thank you for your help

cheers