rfc787.txt
来自「RFC 的详细文档!」· 文本 代码 · 共 1,404 行 · 第 1/5 页
TXT
1,404 行
service with the single-operation interface event of connection-
less service.
Many of those involved in OSI standardization activities have
agreed on a pair of definitions for connectionless data
transmission, one for architectural and conceptual purposes, and
one for service-definition purposes[4]. The architectural
definition, which has been proposed for inclusion in the Re-
ference Model, is:
"Connectionless Data Transmission is the transmission (not
transfer) of an (N)-service-data-unit from a source
(N)-service-access-point to one or more destination
(N)-service-access-points without establishing an (N)-connection
for the transmission."
The service definition, which is intended to provide a workable
basis for incorporating a connectionless service into the
| |
(N)-data | |
request | |
--------->| |
| (N)-LAYER |
| |--------->
| | (N)-data
| | indication
| |
FIGURE 3 - Connectionless Data Transmission
(N)-data | |
request | |
--------->| |
| | (N)-data
| (N)-LAYER |--------->
| | indication
<---------| |
(N)-data | |
confirm | |
FIGURE 4 - "Reliable Datagram" Service
Connectionless Data Transmission, Rev. 1.00
service descriptions for individual layers of the Reference
Model, is:
"A Connectionless (N)-Service is one that accomplishes the
transmission of a single self-contained (N)-service-data-unit
between (N+1)-entities upon the performance of a single
(N)-service access."
Both of these definitions depend heavily on the distinction
between the terms "transmit", "transfer", and "exchange":
Transmit: "to cause to pass or be conveyed through space or a
medium." This term refers to the act of conveying only, without
implying anything about reception.
Transfer: "to convey from one place, person, or thing, to
another." A one-way peer-to-peer connotation restricts the use
of this term to cases in which the receiving peer is party to
and accepts the data transferred.
Exchange: "to give and receive, or lose and take, reciprocally,
as things of the same kind." A two-way peer-to-peer connotation
restricts the use of this term to cases in which both give and
receive directions are clearly evident.
These definitions are clearly of limited usefulness by
themselves. They do, however, provide a framework within which
to explore the following characteristics of CDT:
1. "One-shot" Operation.
The most user-visible characteristic of connectionless data
transmission is the single service access required to initiate
the transmission of a data unit. All of the information re-
quired to deliver the data unit - destination address, quality
of service selection, options, etc. - is presented to the
connectionless (N)-service provider, along with the data, in a
single logical service-access operation that is not considered
by the (N)-service to be related in any way to other access
operations, prior or subsequent (note, however, that since OSI
is not concerned with implementation details, the specific
interface mechanism employed by a particular implementation of
connectionless service might involve more than one interface
exchange to accomplish what is, from a logical standpoint, a
single operation). Once the service provider has accepted a
data unit for connectionless transmission, no further communica-
tion occurs between the provider and the user of the service
concerning the fate or disposition of the data.
Connectionless Data Transmission, Rev. 1.00
2. Two-party Agreement.
Connection-oriented data transfer requires the establishment of
a three-party agreement between the participating (N+1)-entities
and the (N)-service. A connectionless service, however, invol-
ves only two-party agreements: there may be an agreement between
the corresponding (N+1)-entities, unknown to the (N)-service,
and there may be local agreements between each (N+1)-entity and
its local (N)-service provider, but no (N)-protocol information
is ever exchanged between (N)-entities concerning the mutual
willingness of the (N+1)-entities to engage in a connectionless
transmission or to accept a particular data unit.
In practice, some sort of a priori agreement (usually a system
engineering design decision) is assumed to exist between the
(N+1)-entities and the (N)-service concerning those parameters,
formats, and options that affect all three parties as a unit.
However, considerable freedom of choice is preserved by allowing
the user of a connectionless service to specify most parameter
values and options - such as transfer rate, acceptable error
rate, etc. - at the time the service is invoked. In a given
implementation, if the local (N)-service provider determines
immediately (from information available to it locally) that the
requested operation cannot be performed under the conditions
specified, it may abort the service primitive, returning an
implementation-specific error message across the interface to
the user. If the same determination is made later on, after the
service-primitive interface event has completed, the transmis-
sion is simply abandoned, since users of a connectionless
service can be expected to recover lost data if it is important
for them to do so.
3. Self-contained Data Units.
Data units transmitted via a connectionless service, since they
bear no relationship either to other data units or to a "higher
abstraction" (such as a connection), are entirely
self-contained. All of the addressing and other information
needed by the service provider to deliver a data unit to its
destination must be included in each transmission. On the one
hand, this represents a greater overhead than is incurred during
the data transfer phase of a connection-oriented interaction; on
the other, it greatly simplifies routing, since each data unit
carries a complete destination address and can be routed without
reference to connection-related information that may not, for
example, be readily available at intermediate nodes.
4. Data Unit Independence.
The connectionless transmission of data creates no relationship,
express or implied, between data units. Each invocation of a
Connectionless Data Transmission, Rev. 1.00
connectionless service begins the transmission of a single data
unit. Nothing about the service invocation, the transmission of
the data by the connectionless service, or the data unit itself
affects or is affected by any other past, present, or future
operation, whether connection-oriented or connectionless. A
series of data units handed one after the other to a connection-
less service for delivery to the same destination will not
necessarily be delivered to the destination in the same order;
and the connectionless service will make no attempt to report or
recover instances of non-delivery.
Note: A number of popular variations on CDT include
features that run counter to those described
above. These variations deserve to be discussed
on their own merits, but should not be confused
with the architectural concept of connectionless
data transmission.
These characteristics make CDT attractive in applications that
involve short-term request-response interactions, exhibit a high
level of redundancy, must be flexibly reconfigurable, or derive
no benefit from guaranteed in-sequence delivery of data.
3 The Rationale for Connectionless Data Transmission
Because CDT is not as widely understood as connection-oriented
data transfer, it has often been difficult in the course of
developing service and protocol definitions to adduce a ration-
ale for incorporating CDT, and even more difficult to determine
appropriate locations for connectionless service within the
layered hierarchy of OSI. This section addresses the first
concern; the next section will deal with the second.
The most natural way to discover the power and utility of the
CDT concept is to examine applications and implementation
technologies that depend on it. The following observations are
distilled from the specifications and descriptions of actual
protocols and systems (many of which have been implemented), and
from the work of individuals and organizations engaged in the
OSI standardization effort (quoted material is from reference 3,
except where otherwise noted). They are divided into seven
(occassionally overlapping) categories which classify the
applications for which CDT is well suited.
Inward data collection involves the periodic active or passive
sampling of a large number of data sources. A sensor net
Connectionless Data Transmission, Rev. 1.00
gathering data from dedicated measurement stations; a network
status monitor constantly refreshing its knowledge of a network
environment; and an automatic alarm or security system in which
each component regularly self-tests and reports the result, are
all engaged in this type of interaction, in which a "large
number of sources may be reporting periodically and asynchron-
ously to a single reporting point. In a realtime monitoring
situation, these readings could normally be lost on occassion
without causing distress, because the next update would be
arriving shortly. Only if more than one successive update
failed to arrive within a specified time limit would an alarm be
warranted. If, say, a fast connect/disconnect three-way
handshake cost twice as much as a one-way [connectionless] data
transmission which had been system engineered to achieve a
certain acceptable statistical reliability figure, the cost of
connection-oriented inward data collection for a large distri-
buted application could be substantially greater than for
[connectionless collection], without a correspondingly greater
benefit to the user."[3]
Outward data dissemination is in a sense the inverse of the
first category; it concerns the distribution of a single data
unit to a large number of destinations. This situation is
found, for example, when a node joins a network, or a
commonly-accessible server changes its location, and a new
address is sent to other nodes on the network; when a synchroni-
zing message such as a real-time clock value must be sent to all
participants in some distributed activity; and when an operator
broadcasts a nonspecific message (e.g., "Network coming down in
five minutes"). In such cases, the distribution cost (including
time) may far exceed the cost of generating the data; control-
ling the overall cost depends on keeping the cost of dissemina-
tion as low as possible.
Request-response applications are those in which a service is
provided by a commonly accessible server process to a large
number of distributed request sources. The typical interaction
consists of a single request followed by a single response, and
usually only the highest-level acknowledgement - the response
itself - is either necessary or meaningful. Many commercial
applications (point of sale terminals, credit checking, reserva-
tion systems, inventory control, and automated banking systems)
and some types of industrial process control, as well as more
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?