----MESSAGE-BEGIN---- <1983011420380000> Date: 15 Jan 1983 0438-PST From: Henry W. Miller Subject: SMTP test To: tcp-ip cc: Miller, roode THIS IS THE BEGINNING OF THE TEST... We are having a few problems debugging our SMTP mailer and server. Would you please send this message back to us, along with any symptoms you might see. THIS IS GARBAGE TEXT TO TEST THE MAILER... ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 ;TEST LOWER CASE abcdefghijklmnopqrstuvwxyz0123456789 abcdefghijklmnopqrstuvwxyz0123456789 abcdefghijklmnopqrstuvwxyz0123456789 abcdefghijklmnopqrstuvwxyz0123456789 abcdefghijklmnopqrstuvwxyz0123456789 abcdefghijklmnopqrstuvwxyz0123456789 abcdefghijklmnopqrstuvwxyz0123456789 abcdefghijklmnopqrstuvwxyz0123456789 abcdefghijklmnopqrstuvwxyz0123456789 abcdefghijklmnopqrstuvwxyz0123456789 ;THE FOLLOWING IS A TEST TO SEE WHAT HAPPENS IF THE SENDER ;SENDS A . SEQUENCE IN THE MIDDLE OF TEXT BLAH, BLAH, . BLAH, BLAH... . Your obedient serpent, -HWM ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983011502530000> Date: 15 Jan 1983 1053-PST From: Henry W. Miller Subject: Re: Telnet negotiations in SMTP To: ROODE, TCP-IP cc: Postel at USC-ISIF, Taft%Parc at SANDIA, Miller In-Reply-To: Your message of 15-Jan-83 0706-PST As I read it, the SMTP spec had nothing to do with telnet terminals. When II was hacking it, I was just sending data down via the JCN, and it seemed happy as a pig in mud. However, the document in the IPTW is incomplete: t does not include all possible telnet options as an earlier one for NVT's did. -HWM ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983011506572200> Mail-from: ARPANET host SU-SCORE rcvd at 15-Jan-83 1942-PST Date: Sat 15 Jan 83 14:57:22-PST From: Mark Crispin Subject: Re: Telnet negotiations in SMTP To: ROODE@SRI-NIC.ARPA cc: TCP-IP@SRI-NIC.ARPA, Postel@USC-ISIF.ARPA, Taft%Parc@SANDIA.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) In-Reply-To: Your message of Sat 15 Jan 83 07:06:00-PST TELNET negotiations in SMTP are a bug. There is a bug in my SMTP in that when you send a QUIT command a Timing-Mark gets sent. Also, I think my SMTP answers TELNET negotiations if the user SMTP originates them. This is because there is no way to put a job on a TVT without disabling protocol. My SMTP carefully does not do anything to originate protocol, but when you do a QUIT either DTACH% or LGOUT% do an internal DOBE% which negotiates the Timing-Mark. My personal recommendation is to accept negotiations to the point of ignoring them, and tell the SMTP implementor that his/her SMTP has a bug. In the case of my SMTP, I agree it's a bug, and I am committed to fix it eventually. -- Mark -- ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983011508264100> Mail-from: ARPANET host SU-SCORE rcvd at 15-Jan-83 1943-PST Date: Sat 15 Jan 83 16:26:41-PST From: Mark Crispin Subject: Re: Telnet negotiations in SMTP To: Taft@PARC-MAXC.ARPA cc: ROODE@SRI-NIC.ARPA, TCP-IP@SRI-NIC.ARPA, Postel@USC-ISIF.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) In-Reply-To: Your message of Sat 15 Jan 83 10:38:00-PST I agree with Ed. My (minor) usage of TELNET protocol in the Score SMTP server is a bug. I hope that a single Timing-Mark while negotiating a QUIT command does not seriously impact anybody (it really shouldn't, since the message has already been delivered). ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983011510150000> Mail-from: ARPANET host USC-ISID rcvd at 15-Jan-83 1818-PST Date: 15 Jan 1983 1815-PST Sender: HAGAN at USC-ISID Subject: Re: SMTP test From: HAGAN at USC-ISID To: Miller at SRI-NIC Cc: tcp-ip at SRI-NIC, roode at SRI-NIC Message-ID: <[USC-ISID]15-Jan-83 18:15:08.HAGAN> In-Reply-To: Your message of 15 Jan 1983 0438-PST [ISID] found no problems. Good luck! Doug Hagan ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983011511190000> Mail-from: ARPANET host USC-ISID rcvd at 15-Jan-83 1923-PST Date: 15 Jan 1983 1919-PST From: MILLS at USC-ISID Subject: Re: Telnet negotiations in SMTP To: ROODE at SRI-NIC, TCP-IP at SRI-NIC cc: Postel at USC-ISIF, Taft%Parc at SANDIA, MILLS In response to the message sent 15 Jan 1983 0706-PST from ROODE@SRI-NIC Folks, Don't even think TELNET options in SMTP. If Jon doesn't beat you up I'll send 5000 IACs to your FTP server. Think about that. I don't like TELNET negotiations in FTP either, but at least there is some basis for that in rescueing runaway data transfers with some servers. Regards, Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983011514430000> Date: 15 Jan 1983 2243-PST From: ROODE at SRI-NIC (David Roode) Subject: Postmaster mailing address To: tcp-ip Location: EJ296 Phone: (415) 859-2774 A useful new mail functionality is being overlooked at many sites. In section 6.3, RFC 822 (August 1982) specifies a reserved address of Postmaster at each host that is supposed to accept general complaints about problems with mail at that host. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983011601444300> Return-path: Mail-from: LBL-CSAM rcvd by SRI-NIC at 16-Jan-83 1119-PST From: mo@LBL-CSAM.ARPA (Mike O'Dell [system]) Date: 16-Jan-83 09:44:43-PST (Sun) Subject: Re: Telnet and SMTP Return-Path: Message-Id: <8300161744.26911@LBL-CSAM.ARPA> Received: by LBL-CSAM.ARPA (3.284 [1/5/83]) id AA26911; 16-Jan-83 09:44:43-PST (Sun) To: cak@Purdue.ARPA Cc: tcp-ip@sri-nic.ARPA, mo@LBL-CSAM.ARPA In-Reply-To: Your message of 16 Jan 1983 0816-PST (Sunday). <8300161616.26324@LBL-CSAM.ARPA> Yes indeed, poking a buggy server with Telnet is imminently useful, in the absence of something else. However, it is trivial to get something else. We have a programm named "mconnect" (named for mail) which will make a bare connection to any specified remote port. The terminal is run in cooked mode (local echos, local erase, line kill, etc, processing...) but just copies lines too and from the network connection. This little tool is worth having, regardless of name, on any machine with a network connection for the reasons cited by Chris. As an alternative, many user telnets have a mode where they don't originate any negotiations (giving you pot-luck!). This is probably a reasonable substitute in a pinch. There is another issue here - robustness. I like this definition: "A robust program is conservative in what it sends to others, but is liberal in what it lets others get away with sending to it." So, in principle, one could argue that a robust SMTP would ignore all Telnet negotiations, or DONT them. However, due to the complexity of all the Telnet options, even parsing them is a pain because of variable lengths and other stuff. A non-trivial amount of mechanism has to be present just to throw the options away. Therefore, in spite of how convenient or robust it might be, basing SMTP on Telnet costs a great deal, and I think the cost clearly outweighs the benefit, especially when the benefits are so easy to get other ways. -Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983011609560000> Date: 16 Jan 1983 1756-PST From: Henry W. Miller Subject: Re: Telnet negotiations in SMTP To: DCP at MIT-MC, ROODE cc: Hornig at MIT-MULTICS, mo at LBL-CSAM, cak at PURDUE, Postel at USC-ISIF, TCP-IP, Taft%Parc at SANDIA, Miller In-Reply-To: Your message of 16-Jan-83 1212-PST Might as well throw my two cents worth: Telnet is good for debugging, but it is just a trivial to to write a small set of routines that will except text from you (or use pre-wired strings), and force them down the SMTP port's throat. This is the procedure I used when hacking up an experimental SMTP sender a few months back, and had about half of the send routines written and debugged in a single morning. Never even used TELNET. -HWM ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983011610160000> Date: 16 Jan 1983 1816-PST From: Henry W. Miller Subject: Re: Telnet negotiations in SMTP To: MILLS at USC-ISID, ROODE, TCP-IP cc: Postel at USC-ISIF, Taft%Parc at SANDIA, Miller In-Reply-To: Your message of 15-Jan-83 1919-PST Speaking of Telnet negotiations, we saw this seqquence while speaking to TOPS20 sites, which caused us to hang: [TOPS20] => We had to respond with: to get anything to come thru, although Jon thinks would work as well. Alas, we never had time to try the latter. KLH discovered this lossage. -HWM ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983011610220000> Date: 16 Jan 1983 1822-PST From: Henry W. Miller Subject: Re: SMTP test To: tcp-ip cc: roode, Miller In-Reply-To: Your message of 15-Jan-83 0438-PST Your server died on the . -HWM ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983011614400000> Return-path: Mail-from: USC-ISIF rcvd by SRI-NIC at 17-Jan-83 0106-PST Date: 16 Jan 1983 2240-PST From: MOCKAPETRIS at USC-ISIF Subject: TELNET has no place in SMTP To: roode at SRI-NIC, tcp-ip at SRI-NIC, taft%parc at SANDIA, To: mills at ISID, admin.mrc at SU-SCORE, cak at PURDUE cc: postel There is no good reason to have TELNET negotiations in SMTP. Mailers that use them will either not work or degrade performance of the mail system. (a la the MRC case of restricted TELNET pollution.) pvm ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983011704562800> Return-path: Mail-from: PURDUE rcvd by SRI-NIC at 17-Jan-83 0700-PST Date: 17 Jan 1983 09:56:28-EST From: Christopher A Kent Reply-to: cak@Purdue.ARPA To: Miller@SRI-NIC cc: Hornig@MIT-MULTICS, mo@LBL-CSAM, cak@PURDUE, Postel@USC-ISIF, TCP-IP@SRI-NIC, Taft@Parc, @, SANDIA@Purdue, Miller@SRI-NIC, DCP@MIT-MC, ROODE@SRI-NIC Subject: Re: Telnet negotiations in SMTP In-reply-to: Your message of 16 Jan 1983 1756-PST. Yup, I agree. I'm hacking up my own raw tty->net program today -- no more Telnet to debug servers for me! I think that we should follow Mark's suggestion -- swallow the options and send back a message (would someone care to suggest a reply code?). Cheers, chris ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983011706070000> Date: 17 Jan 1983 1407-PST From: KLH at SRI-NIC Subject: Re: TELNET has no place in SMTP To: MOCKAPETRIS at USC-ISIF, roode, tcp-ip, taft%parc at SANDIA, mills at USC-ISID, admin.mrc at SU-SCORE, cak at PURDUE cc: postel at USC-ISIF In-Reply-To: Your message of 16-Jan-83 2240-PST I have been dealing with FTP and netmail for a long time, and completely agree that TELNET negotiations don't belong in SMMTP. I think the only reason it was mentioned at all was to grab onto the existing TELNET-NVT definition of the ASCII char set; e.g. a bare CR should be sent as CR-NULL, etc. However, only Postel knows for sure what he had in mind at the time. I would be interested in hearing about any screw cases which TELNET option negotiations are intended to handle... ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983011707180000> Date: 17 Jan 1983 1518-PST From: KLH at SRI-NIC Subject: TOPS-20 TCP server bug? To: tcp-ip At the Internet meeting a possible bug with TOPS-20 TCP was mentioned; apparently if a SYN comes in for a port that is being listened on (by a server), then things get into a state such that if for some reason the synchronization does not proceed all the way to OPEN, things will be hung; further SYNs from other remote sites will not succeed, because only one process is LISTENing and the state of that process is best described as wedged. It is not clear if there is any way for the server program itself to avoid this. Any comments? (Note, I have not looked at the code, being on a slow terminal-- possibly this is a false alarm, but I'd like to find out). --Ken ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983011713570000> Return-path: Mail-from: USC-ISIF rcvd by SRI-NIC at 17-Jan-83 2203-PST Date: 17 Jan 1983 2157-PST From: POSTEL at USC-ISIF Subject: Telnet Signals & Options in SMTP To: TCP-IP at SRI-NIC TELNET Signial and Options are explicitly forbidden on the SMTP connection. --jon. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983011716340000> Date: 18 Jan 1983 0034-PST From: Henry W. Miller Subject: Re: SMTP test To: tcp-ip cc: roode, Miller In-Reply-To: Your message of 15-Jan-83 0438-PST Lynn, You are dropping the "." between the 's. -HWM ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983012110524500> Mail-From: created at 21-Jan-83 12:52:05 Mail-from: ARPANET host MITRE-BEDFORD rcvd at 21-Jan-83 1251-PST Date: Fri Jan 21 15:52:45 1983 From: lcg at MITRE-BEDFORD To: tcp-ip-request@sri-nic cc: lcg Subject: TCP/IP ---------------------- I am currently working on a project to implement a local area network in the Pentagon. My task to write an issues and implementation paper on TCP/IP. I know many people and companies are conducting TCP/IP implementation research and that a great deal of this information is either not written down or widely published. If you have any documentation concerning TCP/IP implementations, could you please send the information to my mailstop or this name and address: Remailed-date: 21 Jan 1983 1305-PST Remailed-from: Henry W. Miller Remailed-to: tcp-ip Louise Gilman Mitre Corporation Mail Stop J225 Box 208 Bedford, MA 01730 Thank you. Sincerely, Louise Gilman PS If you would prefer to talk via phone my business Tel. # is (617)271-7678. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983012115250000> Received: from USC-ISIB by SRI-NIC at 21-Jan-83 2335-PST Date: 21 Jan 1983 2325-PST Sender: JGOLDBERGER at USC-ISIB Subject: Re: TOPS-20 TCP server bug? From: Joel Goldberger To: KLH at SRI-NIC Cc: tcp-ip at SRI-NIC Message-ID: <[USC-ISIB]21-Jan-83 23:25:26.JGOLDBERGER> In-Reply-To: Your message of 17 Jan 1983 1518-PST To my knowledge there is no facility to "queue" SYNs as was possible with NCP RFC's. This does indeed result in the condition that was mentioned. We at ISI have changed our listeners to have an initial timeout of 30 seconds and then reset the timeout for the connection to 3 minutes. This means that at worst the listener will get wedged for 30 seconds. - Joel - ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983012118230000> Date: 22 Jan 1983 0223-PST From: Henry W. Miller Subject: Re: TOPS-20 TCP server bug? To: KLH, tcp-ip cc: Miller In-Reply-To: Your message of 17-Jan-83 1518-PST Hmm, it is possible, since the SYN response code is so scattered. My main concern at the moment is the lack of timeout parameters in RECV anc CLOSE, since if the distant host goes south of the border, the listener mighht well hang until the sun novas, or until the next crash waiting. (Assuming, of course DATE48 doesn't happen. Date 48 will happen in 2048, and is anologous to DATE75, when the 18 bit field wiill be filled.) -HWM ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983012118300000> Date: 22 Jan 1983 0230-PST From: Henry W. Miller Subject: Re: TOPS-20 TCP server bug? To: JGoldberger at USC-ISIB, KLH cc: tcp-ip, Miller In-Reply-To: Your message of 21-Jan-83 2325-PST To my knowledge also (and II know that code well...) there is no way to q SYN's. Your suggestion sounds timely and is well taken. -HWM ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983012402500000> Mail-From: created at 24-Jan-83 10:53:21 Mail-from: ARPANET host SRI-KL rcvd at 24-Jan-83 1053-PST Date: 24 Jan 1983 1050-PST From: Mathis at SRI-KL Subject: Re: TOPS-20 TCP server bug? To: KLH at SRI-NIC cc: tcp-ip at SRI-NIC, Mathis at SRI-KL In-Reply-To: Your message of 17-Jan-83 1518-PST Ken, A solution would be to allow multiple listening connections for the same local port. Nothing in the spec would prohibit this. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983012410510000> Received: from USC-ISIF by SRI-NIC at 25-Jan-83 0337-PST Date: 24 Jan 1983 1851-PST From: POSTEL at USC-ISIF Subject: TCP servers and Listening Ports To: TCP-IP at SRI-NIC KLH raised a concern about application servers being locked up (i.e., not listening) while a connection is in the process of opening. This is a real possibility if the server is constructed in (as several are) a way that does not start a new listen until the open negotiation is completed or times out. Joel Goldberger noted that one could (as ISI TOPS20s now do) put a short time out on the open negotiation, and a longer time out on the data transfer phase of the connection. I would like to point out that it is also possible to construct a server such that it starts a new listen as just as the open negotiation is begun, and thus nearly always have a listen pending independent of the outcome of any specific open negotiation. This generally takes a bit more planning and control in the top level process, but it may be worth the effort if non-listening servers become a significant complaint. --jon. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983012502480000> Received: from MIT-MULTICS by SRI-NIC at 25-Jan-83 0448-PST Date: 25 January 1983 07:48 est From: JSLove at MIT-MULTICS (J. Spencer Love) Subject: TCP Services caught with their pants down To: KLH at MIT-MC cc: TCP-IP at SRI-NIC, JSLove.PDO at MIT-MULTICS The Multics TCP implementation includes a type of connection called a "template", which is a TCB in the listening state which spins off "clones" whenever an attempt is made to connect to it. The only operations permitted on a template are creation (passive OPEN) and destruction (ABORT). The TCB sends messages to the owning process which are the handles of the clones when they are created (actually, when they enter the established state, since the TCP can handle that negotiation without bothering the service process). I realize that this is a lot of hair to go to, but it does guarantee that there are no windows when a service request could get a RST instead of a SYN. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983012504110000> Received: from RADC-MULTICS by SRI-NIC at 25-Jan-83 0613-PST Date: 25 January 1983 09:11 est From: Ata.SysMaint at RADC-MULTICS Subject: Re: TOPS-20 TCP server bug? To: Mathis at SRI-KL cc: KLH at SRI-NIC, tcp-ip at SRI-NIC In-Reply-To: Message of 24 January 1983 13:50 est from Mathis You cannpt have 2 unrestricted listens on the same local port. This is because a unrestricted listen is defined to have a foreign port of 0. 2 Unrestricted listens on the same local port would result in 2 TCBS with the same local/foreign port combination. This is in violation of the specs. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983012505180000> Mail-From: created at 25-Jan-83 15:45:27 Mail-from: ARPANET host SRI-KL rcvd at 25-Jan-83 1545-PST Date: 25 Jan 1983 1318-PST From: Mathis at SRI-KL Subject: Re: TOPS-20 TCP server bug? To: Ata.SysMaint at RADC-MULTICS cc: KLH at SRI-NIC, tcp-ip at SRI-NIC, Mathis at SRI-KL In-Reply-To: Your message of 25-Jan-83 0911-PST The intent of the spec is to unambigiously define to which TCB an incoming segment refers. The issues of having multiple unspecified listens on the same local port is primarily a local implementation detail since consistent external behavior to other TCPs can be achieved. Multiple fully specified connections on the same local/foreign port pairs are not allowed. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983012505480000> Date: 25 Jan 1983 1348-PST From: Henry W. Miller Subject: Re: TCP servers and Listening Ports To: POSTEL at USC-ISIF, TCP-IP cc: Miller In-Reply-To: Your message of 24-Jan-83 1851-PST Several of our servers do it that way, or simply fire up a number of server sub-forks upon initializing. The monitor, if I am not mistaken, fires up listeners upon TVT initializatoin, and hands them off to the TVT when a connect occurs. -HWM ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983012602540000> Received: from USC-ISIF by SRI-NIC at 26-Jan-83 1221-PST Date: 26 Jan 1983 1054-PST From: MOCKAPETRIS at USC-ISIF Subject: Re: TOPS-20 TCP server bug? To: KLH at SRI-NIC cc: MOCKAPETRIS at USC-ISIF, postel at USC-ISIF, cc: tcp-ip at SRI-NIC, mathis at SRI-KL In response to your message sent 17 Jan 1983 1518-PST At ISI we have noted the hung listener problem (it does happen) and reset the listening port if the connection doesn't go to established within a minute. If you use PSIs to detect a new connection on the listen port, you should also protect against connection establishment between the time of the OPEN and the CHANL for the state change. Alas, this can also happen. paul ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983012702213600> Received: from COMPION-VMS by SRI-NIC at 27-Jan-83 0621-PST Date: Thu, 27 Jan 83 08:21:36 CST From: schur at COMPION-VMS Subject: ftp multiple transfer problem To: tcp-ip at sri-nic Cc: schur During the implementation of ftp we have noticed the following problem with the interaction of the ftp and tcp protocols: 1. When a data transfer is started a connection is opened between the user ftp port and the server ftp port - 1. 2. In many cases the data connection must be closed to indicate EOF. At this point, the connection will start closing and eventually go into the TIME-WAIT state (for an arbitrary period of two minutes, as the protocol indicates). 3. If ftp wishes to open the data connection again during this TIME-WAIT period, it will not be allowed to do so, since it would be using the same local and foreign ports, and foreign internet address. The TCP protocol requires that we be able to receive packets for the connection in the TIME-WAIT state, so we can't reopen a new connection until it has completely closed. This scenario causes an unacceptable delay when using ftp for multiple transfers requiring opening and closing of the data connection. Do other implementors have this problem. If not, what fix did you apply or is there something in the protocols that I have missed. John Schur ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983012702461200> Received: from COMPION-VMS by SRI-NIC at 27-Jan-83 0645-PST Date: Thu, 27 Jan 83 08:46:12 CST From: schur at DTI-VMS Subject: resending using old site name To: tcp-ip at sri-nic I am resending this message using our old site name, since some sites would not accept this mail because they did not know of our new name. I apologize to anyone who is receiving this twice. Please send all replies to . During the implementation of ftp we have noticed the following problem with the interaction of the ftp and tcp protocols: 1. When a data transfer is started a connection is opened between the user ftp port and the server ftp port - 1. 2. In many cases the data connection must be closed to indicate EOF. At this point, the connection will start closing and eventually go into the TIME-WAIT state (for an arbitrary period of two minutes, as the protocol indicates). 3. If ftp wishes to open the data connection again during this TIME-WAIT period, it will not be allowed to do so, since it would be using the same local and foreign ports, and foreign internet address. The TCP protocol requires that we be able to receive packets for the connection in the TIME-WAIT state, so we can't reopen a new connection until it has completely closed. This scenario causes an unacceptable delay when using ftp for multiple transfers requiring opening and closing of the data connection. Do other implementors have this problem. If not, what fix did you apply or is there something in the protocols that I have missed. John Schur ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983012707420000> Received: from RADC-MULTICS by SRI-NIC at 27-Jan-83 0947-PST Date: 27 January 1983 12:42 est From: Ata.SysMaint at RADC-MULTICS Subject: Re: ftp multiple transfer problem To: schur at COMPION-VMS cc: tcp-ip at SRI-NIC In-Reply-To: Message of 27 January 1983 11:52 est from schur Yes, we have the same problem as other impelmentators do. A bypass is to use the port command specifying a different port for each file transfer. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983012710204900> Received: from COMPION-VMS by SRI-NIC at 27-Jan-83 1420-PST Date: Thu, 27 Jan 83 16:20:49 CST From: schur at COMPION-VMS Subject: multiple ftp transfers To: tcp-ip at sri-nic Cc: schur Other than using the port command to do multiple ftp transfers, does anyone have another solution that doesn't violate any protocols. Is there any consideration being given to changing the protocols to fix this problem? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1983012810520000> Received: from USC-ISIF by SRI-NIC at 29-Jan-83 1515-PST Date: 28 Jan 1983 1852-PST From: POSTEL at USC-ISIF Subject: FTP Clarifications To: tcp-ip at NIC < INC-PROJECT, FTP-NOTE.NLS.3, >, 28-Jan-83 18:51 JBP ;;;; There are several changes and clarifications needed in the File Transfer specification (RFC-765 = IEN-149). Here are two important points. 1. Mail Commands: The mail commands in the FTP are NOT to be implemented. Use the separate SMTP protocol instead. 2. Data Connection Management: a. Default Data Connection Ports: All FTP implementations must support use of the default data connection ports, and only the User-PI may initiatate the use of non-default ports. b. Negotiating Non-Default Data Ports: The User-PI may specify a non-default user side data port with the PORT command. The User-PI may request the server side to identify a non-default server side data port with the PASV command. Since a connection is defined by the pair of addresses, either of these actions is enough to get a different data connection, still it is permitted to do both commands to use new ports on both ends of the data connection. c. Reuse of the Data Connection: When using the stream mode of data transfer the end of the file must be indicated by closing the connection. This causes a problem if multiple files are to be transfered in the session, due to need for TCP to hold the connection record for a time out period to guarantee the reliable communication. Thus the connection can not be reopened at once. There are two solutions to this problem. The first is to negotiate a non-default port (as in (b) above). The second is to use another transfer mode. A comment on transfer modes. The stream transfer mode is inherently unreliable, since one can not determine if the connection closed prematurely or not. The other transfer modes (Block, Compressed) do not close the connection to indicate the end of file. They have enough FTP encoding that the data connection can be parsed to determine the end of the file. Thus using these modes one can leave the data connection open for multiple file transfers. Why this was not a problem with the old NCP FTP: The NCP was designed with only the ARPANET in mind. The ARPANET provides very reliable service, and the NCP counted on it. If any packet of data from an NCP connection were lost or damaged by the network the NCP could not recover. It is a tribute to the ARPANET designers that the NCP FTP worked so well. The TCP is designed to provide reliable connections over many different types of network and interconnections of networks. TCP must cope with a set of networks that can not promise to work as well as the ARPANET. TCP must make its own provisions for end-to-end recovery from lost or damaged packets. This leads to the need for the connection phase-down time-out. The NCP never had to deal with acknowledgements or retansmissions or many other things the TCP must do to make connection reliable in a more complex world. --jon. ------- ----MESSAGE-END----