rfc1045.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,491 行 · 第 1/5 页

field, the file server VMTP module need not save multi-packet Responses
for retransmission.  Retransmissions, when needed, are instead handled
directly from the file server buffers.

The SegmentSize field indicates the size of the data segment, if
present.  The CoresidentEntity, MsgDelivery and SegmentSize fields are
usable as additional user data if they are not otherwise used.

The Flags field provides a simple mechanism for the user level to
communicate its use of VMTP options with the VMTP module as well as for
VMTP modules to communicate this use among themselves.  The use of these
options is generally fixed for each remote procedure so that an RPC
mechanism using VMTP can treat the Flags as an integral part of the
RequestCode field for the purpose of demultiplexing to the correct stub.

A Response message control block follows the same format except the
Response is sent from the Server to the Client and there is no
Coresident Entity field (and thus 20 octets of user data).


2.5. Reliability

VMTP provides reliable, sequenced transfer of request and response
messages as well as several variants, such as unreliable datagram
requests.  The reliability mechanisms include: transaction identifiers,


Cheriton                                                       [page 12]



RFC 1045                       VMTP                        February 1988 


checksums, positive acknowledgment of messages and timeout and
retransmission of lost packets.


2.5.1. Transaction Identifiers

Each message transaction is uniquely identified by the pair (Client,
Transaction).  (We defer discussion of the ForwardCount field to Section
2.9.)  The 32-bit transaction identifier is initialized to a random
value when the Client entity is created or allocated its entity
identifier.  The transaction identifier is incremented at the end of
each message transaction.  All Responses with the same specified
(Client, Transaction) pair are associated with this Request.

The transaction identifier is used for duplicate suppression at the
Server.  A Server maintains a state record for each Client for which it
is processing a Request, identified by (Client, Transaction).  A Request
with the same (Client, Transaction) pair is discarded as a duplicate.
(The ForwardCount field must also be equal.)  Normally, this record is
retained for some period after the Response is sent, allowing the Server
to filter out subsequent duplicates of this Request.  When a Request
arrives and the Server does not have a state record for the sending
Client, the Server takes one of three actions:

   1. The Server may send a Probe request, a simple query
      operation, to the VMTP management module associated with the
      requesting Client to determine the Client's current
      Transaction identifier (and other information), initialize a
      new state record from this information, and then process the
      Request as above.

   2. The Server may reason that the Request must be a new request
      because it does not have a state record for this Client if it
      keeps these state records for the maximum packet lifetime of
      packets in the network (plus the maximum VMTP retransmission
      time) and it has not been rebooted within this time period.
      That is, if the Request is not new either the Request would
      have exceeded the maximum packet lifetime or else the Server
      would have a state record for the Client.

   3. The Server may know that the Request is idempotent or can be
      safely redone so it need not care whether the Request is a
      duplicate or not.  For example, a request for the current
      time can be responded to with the current time without being
      concerned whether the Request is a duplicate.  The Response
      is discarded at the Client if it is no longer of interest.



Cheriton                                                       [page 13]



RFC 1045                       VMTP                        February 1988 


2.5.2. Checksum

Each VMTP packet contains a checksum to allow the receiver to detect
corrupted packets independent of lower level checks.  The checksum field
is 32 bits, providing greater protection than the standard 16-bit IP
checksum (in combination with an improved checksum algorithm).  The
large packets, high packet rates and general network characteristics
expected in the future warrant a stronger checksum mechanism.

The checksum normally covers both the VMTP header and the segment data.
Optionally (for real-time applications), the checksum may apply only to
the packet header, as indicated by the HCO control bit being set in the
header.  The checksum field is placed at the end of the packet to allow
it to be calculated as part of a software copy or as part of a hardware
transmission or reception packet processing pipeline, as expected in the
next generation of network interfaces.  Note that the number of header
and data octets is an integral multiple of 8 because VMTP requires that
the segment data be padded to be a multiple of 64 bits.  The checksum
field is appended after the padding, if any.  The actual algorithm is
described in Section 3.2.

A zero checksum field indicates that no checksum was transmitted with
the packet.  VMTP may be used without a checksum only when there is a
host-to-host error detection mechanism and the VMTP security facility is
not being used.  For example, one could rely on the Ethernet CRC if
communication is restricted to hosts on the same Ethernet and the
network interfaces are considered sufficiently reliable.


2.5.3. Request and Response Acknowledgment

VMTP assumes an unreliable datagram network and internetwork interface.
To guarantee delivery of Requests and Response, VMTP uses positive
acknowledgments, retransmissions and timeouts.

A Request is normally acknowledged by receipt of a Response associated
with the Request, i.e. with the same (Client, Transaction).  With
streamed message transactions, it may also be acknowledged by a
subsequent Response that acknowledges previous Requests in addition to
the transaction it explicitly identifies.  A Response may be explicitly
acknowledged by a NotifyVmtpServer operation requested of the manager
for the Server.  In the case of streaming, this is a cumulative
acknowledgment, acknowledging all Responses with a lower transaction
identifier as well.)  In addition, with non-streamed communication, a
subsequent Request from the same Client acknowledges Responses to all
previous message transactions (at least in the sense that either the
client received a Response or is no longer interested in Responses to


Cheriton                                                       [page 14]



RFC 1045                       VMTP                        February 1988 


those earlier message transactions).  Finally, a client response timeout
(at the server) acknowledges a Response at least in the sense that the
server need not be prepared to retransmit the Response subsequently.
Note that there is no end-to-end guarantee of the Response being
received by the client at the application level.


