source of a socket error message

[Douglas Ruisaard]

I *REALLY* appreciate the responses!  Beyond where (exactly) LC actually generates this message (I can see it in the LC executable in a large "look-up" table), I was hoping I could find it in a "read-able" script so I could trace the logic.

I'm trying NOT to exceed the scope of a subject related to this list-group and do not expect an actual solution to the issue.  By the way, there REALLY are 5,000+ installations of the remote LC app spread all across the province of Ontario... which, if you're unfamiliar with Canada is worth look at on a map to see the geographic distribution "scope".  It's taken over 10 years to implement that number of sites for the very large medical information provider I contract to.

That's why Bob's "heebie jeebies" comment is SO relevant!  But, to wrap up the "story"... my ultimate goal, in regard to this request, is to avoid "allowing" my customer to dismiss the issues (which occur on a regular but erratic basis) as a remote ISP/DNS cause ... if at all possible.  I'd like them to exhaust any in-house possibilities or causes before they (and I) concede that the events are beyond their control or influence.  By eliminating any possibility that the connection issues are LC-related, I can honestly push the problem back into the customer's lap.

I will request that they now "map" even some of the affected sites with regard to the remote sites' ISP's.  One other relevant piece of information.. when this situation occurs... only a small percentage of the connecting sites are affected.  In the last incident (a few days ago)... over 1,000 site successfully connected in the same 1 hour time-window as the 50 site which exhibited the error!  "Normally" (however), any 1 hour period of time has fewer than 5 sites which may have encounter this "can't resolve hostname" error... THAT's acceptable... 50 in 1 hour is NOT.

Again.. thanks so much ... as always I can depend on this group for a very informed and helpful set of responses.

Cheers!

Douglas Ruisaard
Trilogy Software
(250) 573-3935

> Date: Thu, 18 Jul 2019 15:37:23 +0000
> From: Bob Sneidar <bobsneidar at iotecdigital.com>
> To: How to use LiveCode <use-livecode at lists.runrev.com>
> Subject: Re: source of a socket error message
> Message-ID: <B603C040-8B0A-4548-8849-6D0294D1E1E8 at iotecdigital.com>
> Content-Type: text/plain; charset="us-ascii"
> 
> Not to put too fine a point on it but that gives me the heebie jeebies. There are ~5000 instances of
> the app. The dev can't control what the ISP of the server does, or if the hosting company goes out of
> business or gets bought out. Although rare, an ISP CAN alter the public IP subnet. It happened to me
> twice, a long time ago admittedly. Once for my homw ISP and one for a business ISP.
> 
> Using IP addresses is like using pointers in app development.
> 
> Bob S
> 
> 
> > On Jul 18, 2019, at 08:11 , dsc--- via use-livecode <use-livecode at lists.runrev.com> wrote:
> >
> > If you have control over the server and know the IP address will never change, you can skip the name
> lookup and just use the IP address.
> 
> 
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Thu, 18 Jul 2019 08:46:05 -0700
> From: Mark Wieder <ahsoftware at sonic.net>
> To: dsc--- via use-livecode <use-livecode at lists.runrev.com>
> Subject: Re: source of a socket error message
> Message-ID: <c9947805-d548-71d0-fd97-e9a3d7d6f925 at sonic.net>
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> On 7/18/19 8:11 AM, dsc--- via use-livecode wrote:
> > Also...
> >
> > If you have control of these sites and even if you use an ISP DNS service, you can add a secondary
> DNS IP address, perhaps a public recursive name server such as the Google Public DNS (8.8.8.8).  This
> will add a robustness without upgrading the software.
> >
> > If you don't manage those, you can you can upgrade the software to access a public name server
> directly with TLS, or use DNS over HTTPS. DNS over HTTPS is not as easy as it sounds, but should be
> doable. It is available without filtering from Google, Quad9 (use 9.9.9.10 for no filtering), or (if
> you don't use Cisco) Cloudflare 1.1.1.1.
> 
> DoH is getting easier to use all the time but still hasn't reached a level of plug-and-play
> availability. I set up a Raspberry pi on our LAN running a DoH service that hooks into Cloudflare on
> the backend and it's transparent and painless (if I'm allowed to mix metaphors).
> 
> Normally I'd agree with you on this, but what has me worried about the problem situation is
> "occasionally I get a "mass" of errors (50 or 60) within a 1 hour period of time from a large variety
> of different external sites". So it's not a DNS outage from a single location,
> 
> That said, last week I had a maddeningly similar thing occur here... I suddenly couldn't resolve
> addresses, and worse, couldn't even ping numeric addresses outside our ISP's gateway. After working
> with our ISP's tech support, rebooting our router got us a new IP address in the router's routing
> table and that fixed the problem. Possibly some problem with fiber DHCP refreshing, and I hesitate to
> suggest that something similar is at work here, but strange things happen.
> 
> >
> > You might want to add some network diagnostics, where you can log or otherwise report the results.
> This will help solidify your analysis.
> >
> > If you have control over the server and know the IP address will never change, you can skip the name
> lookup and just use the IP address.
> 
> That or your excellent suggestion of cacheing the address once it's originally resolved.
> 
> --
>   Mark Wieder
>   ahsoftware at gmail.com
>