RFC768UserDatagramProtocol用戶數(shù)據(jù)協(xié)議外文翻譯

1、rfc 768j. postel1st28 august 1980user datagram protocolintroductionthis user datagram protocol (udp) is defincd to make available a datagram mode of packetswi tched computer communication in the environment of an interconnected set of computer networks. this protocol assumes that the internet protoc

2、ol (ip) 1 is used as the underlying protocol.this protocol provides a procedure for applicat ion programs to send messages to other programs with a minimum of protocol mechanism. the protocol is transaction oriented, and delivery and duplicate protection are not guaranteed. applications requiring or

3、dered reliable delivery of streams of data should use the transmission control protocol (tcp) 2.format01-7 815 1623 2431|141十十十十1sourcedestination1portport|4+length| checksum+idata octets user datagram header formatfieldssource port is an optional field, when meaningful, it indicates the port of the

4、 sending process, and may be assumed to be the port to which areply should be addressed in the absenee of any other information.ifnot used, a value of zero is insertedposteluser datagram protocolfieldspage 128 aug 1980rfc 768destination port has a meaning within the context of a particular internet

5、dost inat ion addresslength i s the 1ength header and the data, eight.)in octets of this user datagram including this (this means the minimum value of the length ischecksum is the 16bitone" s complement of the ones complement sum of apseudo header of information from the tp header,the udp heade

6、r, and thedata, padded with zero octets at the end (if necessary)to make amultiple of two octets.the pseudo header conceptually prefixed to the udp header contains the source address, the destination address, the protocol, and the udp length. this information gives protection against misrouted datag

7、rams. this checksum procedure is the same as is used in tcp.07 815 1623 2431+source addressd+idost ination address|d+zero |protocol| udp length+if the computed checksum is zero, it is transmitted as al 1 ones (the equivalent in one's complement arithmetic). an al 1 zero transmitted checksum valu

8、e means that the transmitter generated no checksum (for debugging or for higher level protocols that don't care)-user interfacea user interface should allowthe creation of new receive ports,receive operations on the receive ports that return the data octets and an indication of source port and s

9、ource address,and an operation that allows a datagram to be sent, specifying the data, source and destination ports and addresses to be sent.28 aug 1980rfc 768page 2posteluser datagram protocolip interfaceip interfacethe udp module must be able to determine the source and destination internet addres

10、ses and the protocol field from the internet header one possible udp/ip interface wou1d return the whole internet datagram including all of the inlernet header in response to a receive operation. such an interface would also al low the udp to pass a ful1 internet datagram complete with header to the

11、 ip to send. the ip would verify certain fields for consistency and compute the internet header checksumprotocol applicationthe major uses of this protocol is the internot name server 3, and the trivial file transfer 4.protocol numberthis is protocol 17 (21 octal) whon used in the internet protocolo

12、ther protocol numbers are listed in 5.references1 postel, j., ''internet protocol, " rfc 760, usc/informationsciences institute, january 1980.postel, j., transmission control protocol," rfc 761,usc/tnformation sciences institute, january 1980.3postel, j., "internet name server

13、,77 usc/information sciences institute, ien 116, august 1979.4sollins, k. , "the tftp protocol,，z massachusetts institute of technology, ten 133, january 1980.5postel,j. ,''assigned numbers," usc/information sciencesinstitute, rfc 762, january 1980.postelpage 3rfc 768j. postel1st19

14、80 年 8 月 28 口用廣數(shù)據(jù)協(xié)議介紹用戶數(shù)據(jù)報協(xié)議是定義用來在互連網(wǎng)絡(luò)壞境中提供數(shù)據(jù)包交換的計算機通信的協(xié)議。此 協(xié)議默認認為網(wǎng)路i辦議（tp） 1是其下層協(xié)議。這協(xié)議提供了向另一用戶程序發(fā)送信息的最簡便的協(xié)議機制。此協(xié)議是面向操作的，未捉供提交和復(fù)制保護。如呆應(yīng)用程序要求可靠的數(shù)據(jù)傳送應(yīng)該使用傳輸控制協(xié)議（tcp） 2。格式如下：07 815 1623 2431+h+i 源端口i目的地端口iiii+i用戶數(shù)據(jù)包 i 校驗和 ii的長度ii+ii數(shù)據(jù)用戶數(shù)據(jù)頭格式源端口是可選域，當其冇意義時,它指的是發(fā)送進程的端口，這也就假定了在沒冇其 它信息的情況下，返i川信息應(yīng)閡句什么地方發(fā)送。如果

15、不使用它，則在此域中填0。postel笫 1 頁1980年8月28日用戶數(shù)據(jù)協(xié)議rfc 768域冃的端口在特定的網(wǎng)絡(luò)冃的地址中具冇意義。長度指的是此用戶數(shù)據(jù)報長度的八進制表示。（這表明最小的數(shù)據(jù)報長度是8。）校驗碼有16位，是對ip頭，udp頭和數(shù)據(jù)中信息包頭的數(shù)位取反z和再取反得到的。包頭從概念上說是在udp頭信息之前的，它包括有源地址，日的地地址，所使用的協(xié) 議和udp長度。這些信息使信息不能被錯誤地接收。這個校驗過程與tcp小使用的過程一 致。07815 1623 2431+1+-+源地址+1+14-冃的地址1-v1 01協(xié)議1udp長度1+一+如果計算出的校驗碼為零，它將被全零發(fā)送。全

16、零的校驗值意味著發(fā)送者未產(chǎn)牛校驗碼。川戶接口用八接口應(yīng)該允許創(chuàng)建新的接收端口，在接收端口的接收操作有：應(yīng)該返回一個八進制數(shù)說明源端口和源地址，允許數(shù)據(jù)報傳送，指定數(shù)據(jù)，源和h標端口和冃的地地址。postel第2頁1980年8月28日rfc 768用戶數(shù)據(jù)協(xié)議ip界面ip界而udp模塊必須能夠決定源和目標的網(wǎng)絡(luò)地址，而口必須能夠從包頭中得知所使用的協(xié) 議。一個可能的接口方式是返冋整個數(shù)據(jù)報，包括接收操作返回的包頭。這樣的接口還應(yīng)該 允許idp向ip傳送完整的帶包頭的數(shù)據(jù)報用于傳送。iii ip來確定一致性并計算校驗碼。協(xié)議應(yīng)川本議定書的主要用途是互聯(lián)網(wǎng)名稱服務(wù)器3和小文件傳輸協(xié)議4。協(xié)議號在ip

17、中使用它時,它的協(xié)議號是17 （八進制中是21）。其它協(xié)議編號己經(jīng)列在5。參考文獻1 postel, j., "internet protocol, z/ rfc 760, usc/ t n f or mat i on sciences institute, january 1980.2 postel, j.,，ztransmissioncontrol protocol,rfc 761,usc/tnformation sciences tnstitute, january 1980.3 postel, j., "internet name server," usc