Hi,
I am using Apple's Network.framework APIs, specifically NWConnection and NWListener over UDP, in my project. Both APIs use state-update handlers, and I would like to clarify a few aspects of their lifecycle and callback-delivery semantics.
- Are .failed and .cancelled delivered only once during the lifecycle?
For a given NWConnection or NWListener instance, my understanding is that .failed is a terminal state and the object does not recover from it.
Is .failed guaranteed to be delivered at most once during the lifetime of an instance?
If the object enters .failed, can I call cancel() on that same instance? If so, will the state-update handler subsequently receive .cancelled?
Is .cancelled guaranteed to be delivered at most once per instance, even if cancel() is called multiple times?
If the object is in the .waiting state and I call cancel(), causing it to transition to .cancelled, is it guaranteed that .failed will not subsequently be delivered for that instance? Since there is no transition from .cancelled -> .failed?
- What happens when stateUpdateHandler is replaced while callbacks are pending?
Consider the following scenario:
I create an NWConnection and assign a stateUpdateHandler (Handler A).
The connection's state changes, and a callback for Handler A is enqueued on the connection's associated DispatchQueue.
Before that queued callback executes, I replace stateUpdateHandler with Handler B.
If the callback for Handler A was already enqueued before the handler was replaced, will Handler A still be invoked? My understanding is Yes, since it was already queued.
If the object is in the .waiting state and I call cancel(), causing it to transition to .cancelled, is it guaranteed that .failed will not subsequently be delivered for that instance
Can the same state notification be delivered to both Handler A and Handler B, or is it delivered to only one of them i.e., Handler A, since during the state-change Handler A was the one as stateUpdateHandler?
Thanks!
Is .failed guaranteed to be delivered at most once during the lifetime of an instance?
Yes.
If the object enters .failed, can I call cancel() on that same instance?
Yes.
If so, will the state-update handler subsequently receive .cancelled?
Yes.
Is .cancelled guaranteed to be delivered at most once per instance, even if cancel() is called multiple times?
Yes.
If the object is in the .waiting state and I call cancel(), causing it to transition to .cancelled, is it guaranteed that .failed will not subsequently be delivered for that instance?
Yes, but you have to be careful here. Calls to your state update handler are serialised and it’s possible that the .failed(_:) could be delivered before you cancellation takes effect.
- What happens when
stateUpdateHandleris replaced while callbacks are pending?
My advice is that you avoid writing code that does that. Rather:
- Set your handlers before you start you connection.
- Avoid changing them at all…
- Except to
nilthem out as you cancel the connection.
If you want to do this sort of switcheroo, do it inside your handler, in code that you control, and for which you can guarantee the semantics.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
