|
|
ARCHIVE: TCP-IP Distribution List - Archives (1983)
DOCUMENT: TCP-IP Distribution List for January 1983 (33 messages, 9686 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1983/01.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
-----------[000000][next][prev][last][first]---------------------------------------------------- Date: 15 Jan 1983 0438-PST From: Henry W. Miller <Miller at SRI-NIC> To: tcp-ip Cc: Miller, roode Subject: SMTP test
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 <CRLF>.<CRLF> SEQUENCE IN THE MIDDLE OF TEXT BLAH, BLAH, . BLAH, BLAH... . Your obedient serpent, -HWM -------
-----------[000001][next][prev][last][first]---------------------------------------------------- Date: 15 Jan 1983 1053-PST From: Henry W. Miller <Miller at SRI-NIC> To: ROODE, TCP-IP Cc: Postel at USC-ISIF, Taft%Parc at SANDIA, Miller Subject: Re: Telnet negotiations in SMTP
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 -------
-----------[000002][next][prev][last][first]---------------------------------------------------- Date: Sat 15 Jan 83 14:57:22-PST From: Mark Crispin <Admin.MRC@SU-SCORE.ARPA> To: ROODE@SRI-NIC.ARPA Cc: TCP-IP@SRI-NIC.ARPA, Postel@USC-ISIF.ARPA, Taft%Parc@SANDIA.ARPA Subject: Re: Telnet negotiations in SMTP
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 --
-------
-----------[000003][next][prev][last][first]---------------------------------------------------- Date: Sat 15 Jan 83 16:26:41-PST From: Mark Crispin <Admin.MRC@SU-SCORE.ARPA> To: Taft@PARC-MAXC.ARPA Cc: ROODE@SRI-NIC.ARPA, TCP-IP@SRI-NIC.ARPA, Postel@USC-ISIF.ARPA Subject: Re: Telnet negotiations in SMTP
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). -------
-----------[000004][next][prev][last][first]---------------------------------------------------- Date: 15 Jan 1983 1815-PST From: HAGAN at USC-ISID To: Miller at SRI-NIC Cc: tcp-ip at SRI-NIC, roode at SRI-NIC Subject: Re: SMTP test
[ISID]<Hagan> found no problems. Good luck! Doug Hagan
-----------[000005][next][prev][last][first]---------------------------------------------------- Date: 15 Jan 1983 1919-PST From: MILLS at USC-ISID To: ROODE at SRI-NIC, TCP-IP at SRI-NIC Cc: Postel at USC-ISIF, Taft%Parc at SANDIA, MILLS Subject: Re: Telnet negotiations in SMTP
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 -------
-----------[000006][next][prev][last][first]---------------------------------------------------- Date: 15 Jan 1983 2243-PST From: ROODE at SRI-NIC (David Roode) To: tcp-ip Subject: Postmaster mailing address
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. -------
-----------[000007][next][prev][last][first]---------------------------------------------------- Date: 16-Jan-83 09:44:43-PST (Sun) From: mo@LBL-CSAM.ARPA (Mike O'Dell [system]) To: cak@Purdue.ARPA Cc: tcp-ip@sri-nic.ARPA, mo@LBL-CSAM.ARPA Subject: Re: Telnet and SMTP
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
-----------[000008][next][prev][last][first]---------------------------------------------------- Date: 16 Jan 1983 1756-PST From: Henry W. Miller <Miller at SRI-NIC> 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 Subject: Re: Telnet negotiations in SMTP
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 -------
-----------[000009][next][prev][last][first]---------------------------------------------------- Date: 16 Jan 1983 1816-PST From: Henry W. Miller <Miller at SRI-NIC> To: MILLS at USC-ISID, ROODE, TCP-IP Cc: Postel at USC-ISIF, Taft%Parc at SANDIA, Miller Subject: Re: Telnet negotiations in SMTP
Speaking of Telnet negotiations, we saw this seqquence while speaking to TOPS20 sites, which caused us to hang: [TOPS20] => <IAC><Do TimingMark> We had to respond with: <IAC><Will TimingMark> to get anything to come thru, although Jon thinks <IAC><Won't TimingMark> would work as well. Alas, we never had time to try the latter. KLH discovered this lossage. -HWM -------
-----------[000010][next][prev][last][first]---------------------------------------------------- Date: 16 Jan 1983 1822-PST From: Henry W. Miller <Miller at SRI-NIC> To: tcp-ip Cc: roode, Miller Subject: Re: SMTP test
Your server died on the <CRLF>.<CRLF> -HWM -------
-----------[000011][next][prev][last][first]---------------------------------------------------- Date: 16 Jan 1983 2240-PST From: MOCKAPETRIS at USC-ISIF To: roode at SRI-NIC, tcp-ip at SRI-NIC, taft%parc at SANDIA, mills at ISID, admin.mrc at SU-SCORE, cak at PURDUE Cc: postel Subject: TELNET has no place in SMTP
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 -------
-----------[000012][next][prev][last][first]---------------------------------------------------- Date: 17 Jan 1983 09:56:28-EST From: Christopher A Kent <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
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
-----------[000013][next][prev][last][first]---------------------------------------------------- Date: 17 Jan 1983 1407-PST From: KLH at SRI-NIC 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 Subject: Re: TELNET has no place in SMTP
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... -------
-----------[000014][next][prev][last][first]---------------------------------------------------- Date: 17 Jan 1983 1518-PST From: KLH at SRI-NIC To: tcp-ip Subject: TOPS-20 TCP server bug?
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 -------
-----------[000015][next][prev][last][first]---------------------------------------------------- Date: 17 Jan 1983 2157-PST From: POSTEL at USC-ISIF To: TCP-IP at SRI-NIC Subject: Telnet Signals & Options in SMTP
TELNET Signial and Options are explicitly forbidden on the SMTP connection. --jon. -------
-----------[000016][next][prev][last][first]---------------------------------------------------- Date: 18 Jan 1983 0034-PST From: Henry W. Miller <Miller at SRI-NIC> To: tcp-ip Cc: roode, Miller Subject: Re: SMTP test
Lynn, You are dropping the "." between the <CRLF>'s. -HWM -------
-----------[000017][next][prev][last][first]---------------------------------------------------- Date: Fri Jan 21 15:52:45 1983 From: lcg at MITRE-BEDFORD To: tcp-ip-request@sri-nic Cc: lcg Subject: 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.
-----------[000018][next][prev][last][first]---------------------------------------------------- Date: 21 Jan 1983 2325-PST From: Joel Goldberger <JGoldberger@USC-ISIB> To: KLH at SRI-NIC Cc: tcp-ip at SRI-NIC Subject: Re: TOPS-20 TCP server bug?
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 -
-----------[000019][next][prev][last][first]---------------------------------------------------- Date: 22 Jan 1983 0223-PST From: Henry W. Miller <Miller at SRI-NIC> To: KLH, tcp-ip Cc: Miller Subject: Re: TOPS-20 TCP server bug?
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 -------
-----------[000020][next][prev][last][first]---------------------------------------------------- Date: 22 Jan 1983 0230-PST From: Henry W. Miller <Miller at SRI-NIC> To: JGoldberger at USC-ISIB, KLH Cc: tcp-ip, Miller Subject: Re: TOPS-20 TCP server bug?
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 -------
-----------[000021][next][prev][last][first]---------------------------------------------------- Date: 24 Jan 1983 1050-PST From: Mathis at SRI-KL To: KLH at SRI-NIC Cc: tcp-ip at SRI-NIC, Mathis at SRI-KL Subject: Re: TOPS-20 TCP server bug?
Ken, A solution would be to allow multiple listening connections for the same local port. Nothing in the spec would prohibit this. -------
-----------[000022][next][prev][last][first]---------------------------------------------------- Date: 24 Jan 1983 1851-PST From: POSTEL at USC-ISIF To: TCP-IP at SRI-NIC Subject: TCP servers and Listening Ports
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. -------
-----------[000023][next][prev][last][first]---------------------------------------------------- Date: 25 January 1983 07:48 est From: JSLove at MIT-MULTICS (J. Spencer Love) To: KLH at MIT-MC Cc: TCP-IP at SRI-NIC, JSLove.PDO at MIT-MULTICS Subject: TCP Services caught with their pants down
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.
-----------[000024][next][prev][last][first]---------------------------------------------------- Date: 25 January 1983 09:11 est From: Ata.SysMaint at RADC-MULTICS To: Mathis at SRI-KL Cc: KLH at SRI-NIC, tcp-ip at SRI-NIC Subject: Re: TOPS-20 TCP server bug?
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.
-----------[000025][next][prev][last][first]---------------------------------------------------- Date: 25 Jan 1983 1318-PST From: Mathis at SRI-KL To: Ata.SysMaint at RADC-MULTICS Cc: KLH at SRI-NIC, tcp-ip at SRI-NIC, Mathis at SRI-KL Subject: Re: TOPS-20 TCP server bug?
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. -------
-----------[000026][next][prev][last][first]---------------------------------------------------- Date: 25 Jan 1983 1348-PST From: Henry W. Miller <Miller at SRI-NIC> To: POSTEL at USC-ISIF, TCP-IP Cc: Miller Subject: Re: TCP servers and Listening Ports
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 -------
-----------[000027][next][prev][last][first]---------------------------------------------------- Date: 26 Jan 1983 1054-PST From: MOCKAPETRIS at USC-ISIF To: KLH at SRI-NIC Cc: MOCKAPETRIS at USC-ISIF, postel at USC-ISIF, tcp-ip at SRI-NIC, mathis at SRI-KL Subject: Re: TOPS-20 TCP server bug?
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 -------
-----------[000028][next][prev][last][first]---------------------------------------------------- Date: Thu, 27 Jan 83 08:21:36 CST From: schur at COMPION-VMS To: tcp-ip at sri-nic Cc: schur Subject: ftp multiple transfer problem
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 <schur at compion-vms>
-----------[000029][next][prev][last][first]---------------------------------------------------- Date: Thu, 27 Jan 83 08:46:12 CST From: schur at DTI-VMS To: tcp-ip at sri-nic Subject: resending using old site name
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 <schur at compion-vms>. 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 <schur at compion-vms>
-----------[000030][next][prev][last][first]---------------------------------------------------- Date: 27 January 1983 12:42 est From: Ata.SysMaint at RADC-MULTICS To: schur at COMPION-VMS Cc: tcp-ip at SRI-NIC Subject: Re: ftp multiple transfer problem
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.
-----------[000031][next][prev][last][first]---------------------------------------------------- Date: Thu, 27 Jan 83 16:20:49 CST From: schur at COMPION-VMS To: tcp-ip at sri-nic Cc: schur Subject: multiple ftp transfers
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?
-----------[000032][next][prev][last][first]---------------------------------------------------- Date: 28 Jan 1983 1852-PST From: POSTEL at USC-ISIF To: tcp-ip at NIC Subject: FTP Clarifications
< 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.
-------
END OF DOCUMENT
| ISSN 1742-948X 01 (Online) | 2005/03/01 | Copyright 2002-2008 securitydigest.org. All rights reserved. |