Re: source of a socket error message
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 + > From: Bob Sneidar > To: How to use LiveCode > Subject: Re: source of a socket error message > Message-ID: > 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 > > 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 > To: dsc--- via use-livecode > Subject: Re: source of a socket error message > Message-ID: > 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
Re: source of a socket error message
It might be we are overcomplicating things. Maybe this just needs a support note to check the Internet connection. I am having a little trouble picturing the situation here. And like you, I wonder about the description. Since one city was mentioned, I thought there was a possibility of a single ISP having trouble with DNS. I can't tell if this is WAN or Internet, controlled sites or customer devices, ... Filtering... Another thing I thought about is filtering. I have seen evil filtering based on the URL that returns an IP address that returns a page with ads based on the contents of the URL. That would not return an error, but could mess up code trying to parse the result. I suppose that a filtering name server might return a lookup error for either a URL or an IP. The latter is goofy, but if that happens, bad neighbors could cause a loss of name service for the app's server. Or if the URL is accidentally, temporarily or maliciously put on Santa's naughty list for an hour, DNS for it might be unavailable. Quad9 (9.9.9.9) will reply with a NXDOMAIN (non-existent domain) if a site is blocked. The solution might be a support note to avoid filtering if it is not otherwise needed. (Long ago, before we had our own LiveCode function, I made a small DNS client library. About the same time I got a new DSL router. The library was inconsistent in getting a lookup error. I was frustrated trying to debug this, but I figured it out. At boot, the router kept changing the name service IP address to one that pointed a site that returned an IP that generated ads, even though I had saved a different IP. I don't remember how I fixed that.) > On Jul 18, 2019, at 9:46 AM, Mark Wieder via use-livecode > wrote: > > 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 > ahsoftw...@gmail.com > > ___ > 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
Re: source of a socket error message
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 ahsoftw...@gmail.com ___ 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
Re: source of a socket error message
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 > 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. ___ 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
Re: source of a socket error message
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 > 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 >> 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
Re: source of a socket error message
That answer is probably bang on ...and a solution to top it off. * slow clap * On Wed, Jul 17, 2019 at 9: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
Re: source of a socket error message
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 > 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
source of a socket error message
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