2.5.4. Retransmissions

In general, a Request or Response is retransmitted periodically until
acknowledged as above, up to some maximum number of retransmissions.
VMTP uses parameters RequestRetries(Server) and ResponseRetries(Client)
that indicate the number of retransmissions for the server and client
respectively before giving up.  We suggest the value 5 be used for both
parameters based on our experience with VMTP and Internet packet loss.
Smaller values (such as 3) could be used in low loss environments in
which fast detection of failed hosts or communication channels is
required.  Larger values should be used in high loss environments where
transport-level persistence is important.

In a low loss environment, a retransmission only includes the MCB and
not the segment data of the Request or Response, resulting in a single
(short) packet on retransmission.  The intended recipient of the
retransmission can request selective retransmission of all or part of
the segment data as necessary.  The selective retransmission mechanism
is described in Section 2.13.

If a Response is specified as idempotent, the Response is neither
retransmitted nor stored for retransmission.  Instead, the Client must
retransmit the Request to effectively get the Response retransmitted.
The server VMTP module responds to retransmissions of the Request by
passing the Request on to the server again to have it regenerate the
Response (by redoing the operation), rather than saving a copy of the
Response.  Only Request packets for the last transaction from this
client are passed on in this fashion; older Request packets from this
client are discarded as delayed duplicates.  If a Response is not
idempotent, the VMTP module must ensure it has a copy of the Response
for retransmission either by making a copy of the Response (either
physically or copy-on-write) or by preventing the Server from continuing
until the Response is acknowledged.


2.5.5. Timeouts

There is one client timer for each Client with an outstanding
transaction.  Similarly, there is one server timer for each Client
transaction that is "active" at the server, i.e. there is a transaction


Cheriton                                                       [page 15]



RFC 1045                       VMTP                        February 1988 


record for a Request from the Client.

When the client transmits a new Request (without streaming), the client
timer  is set to roughly the time expected for the Response to be
returned.  On timeout, the Request is retransmitted with the APG
(Acknowledge Packet Group) bit set.  The timeout is reset to the
expected roundtrip time to the Server because an acknowledgment should
be returned immediately unless a Response has been sent.  The Request
may also be retransmitted in response to receipt of a VMTP management
operation indicating that selected portions of the Request message
segment need to be retransmitted.  With streaming, the timeout applies
to the oldest outstanding message transaction in the run of outstanding
message transactions.  Without streaming, there is one message
transaction in the run, reducing to the previous situation.  After the
first packet of a Response is received, the Client resets the timeout to
be the time expected before the next packet in the Response packet group
is received, assuming it is a multi-packet Response.  If not, the timer
is stopped.  Finally, the client timer is used to timeout waiting for
second and subsequent Responses to a multicast Request.

The client timer is set at different times to four different values:

TC1(Server)     The expected time required to receive a Response from
                the Server.  Set on initial Request transmission plus
                after its management module receives a NotifyVmtpClient
                operation, acknowledging the Request.

TC2(Server)     The estimated round trip delay between the client and
                the server.  Set when retransmitting after receiving no
                Response for TC1(Server) time and retransmitting the
                Request with the APG bit set.

TC3(Server)     The estimated maximum expected interpacket time for
                multi-packet Responses from the Server.  Set when
                waiting for subsequent Response packets within a packet
                group before timing out.

TC4             The time to wait for additional Responses to a group
                Request after the first Response is received.  This is
                specified by the user level.

These values are selected as follows.  TC1 can be set to TC2 plus a
constant, reflecting the time within which most servers respond to most
requests.  For example, various measurements of VMTP usage at Stanford
indicate that 90 percent of the servers respond in less than 200
milliseconds.  Setting TC1 to TC2 + 200 means that most Requests receive
a Response before timing out and also that overhead for retransmission


Cheriton                                                       [page 16]



RFC 1045                       VMTP                        February 1988 


for long running transactions is insignificant.  A sophisticated
implementation may make the estimation of TC1 further specific to the
Server.

TC2 may be estimated by measuring the time from when a Probe request is
sent to the Server to when a response is received.  TC2 can also be
measured as the time between the transmission of a Request with the APG
bit set to receipt of a management operation acknowledging receipt of
the Request.

When the Server is an entity group, TC1 and TC2 should be the largest of
the values for the members of the group that are expected to respond.
This information may be determined by probing the group on first use
(and using the values for the last responses to arrive).  Alternatively,
one can resort to default values.

TC3 is set initially to 10 times the transmission time for the maximum
transmission unit (MTU) to be used for the Response.  A sophisticated
implementation may record TC3 per Server and refine the estimate based
on measurements of actual interpacket gaps.  However, a tighter estimate
of TC3 only improves the reaction time when a packet is lost in a packet
group, at some cost in unnecessary retransmissions when the estimate
becomes overly tight.

The server timer, one per active Client, takes on the following values:

TS1(Client)     The estimated maximum expected interpacket time.  Set
                when waiting for subsequent Request packets within a
                packet group before timing out.

TS2(Client)     The time to wait to hear from a client before
                terminating the server processing of a Request.  This
                limits the time spent processing orphan calls, as well
                as limiting how out of date the server's record of the
                Client state can be.  In particular, TS2 should be
                significantly less than the minimum time within which it
                is reasonable to reuse a transaction identifier.

TS3(Client)     Estimated roundtrip time to the Client,

TS4(Client)     The time to wait after sending a Response (or last