if you add the -v switch to what dar suggested (route -v get default) it returns the mac address for the default gateway which you could store as a location. If mac address is <address...>...
On Fri, Jun 14, 2013 at 12:10 PM, Dar Scott <[email protected]> wrote: > Just wondering. A thought. > > Why not try to open the db? Perhaps in the background. If you have an > image indicating the db selected, it can have some sort of busy look before > one is selected. Or simply use the local db if the remote db is not > available at the time of a save. > > If that works, use it. If it fails, go to the fallback. You can even > keeping trying to open the db. > > By the time the first save is needed, perhaps the decision as to what db > to use is already done. > > Dar > > > On Jun 14, 2013, at 8:03 AM, Dr. Hawkins wrote: > > > On Thu, Jun 13, 2013 at 4:53 PM, Daryl Williams > > <[email protected]> wrote: > >> If I am understanding correctly you might try using either the netstat > or > >> route commands to find your default gateway, and if there is none then > save > >> things to the local database. > > > > doesn't give me the timeout issues again--if the laptop is opened in > > the new location, won't the old router still be on the list, and need > > to be checked? > > > > > >> The problem with this approach will be determining the right syntax to > use > >> for the current platform your code is running on. Unfortunately the > syntax > >> is a bit different from windows to os x to linux, but they will all > report > >> on the routing tables, including the default router, at which point you > just > >> need to parse the command output (again different from platform to > platform) > >> an take the appropriate action. The output can be rather detailed and > >> verbose, but should not too hard to parse. > > > > This isn't too big of a problem--I already have OS based switches > > lying around the code. I guess I'll have to buy a windows machine for > > the first time in my life to do some testing of that code on, though . > > . . > > > > After going through all of these, it sounds like the controlled > > timeout is the way to go--when this stack comes to the front, it does > > a check. If it thinks it's not on the VPN already, it just continues > > to use the local cache db--unless it sees "something"? new telling it > > that the VPN is back, in which case it tries. If it thinks it should > > be on VPN, it pings for good measure with the 1s/50ms timeout. Hmm, > > this can be delayed until the first db write, too. So the only time > > the user gets hit for the whole second is when he actually changes > > from VPN to no VPN (blocked, no internet, whatever). > > > > Thank you to all. I now know more things I never expected to learn :) > > > > > > -- > > Dr. Richard E. Hawkins, Esq. > > (702) 508-8462 > > > > _______________________________________________ > > use-livecode mailing list > > [email protected] > > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > > http://lists.runrev.com/mailman/listinfo/use-livecode > > > _______________________________________________ > use-livecode mailing list > [email protected] > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > _______________________________________________ use-livecode mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
