Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

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