hacks and glory await
This commit is contained in:
174
RFC/rfc768.txt
Normal file
174
RFC/rfc768.txt
Normal file
@@ -0,0 +1,174 @@
|
||||
|
||||
|
||||
RFC 768 J. Postel
|
||||
ISI
|
||||
28 August 1980
|
||||
|
||||
|
||||
|
||||
User Datagram Protocol
|
||||
----------------------
|
||||
|
||||
Introduction
|
||||
------------
|
||||
|
||||
This User Datagram Protocol (UDP) is defined to make available a
|
||||
datagram mode of packet-switched computer communication in the
|
||||
environment of an interconnected set of computer networks. This
|
||||
protocol assumes that the Internet Protocol (IP) [1] is used as the
|
||||
underlying protocol.
|
||||
|
||||
This protocol provides a procedure for application 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 ordered reliable delivery of
|
||||
streams of data should use the Transmission Control Protocol (TCP) [2].
|
||||
|
||||
Format
|
||||
------
|
||||
|
||||
|
||||
0 7 8 15 16 23 24 31
|
||||
+--------+--------+--------+--------+
|
||||
| Source | Destination |
|
||||
| Port | Port |
|
||||
+--------+--------+--------+--------+
|
||||
| | |
|
||||
| Length | Checksum |
|
||||
+--------+--------+--------+--------+
|
||||
|
|
||||
| data octets ...
|
||||
+---------------- ...
|
||||
|
||||
User Datagram Header Format
|
||||
|
||||
Fields
|
||||
------
|
||||
|
||||
Source Port is an optional field, when meaningful, it indicates the port
|
||||
of the sending process, and may be assumed to be the port to which a
|
||||
reply should be addressed in the absence of any other information. If
|
||||
not used, a value of zero is inserted.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Postel [page 1]
|
||||
|
||||
|
||||
28 Aug 1980
|
||||
User Datagram Protocol RFC 768
|
||||
Fields
|
||||
|
||||
|
||||
|
||||
Destination Port has a meaning within the context of a particular
|
||||
internet destination address.
|
||||
|
||||
Length is the length in octets of this user datagram including this
|
||||
header and the data. (This means the minimum value of the length is
|
||||
eight.)
|
||||
|
||||
Checksum is the 16-bit one's complement of the one's complement sum of a
|
||||
pseudo header of information from the IP header, the UDP header, and the
|
||||
data, padded with zero octets at the end (if necessary) to make a
|
||||
multiple 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 datagrams.
|
||||
This checksum procedure is the same as is used in TCP.
|
||||
|
||||
0 7 8 15 16 23 24 31
|
||||
+--------+--------+--------+--------+
|
||||
| source address |
|
||||
+--------+--------+--------+--------+
|
||||
| destination address |
|
||||
+--------+--------+--------+--------+
|
||||
| zero |protocol| UDP length |
|
||||
+--------+--------+--------+--------+
|
||||
|
||||
If the computed checksum is zero, it is transmitted as all ones (the
|
||||
equivalent in one's complement arithmetic). An all zero transmitted
|
||||
checksum value means that the transmitter generated no checksum (for
|
||||
debugging or for higher level protocols that don't care).
|
||||
|
||||
User Interface
|
||||
--------------
|
||||
|
||||
A user interface should allow
|
||||
|
||||
the creation of new receive ports,
|
||||
|
||||
receive operations on the receive ports that return the data octets
|
||||
and an indication of source port and source address,
|
||||
|
||||
and an operation that allows a datagram to be sent, specifying the
|
||||
data, source and destination ports and addresses to be sent.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
[page 2] Postel
|
||||
|
||||
|
||||
28 Aug 1980
|
||||
RFC 768 User Datagram Protocol
|
||||
IP Interface
|
||||
|
||||
|
||||
|
||||
IP Interface
|
||||
-------------
|
||||
|
||||
The UDP module must be able to determine the source and destination
|
||||
internet addresses and the protocol field from the internet header. One
|
||||
possible UDP/IP interface would return the whole internet datagram
|
||||
including all of the internet header in response to a receive operation.
|
||||
Such an interface would also allow the UDP to pass a full internet
|
||||
datagram complete with header to the IP to send. The IP would verify
|
||||
certain fields for consistency and compute the internet header checksum.
|
||||
|
||||
Protocol Application
|
||||
--------------------
|
||||
|
||||
The major uses of this protocol is the Internet Name Server [3], and the
|
||||
Trivial File Transfer [4].
|
||||
|
||||
Protocol Number
|
||||
---------------
|
||||
|
||||
This is protocol 17 (21 octal) when used in the Internet Protocol.
|
||||
Other protocol numbers are listed in [5].
|
||||
|
||||
References
|
||||
----------
|
||||
|
||||
[1] Postel, J., "Internet Protocol," RFC 760, USC/Information
|
||||
Sciences Institute, January 1980.
|
||||
|
||||
[2] Postel, J., "Transmission Control Protocol," RFC 761,
|
||||
USC/Information Sciences Institute, January 1980.
|
||||
|
||||
[3] Postel, J., "Internet Name Server," USC/Information Sciences
|
||||
Institute, IEN 116, August 1979.
|
||||
|
||||
[4] Sollins, K., "The TFTP Protocol," Massachusetts Institute of
|
||||
Technology, IEN 133, January 1980.
|
||||
|
||||
[5] Postel, J., "Assigned Numbers," USC/Information Sciences
|
||||
Institute, RFC 762, January 1980.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Postel [page 3]
|
||||
|
||||
Reference in New Issue
Block a user