On Dec 15, 2008, at 5:49 AM, norio wrote:
> I'm sorry to ask you this again.
>
> I don't know if I could have told you my problem correctly, please
> let me tell you again.
>
> 1. My app gets NSWorkspaceDidUnmountNotification.
> 2. Under 10.5, users can handle some actions before the notification
> comes to my app.
>
> I'd like my app to get noticed that a network connection was cut as
> very soon as it occurred.
NSWorkspaceDidUnmountNotification is about volumes, not the network,
although if you have a network volume mounted and the connection is
disrupted, I suppose it will be unmounted.
The Finder and NSWorkspace are both using the Disk Arbitration
framework to be notified of such events. There's no way to guarantee
that your app receives the Disk Arbitration notification before the
Finder. Depending on what notification the Finder is using, though,
it may be at a different point in the sequence. You could take a look
at Disk Arbitration to see if registering for certain notifications
gets you an earlier opportunity to react. Ultimately though, on a
multi-processing OS you have no guarantee of being able to complete
your processing before other applications have an opportunity to do
some processing of their own. You should reconsider your design if
you think you have such a requirement.
You might also take a look at the Network Reachability API <
http://developer.apple.com/documentation/Networking/Conceptual/SystemConfig
Frameworks/SC_ReachConnect/chapter_5_section_4.html>. This will notify your app when the system becomes aware of a
network reachability change. Note the important caveat: in general,
it is not possible for one computer to detect if another computer is
_truly_ "reachable" over the network. From <
http://developer.apple.com/documentation/Networking/Conceptual/SystemConfig
Frameworks/SC_ReachConnect/chapter_5_section_2.html>:
> The System Configuration reachability API helps an application
> determine if a remote host is reachable. A remote host is considered
> reachable if a data packet sent to the host can leave the local
> computer, regardless of what ultimately happens to the packet. In
> other words, the reachability of a remote host does not guarantee
> that the host will receive the data.
>
> In practice, when a remote host is deemed reachable, but the packets
> you send to it fail to arrive, the myriad possible reasons for the
> failure fall into two broad categories:
>
> 1. A part of the Internet connection over which you have no
> control is broken. For example, the remote host’s server is down.
> 2. A part of your local network infrastructure over which you
> might have control is broken. For example, your modem hasn’t dialed
> or your AirPort base station is turned off.
>
> The reachability API cannot help you with problems in the first
> category. As long as data packets can leave the local machine, the
> remote host is considered reachable. [...]
Good luck,
Ken
