question about netstat Recv-Q - TCP-IP

This is a discussion on question about netstat Recv-Q - TCP-IP ; I encouter a strange problem. my server program go wrong when it is running for a while. when server close end point socket ,the client end point socket is keeping alive. when I use tcpdump in a computer connected to ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: question about netstat Recv-Q

  1. question about netstat Recv-Q

    I encouter a strange problem. my server program go wrong when it is
    running for a while. when server close end point socket ,the client
    end point socket is keeping alive. when I use tcpdump in a computer
    connected to server long ago , surprising , I found packet coming from
    server that should being send to another computer .

    i want to cry ,how is it?

    and I found end port socket that should being closed before,
    now it's stat is close_wait ,and the Recv-Q is not zero.

    whe the problen occur, i telnet to the server ,and I found the new
    socket created by accept read ago's data that is the end point
    that's stat is close_wait ,and the Recv-Q is not zero.

    i am going to become craze.
    anybody save me ?
    thank you very muth for your help.

  2. Re: question about netstat Recv-Q

    On Sep 3, 2:52*am, "zhangyefei.ye...@gmail.com"
    wrote:
    > I encouter a strange problem. *my server program go wrong *when it is
    > running for a while. when server close end point socket ,the client
    > end point socket is keeping alive. when I use tcpdump in a computer
    > connected to server long ago , surprising , I found packet coming from
    > server *that should being send to another computer .
    >
    > i want to cry ,how is it?
    >
    > and I *found end port socket that should being closed before,
    > now it's stat is close_wait ,and the Recv-Q is not zero.
    >
    > whe the problen occur, i telnet to *the server *,and I found the new
    > socket created by accept read ago's data that is *the end point
    > that's stat is close_wait ,and the Recv-Q is not zero.
    >
    > i am going to become craze.
    > anybody save me ?
    > thank you very muth for your help.


    There's a bug in your program. How much more can we say without seeing
    the code?

    DS

  3. Re: question about netstat Recv-Q

    On Sep 4, 2:52*am, David Schwartz wrote:
    > On Sep 3, 2:52*am, "zhangyefei.ye...@gmail.com"
    >
    >
    >
    > wrote:
    > > I encouter a strange problem. *my server program go wrong *when it is
    > > running for a while. when server close end point socket ,the client
    > > end point socket is keeping alive. when I use tcpdump in a computer
    > > connected to server long ago , surprising , I found packet coming from
    > > server *that should being send to another computer .

    >
    > > i want to cry ,how is it?

    >
    > > and I *found end port socket that should being closed before,
    > > now it's stat is close_wait ,and the Recv-Q is not zero.

    >
    > > whe the problen occur, i telnet to *the server *,and I found the new
    > > socket created by accept read ago's data that is *the end point
    > > that's stat is close_wait ,and the Recv-Q is not zero.

    >
    > > i am going to become craze.
    > > anybody save me ?
    > > thank you very muth for your help.

    >
    > There's a bug in your program. How much more can we say without seeing
    > the code?
    >
    > DS


    source codes is a little big, can not be showed here .sorry.
    but i think my program can not make tcp protocol crazy ?
    this is very strange problem ....
    who Encounter the same problem ?

  4. Re: question about netstat Recv-Q

    On Sep 3, 8:18*pm, "zhangyefei.ye...@gmail.com"
    wrote:

    > source codes is a little big, can not be showed here .sorry.
    > but i think my program can not make tcp protocol crazy ?
    > this is very strange problem ....
    > who *Encounter the same problem ?


    Your problem description is very typical of programs that lose track
    of which socket is which.

    DS

  5. Re: question about netstat Recv-Q

    On Sep 5, 2:06*am, David Schwartz wrote:
    > On Sep 3, 8:18*pm, "zhangyefei.ye...@gmail.com"
    >
    > wrote:
    > > source codes is a little big, can not be showed here .sorry.
    > > but i think my program can not make tcp protocol crazy ?
    > > this is very strange problem ....
    > > who *Encounter the same problem ?

    >
    > Your problem description is very typical of programs that lose track
    > of which socket is which.
    >
    > DS


    thanks very much for your reply.

    i found the connect and disconnect is strange :
    11:15:06.219049 IP a.3658 > b.8888: S 1561001322:1561001322(0) win
    65535
    11:15:06.219066 IP b.8888 > a.3658: S 415149191:415149191(0) ack
    1561001323 win 5840
    11:15:06.235461 IP a.3658 > b.8888: . ack 1 win 65535
    11:15:06.235588 IP a.3658 > b.8888: P 1:26(25) ack 1 win 65535
    11:15:06.235599 IP b.8888 > a.3658: . ack 26 win 5840
    11:15:06.273787 IP b.8888 > a.3658: P 1:30(29) ack 26 win 5840
    11:15:06.290251 IP a.3658 > b.8888: F 26:26(0) ack 30 win 65506
    11:15:06.290793 IP b.8888 > a.3658: F 30:30(0) ack 27 win 5840
    11:15:06.307142 IP a.3658 > b.8888: . ack 31 win 65506



    the normal procedure is such:
    09:42:18.433265 IP a.4462 > b.8888: S 3208938282:3208938282(0) win
    65535
    09:42:18.433283 IP b.8888 > a.4462: S 3128128512:3128128512(0) ack
    3208938283 win 5840
    09:42:18.459116 IP a.4462 > b.8888: . ack 1 win 65535
    09:42:18.459202 IP a.4462 > b.8888: P 1:26(25) ack 1 win 65535
    09:42:18.459212 IP b.8888 > a.4462: . ack 26 win 5840
    09:42:18.512317 IP b.8888 > a.4462: P 1:30(29) ack 26 win 5840
    09:42:18.512329 IP b.8888 > a.4462: F 30:30(0) ack 26 win 5840
    09:42:18.538132 IP a.4462 > b.8888: . ack 31 win 65506
    09:42:18.538165 IP a.4462 > b.8888: F 26:26(0) ack 31 win 65506
    09:42:18.538176 IP b.8888 > a.4462: . ack 27 win 5840

    the disconnect should have four data packet, that is
    a->b F
    b->a ack
    b->a F
    a->b ack
    can this show some hints of the problem ?
    thanks .

  6. Re: question about netstat Recv-Q

    On Sep 5, 5:38*am, "zhangyefei.ye...@gmail.com"
    wrote:
    > On Sep 5, 2:06*am, David Schwartz wrote:
    >
    > > On Sep 3, 8:18*pm, "zhangyefei.ye...@gmail.com"

    >
    > > wrote:
    > > > source codes is a little big, can not be showed here .sorry.
    > > > but i think my program can not make tcp protocol crazy ?
    > > > this is very strange problem ....
    > > > who *Encounter the same problem ?

    >
    > > Your problem description is very typical of programs that lose track
    > > of which socket is which.

    >
    > > DS

    >
    > thanks very much for your reply.
    >
    > i found the connect and *disconnect is strange :
    > 11:15:06.219049 IP a.3658 > b.8888: S 1561001322:1561001322(0) win
    > 65535
    > 11:15:06.219066 IP b.8888 > a.3658: S 415149191:415149191(0) ack
    > 1561001323 win 5840
    > 11:15:06.235461 IP a.3658 > b.8888: . ack 1 win 65535
    > 11:15:06.235588 IP a.3658 > b.8888: P 1:26(25) ack 1 win 65535
    > 11:15:06.235599 IP b.8888 > a.3658: . ack 26 win 5840
    > 11:15:06.273787 IP b.8888 > a.3658: P 1:30(29) ack 26 win 5840
    > 11:15:06.290251 IP a.3658 > b.8888: F 26:26(0) ack 30 win 65506
    > 11:15:06.290793 IP b.8888 > a.3658: F 30:30(0) ack 27 win 5840
    > 11:15:06.307142 IP a.3658 > b.8888: . ack 31 win 65506

    So your server is sending a packet out of order, without the source
    (for disconnect function) it is impossible to say anything more than
    what was said before:
    "There's a bug in your program" by David Schwartz
    >
    > the normal procedure is such:
    > 09:42:18.433265 IP a.4462 > b.8888: S 3208938282:3208938282(0) win
    > 65535
    > 09:42:18.433283 IP b.8888 > a.4462: S 3128128512:3128128512(0) ack
    > 3208938283 win 5840
    > 09:42:18.459116 IP a.4462 > b.8888: . ack 1 win 65535
    > 09:42:18.459202 IP a.4462 > b.8888: P 1:26(25) ack 1 win 65535
    > 09:42:18.459212 IP b.8888 > a.4462: . ack 26 win 5840
    > 09:42:18.512317 IP b.8888 > a.4462: P 1:30(29) ack 26 win 5840
    > 09:42:18.512329 IP b.8888 > a.4462: F 30:30(0) ack 26 win 5840
    > 09:42:18.538132 IP a.4462 > b.8888: . ack 31 win 65506
    > 09:42:18.538165 IP a.4462 > b.8888: F 26:26(0) ack 31 win 65506
    > 09:42:18.538176 IP b.8888 > a.4462: . ack 27 win 5840
    >
    > the disconnect should have four data packet, that is
    > a->b *F
    > b->a *ack
    > b->a *F
    > a->b ack
    > can this show some hints of the problem ?
    > thanks .



  7. Re: question about netstat Recv-Q

    zhangyefei.yefei@gmail.com wrote:
    > On Sep 5, 2:06?am, David Schwartz wrote:
    > > On Sep 3, 8:18?pm, "zhangyefei.ye...@gmail.com"
    > >
    > > wrote:
    > > > source codes is a little big, can not be showed here .sorry.
    > > > but i think my program can not make tcp protocol crazy ?
    > > > this is very strange problem ....
    > > > who ?Encounter the same problem ?

    > >
    > > Your problem description is very typical of programs that lose track
    > > of which socket is which.
    > >
    > > DS


    > thanks very much for your reply.


    > i found the connect and disconnect is strange :
    > 11:15:06.219049 IP a.3658 > b.8888: S 1561001322:1561001322(0) win
    > 65535
    > 11:15:06.219066 IP b.8888 > a.3658: S 415149191:415149191(0) ack
    > 1561001323 win 5840
    > 11:15:06.235461 IP a.3658 > b.8888: . ack 1 win 65535
    > 11:15:06.235588 IP a.3658 > b.8888: P 1:26(25) ack 1 win 65535
    > 11:15:06.235599 IP b.8888 > a.3658: . ack 26 win 5840
    > 11:15:06.273787 IP b.8888 > a.3658: P 1:30(29) ack 26 win 5840
    > 11:15:06.290251 IP a.3658 > b.8888: F 26:26(0) ack 30 win 65506
    > 11:15:06.290793 IP b.8888 > a.3658: F 30:30(0) ack 27 win 5840
    > 11:15:06.307142 IP a.3658 > b.8888: . ack 31 win 65506


    Looks fine to me. A sends 25 bytes, B's stack ACKs it with a
    standalone ACK, B sends a 29 byte reply. A closes his end triggering
    a FIN with sequence number 26 and piggybacking the ACK of B's
    application response, then B sends a FIN with a piggybacked ACK for
    A's FIN. Finally A ACKs B's FIN.

    > the normal procedure is such:
    > 09:42:18.433265 IP a.4462 > b.8888: S 3208938282:3208938282(0) win
    > 65535
    > 09:42:18.433283 IP b.8888 > a.4462: S 3128128512:3128128512(0) ack
    > 3208938283 win 5840
    > 09:42:18.459116 IP a.4462 > b.8888: . ack 1 win 65535
    > 09:42:18.459202 IP a.4462 > b.8888: P 1:26(25) ack 1 win 65535
    > 09:42:18.459212 IP b.8888 > a.4462: . ack 26 win 5840
    > 09:42:18.512317 IP b.8888 > a.4462: P 1:30(29) ack 26 win 5840
    > 09:42:18.512329 IP b.8888 > a.4462: F 30:30(0) ack 26 win 5840
    > 09:42:18.538132 IP a.4462 > b.8888: . ack 31 win 65506
    > 09:42:18.538165 IP a.4462 > b.8888: F 26:26(0) ack 31 win 65506
    > 09:42:18.538176 IP b.8888 > a.4462: . ack 27 win 5840


    > the disconnect should have four data packet, that is
    > a->b F
    > b->a ack
    > b->a F
    > a->b ack
    > can this show some hints of the problem ?


    No. Disconnect does not _have_ to be four distinct TCP segments. It
    is perfectly acceptable to have:

    a->b FIN
    b->a FIN, ACK
    a->b ACK

    But it does look like in the first trace above, A is first to close,
    in the second B is first to close.


    --
    The computing industry isn't as much a game of "Follow The Leader" as
    it is one of "Ring Around the Rosy" or perhaps "Duck Duck Goose."
    - Rick Jones
    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...

  8. Re: question about netstat Recv-Q

    On Sep 6, 8:15*am, Rick Jones wrote:
    > zhangyefei.ye...@gmail.com wrote:
    > > On Sep 5, 2:06?am, David Schwartz wrote:
    > > > On Sep 3, 8:18?pm, "zhangyefei.ye...@gmail.com"

    >
    > > > wrote:
    > > > > source codes is a little big, can not be showed here .sorry.
    > > > > but i think my program can not make tcp protocol crazy ?
    > > > > this is very strange problem ....
    > > > > who ?Encounter the same problem ?

    >
    > > > Your problem description is very typical of programs that lose track
    > > > of which socket is which.

    >
    > > > DS

    > > thanks very much for your reply.
    > > i found the connect and *disconnect is strange :
    > > 11:15:06.219049 IP a.3658 > b.8888: S 1561001322:1561001322(0) win
    > > 65535
    > > 11:15:06.219066 IP b.8888 > a.3658: S 415149191:415149191(0) ack
    > > 1561001323 win 5840
    > > 11:15:06.235461 IP a.3658 > b.8888: . ack 1 win 65535
    > > 11:15:06.235588 IP a.3658 > b.8888: P 1:26(25) ack 1 win 65535
    > > 11:15:06.235599 IP b.8888 > a.3658: . ack 26 win 5840
    > > 11:15:06.273787 IP b.8888 > a.3658: P 1:30(29) ack 26 win 5840
    > > 11:15:06.290251 IP a.3658 > b.8888: F 26:26(0) ack 30 win 65506
    > > 11:15:06.290793 IP b.8888 > a.3658: F 30:30(0) ack 27 win 5840
    > > 11:15:06.307142 IP a.3658 > b.8888: . ack 31 win 65506

    >
    > Looks fine to me. *A sends 25 bytes, B's stack ACKs it with a
    > standalone ACK, B sends a 29 byte reply. *A closes his end triggering
    > a FIN with sequence number 26 and piggybacking the ACK of B's
    > application response, then B sends a FIN with a piggybacked ACK for
    > A's FIN. *Finally A ACKs B's FIN.
    >
    >
    >
    > > the normal procedure is such:
    > > 09:42:18.433265 IP a.4462 > b.8888: S 3208938282:3208938282(0) win
    > > 65535
    > > 09:42:18.433283 IP b.8888 > a.4462: S 3128128512:3128128512(0) ack
    > > 3208938283 win 5840
    > > 09:42:18.459116 IP a.4462 > b.8888: . ack 1 win 65535
    > > 09:42:18.459202 IP a.4462 > b.8888: P 1:26(25) ack 1 win 65535
    > > 09:42:18.459212 IP b.8888 > a.4462: . ack 26 win 5840
    > > 09:42:18.512317 IP b.8888 > a.4462: P 1:30(29) ack 26 win 5840
    > > 09:42:18.512329 IP b.8888 > a.4462: F 30:30(0) ack 26 win 5840
    > > 09:42:18.538132 IP a.4462 > b.8888: . ack 31 win 65506
    > > 09:42:18.538165 IP a.4462 > b.8888: F 26:26(0) ack 31 win 65506
    > > 09:42:18.538176 IP b.8888 > a.4462: . ack 27 win 5840
    > > the disconnect should have four data packet, that is
    > > a->b *F
    > > b->a *ack
    > > b->a *F
    > > a->b ack
    > > can this show some hints of the problem ?

    >
    > No. *Disconnect does not _have_ to be four distinct TCP segments. *It
    > is perfectly acceptable to have:
    >
    > a->b FIN
    > b->a FIN, ACK
    > a->b ACK
    >
    > But it does look like in the first trace above, A is first to close,
    > in the second B is first to close.
    >
    > --
    > The computing industry isn't as much a game of "Follow The Leader" as
    > it is one of "Ring Around the Rosy" or perhaps "Duck Duck Goose."
    > * * * * * * * * * * * * * * * * * * * * * * * * * * - Rick Jones
    > 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 you so much.
    your explanation make me understand tcp connection establishment and
    termination better.
    it help me resolve my confusion.

    Also ,i seems that i found what caused my above problem.
    i am new to epoll program.in my server program, i create listen
    socket ,and sets the edge triggered( that is EPOLLET ) behavior for
    it.
    it is a completely wrong usage.
    when currently a few new connections comes , server can ony accept a
    new connection ,leaving others in connection request queue .

    we should use level trigger for listen socket.

    Also thanks David Schwartz ,GArlington.
    thanks all very much.

+ Reply to Thread