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. 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. > On Jul 17, 2019, at 7:51 PM, Dar Scott via use-livecode > <use-livecode@lists.runrev.com> wrote: > > This is very likely a loss of network availability and of that a loss of > Internet availability. > > The library will first look up the URI to get an IP address. The IP address > is used to make a connection to the server. The computer has (or can get) an > IP address to use for making that look up. Since that this the first > operation, a loss of Internet will show up with that error. > > If you are sure there is access to the Internet, then it might be that the > DNS server is down. That seems unlikely, but possible. If the server IP is > fixed, then use a cached version of the IP. Use hostNameToAddress() to get > the IP address, save that on success, use the saved address on failure. > > >> On Jul 17, 2019, at 6:27 PM, Douglas Ruisaard via use-livecode >> <use-livecode@lists.runrev.com> wrote: >> >> Let me start this off by stating that the information I am seeking IS NOT >> due to an *issue* with LC. Hopefully, I can make it clear why I am asking >> for assistance from this group in regard to the situation I am trying to >> deal with and why I need the LC expertise of this group as a resource. >> >> In a portion of a large application, which has been distributed to a large >> number (5,000+) of remote/external sites, I have a call to a TCP socket: >> >> on OpenCard >> ... >> put ftp_server & ":" & tcp_port into temp1 >> open socket to temp1 with message "NewConnection" >> wait for messages >> end OpenCard >> >> Then there are a variety of "call-backs" based on when happens after I open >> the socket. One of these call-backs is "socketError": >> >> on socketError theID, theError >> close socket theID >> do_log " " & sftp_account && "file: " & "There is a problem with the TCP >> connection: " & theError, "connect", 3 >> ... >> end socketError >> >> This works PERFECTLY 99.999% of the time. However, 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 (I get all of the remote site's logs) >> ... i.e. many different sites connecting in from many different locations >> around the province of Ontario ... a very large place! >> >> The error returned is: "can't resolve hostname"... returned in the >> "theError" parameter of the socketError function. >> >> Here's where I need help. I need to find out, with as great a level of >> detail as possible, EXACTLY what (from LC's "point-of-view") triggers this >> error, what part(s) of the LC engine are involved with generating this error >> and if there is more than the obvious cause of the remote site's DNS server >> (via their ISP or internal server(s)) not being able to "see" the hostname >> that could produce this error. >> >> Although this "error" appears to be "common" from a variety of sources (none >> of which are written in LC, as far as I can tell)... I cannot find any >> "standard" by which a DNS generates this specific message. NSLOOKUP would >> be the closest candidate but even it doesn't produce this specific error of >> being "unable to resolve the hostname"... so that leaves LC with the >> responsibility of the content of the error. >> >> I REALLY want to emphasize that, as far as I am concerned, this is not a >> problem with LC, in any manner... but I need to find out where and why LC >> generates this message. >> >> I am not sure what or where to search for this error or what generates it >> from with the LC components but if someone could help me "find" a starting >> point, I should be able to reverse-engineer the logic. >> >> The overall situation is fairly complex but I'd be very open to providing >> more details if anyone feels it is warranted. >> >> Whatever help could be provided will be very, very appreciated! >> >> Douglas Ruisaard >> Trilogy Software >> (250) 573-3935 >> >> >> >> >> _______________________________________________ >> use-livecode mailing list >> use-livecode@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@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@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
