Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!ucla-cs!zen!ucbvax!A.ISI.EDU!LYNCH From: LYNCH@A.ISI.EDU (Dan Lynch) Newsgroups: comp.protocols.tcp-ip Subject: Re: connection establish timeout query Message-ID: <8707041608.AA08157@ucbvax.Berkeley.EDU> Date: Sat, 4-Jul-87 11:46:42 EDT Article-I.D.: ucbvax.8707041608.AA08157 Posted: Sat Jul 4 11:46:42 1987 Date-Received: Sat, 4-Jul-87 20:09:01 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 37 Mike and David, You are asking a question that covers many sins. The usual numbers for "open connection" timeouts range from 30-120 seconds. If you are using numbers much smaller than these you wil see lots of timeouts. The problem of selcting the "right" timeout is a bit complex because of what you (the initiator) might be trying to accomplish. E.g., if it is a Telnet session then the user is a human and can abort the (presumably hopeless) connection attempt by some local action (escape character or its functional equivalent on each system -- if you don't have the equivalent of an "interrupt now" initiated by the user from the keyboard, then...) so you may as well select a long timeout (2 minutes) and let the connection get established if at all possible. The same goes for FTP because it is user initiated. However, for mail (SMTP) things can get different. It is usually implemented as a background process that slurps over the file system looking for mail files to send out. If this SMTP process uses a long timeout and it runs into a bunch of mail for a dead site it has to get smart about what is (not) happening and not spend a lot of time waiting for a connection to the dead host. Thus a short timeout (30 seconds) might be in order. Big systems that do lots of mail have had to take more hurculean efforts in this arena, like running a number of SMTP mail processes in parallel and having some scheme for staying out of each other's way... The reason for along timeout can lie with many sources: the local host might not have a good retransmission timout for the original "open packet", the network(s) may be congested, or the remote host may take some time to set up a process to respond to the open request. Anyway, the major crime is to have client programs choosing a timeout that is smaller than the retransmission timeout that the TCP is using to detect a lost packet and try the open SYN again. Dan -------