Now that I've had a chance to spend some time trying to resolve the issue, I've got a working patch, so I thought I'd revisit the issue in case anybody was interested. I had to do two things to get CBL to function behind a proxy without external DNS access.
First, I had to modify the Reachability check in order to allow it to attempt the sync in the first place. I'm still undecided about what the correct thing to do is, so for the moment I've modified my copy to use "localhost" instead of the actual hostname of the remote server. I'm sure this is not optimal, but for the moment it allows the sync process to begin. Having put a bit more thought into it, I think the most correct thing to do is probably to check the proxy settings and use the proxy server for the reachability check instead of the sync host if one is defined, but the current check seems to work OK for now. Second, I had to change the way the CBLSocketChangeTracker class was configuring its proxy settings. The existing version looks like it should work correctly (it's hard to say given the sparse documentation of the CFHTTPStream stuff), but in my testing it does not correctly use the proxy. Instead, a DNS error is thrown upon attempting to connect. Passing in the entire settings dictionary returned from CFNetworkCopySystemProxySettings does work correctly for my use case, so it appears that it is not necessary to manually call CFNetworkCopyProxiesForURL to before passing in the settings. Patch here: https://github.com/boxer/couchbase-lite-ios/commit/8213589b779e5c41b0c490f7e8611b92ecd53463 We'll be testing this out in our customer's environment for the next few weeks, will report back if we run into any troubles with this solution. Don't know if it makes sense for the general case, but for us it resolved a complete inability to sync in this environment. Andrew, thanks again for your clarifications re: the reachability library. - Ian On May 17, 2014, at 11:08 AM, ian ragsdale <[email protected]> wrote: > Hmm, that's quite annoying, as their current sample code does that exact > thing: > https://developer.apple.com/Library/ios/samplecode/Reachability/Listings/Reachability_Reachability_m.html. > > Do you know _why_ he suggests not to do that? > > In this case, I think that not bringing up the radios is the exact thing I > WANT to accomplish. I'd suggest that CBL would probably NOT want to activate > the radios on it's own, but continue to check opportunistically. Making sure > that the radios up should be in charge of the app developer. I just would > like CBL to actually try to sync in an environment where Reachability says > no, but the existence of a proxy would allow it to work anyway. > > However, perhaps I'm thinking too generally. Perhaps a simple flag for the > library that tells it that I will handle checking for reachability or a > pluggable implementation for CBLReachability would make more sense? I'm sure > this is a bit of an esoteric case, and the problem I'm solving here will not > be one for the vast majority of people. Or I can just continue to make a > fork, I just prefer to share improvements back when possible. > > - Ian > > On May 16, 2014, at 10:53 PM, Andrew W. Donoho <[email protected]> > wrote: > >> >> On May 16, 2014, at 13:00 , Ian Ragsdale <[email protected]> wrote: >> >>> Sounds like the right thing to do is probably to do a check for >>> reachability on the zero address (as Apple does in their sample code for >>> reachabilityForInternetConnection), which should tell us if the radio is >>> active, and then if the radio is active, we can then make a request to >>> verify that the server is actually reachable. That way, we won't >>> unnecessarily tax the battery. >> >> >> >> Ian, >> >> I've had a long conversation with Kevin, the author of Apple's >> Reachability code. (BTW, I have substantially improved it and added a few >> features, such as touching the of hosts, etc.) I have a blog post to that >> effect. >> >> Kevin would advise you to not listen on 0.0.0.0. You should listen on >> the address of a real host that you really want to connect with. (The fact >> that your DNS is frakked is a different question.) Checking for reachability >> on any address tells you nothing if you haven't tried to bring up the >> radios. You must attempt to bring them up first and then check reachability. >> The check alone does nothing of value. >> >> >> >> Anon, >> Andrew >> ____________________________________ >> Andrew W. Donoho >> Donoho Design Group, L.L.C. >> [email protected], +1 (512) 666-7596, twitter.com/adonoho >> >> Download Retweever here: <http://Retweever.com> >> >> No risk, no art. >> No art, no reward. >> -- Seth Godin >> >> >> > -- You received this message because you are subscribed to the Google Groups "Couchbase Mobile" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/923BE3B3-7A78-471F-8C91-5CA4245B41C2%40gmail.com. For more options, visit https://groups.google.com/d/optout.
