a *fast* check for whether another machine is on the local network?

[Mike Bonner]

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 <dsc at swcp.com> 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
> > <daryl at synergetic-data.com> 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
> > use-livecode at lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>