Re: onSocketDidDisconnect in CocoaAsyncSocket
Re: onSocketDidDisconnect in CocoaAsyncSocket
- Subject: Re: onSocketDidDisconnect in CocoaAsyncSocket
- From: Bing Li <email@hidden>
- Date: Wed, 04 May 2011 16:45:12 +0800
Dear Patrick,
Thanks so much for your reply!
I ever believed that TCP protocols handle everything on the connection. Only
UDP needs a lot of work to manage the connection. According to your
description, it is not like that?
I have not worked on a so low level network programming. Your email helps me
a lot. If you could take a look at the code, I appreciate so much!
Best,
Bing
On Wed, May 4, 2011 at 4:13 PM, Patrick Mau <email@hidden> wrote:
> Hallo Bing
>
> The Networking API gives you choices to react. It was a good design to not
> specify automatic timeouts within TCP.
>
> Think about unplugging a network cable or even a 5 minute power outage. If
> you, as an application designer rely
> on a functional connection even afterthese events, you could do with TCP.
> Becuase no one but you is responsible
> to decide how to react. Therefore no-one has closed anything for you.
>
> Regarding timeouts, I think every networked client-server code has to
> handle timeouts on an application level to
> limit resource usage.
>
> You can even handle your client getting killed in Activity Monitor by
> writing a signal handler for SIGTERM.
> That is, by the way, the difference between the "Quit" and "Force Quit"
> action. One sends a SIGTERM, the
> other a SIGKILL. The last one can not be handled in code, per definition.
>
> You should not use socket I/O functions in signal handling code hoever, you
> should only set a flag and
> test for that in you main run loop.
>
> Regarding heartbeat, there's the SO_KEEPALIVE socket option, that is used
> to transmit packets of zero length
> on idle connections. This is useful to prevent hardware in your network,
> i.e firewalls or load-balancers to
> forget about NAT or dynamic rules. They do limit resources, too. By using
> timeouts.
>
> Instead of talking about TCP in general I will look at the sample code you
> mentioned in your first mail
> and code an example project if I have the time today.
>
> Best regards
> Patrick
>
>
>
> On 04.Mai.2011, at 05:52, Bing Li wrote:
>
> Dear Patrick,
>
> Thanks so much for your answer!
>
> I don't know the details of TCP. However, TCP should be a reliable
> protocol. Developers are not required to keep its connection state since TCP
> does that. That's one of the important differences between TCP and UDP,
> right? When using UDP, it is mandatory to keep the connection by developers
> themselves. Am I right?
>
> According to my experiences, when a TCP connection is disconnected without
> calling the relevant closing method, an exception should be thrown in the
> counterpart side. Do you think so? A heartbeat you mentioned should be
> handled by TCP not programmers.
>
> Best regards,
> Bing
>
> On Wed, May 4, 2011 at 2:08 AM, Patrick Mau <email@hidden> wrote:
>
>> Hallo Bing
>>
>> I saw your message and thought I share my ideas. Maybe it's of some use to
>> you.
>>
>> TCP/IP is a state machine, meaning it can only react to state changes on a
>> connection.
>>
>> When you kill a connected client, no packet is transmitted to your server
>> anymore.
>> That means that it has not received a FIN packet that would indicate your
>> client
>> has been killed.
>>
>> Your server will only know about your terminated client by the time it
>> reads or writes
>> to the socket, because it will no longer receive an ACK for these packets.
>>
>> That's where timeouts come into play. If you install some kind of timer
>> that would fire
>> after a certain time of inactivity, your server itself should close the
>> connection.
>>
>> It will then timeout waiting for the ACK that it is waiting for in
>> response to the
>> FIN packet it has tried to send.
>>
>> That's all based on on my BSD socket programming knowlegde, I've not used
>> the CocoaAsyncSocket API myself.
>>
>> I hope it gives you some idea.
>> Patrick
>>
>> On 02.Mai.2011, at 18:16, Bing Li wrote:
>>
>> > Dear all,
>> >
>> > Can anyone answer this question?
>> >
>> > Thanks so much!
>> > Bing
>> >
>> > On Fri, Apr 29, 2011 at 7:21 PM, Bing Li <email@hidden> wrote:
>> >
>> >> Dear Michael,
>> >>
>> >> "Disgracefully" means the client does not close normally. It might be
>> >> crashed or closed by killing the relevant thread or process. I did that
>> by
>> >> clicking the red Tasks button in XCode. In this situation, the
>> connection
>> >> must not be closed properly with the socket methods.
>> >>
>> >> According to my test, [AsyncSocketDelegate onSocket:
>> >> willDisconnectWithError:] is not called either.
>> >>
>> >> I got the sample code from
>> >> http://www.macresearch.org/cocoa-scientists-part-xxix-message. I am
>> still
>> >> a new developer. I am not sure if the code has any problems.
>> >>
>> >> Thanks so much for your help!
>> >>
>> >> Best regards,
>> >> BIng
>> >>
>> >>
>> >> On Fri, Apr 29, 2011 at 6:56 AM, Michael Dautermann <
>> email@hidden>wrote:
>> >>
>> >>>>
>> >>>> I started to use CocoaAsyncSocket to establish TCP connections among
>> >>> iPads.
>> >>>>
>> >>>> I got a problem. According to the references (
>> >>>> http://code.google.com/p/cocoaasyncsocket/wiki/Reference_AsyncSocket
>> ),
>> >>>> onSocketDidDisconnect would be invoked immediately if the connection
>> is
>> >>> not
>> >>>> already disconnected. I felt confused. What does "not already
>> >>> disconnected"
>> >>>> mean? I think onSocketDidDisconnect should be called when a
>> connection
>> >>> is
>> >>>> disconnected. The description in the reference is wrong?
>> >>>>
>> >>>> I implemented a server and a client using CocoaAsyncSocket. When
>> closing
>> >>> the
>> >>>> client disgracefully, I noticed that onSocketDidDisconnect was NOT
>> >>> called.
>> >>>> Anything wrong with it?
>> >>>
>> >>> Here are some questions that might help get some further context:
>> >>>
>> >>> how are you closing the client "disgracefully"?
>> >>>
>> >>> did the companion [AsyncSocketDelegate onSocket:
>> willDisconnectWithError:]
>> >>> method get called?
>> >>>
>> >>> did you properly set your delegate and define that your object (the
>> one
>> >>> that holds your delegate methods) conforms to the delegate protocol in
>> it's
>> >>> .h file?
>> >>>
>> >>>
>> >>>
>> >>
>> > _______________________________________________
>> >
>> > Cocoa-dev mailing list (email@hidden)
>> >
>> > Please do not post admin requests or moderator comments to the list.
>> > Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>> >
>> > Help/Unsubscribe/Update your Subscription:
>> >
>> >
>> > This email sent to email@hidden
>>
>>
>
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden