The Chilkat components share the same underlying TCP/IP socket code, so when there’s a connectivity problem with a server (i.e. a TCP/IP connection cannot be established), you’ll see the following tell-tale phrases in your LastErrorText:
socket is not ready for writing
Connect function failed.
SocketError: WSAEWOULDBLOCK The socket would block.
You can verify connectivity with a server by opening a DOS command prompt and issuing a telnet to the remote server hostname:port.
For example:
telnet smtp.comcast.net 25
telnet smtp.gmail.com 25
You’ll get a response back like this:
220 comcast.net - Maillennium ESMTP/MULTIBOX rwcrmhc14 #51
or
220 mx.google.com ESMTP x56sm1026797pyg
You may then type "quit" followed by a carriage-return.
If there is no connectivity, your DOS command prompt will hang.
Here are other examples:
To telnet to a POP3 server:
telnet mail.chilkatsoft.com 110
You’ll get a response such as:
+OK AVG POP3 Proxy Server <18770.1173954239@xmail08.myhosting.com> 7.5.442/7.5.446 [268.18.11/721]
Type "quit" followed by a carriage-return.
To telnet to an IMAP server:
telnet imap.aol.com 143
the response looks something like this:
* OK imap-da08.mx.aol.com v52_r1.2 server ready
type "123 LOGOUT" followed by a carriage-return.
To telnet to an FTP server:
telnet ftp.microsoft.com 21
the response looks like:
220 Microsoft FTP Service
type "quit" followed by a carriage-return.
To telnet to an HTTP server:
telnet www.chilkatsoft.com 80
You’ll get a prompt back waiting for input. Type "quit" and press RETURN, and you’ll get this back:
HTTP/1.1 400 Bad Request
Content-Type: text/html
Date: Thu, 15 Mar 2007 10:30:02 GMT
Connection: close
Content-Length: 35
<h1>Bad Request (Invalid Verb)</h1>
Connection to host lost.
What happens if you try to telnet to a SSL port? (i.e. port 465 for SMTP, port 995 for POP3, port 993 for IMAP, port 990 for FTP, port 443 for HTTP)
You’ll get a prompt back without any text. If you start typing some garbage, like "asdfasdf…" you’ll see that the server just closes the connection and you get your DOS prompt back. It’s because you obviously weren’t sending what it expected to establish an SSL connection — but you did verify TCP/IP connectivity with the remote port.
