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!