Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!decwrl!ucbvax!ATHOS.RUTGERS.EDU!hedrick From: hedrick@ATHOS.RUTGERS.EDU (Charles Hedrick) Newsgroups: comp.protocols.ibm Subject: Re: (none) Message-ID: <8809300531.AA22822@jade.berkeley.edu> Date: 29 Sep 88 19:48:28 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Charles Hedrick Organization: The Internet Lines: 30 Actually the term "unreliable" has three different meanings in TCP/IP, depending upon whether you're using it to describe IP, UDP, or the many buggy implementations that exist -:). telnet, ftp NFS, name service TCP UDP --------IP----------- IP does checksums only for the IP header. The main information this includes is the source and destination address. The IP level does not check the data. Thus the IP level is "unreliable" both in the sense that it does not guarantee delivery and in the sense that it may give you bad data. There are some applications written directly on top of IP, not using TCP or UDP. They have to contend with unreliable in its full definition. TCP does checksums for all of the data. It also does retransmissions as necessary to make sure all the data arrives exactly once. Thus Protocols written on top of TCP don't have to worry about this, and can treat TCP as providing reliable data. UDP normally checksums its data. It does not guarantee arrival. Thus applications written on top of UDP can assume that what they get is uncorrupted, but they may have to do retransmission at the application level, because delivery is not guaranteed. So UDP is unreliable in the sense of delivery but not in the sense of corruption. Note however that it is possible to turn off checksumming in UDP. The most infamous case is Sun, which turns it off for NFS (for performance reasons -- it even makes sense when you use NFS the way they intended).