Network framework and background tasks

I'm working on an MQTT client for Apple platforms (macOS, iOS, and possibly tvOS and watchOS).

The story here varies by platform:

• For macOS, it’s possible to run indefinitely in the background.

• watchOS has significantly more restrictions than iOS. See TN3135 Low-level networking on watchOS for the details.

• tvOS generally follows iOS, except that one of the common workarounds, push notifications, is not available there.

The rest of my response focuses on iOS (including iPadOS).

it seems that my best bet is to use a long-running background process with while setting up the connection. Does that sound like the right approach?

No. Quoting iOS Background Execution Limits:

To request extended background execution time, typically delivered overnight when the user is asleep, use BGProcessingTaskRequest.

So, unless you just happen to want to run these connections at some randomish time during the middle of the night (-: this is unlikely to be useful to you.

I currently have a working BSD socket. I'm not sure if it is necessary to switch to the Network Framework to have the background task working, but I'm open to switching if it's necessary.

Network framework doesn’t change this situation. BSD Sockets and Network framework are both low-level networking APIs, and they behave similarly when in comes to networking in the background.

As to what you should do, it very much depends on the specifics of your MQTT client. In many cases the best path forward is to offload this work to a server, and have it generate push notifications to notify the iPhone user of relevant conditions.

the link to "WWDC 2020 Session 10063 Background Execution Demystified" … is broken. Is there a way to access the content there?

That video is no longer available from Apple )-: I haven’t fixed the link because a) sometimes I’m able to ‘resurrect’ important videos like this one, and b) the details in the link make it easier to find related non-Apple resources.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hi Quinn,

Thank you so much for the response. I have some follow-up questions about network suspension and resumption (or socket reclaim?).

From Networking and Multitasking

All iOS networking APIs are ultimately implemented in terms of the BSD Sockets API

From this statement, I got the impression that the Apple Network Framework uses BSD Sockets for its underlying implementation. However, in your reply from iOS/tvOS seem to reuse closed sockets, you mentioned

this is all Network framework and thus there are no sockets in play

I'm a little confused about what does the "no sockets" means here.

Here’s my understanding of the reclaim mechanism for Listening Sockets—please correct me if I'm wrong:

• If the resource is reclaimed, to resume the app properly, the app needs to reconfigure the socket, perform the handshakes, and re-established the connection.
• If the resource is not reclaimed yet, the socket is put in idle while the app is in the background. When the socket is resumed, the app can continue processing the requests. (Of course, as the socket was idled, the requests might fail or time out, and the app would need to handle these cases.)

One peculiar thing I’ve noticed is that the "reclaim" behavior seems inconsistent. While testing with the Network framework using the following steps from Networking and Multitasking

1. putting your app in the background
2. ensuring that the app is suspended
3. locking the screen

Sometimes when the socket is reclaimed, the Network framework sends out a TCP FIN packet and closes the connection, and other times it does not. Does this mean the behavior is undefined for reclaim, or am I doing something wrong?

Additionally, I observed the same results using my own BSD socket implementation and the Apple Network framework (the test app is based on the SWIFT-NIO library). It seems they behave similarly. As I planed to move to the Network Framework for TLS1.3 support, are there any features or behaviors that the Network Framework provides that I should be aware of?

Thanks again for your help!

From this statement, I got the impression that the Apple Network Framework uses BSD Sockets for its underlying implementation.

This has changed in recent years [1], where Apple has been rolling out a user-space networking stack. Network framework will use either BSD Sockets or the user-space networking stack depending on the exact circumstances [2].

As to the behaviour you’re seeing, the key thing to note in TN2277 is the phrase “becomes eligible for suspension”. As an app developer, you’re not notified when your app gets suspended. There is one obvious high-level factor here — your app won’t be suspended while it’s in the foreground — but after that things get complex. If your app runs in the background, you have to track whether your eligible for suspension or not. If your app can run in the background for many different reasons, that tracking gets rather complicated )-:

Once you have this sorted out, the next step is to decide what to do with your network constructs. For listeners (listening socket and NWListener) the answer is clear: Close them when you become eligible for suspension and re-open them when that’s no longer the case. This is the only sensible option because, if you get suspended but your connection isn’t defuncted [3], clients will connect but not receive any response.

For connections you get to make the tradeoff described in the Data Socket section of TN2277. If you leave the connection open, you have to accept that the actual on-the-wire behaviour is unspecified. If you just get suspended then the connection goes ‘deaf’. If you get suspended and the connection is defuncted, the remote peer sees the connection close.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] TN2277 is in the Documentation Archive for a reason: While most of the concepts are still accurate, a bunch of details have changed.

[2] We’ve recently been discussing this on this thread.

[3] This is one of those places where TN2277 could do with an update. I’ve started using “defuncted” in preference to “socket resource reclaimed” because a) it better maps to what you’ll see in the Darwin open source, and b) it works for both BSD Sockets and Network framework. It’s also less typing (-: