Re: iOS: Keeping a loopback-only socket open across backgrounding?
Re: iOS: Keeping a loopback-only socket open across backgrounding?
- Subject: Re: iOS: Keeping a loopback-only socket open across backgrounding?
- From: "Quinn \"The Eskimo!\"" <email@hidden>
- Date: Wed, 10 Aug 2011 11:06:20 +0100
On 9 Aug 2011, at 22:34, Jens Alfke wrote:
> Is there any way to get local loopback sockets (i.e. those bound to 0.0.0.0) to not close?
Well, as Andreas pointed out, 0.0.0.0 is not a local loopback socket. You definitely want 127.0.0.1 here.
Regardless, there's no way to prevent sockets like this from potentially getting reclaimed while you're suspended in the background. The only sockets that aren't eligible for reclamation are those registered with VoIP, and a) you can't use that facility in non-VoIP apps, and b) that facility is restricted to connection sockets and can't be used for listening sockets.
> - When the listener socket re-opens it gets a different randomized port number, invalidating any URLs the client code is keeping around. (We can try to re-use the same port we got the first time, but that’s not guaranteed to succeed.)
Given SO_REUSEADDR and a sufficiently non-obvious port number, this seems like a relatively minor concern.
> - On returning to the foreground we have a race condition between client code that wants to start connections, and the server code that needs to re-open its listener. This needs some kind of synchronization to resolve.
Right. But you need this sort of synchronisation anyway, because you don't want to start new HTTP operations while you're in the background and on the way to being suspended.
> - Any HTTP transactions still in flight get invalidated too and have to be re-started somehow. (Or else we track them all, and delay going into the background until they complete.)
There are two ways to tackle this:
o Have you did-enter-background code cancel any running transaction synchronously, that is, before returning.
o Use the task completion API to associate background tasks with each running transaction. This makes your app not eligible for suspension while there are transactions in flight.
Both of these techniques require you to address the previous point, that is, to prevent new transactions from getting started from the point where did-enter-background returns to the point where will-enter-foreground starts.
S+E
--
Quinn "The Eskimo!" <http://www.apple.com/developer/>
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden