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: Andreas Fink <email@hidden>
- Date: Wed, 10 Aug 2011 06:58:33 +0200
Am 09.08.2011 um 23:34 schrieb Jens Alfke:
> So, iOS closes all of an app’s open sockets when the app goes into the background. Is there any way to get local loopback sockets (i.e. those bound to 0.0.0.0) to not close?
Why is this a problem if you use HTTP? HTTP is stateless so you can reconnect anytime.
And why don't you bind to 127.0.0.1? Binding to 0.0.0.0 means all interfaces which means it can be accessed over wifi or 3G/EDGE/GPRS which might not be intentionally. In other words, using connecting to 127.0.0.1 makes it work in flight mode.
>
> This is proving problematic for CouchDB, which fundamentally has a client/server architecture based on HTTP. We’re running it in iOS by having the server code open a TCP listener socket bound to 0.0.0.0; the client code can then construct a URL from this and talk to the server using NSURLConnection.
The listener can simply rerun the bind/accept when waking up. Shouldn't be too difficult to deal with.
>
> (Yes, this is a bit of a kludge. In the long run we could switch to using some other mechanism, but it would be a big architectural change since HTTP is pretty fundamental to the way CouchDB works.)
>
> Problems this causes are
> - 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.)
You can avoid this by using a fixed port number.
> - 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.
The simplest thing is the client retrying if it gets no connection or to set the timeout long enough so the server for sure is started (or both)
> - 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.)
If you put the app to sleep it might also very well got killed. You have to deal with this anyway.
>
> We can solve these, but it would be so much easier if we could somehow keep that listener socket open.
>
> —Jens _______________________________________________
> 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
_______________________________________________
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