On Aug 9, 2011, at 9:58 PM, Andreas Fink wrote: 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. You’re right, we only want to bind to the loopback interface (and not accept outside connections) so 127.0.0.1 is correct — I think 0.0.0.0 was left behind from the original server-centric config. I’ll need to fix that.
The listener can simply rerun the bind/accept when waking up. Shouldn't be too difficult to deal with.
Sure, at the 10,000-foot level it’s not difficult. It’s at the actual implementation level that it is. The core CouchDB code is cross-platform, written in Erlang, and was originally designed to run on servers and desktop-class machines. It has no notion of iOS backgrounding and does not expect that its listener socket is going to be forcibly closed by the OS. For extra fun, Erlang is running on a background thread and has some very unusual internal multitasking for its lightweight ‘processes’, which complicates attempts to talk to it from the main thread.
Again, I’m not saying this is months of work, just that it would be nice to avoid it if at all possible. We do have an engineer working on adapting the server code to handle this, but it’s tricky, and I wanted to explore whether there’s an easier solution of somehow keeping the listener open and avoiding the whole issue. (There’s also the unrelated issue that restarting the server on every wake-up is going to consume CPU, which might affect responsiveness. We don’t know the extent of that yet.)
You can avoid this by using a fixed port number.
Sure. Which specific number should we choose, to guarantee no conflict with anything else that might be running on the device, including audio sockets kept alive by a background VoIP or streaming-music app? And what do we do when the user has two apps that are both using Couchbase Mobile and want to bind to the same port number? (Yes, one of them will be suspended before the other one starts up, but that smells like a race condition just waiting to bite us.)
Architecturally, a good solution might be to switch from TCP sockets to Unix domain sockets, but that involves plumbing to be able to run HTTP requests over them. I’ve actually done that before (as part of the PubSub framework) and it was distinctly nontrivial, involving implementing a new NSURLConnection protocol.
—Jens |