FIN_WAIT_2 status at Client side - Unix

This is a discussion on FIN_WAIT_2 status at Client side - Unix ; 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) ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: FIN_WAIT_2 status at Client side

  1. FIN_WAIT_2 status at Client side

    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/facilitie...q-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

  2. Re: FIN_WAIT_2 status at Client side

    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.

  3. Re: FIN_WAIT_2 status at Client side

    In article <9f59573e-711e-46e1-a810-a975e32a5ddf@p25g2000hsf.googlegroups.com>,
    Ahmad Jalil Qarshi wrote:
    >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


  4. Re: FIN_WAIT_2 status at Client side

    On Mar 12, 6:06 am, Ahmad Jalil Qarshi
    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

  5. Re: FIN_WAIT_2 status at Client side

    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 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 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
    --
    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...

  6. Re: FIN_WAIT_2 status at Client side

    In article
    <9f59573e-711e-46e1-a810-a975e32a5ddf@p25g2000hsf.googlegroups.com>,
    Ahmad Jalil Qarshi 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/facilitie...cket-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 ***

  7. Re: FIN_WAIT_2 status at Client side

    On Mar 13, 4:46 am, Barry Margolin wrote:
    > In article
    > <9f59573e-711e-46e1-a810-a975e32a5...@p25g2000hsf.googlegroups.com>,
    > Ahmad Jalil Qarshi 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/facilitie...x/unix-socket-...
    > > 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, 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

+ Reply to Thread