FIN_WAIT_2 status at Client side

[Ahmad Jalil Qarshi]

Hi,

I have developed a socket based (Connection Less) client application
on AIX 5.2 for a third party server.

The protocol is somewhat like:

1) Connect with server at port 5555
2) Send Request to Server at specified port.
3) Close connection with server. (This is must. Client must close the
port after sending request otherwise the server will not send us
response).
4) Open a listening port at Client (Port: 9999) to receive the
response from Server.
5) Receive Response and process at Client side. (Server is responsible
to Close the connection at port 9999).

Now the problem is that when I close connection with server (using the
close() function) after sending request to server at port 5555,
somehow the port 5555 is not properly closed. The close function
returns 0, which indicates successful close.

When I use netstat on my client machine I can see following port
status.

Proto Recv-Q Send-Q Local Address Foreign
Address (state)
-------- ---------- -----------
--------------------- --------------------------
------------------
tcp4 0 0 server1.59959
200.10.196.3.5555 FIN_WAIT_2

According to TCP/IP protocol it indicates that the Close function is
being called at Client side but server has not properly closed the
port. The third party server vendor is claiming that I am not properly
closing the port at client side so this problem is at client side.

A short description of Client/Server TCP/IP protocol is given at:
http://www.softlab.ntua.gr/faciliti.../unix-socket-faq/unix-socket-faq-2.html#ss2.7

Now what I want to know is where the actual problem, at client side or
server side and what is the solution.

Thanks in anticipation,

Ahmad Jalil Qarshi

 

[Kenny McCormack]

Hi,

I have developed a socket based (Connection Less) client application
on AIX 5.2 for a third party server.

(Posting from clc - note the "CLC effect" in full bloom...)

With love and affection:

Off topic. Not portable. Cant discuss it here. Blah, blah, blah.

--
Useful clc-related links:

http://en.wikipedia.org/wiki/Aspergers
http://en.wikipedia.org/wiki/Clique
http://en.wikipedia.org/wiki/C_programming_language

 

[Rick Jones]

First, a netnanny nit:

When you cross-post to so many groups, you should select one for the
Followup-To: header. I've trimmed comp.lang.c from the followup-to:
header on this, please further trim it down to one group of your
chosing. My initial suggestion would be comp.protocols.tcp-ip.

1) Connect with server at port 5555
2) Send Request to Server at specified port.
3) Close connection with server. (This is must. Client must close the
port after sending request otherwise the server will not send us
response).
4) Open a listening port at Client (Port: 9999) to receive the
response from Server.
5) Receive Response and process at Client side. (Server is responsible
to Close the connection at port 9999).

Why can't the server simply send the response back down the connection
to port 5555? It seems really silly to go to all the trouble of
establishing a second TCP connection when you already have one which
is perfectly capable. And by requiring connection establishment by
both ends, it makes life much more complicated when dealing with
firewalls.

Now the problem is that when I close connection with server (using the
close() function) after sending request to server at port 5555,
somehow the port 5555 is not properly closed. The close function
returns 0, which indicates successful close.

When I use netstat on my client machine I can see following port
status.

Proto Recv-Q Send-Q Local Address Foreign
Address (state)
-------- ---------- -----------
--------------------- --------------------------

According to TCP/IP protocol it indicates that the Close function is
being called at Client side but server has not properly closed the
port. The third party server vendor is claiming that I am not properly
closing the port at client side so this problem is at client side.

The third party server vendor is confused or there is a device between
your client and the server doing evil things. You have done
everything you should on your end.

FIN_WAIT_2 does indeed mean that endpoint has sent a FINished segment,
and that segment has been ACKnowldeged by the remote. It is now
sitting there waiting for a FINished segment from the remote.

Perhaps the third party server code is doing something bad like using
an abortive close on the connection. That will send a ReSeT segment
rather than a FINished segment, and RST's are not retransmitted when
lost.

What you need is a packet trace at both ends.

rick jones

 

[Barry Margolin]

Hi,

I have developed a socket based (Connection Less) client application
on AIX 5.2 for a third party server.

The protocol is somewhat like:

1) Connect with server at port 5555
2) Send Request to Server at specified port.
3) Close connection with server. (This is must. Client must close the
port after sending request otherwise the server will not send us
response).
4) Open a listening port at Client (Port: 9999) to receive the
response from Server.

That's a very strange protocol design. Why doesn't it just send the
response on the same connection? If it needs to get an EOF to indicate
the end of the request, that's what half-closed connections are for; the
client would use shutdown(s, SHUT_WR) to send a FIN without closing the
connection.

Shouldn't you open the listening port before closing the connection with
the server? Otherwise, what happens if the server is faster than the
client, so it tries to connect to your port 9999 before you open it?

5) Receive Response and process at Client side. (Server is responsible
to Close the connection at port 9999).

Now the problem is that when I close connection with server (using the
close() function) after sending request to server at port 5555,
somehow the port 5555 is not properly closed. The close function
returns 0, which indicates successful close.

When I use netstat on my client machine I can see following port
status.

Proto Recv-Q Send-Q Local Address Foreign
Address (state)
-------- ---------- -----------
--------------------- --------------------------
------------------
tcp4 0 0 server1.59959
200.10.196.3.5555 FIN_WAIT_2

According to TCP/IP protocol it indicates that the Close function is
being called at Client side but server has not properly closed the
port. The third party server vendor is claiming that I am not properly
closing the port at client side so this problem is at client side.

A short description of Client/Server TCP/IP protocol is given at:
http://www.softlab.ntua.gr/facilities/documentation/unix/unix-socket-faq/unix-
socket-faq-2.html#ss2.7

Now what I want to know is where the actual problem, at client side or
server side and what is the solution.

Sounds to me like the problem is on the server. FIN_WAIT_2 means you've
sent a FIN, received an ACK of the FIN, and you're waiting for the other
side to send its FIN. That happens when the server closes its end of
the connection.

 

[Ahmad Jalil Qarshi]

That's a very strange protocol design. Why doesn't it just send the
response on the same connection? If it needs to get an EOF to indicate
the end of the request, that's what half-closed connections are for; the
client would use shutdown(s, SHUT_WR) to send a FIN without closing the
connection.

Shouldn't you open the listening port before closing the connection with
the server? Otherwise, what happens if the server is faster than the
client, so it tries to connect to your port 9999 before you open it?










Sounds to me like the problem is on the server. FIN_WAIT_2 means you've
sent a FIN, received an ACK of the FIN, and you're waiting for the other
side to send its FIN. That happens when the server closes its end of
the connection.

Thanks all (especially Rick Jones and Barry Margolin) for your kind
illustrative response.

Dear Barry, as I told you that its a third party server so I have to
follow this protocol. Our response listener module is always running
so it doesn't matter how fast the server is. As far as problem is
concerned I am totally agree with you that the problem is at server
side.

Regards,

Ahmad Jalil Qarshi

 

[Henry]

Hi,

I have developed a socket based (Connection Less) client application
on AIX 5.2 for a third party server.

The protocol is somewhat like:

1) Connect with server at port 5555
2) Send Request to Server at specified port.
3) Close connection with server. (This is must. Client must close the
port after sending request otherwise the server will not send us
response).
4) Open a listening port at Client (Port: 9999) to receive the
response from Server.
5) Receive Response and process at Client side. (Server is responsible
to Close the connection at port 9999).

Now the problem is that when I close connection with server (using the
close() function) after sending request to server at port 5555,
somehow the port 5555 is not properly closed. The close function
returns 0, which indicates successful close.

When I use netstat on my client machine I can see following port
status.

Proto Recv-Q Send-Q Local Address Foreign
Address (state)
-------- ---------- -----------
--------------------- --------------------------
------------------
tcp4 0 0 server1.59959
200.10.196.3.5555 FIN_WAIT_2

According to TCP/IP protocol it indicates that the Close function is
being called at Client side but server has not properly closed the
port. The third party server vendor is claiming that I am not properly
closing the port at client side so this problem is at client side.

A short description of Client/Server TCP/IP protocol is given at:http://www.softlab.ntua.gr/facilities/documentation/unix/unix-socket-...

Now what I want to know is where the actual problem, at client side or
server side and what is the solution.

Thanks in anticipation,

Ahmad Jalil Qarshi

Only time I've had issues with FIN_WAIT_2 was with a printer being
timed-out by a PIX Firewall.
Stupid Firewalls. Waste of money