Ooops, your text could be twins. No wonder I got confused! Those D's and A's and R's all look alike.
On Fri, Jun 14, 2013 at 12:27 PM, Dar Scott <[email protected]> wrote: > That was Daryl. I suggested arp and ipconfig, but leaned toward ping and > maybe a socket test, but if it can be done in the background I like best a > direct test of connecting to the db. It is easy to get us confused; just > remember, I'm the round hirsute one. > > Dar > > > On Jun 14, 2013, at 12:16 PM, Mike Bonner wrote: > > > 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 > > > _______________________________________________ > 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
