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 protected]> 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 protected]> 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 protected]> 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 protected]>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 protected]) >> > >> > 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: >> > >> http://lists.apple.com/mailman/options/cocoa-dev/cocoa-dev%40mail.c2am.de >> > >> > This email sent to [email protected] >> >> > > _______________________________________________ Cocoa-dev mailing list ([email protected]) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
