Prev: Class "COM" not found
Next: SQL Queries
From: Phpster on 19 Dec 2009 21:36 The next way to handle this might be to code an AIR app. Then it's a simple js trap to see if connectivity exists. Bastien Sent from my iPod On Dec 19, 2009, at 7:13 PM, "Angus Mann" <angusmann(a)pobox.com> wrote: > Hi all. > > I'w writing a PHP app that is designed to run over a LAN, so > internet connection for the server is not really essential. Some > users may deliberately not connect it to the internet as a security > precaution. > > But I'd like the app to make use of an internet connection if it > exists to check for an update, and notify the user. > > Is there a simple way for a PHP script to check if it has an > internet connection? > > I thought of this : > > if(fsockopen("www.google.com", 80)){ > // we are connected > } > > Is this OK or is there something better for the purpose? > > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php >
From: Andy Shellam on 20 Dec 2009 04:32 > > I think the only way to detect if it can connect to the Internet is to > see if you can grab a file from somewhere on the Internet. I'd hazard a > guess that when operating systems are able to tell you they can "connect > to the Internet" they are actually saying they can ping a predetermined > remote host. I think checking if PHP can grab a remote file with Curl > would be sufficient in this case. Personally, I'd do a DNS lookup - even connecting to a server is a lot more overhead than a simple DNS request. You could force the DNS server to be one external to your network - e.g. dig @a.root-servers.net www.google.co.uk. If the dig command fails, you're not connected. Or just try and get the update anyway - if the download fails, you're not connected (or there's something wrong with the update server.)
From: LinuxManMikeC on 20 Dec 2009 05:00 On Sun, Dec 20, 2009 at 2:32 AM, Andy Shellam <andy-lists(a)networkmail.eu> wrote: >> >> I think the only way to detect if it can connect to the Internet is to >> see if you can grab a file from somewhere on the Internet. I'd hazard a >> guess that when operating systems are able to tell you they can "connect >> to the Internet" they are actually saying they can ping a predetermined >> remote host. I think checking if PHP can grab a remote file with Curl >> would be sufficient in this case. > > Personally, I'd do a DNS lookup - even connecting to a server is a lot more overhead than a simple DNS request. Â You could force the DNS server to be one external to your network - e.g. dig @a.root-servers.net www.google.co.uk. Â If the dig command fails, you're not connected. > > Or just try and get the update anyway - if the download fails, you're not connected (or there's something wrong with the update server.) By attempting to connect you will implicitly query DNS (which itself is a connection to server). If you're not online you won't be able to resolve the domain name. Hence no overhead of actually connecting, because that won't even start to happen until the hostname is resolved to an IP. If it happens to resolve from some cache, oh well. Not like its that much overhead. You're nitpicking over the number of packets it takes to SYN/ACK.
From: Andy Shellam on 20 Dec 2009 14:29 > By attempting to connect you will implicitly query DNS (which itself > is a connection to server). No it's not - it's putting out a packet targeted at an IP address and hoping a server will answer - hence why multi-cast works for DNS because you're not directly connecting to a specified server, like you do with TCP/IP. I believe it's similar for ping which is why it's used so commonly in monitoring applications. > If you're not online you won't be able to > resolve the domain name. Exactly - so if all the OP wanted to check for was a working Internet connection, then DNS is a better way to go IMHO. > Hence no overhead of actually connecting, > because that won't even start to happen until the hostname is resolved > to an IP. If it happens to resolve from some cache, oh well. Not > like its that much overhead. You're nitpicking over the number of > packets it takes to SYN/ACK. Yep and if it's running inside a LAN with x number of computers all doing the same thing, that mounts up to a lot of unnecessary traffic - I've seen it.
From: "Bob McConnell" on 21 Dec 2009 09:05
From: Andy Shellam >> By attempting to connect you will implicitly query DNS (which itself >> is a connection to server). > > No it's not - it's putting out a packet targeted at an IP address > and hoping a server will answer - hence why multi-cast works for > DNS because you're not directly connecting to a specified server, > like you do with TCP/IP. I believe it's similar for ping which is > why it's used so commonly in monitoring applications. > > > If you're not online you won't be able to >> resolve the domain name. > > Exactly - so if all the OP wanted to check for was a working > Internet connection, then DNS is a better way to go IMHO. Both at home and at work there are caching DNS on the LAN. So a DNS request may come back with a valid IP address when the WAN connection is down. I still won't be able to connect to the remote site. Bob McConnell |