📄 rfc938.txt
字号:
value of the length is 8.)
2.6 Checksum
The checksum is the 16-bit one's complement of the one's
complement sum of the IRTP header and the transaction packet data
(padded with an octet of zero if necessary to make an even number
of octets.)
Miller [Page 4]
RFC 938 February 1985
Internet Reliable Transaction Protocol
CHAPTER 3 - INTERFACES
3.1 User Services Provided by IRTP
The exact interface to the TRTP from the using processes is
implementation dependent, however, IRTP should provide the
following services to the using processes.
o user processes must be able to claim a port number
o users must be able to request that data be sent to a
particular port at an internet address (the port must be one
which the user has claimed)
o users must be able to request transaction data from a
particular port at any (unspecified) remote internet address
(the port must be one which the user has claimed)
o if a port is determined to be unreachable at a particular
destination, the using process which has claimed that port
should be notified
In addition to these minimal data transfer services, a particular
implementation may want to have a mechanism by which a
"supervisory" (that is, port independent) module can define
dynamically the remote internet addresses which are legal targets
for host to host communication by this IRTP module. This
mechanism might be internal or external to the IRTP module itself.
3.2 IP Services Expected by IRTP
IRTP expects a standard interface to IP through which it can send
and receive transaction packets as IP datagrams. In addition, if
possible, it is desirable that IP or ICMP notify IRTP in the event
that a remote internet address is unreachable.
If the IP implementation (including ICMP) is able to notify IRTP
of source quench conditions, individual IRTP implementations may
be able to perform some dynamic adjustment of transmission
characteristics.
Miller [Page 5]
RFC 938 February 1985
Internet Reliable Transaction Protocol
CHAPTER 4 - MODEL OF OPERATION
The basic operation of IRTP is as follows. The first time two hosts
communicate (or the first time after both have simultaneously
failed,) synchronization is established using constant initial
sequence numbers (there is a sequence number for each direction of
transmission). The TCP "quiet time" is used following reboots to
insure that this will not cause inaccurate acknowledgment processing
by one side or the other.
Once synchronization has been achieved data may be passed in both
directions. Each transaction packet has a 16 bit sequence number.
Sequence numbers increase monotonically as new packets are generated.
The receipt of each sequence number must be acknowledged, either
implicitly or explicitly. At most 8 unacknowledged packets may be
outstanding in one direction. This number (called MAXPACK) is fixed
for all IRTP modules. Unacknowledged packets must be periodically
retransmitted. Sequence numbers are also used for duplicate
detection by receiving IRTP modules.
If synchronization is lost due to the failure of one of the
communicating hosts, after a reboot that host requests the remote
host to communicate sequence number information, and data transfer
continues.
4.1 State Variables
Each IRTP is associated with a single internet address. The
synchronization mechanism of the IRTP depends on the requirement
that each IRTP module knows the internet addresses of all modules
with which it will communicate. For each remote internet address,
an IRTP module must maintain the following information (called the
connection table):
rem_addr (32 bit remote internet address)
conn_state (8 bit connection state)
snd_nxt (16 bit send sequence number)
rcv_nxt (16 bit expected next receive sequence number)
snd_una (16 bit first unacknowledged sequence number)
In addition to maintaining the connection tables defined above, it
is required that every IRTP module have some mechanism which
generates "retransmission events" such that SYNCH packets are
periodically retransmitted for any connection in synch_wait state
(see Section 4.3), and the appropriate DATA packet is periodically
retransmitted for any connection in data_transfer state (see
Section 4.4.2). It is implementation dependent whether this
Miller [Page 6]
RFC 938 February 1985
Internet Reliable Transaction Protocol
mechanism is connection dependent, or a uniform mechanism for all
connections, so it has not been made part of the connection state
table. See Chapter 5 for more discussion.
4.2 IRTP Initialization
Whenever a remote internet address becomes known by an IRTP
process, a 2 minute "quiet time" as described in the TCP
specification must be observed before accepting any incoming
packets or user requests. This is to insure that no old IRTP
packets are still in the network. In addition, a connection table
is initialized as follows:
rem_addr = known internet address
conn_state = 0 = out-of-synch
snd_nxt = 0
rcv_nxt = 0
snd_una = 0
Strictly speaking, the IRTP specification does not allow
connection tables to be dynamically deleted and recreated,
however, if this happens the above procedure must be repeated.
See Chapter 5 for more discussion.
4.3 Host-to-Host Synchronization
An IRTP module must initiate synchronization whenever it receives
a DATA packet or a user request referencing an internet address
whose connection state is out-of-synch. Typically, this will
happen only the first time that internet address is active
following the reinitialization of the IRTP module. A SYNCH packet
as shown below is transmitted. Having sent this packet, the host
enters connection state synch_wait (conn_state = 1). In this
state, any incoming DATA, DATA ACK or PORT NAK packets are
ignored. The SYNCH packet itself must be retransmitted
periodically until synchronization has been achieved.
4.3.1 Response to SYNCH Packets -
Whenever a SYNCH packet is received, the recipient, regardless
of current connection state, is required to to return a SYNCH
ACK packet as shown below. At this point the recipient enters
data_transfer state (conn_state = 2).
Miller [Page 7]
RFC 938 February 1985
Internet Reliable Transaction Protocol
4.3.2 Response to SYNCH ACK Packet -
On receipt of a SYNCH ACK packet, the behavior of the recipient
depends on its state. If the recipient is in synch_wait state
the recipient sets rcv_nxt to the sequence number value, sets
snd_nxt and snd_una to the value in the two-octet data field,
and enters data_transfer state (conn_state = 2). Otherwise,
the packet is ignored.
0 7 8 15 16 31
+--------+--------+--------+--------+
|00000000|00000000|00000000 00000000|
+--------+--------+--------+--------+
| 8 | checksum |
+-----------------+-----------------+
Figure 4-1. SYNCH Packet Format
0 7 8 15 16 31
+--------+--------+--------+--------+
|00000001| unused | snd_una |
+--------+--------+--------+--------+
| 10 | checksum |
+-----------------+-----------------+
| rcv_nxt |
+-----------------+
Figure 4-2. SYNCH ACK Packet Format
4.4 Transmitting Data
Once in data_transfer state DATA, DATA ACK and PORT NAK packets
are used to achieve communication between IRTP processes, subject
to the constraint that no more than MAXPACK unacknowledged packets
may be transmitted on a connection at any time. Note that all
arithmetic operations and comparisons on sequence numbers
described in this chapter are to be done modulo 2 to the 16.
4.4.1 Receiving Data From Using Processes -
User processes may request IRTP to send packets of at most 512
user data octets to a remote internet address and IRTP port.
When such a request is received, the behavior of the IRTP
depends on the state of the connection with the remote host and
on implementation dependent considerations. If the connection
Miller [Page 8]
RFC 938 February 1985
Internet Reliable Transaction Protocol
between this IRTP module and the remote host is not in
data_transfer state, that state must be achieved (see Section
4.3) before acting on the user request.
Once the connection is in data_transfer state, the behavior of
the IRTP module in reaction to a write request from a user is
implementation dependent. The simplest IRTP implementations
will not accept write requests when MAXPACK unacknowledged
packets have been sent to the remote connection and will
provide interested users a mechanism by which they can be
notified when the connection is no longer in this state, which
is called flow controlled. Such implementations are called
blocking IRTP implementations. These implementations check, on
receipt of a write request, to see if the value of snd_nxt is
less than snd_una+MAXPACK. If it is, IRTP prepends a DATA
packet header as shown below, and transmits the packet. The
value of snd_nxt is then incremented by one. In addition, the
packet must be retained in a retransmission queue until it is
acknowledged.
0 7 8 15 16 31
+--------+--------+--------+--------+
|00000010|port num| snd_nxt |
+--------+--------+--------+--------+
| length | checksum |
+-----------------+-----------------+
| data octet(s) |
+ . . . . . . . . . . . . . . . . . +
Figure 4-3. DATA Packet Format
Other implementations may allow (some number of) write requests
to be accepted even when the connection is flow controlled.
These implementations, called non-blocking IRTP
implementations, must maintain, in addition to the
retransmission queue for each connection, a queue of accepted
but not yet transmitted packets, in order of request. This is
called the pretransmission queue for the connection.
When a non-blocking implementation receives a write request, if
the connection is not flow controlled, it behaves exactly as a
blocking IRTP. Otherwise, it prepends a DATA packet header
without a sequence number to the data, and appends the packet
to the pretransmission queue. Note that in this case, snd_nxt
is not incremented. The value of snd_nxt is incremented only
when a packet is transmitted for the first time.
Miller [Page 9]
RFC 938 February 1985
Internet Reliable Transaction Protocol
4.4.2 Packet Retransmission -
The IRTP protocol requires that the transaction packet with
sequence number snd_una be periodically retransmitted as long
as there are any unacknowledged, but previously transmitted,
packets (that is, as long as the value of snd_una is not equal
to that of snd_nxt.)
The value of snd_una increases over time due to the receipt of
DATA ACK or PORT NAK packets from a remote host (see Sections
4.5.3 and 4.5.4 below). When either of these packet types is
received, if the incoming sequence number in that packet is
greater than the current value of snd_una, the value of snd_una
is set to the incoming sequence number in that packet. Any
DATA packets with sequence number less than the new snd_una
which were queued for retransmission are released.
(If this is a non-blocking IRTP implementation, for each DATA
packet which is thus released from the retransmission queue,
the earliest buffered packet may be transmitted from the
pretransmission queue, as long as the pretransmission queue is
non-empty. Prior to transmitting the packet, the current value
of snd_nxt is put in the sequence number field of the header.
The value of snd_nxt is then incremented by one.)
Finally, if the acknowledgment is a PORT NAK, the user process
with the nacked port number should be notified that the remote
port is not there.
It is also to be desired, though it is not required, that IRTP
modules have some mechanism to decide that a remote host is not
responding in order to notify user processes that this host is
apparently unreachable.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -