Home > Archive > Unix Programming > March 2008 > FIN_WAIT_2 status at Client side
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
FIN_WAIT_2 status at Client side
|
|
| Ahmad Jalil Qarshi 2008-03-12, 8:12 am |
| 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...aq-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
| |
| Rainer Temme 2008-03-12, 7:31 pm |
| Ahmad Jalil Qarshi wrote:
>
> When I use netstat on my client machine I can see following port
> status.
>
> Proto Recv-Q Send-Q Local Address ForeignAddress (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.
The FIN_WAIT_2 leaves absolutely no doubt:
The socket with the local end server1:59959 that is connected
to the remote end (server end) 200.10.196.3:5555 is in
state FIN_WAIT_2.
in this state, the local application has:
- called close()
- Local TCP has sent a SYN
- Local TCP has received an ACK
TCP is now waiting for a FIN from the remote side.
This will only come, if the remote (server) application
calls close().
The third party vendor is telling rubbish.
| |
|
|
| David Schwartz 2008-03-12, 7:31 pm |
| On Mar 12, 6:06 am, Ahmad Jalil Qarshi <Ahmad.Jalil.Qar...@gmail.com>
wrote:
> 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.
And that's a problem because ... ?
> 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.
And the problem is ... ?
> Now what I want to know is where the actual problem, at client side or
> server side and what is the solution.
What's the problem? You've shown your attempts to diagnose the problem
but not what the actual problem is. What goes wrong?
DS
| |
| Rick Jones 2008-03-12, 7:31 pm |
| 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.
In comp.unix.aix Ahmad Jalil Qarshi <Ahmad.Jalil.Qarshi@gmail.com> wrote:
> 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)
> -------- ---------- -----------
> --------------------- --------------------------
> ------------------
> 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.
The third party server vendor is  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
--
Process shall set you free from the need for rational thought.
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...
| |
| Barry Margolin 2008-03-12, 7:31 pm |
| In article
<9f59573e-711e-46e1-a810-a975e32a5ddf@p25g2000hsf.googlegroups.com>,
Ahmad Jalil Qarshi <Ahmad.Jalil.Qarshi@gmail.com> wrote:
> 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/faciliti...ocket-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.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
| |
| Ahmad Jalil Qarshi 2008-03-13, 8:16 am |
| On Mar 13, 4:46 am, Barry Margolin <bar...@alum.mit.edu> wrote:
> In article
> <9f59573e-711e-46e1-a810-a975e32a5...@p25g2000hsf.googlegroups.com>,
> Ahmad Jalil Qarshi <Ahmad.Jalil.Qar...@gmail.com> wrote:
>
>
>
>
>
> 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.
>
> --
> Barry Margolin, bar...@alum.mit.edu
> Arlington, MA
> *** PLEASE don't copy me on replies, I'll read them in the group ***
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
| |
|
| On Mar 13, 2:06 am, Ahmad Jalil Qarshi <Ahmad.Jalil.Qar...@gmail.com>
wrote:
> 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-...
>
> 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
|
|
|
|
|