📄 rfc938.txt
字号:
Network Working Group Trudy Miller
Request for Comments: 938 ACC
February 1985
Internet Reliable Transaction Protocol
Functional and Interface Specification
STATUS OF THIS MEMO
This RFC is being distributed to members of the DARPA research
community in order to solicit their reactions to the proposals
contained in it. While the issues discussed may not be directly
relevant to the research problems of the DARPA community, they may be
interesting to a number of researchers and implementors. This RFC
suggests a proposed protocol for the ARPA-Internet community, and
requests discussion and suggestions for improvements. Distribution
of this memo is unlimited.
ABSTRACT
The Internet Reliable Transaction Protocol (IRTP) is a transport
level host to host protocol designed for an internet environment. It
provides reliable, sequenced delivery of packets of data between
hosts and multiplexes/demultiplexes streams of packets from/to user
processes representing ports. It is simple to implement, with a
minimum of connection management, at the possible expense of
efficiency.
Miller [Page i]
RFC 938 February 1985
Internet Reliable Transaction Protocol
TABLE OF CONTENTS
INTRODUCTION
1.1 Purpose ......................................... 1
1.2 Underlying Mechanisms ........................... 1
1.3 Relationship to Other Protocols ................. 2
IRTP HEADERS
2.1 Header Format ................................... 3
2.2 Packet Type ..................................... 3
2.3 Port Number ..................................... 3
2.4 Sequence Number ................................. 4
2.5 Length .......................................... 4
2.6 Checksum ........................................ 4
INTERFACES
3.1 User Services Provided By IRTP .................. 5
3.2 IP Services Expected by IRTP .................... 5
MODEL OF OPERATION
4.1 State Variables ................................. 6
4.2 IRTP Initialization ............................. 7
4.3 Host-to-Host Synchronization .................... 7
4.3.1 Response to SYNCH Packets ..................... 7
4.3.2 Response to SYNCH ACK Packet .................. 8
4.4 Transmitting Data ............................... 8
4.4.1 Receiving Data From Using Processes ........... 8
4.4.2 Packet Retransmission ......................... 10
4.5 Receiving Data .................................. 10
4.5.1 Receive and Acknowledgment Windows ............ 11
4.5.2 Invalid Packets ............................... 12
4.5.3 Sequence Numbers Within Acknowledge Window .... 12
4.5.4 Sequence Numbers Within the Receive Window .... 12
4.5.5 Forwarding Data to Using Processes ............ 13
IMPLEMENTATION ISSUES
5.1 Retransmission Strategies ....................... 14
5.2 Pinging ......................................... 14
5.3 Deleting Connection Tables ...................... 16
Miller [Page ii]
RFC 938 February 1985
Internet Reliable Transaction Protocol
LIST OF FIGURES
Figure 1-1 Relationship of IRTP to Other Protocols . 2
Figure 2-1 IRTP Header Format ...................... 3
Figure 4-1 SYNCH Packet Format ..................... 8
Figure 4-2 SYNCH ACK Packet Format ................. 8
Figure 4-3 DATA Packet Format ...................... 9
Figure 4-4 DATA ACK Packet Format .................. 11
Figure 4-5 PORT NAK Packet Format .................. 11
ABBREVIATIONS
ICMP Internet Control Message Protocol
IP Internet Protocol
IRTP Internet Reliable Transaction Protocol
RDP Reliable Data Protocol
TCP Transmission Control Protocol
UDP User Datagram Protocol
Miller [Page iii]
RFC 938 February 1985
Internet Reliable Transaction Protocol
CHAPTER 1 - INTRODUCTION
The Internet Reliable Transaction Protocol (IRTP) is a full duplex,
transaction oriented, host to host protocol which provides reliable
sequenced delivery of packets of data, called transaction packets.
Note: throughout this document the terms host and internet address
are used interchangeably.
1.1 Purpose
The IRTP was designed for an environment in which one host will
have to maintain reliable communication with many other hosts. It
is assumed that there is a (relatively) sporadic flow of
information with each destination host, however information flow
may be initiated at any time at either end of the connection. The
nature of the information is in the form of transactions, i.e.
small, self contained messages. There may be times at which one
host will want to communicate essentially the same information to
all of its known destinations as rapidly as possible.
In effect, the IRTP defines a constant underlying connection
between two hosts. This connection is not established and broken
down, rather it can be resynchronized with minimal loss of data
whenever one of the hosts has been rebooted.
Due to the lack of connection management, it is desirable that all
IRTP processes keep static information about all possible remote
hosts. However, the IRTP has been designed such that minimal state
information needs to be associated with each host to host pair,
thereby allowing one host to communicate with many remote hosts.
The IRTP is more complex than UDP in that it provides reliable,
sequenced delivery of packets, but it is less complex than TCP in
that sequencing is done on a packet by packet (rather than
character stream) basis, and there is only one connection defined
between any two internet addresses (that is, it is not a process
to process protocol.)
1.2 Underlying Mechanisms
The IRTP uses retransmission and acknowledgments to guarantee
delivery. Checksums are used to guarantee data integrity and to
protect against misrouting. There is a host to host
synchronization mechanism and packet sequencing to provide
duplicate detection and ordered delivery to the user process. A
simple mechanism allows IRTP to multiplex and demultiplex streams
Miller [Page 1]
RFC 938 February 1985
Internet Reliable Transaction Protocol
of transaction packets being exchanged between multiple IRTP users
on this host and statically paired IRTP users on the same remote
host.
1.3 Relationship to Other Protocols
The IRTP is designed for use in a potentially lossy internet
environment. It requires that IP be under it. The IP protocol
number of IRTP is 28.
Conversely, IRTP provides a reliable transport protocol for one or
more user processes. User processes must have well-known IRTP
port numbers, and can communicate only with matching processes
with the same port number. (Note that the term port refers to a
higher level protocol. IRTP connections exists between two hosts,
not between a host/port and another host/port.)
These relationships are depicted below.
+--------+ +--------+ +-----------+
| port a |....| port x | | TCP users | Application Level
+--------+ +--------+ +-----------+
| | | ... |
+--------------+ +-----------+
| IRTP | | TCP | Host Level
+--------------+ +-----------+
| |
+--------------------------------------+
| Internet Protocol and ICMP | Internet Level
+--------------------------------------+
|
+--------------------------------------+
| Local Network Protocol | Network Level
+--------------------------------------+
Figure 1-1. Relationship of IRTP to Other Protocols
Miller [Page 2]
RFC 938 February 1985
Internet Reliable Transaction Protocol
CHAPTER 2 - IRTP HEADERS
2.1 Header Format
Each IRTP packet is preceded by an eight byte header depicted
below. The individual fields are described in the following
sections.
0 7 8 15 16 31
+--------+--------+--------+--------+
| packet | port | sequence |
| type | number | number |
+--------+--------+--------+--------+
| length | checksum |
| | |
+-----------------+-----------------+
| |
| optional data octets |
+ . . . . . . . . . . . . . . . . . |
Figure 2-1. IRTP Header Format
2.2 Packet Type
Five packet types are defined by the IRTP. These are:
packet type numeric code
SYNCH 0
SYNCH ACK 1
DATA 2
DATA ACK 3
PORT NAK 4
The use of individual packet types is discussed in MODEL OF
OPERATION.
2.3 Port Number
This field is used for the multiplexing and demultiplexing of
packets from multiple user processes across a single IRTP
connection. Processes which desire to use IRTP must claim port
numbers. A port number represents a higher level protocol, and
data to/from this port may be exchanged only with a process which
has claimed the same port number at a remote host. A process can
claim multiple port numbers, however, only one process may claim
an individual port number. All port numbers are well-known.
Miller [Page 3]
RFC 938 February 1985
Internet Reliable Transaction Protocol
2.4 Sequence Number
For each communicating pair of hosts, there are two sequence
numbers defined, which are the send sequence numbers for the two
ends. Sequence numbers are treated as unsigned 16 bit integers.
Each time a new transaction packet is sent, the sender increases
the sequence number by one. Initial sequence numbers are
established when the connection is resynchronized (see Section
4.3.)
2.5 Length
The length is the number of octets in this transaction packet,
including the header and the data. (This means that the minimum
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -