timeout
[1/20] from: ptretter:norcom2000 at: 9-Apr-2001 11:34
How do I set the timeouts for port openings? For example:
open ftp://ftp.microsoft.com is fast but if I spelled it wrong it would take some time
to before it timeouts - such as open ftp://ftp.microsofy.com.
Paul Tretter
[2/20] from: holger:rebol at: 9-Apr-2001 10:32
On Mon, Apr 09, 2001 at 11:34:48AM -0500, Paul Tretter wrote:
> How do I set the timeouts for port openings? For example:
>
> open ftp://ftp.microsoft.com is fast but if I spelled it wrong it would take some time
to before it timeouts - such as open ftp://ftp.microsofy.com.
At the moment you can only set read timeouts (system/schemes/default/timeout). There
are a lot
of other situations in which networking causes delays. In the example above it is the
DNS lookup. Depending on the operating system it is not always possible to adjust the
delay,
i.e. sometimes it is handled within the OS.
For DNS lookups the only way to change timeouts is by using async DNS lookups
(dns:///async), but that only works on some operating systems.
--
Holger Kruse
[holger--rebol--com]
[3/20] from: ptretter:charter at: 9-Apr-2001 13:06
Cool Holger, I actually found that timeout after I sent the email. My new
question is that there is no way really to use numbers smaller than "1" for
that value is there? Also I noticed timeout values in the protocol
specific schemes such as ftp. What are these values used for.
Paul Tretter
[4/20] from: holger:rebol at: 9-Apr-2001 11:29
On Mon, Apr 09, 2001 at 01:06:08PM -0500, Paul Tretter wrote:
> Cool Holger, I actually found that timeout after I sent the email. My new
> question is that there is no way really to use numbers smaller than "1" for
> that value is there? Also I noticed timeout values in the protocol
> specific schemes such as ftp. What are these values used for.
You can set timeouts to a time! value, e.g. 0:0.5 for half a second.
Protocol-specific timeouts have precedence over the default timeout.
--
Holger Kruse
[holger--rebol--com]
[5/20] from: ptretter:norcom2000 at: 9-Apr-2001 17:01
Cool thanks - didnt know that. Will help greatly.
Paul Tretter
[6/20] from: ptretter:norcom2000 at: 9-Apr-2001 18:02
Actually this seems quite buggy on win platform (win2k here). I get a much
longer timeout period with "0:0.5" than I get with "1".
Paul Tretter
[7/20] from: holger:rebol at: 9-Apr-2001 17:10
On Mon, Apr 09, 2001 at 06:02:50PM -0500, Paul Tretter wrote:
> Actually this seems quite buggy on win platform (win2k here). I get a much
> longer timeout period with "0:0.5" than I get with "1".
Cannot be :). Keep in mind that as I mentioned before the timeout only
applies to individual reads, not to the other parts of communication,
such as DNS lookup, connecting to a site, sending a request to a site
etc.
--
Holger Kruse
[holger--rebol--com]
[8/20] from: ptretter:norcom2000 at: 10-Apr-2001 7:17
Thanks for the comments. I do know that the setting in
system/schemes/default/timeout does effect the timing of the process. Not
sure in detail what the timeout is actually manipulating (RT folks - helps
us out here). But the purpose of the script at this point was just to get
an indea on where to start with /View since I will eventually expand this to
be more similiar to the "SHIELDS UP" service provided by Steve Gibson at
Gibson Research grc.com. I think a good book for Elan might be to document
a reference of all the items such as this timeout item and gives us the
purpose and use of these items.
Paul Tretter
[9/20] from: athena:pop3-dfw:myfirstlink at: 10-Apr-2001 6:15
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. Others may ignore the request in which case the TCP stack
timeout controls how long it will take to complete. UDP is another
story. Obviously, where actual communication occurs, network time
contributes to how long the open request takes.
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. 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.
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.
Harold Grovesteen
Paul Tretter wrote:
[10/20] 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
<<quoted lines omitted: 5>>
> 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]
[11/20] from: holger:rebol at: 10-Apr-2001 6:44
On Tue, Apr 10, 2001 at 07:17:21AM -0500, Paul Tretter wrote:
> Thanks for the comments. I do know that the setting in
> system/schemes/default/timeout does effect the timing of the process. Not
> sure in detail what the timeout is actually manipulating (RT folks - helps
> us out here).
It is the maximum time between subsequent activities on the socket.
--
Holger Kruse
[holger--rebol--com]
[12/20] from: ptretter:charter at: 9-Apr-2001 20:56
here is an example script thats a port scanner (my intent is to make it much
more than that). Right now it has system/schemes/default/timeout: 1
However if you change it to 0:0.5 it responds much slower - why?
REBOL [
Title: "Port Scanner"
Author: "Paul Tretter"
]
system/schemes/default/timeout: 1
host: Ask "Enter ip address or fully qualified hostname
ex.(ftp.microsoft.com) "
port: to-integer Ask "Enter start port "
End: to-integer Ask "Enter End port "
newhost: rejoin [tcp:// host]
while [(end + 1) <> port][
getports: rejoin [newhost ":" port]
either error? error: try [open getports][
disarm error
print ["nothing at port " port]
][
print ["port " port " available"]
]
port: port + 1
]
halt
[13/20] from: holger:rebol at: 9-Apr-2001 20:07
On Mon, Apr 09, 2001 at 08:56:28PM -0500, Paul Tretter wrote:
> here is an example script thats a port scanner (my intent is to make it much
> more than that). Right now it has system/schemes/default/timeout: 1
You are right, sorry. The timeout value in ports currently only supports
integers. For Core 2.5, that is. Will change in the future :)
--
Holger Kruse
[holger--rebol--com]
[14/20] from: athena:pop3-dfw:myfirstlink at: 10-Apr-2001 22:36
Not true. The ICMP port unreachable message relates to whether and
application is accepting connections or not from the port. A TCP RST is
sent when an non SYN message is received for a non-existent TCP
connection on the receiving system. Two different situations in the TCP
finite state machine. Refer to the TCP RFC for details. The initial
SYN which is transmitted by this application says I want to make a new
connection. The connection is not yet established and therefore the TCP
RST can not possibly be sent. The TCP RST is only sent when a
non-initial SYN has been sent but the receiveing system does not have an
already open connection which should not occur in this situation. This
usually occurs when a pre-existing connection tries to communicate with
a system which for some reason has dropped the connection (application
failure or system restart).
Harold Grovesteen, CCNP
Holger Kruse wrote:
[15/20] from: holger:rebol at: 10-Apr-2001 21:55
On Tue, Apr 10, 2001 at 10:36:08PM -0500, Harold Grovesteen wrote:
> Not true.
Yes, it is :-). Check the sources (BSD e.g.) or just use tcpdump to watch what
happens.
> The ICMP port unreachable message relates to whether and
> application is accepting connections or not from the port. A TCP RST is
> sent when an non SYN message is received for a non-existent TCP
> connection on the receiving system.
A TCP RST is sent in lots of different situations. In the sources of the
(inofficial reference implementation) BSD 4.x this is triggered by a jump to
dropwithreset
within tcp_input(). "dropwithreset" is reached in many
situations, one of which is when the PCB search comes up empty, i.e. if no
listening socket on the specified address/port combination exists. Pretty
much all TCP/IP-enabled operating systems with the exception of Linux and
some embedded systems are based on BSD and inherit this behavior.
> Refer to the TCP RFC for details.
Yes, please do. RFC 793, 3.4, "Reset Generation" state 1: "If the connection
does not exist (CLOSED) then a reset is sent in response to any incoming
segment except another reset." ("CLOSED" in TCP terminology includes the case
of not having a listener on an address/port combination.)
Or check Stevens' TCP/IP Illustrated Vol 2, 28.2: "If the PCB was not found,
the input segment is dropped and an RST is sent as a reply. This is how TCP
handles SYNs that arrive for a server that doesn't exist, for example."
You are probably confusing TCP with UDP. UDP does not have connection semantics
or control packets of its own, and therefore falls back to ICMP for reporting
unreachable ports. TCP never causes "ICMP port unreachable" messages, except as
part of firewalling.
In any case, we are getting off topic here...
--
Holger Kruse
[holger--rebol--com]
[16/20] from: athena:pop3-dfw:myfirstlink at: 11-Apr-2001 8:58
I stand corrected. Thank you. RFC1122 also provides guidelines here.
I see a bit clearer the interaction between the application, TCP and IP
layers in this situation. Live and Learn!
Thank you again,
Harold Grovesteen
Holger Kruse wrote:
[17/20] from: rondon:andrade:uol at: 22-May-2001 8:05
Hi Everybody!
Well, I'm trying to access with HTTP some sites, but sometimes when they
have a lot of traffic, I get a network error "timeout".. I've already set
system/schemes/http/timeout: 0:30:0, but it still give an error with
timeout. I know, I can treat the error with "try ...", but what about the
timeout? I know that the link of the site I'm accessing is too slow, but If
I can get the information waiting in my IE, why using rebol, it can't hold
until get response ...
What's the timeout of IE/NS ? Would it be just to set the same timeout value
? Any clue ?
Thanks in Advance.
Rondon
[18/20] from: rondon:andrade:uol at: 22-May-2001 8:12
Hi Everybody!
Well, I'm trying to access with HTTP some sites, but sometimes when they
have a lot of traffic, I get a network error "timeout".. I've already set
system/schemes/http/timeout: 0:30:0, but it still give an error with
timeout. I know, I can treat the error with "try ...", but what about the
timeout? I know that the link of the site I'm accessing is too slow, but If
I can get the information waiting in my IE, why using rebol, it can't hold
until get response ...
I remember that it happens just in moments of high traffic.
What's the timeout of IE/NS ? Would it be just to set the same timeout value
? Any clue ?
Thanks in Advance.
Rondon
[19/20] from: rondon:andrade:uol at: 22-May-2001 15:11
Hi Everybody!
Sorry to bother you again.. But do you know how to solve the problem of
network timetout
error?
I've tried to set up new timeout values and it does not stay connected until
the value I set.
Do you any clues ?
Thanks in advance.
Rondon
[20/20] from: holger:rebol at: 22-May-2001 11:21
On Tue, May 22, 2001 at 08:12:32AM -0300, Rondon Andrade wrote:
> Hi Everybody!
> Well, I'm trying to access with HTTP some sites, but sometimes when they
<<quoted lines omitted: 4>>
> I can get the information waiting in my IE, why using rebol, it can't hold
> until get response ...
IE/NS have the same problem, but you don't see it because they simply try to
connect again if the first connection attempt fails. You can do the same thing
with REBOL.
There is not much else you can do. Usually this is caused by incorrectly
implemented workarounds for the SYN flood problem at the server, e.g. the
SYN cookie
scheme in some Linux versions. Under heavy load and in congested
networks this can cause TCP protocol violations in the 3-way TCP handshake
and can lead to timeouts at the client.
--
Holger Kruse
[holger--rebol--com]
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted