Re: NSConnection Issue
Re: NSConnection Issue
- Subject: Re: NSConnection Issue
- From: Ken Thomases <email@hidden>
- Date: Wed, 23 Jul 2008 01:03:51 -0500
On Jul 23, 2008, at 12:07 AM, Adam R. Maxwell wrote:
On Jul 22, 2008, at 9:54 PM, Patrick Walker wrote:
I was wondering if anyone had any solutions to determine whether or
not an NSConnection via NSSocketPorts are still valid without each
end polling to see if it still connects? Right now, if the client
tries to access the rootObject it hangs. While this may may only
happen occasionally, I don't like it when the only solution is to
restart the program. I can "live" with this issue if I had to
because all I seem to have to ensure is that the server remains up
and hardware plugged in.
Is there any equivalent for NSConnectionDidDieNotification and
similar notifications that could be gerry-rigged to work on not
just NSPort but NSSocketPort? The documentation at the Apple
Developer site says that NSConnection has two notifications
available for it but unfortunately neither will work if the sockets
are of NSSocketPort. It also says that you detect a failure on the
next message, but the problem is that whenever I try to send a
message, the client locks up.
AFAIK you just have to try connecting if you're using NSSocketPort.
Have you tried using -[NSConnection setRequestTimeout:]? I have a
comment in some of my code which indicates that the default timeout
is really long.
There are (at least) two timeouts involved, the TCP timeout and
NSConnection's timeout(s).
An NSSocketPort will _eventually_ realize that it has broken after you
attempt to send something. It might be quick if the link to the
remote machine is intact -- you'll either get a connection refused or
connection reset. However, if your packets are just getting lost or
dropped (as by a firewall, for example), then TCP will retry
repeatedly with ever-longer waits between tries. It will eventually
give up, but I think it takes a total of 9 minutes.
The NSConnection timeouts (requestTimeout and replyTimeout) are in
effect whether or not the socket connection is still intact. If you
set them lower, then they might trip if, for example, the server is
simply taking a long time to process the request.
I don't think setRequestTimeout: will fix the case of the port being
broken. It puts a limit on how long the NSConnection will wait for
the local kernel to accept its outgoing message. When the TCP
connection is broken, you'll probably still be able to put several
messages on the wire before the TCP window of the connection closes
and then you'll still be able to put some in the kernel buffers for
the socket before they too are full.
setReplyTimeout: puts a limit on total round-trip time for the request
to reach the remote host, for the request to be processed there, and
for the reply to come back. This can more effectively be used to
detect when the socket connection is broken, but it complicates the
situation where the server has to do substantial work to process a
request. You have to use an asynchronous processing scheme. The
client sends a request and the server replies immediately saying that
it has received the request and queued the work. The server then
proceeds to do the work outside of the context of a request pending a
reply. When it's done, it can pass the results back to the client
(which should be awaiting them by sitting in its run loop).
Cheers,
Ken
_______________________________________________
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