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

[Mike Bonner]

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 <dsc at swcp.com> 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 <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
> >>
> > _______________________________________________
> > 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
>