[REBOL] Re: timeout
From: holger:rebol at: 10-Apr-2001 6:42
On Tue, Apr 10, 2001 at 06:15:04AM -0500, Harold Grovesteen wrote:
> What you are attempting to do is open a TCP connection with a host on a
> specific port. The open request is initiated by the application
> (REBOL). Your TCP stack on your system actually handles the three way
> handshake to open the connection. Without an "open" timeout in the
> application, how long it takes for the open request to return to REBOL
> depends upon how the remote host responds (assuming the host is there)
> and timeout settings in the TCP stack. Some hosts will respond with an
> ICMP message indicating the port is not available and that should be
> very quick.
Actually the returned message in that case is not an ICMP message but
a TCP RST packet. ICMP is only returned for unavailable UDP (not TCP)
ports or routing problems in the network.
EVERY host is supposed to return TCP RST for unavailable ports, and
AFAIK every one does. You may still not receive it though if there is
a misconfigured firewall along the way that filters out TCP RSTs.
Some "consumer firewalls" unfortunately do that.
Regardless, if you are using Windows then the TCP RST may not help you
time out quickly, because most versions of Windows ignore incoming TCP RSTs
in most cases. (Don't ask why. This has to do with an ancient Windows
bug that sometimes caused invalid, forged TCP RSTs to be processed
by Windows, opening up a security hole, then in their "infinite wisdom"
Microsoft "fixed" the bug by just ignoring TCP RSTs all the time. Sigh...)
Other platforms do not have that problem though. That bug is the main
reason why most port scanners have their own timeouts.
> Others may ignore the request in which case the TCP stack
> timeout controls how long it will take to complete.
The real problem is that some client TCP/IP stacks ignore the TCP RST,
and that's when the application timeout takes over.
> There are also other ICMP messages the network may return which should
> terminate the open request. If REBOL passes these status messages back,
> assuming the TCP stack provides the reason for the failure to REBOL, you
> may want to look at the error to decide what to do.
ICMP errors are handled internally within the TCP stack and typically lead
to errors at the socket level, which then trigger an error in REBOL. At the
moment there is no way to check the specific error code. This is for a future
version, through the get-modes API.
> For example if the
> destination host is not available you don't need to go through a bunch
> of connection attempts, because none of them will succeed.
Yes, except that "host not available" is rare and if it occurs it is
usually transient, during a switch in dynamic routing.
> And hopefully you are doing this program for a noble purpose. Internet
> security people consider this type of program an indication of an
> attempt to breach security--a hacker attack in progress.
Yes. To make it very clear: depending on circumstances port-scanning
machines for which you are not administratively responsible can be a
criminal offense, and if prosecuted you may be sent to prison for it.
--
Holger Kruse
[holger--rebol--com]
