TCP connection termination not handled well

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



One thing I didn't mention before will perhaps make you feel better. The
OS will not object to the client send()ing on a socket when FIN has been
received on it.  On the server end though is another story. If the file
handle for the socket has been closed (it wouldn't /have/ to be, the
server code could have called shutdown() with SHUT_WR and that would
have also triggered FIN) then when new data is received an RST will be
sent back to the client. Now on the client end if you try to call send()
when the OS has received RST you will indeed get an error... a second
way you will detect that the socket has closed. I attach a real working
Python script that will demonstrate the behavior (the second time the
client calls send() a Python exception will result).

There are lots of subtleties to how TCP works ;-)

On 5/7/13 6:46 PM, Khoa Pham wrote:
> @Jens. thanks
>
> If we can read/write packets to detect closed socket, why is there TCP
> keep alive ??
>
>
> On Tue, May 7, 2013 at 2:07 PM, Jens Jorgensen <jbj1 at ultraemail.net
> <mailto:jbj1 at ultraemail.net>> wrote:
>
>     Well the thing is just because you sniffed the packet off the wire
>     doesn't in any way mean the "client" (i.e. the SIP software) has
>     actually received it. In fact, a pretty reasonable piece of SIP
>     code (I'll just write Python pseudo-code for brevity) might look
>     something like:
>
>     s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>     s.connect( (server, port) )
>     s.send('REGISTER ....')
>     while True :
>         bytes = s.recv(256)
>         if len(bytes) == 0 :
>             # uh-oh, the remote end closed the socket
>
>     And in fact even if the OS has received the [FIN,ACK] already when
>     s.send() is called, this will *not* cause an error. The send()
>     will complete successfully. Try it!
>
>
>     On 5/7/13 2:58 PM, Khoa Pham wrote:
>>     @Jens, thanks for reply
>>
>>     But client already received the [FIN,ACK] from server, it should
>>     know that sending REGISTER does not make sense anymore
>>
>>
>>     On Tue, May 7, 2013 at 12:13 PM, Jens Jorgensen
>>     <jbj1 at ultraemail.net <mailto:jbj1 at ultraemail.net>> wrote:
>>
>>         You make it sound like you want the client to hang up?! As
>>         you know, the primary way a program finds out if a socket is
>>         closed is to try reading or writing on it. In this case the
>>         server has closed its end of the socket but the client
>>         probably doesn't know that (yet)--evidently because it
>>         thought it would get the chance to REGISTER
>>
>>         On 5/6/13 5:15 PM, Khoa Pham wrote:
>>>         Hi pjsip team,
>>>
>>>         When I make REGISTER request to server, I often receive this
>>>
>>>         1. client: SYN
>>>         2. server: SYN, ACK
>>>         3. client: ACK
>>>         4. server: FIN, ACK
>>>         5. client: REGISTER
>>>         6. server: RST
>>>
>>>         Why in step 5 does client not send FIN, ACK ??
>>>
>>>         -- 
>>>         Khoa Pham
>>>         HCMC University of Science
>>>         Faculty of Information Technology
>>>
>>>
>>>         _______________________________________________
>>>         Visit our blog: http://blog.pjsip.org
>>>
>>>         pjsip mailing list
>>>         pjsip at lists.pjsip.org <mailto:pjsip at lists.pjsip.org>
>>>         http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>
>>         -- 
>>         Jens B. Jorgensen
>>         jbj1 at ultraemail.net <mailto:jbj1 at ultraemail.net>
>>
>>
>>         _______________________________________________
>>         Visit our blog: http://blog.pjsip.org
>>
>>         pjsip mailing list
>>         pjsip at lists.pjsip.org <mailto:pjsip at lists.pjsip.org>
>>         http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>
>>
>>
>>
>>     -- 
>>     Khoa Pham
>>     HCMC University of Science
>>     Faculty of Information Technology
>>
>>
>>     _______________________________________________
>>     Visit our blog: http://blog.pjsip.org
>>
>>     pjsip mailing list
>>     pjsip at lists.pjsip.org <mailto:pjsip at lists.pjsip.org>
>>     http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>
>     -- 
>     Jens B. Jorgensen
>     jbj1 at ultraemail.net <mailto:jbj1 at ultraemail.net>
>
>
>     _______________________________________________
>     Visit our blog: http://blog.pjsip.org
>
>     pjsip mailing list
>     pjsip at lists.pjsip.org <mailto:pjsip at lists.pjsip.org>
>     http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>
>
>
>
> -- 
> Khoa Pham
> HCMC University of Science
> Faculty of Information Technology
>
>
> _______________________________________________
> Visit our blog: http://blog.pjsip.org
>
> pjsip mailing list
> pjsip at lists.pjsip.org
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org

-- 
Jens B. Jorgensen
jbj1 at ultraemail.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20130507/838abb8d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tcp_socket_demo.py
Type: text/x-python-script
Size: 468 bytes
Desc: not available
URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20130507/838abb8d/attachment-0001.py>


[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux