How do you determine when to use a LAN or a PUBLIC IP for connections?

Question

I'm using CFStreamCreatePairWithSocketToHost to connect to a server.
I have a public IP address of example.dyndns.com which points to my home office router.
On my home office router I forward port 1234 to a specific server (192.168.2.55)
That specific server runs a service offering data etc. to an iPhone app.
When I am away from the office I user CFStreamCreatePairWithSocketToHost to connect to example.dyndns.com.
No problem. Connection is made and everything runs lovely.
When I am in the office and on the lan however - the connection fails. Basically the packet goes out to the router, or to dyndns, u turns and comes back but doesn't get forwarded to 192.168.2.55.
If I change the code to point to 192.168.2.55 of course it runs fine, but then won't run when I am not on wifi in the office of course.
Is there an elegant way to deal with this? The router has no configurable options that I am able to identify to allow this u-turn type of traffic.
I could I suppose on startup test a connection, then in the stream event handler flip it from WAN to LAN IP on a failure. But that's very combersome - it doesn't easily allow an office user to drop in and out of the office wifi transparently (sure they could kill then restart the app but that's just plain ugly).
Any feedback/sample code people can offer would be appreciated. :-)
Dave.

Answer 1

Llessur999 wrote:
That is a reasonable approach. Without changing network configuration, I don't see an alternative. A few considerations:
Based on your experience, will the length of time to detect unreachability (a network timeout?) cause a usability issue?
Must you support a scenario where a user transitions LAN-to-WAN or WAN-to-LAN while using the app?
If this is used by a wide audience, will configuring the primary/fallback be straightforward?
I don't think there's a usability issue.
Yes. The app is designed for a brick/mortor location that essentially wants to drive the user to the location. The user has to ability to interact with specific hardware components at the location via server/port communications - some of which they can do while they are remote. While they are on location, they need to retain that ability to interact with local equipment even more. Users could be asked to not go on the location wifi of course but that just seems silly and an overall bad user experience.
The primary/fallback configuration should all be done within code (no user interaction). For example the WAN IP will always be X.X.X.X (be it Public IP or dyndns - makes no difference), while the LAN configuration will always know that the lan server it needs to communicate will always be at a specific LAN IP (192.168.x.x).
It would be  godsend to have some sort of API call (or class) that can accept a call to CFStreamCreatePairWithSocketToHost to a specific IP and on seeing that it's unreachable automatically try the secondary IP before returning a failure on the stream.