This is a 'bucket' error used to trap a wide range of problems.
We try to trap more specific errors and report them under a different error
number. If we can not trap a specific error, it gets reported as a 002 error.
The 'Status Note' you see on your CheckUpDown account for the error often gives
a valuable clue as to why the error occurred.
There are many types of 002 errors, most of which reflect a
low-level communications problem which your Web browser would simply report as
'unavailable'. 002 errors can be difficult to analyse precisely because they
occur at a relatively low level (socket creation) in the IP communications
hierarchy. They can also be highly transient. For example a surge in IP traffic
somewhere between our computer and yours can easily cause a time out
condition.
Each socket connection is for a specific IP port number. This is
typically 80 - the 'well known port number' for the HTTP protocol. You may
specify a different port number e.g. if your URL is
http://www.mysite.com:8080 then the port number is 8080. Your Web server
must be listening on this port number. If not, then we may receive an 002
error. In this case, the 'Status Note' for the error typically contains a
'connect' message.
The IP address for your Web site may change. For example you may
switch your Web site from one ISP to another or switch your Web site from one
computer to another on an internal LAN. You may also change the IP port number
which your Web server listens on. So there is now a different IP address for
your IP name. This new information is propagated out over the Internet to a
large number of DNSs, which takes time. It is possible for one DNS to return an
obsolete IP address - one for a computer that no longer recognises your IP
name. In this case the computer may simply fail to respond and the socket
connection fails. So a recent change of IP address may cause an 002 error.
IP connections over the Internet take time - there are
inevitable delays simply because of the size and complexity of the Internet
itself. So we can not wait indefinitely for the socket to be created
successfully. On our internal checks, we set a 20-second limit for the creation
of a usable socket. This 20 seconds is fairly generous - a user accessing your
Web site through a browser typically gives up long before 20 seconds have
elapsed.
The IP address we use may be completely valid, but your Web
server simply fails to respond within the 20-second limit. In other words, the
DNS provides the correct IP address for the computer which hosts your Web site,
but the Web server on that computer is unable to respond quickly enough. It may
simply be too busy dealing with other HTTP requests, or it may be down
altogether, or it may be listening on a different port. Or there may be some
problem with the general configuration of computers dealing with IP traffic at
your computer location, so your Web server simply never receives the socket
connection request at all. Any of these conditions mean that the socket
connection request from our CheckUpDown robot goes into an IP 'black hole' - no
response ever comes back, so CheckUpDown reports a 002 error which 'timed out'.
Or your Web server may respond partially if heavily loaded, so CheckUpDown
reports a 002 error with a 'connection refused' or similar description.
Other conditions may also trigger an 002 error. For example,
your Web server may be up and running and we are trying to connect using a
valid IP address, but there is a network fault which prevents us from opening a
socket connection within 20 seconds. These other conditions are relatively
unlikely.
We are confident that 002 errors you see on your CheckUpDown
account do indeed represent 'down' time i.e. if we get an 002 error then it is
highly likely that other Internet users would have got some kind of error
reported to their browser at that time, or simply given up and surfed off
somewhere else. So 002 errors can not be ignored.
If you see a lot of 002 errors, the first thing you can do is
check that your Web server is indeed up and responding within an acceptable
period of time. You can do this using a browser over the Internet to browse
your site. Note that you should be definitely be 'out on the Internet' when you
do this - simply browsing your site over a local (LAN) connection is *not* a
satisfactory check. If your Web server responds promptly (in well under 20
seconds), then it is likely that the 002 error represents a 'spike' of some
kind. To analyse this adequately requires good system logs - primarily on the
computer which hosts your Web server and on all other computers which sit
between that computer and the Internet itself. Examining these logs, and making
sense of them, can be a lot of work.
We suggest you contact us for further discussion (email
preferred) if you see persistent 002 errors.