RFC722 日本語訳

Network Working Group                                       Jack Haverty  (MIT)
Request for Comments: 722                                             Sept 1976
NIC #36806

ネットワークワーキンググループジャックHaverty(MIT)はコメントのために以下を要求します。 722 1976年9月のNIC#36806

I. ABSTRACT

I. 要約

     This paper addresses some issues concerned with the
design of distributed services.  In particular, it is
concerned with the characteristics of the interactions,
between programs which support some service at various
network sites.  The ideas presented are derived mainly from
experience with various service protocols [Reference 1]
on the ARPANET.

この紙は分配されたサービスのデザインに関するいくつかの問題を扱います。 特に、それは相互作用の特性に関係があります、様々なネットワークサイトでの何らかのサービスをサポートするプログラムの間で。 提示された考えはアルパネットで主に様々なサービスプロトコルの経験[参照1]から引き出されます。

     A model is developed of interactions between programs.
Salient features of this model which promote and simplify
the construction of reliable, responsive services are
identified.  These dualities are motivated by problems
experienced with various ARPANET protocols and in the design
and maintenance of programs which use these protocols in the
performance of some service.

モデルはプログラムの間の相互作用について開発されます。信頼できて、敏感にサービスの工事を促進して、簡素化するこのモデルに関する特徴が特定されます。 これらの二重性は何らかのサービスの性能でこれらのプロトコルを使用するプログラムの様々なアルパネットプロトコルで経験された問題とデザインとメインテナンスで動機づけられています。

     Using this model as a template, the general
architecture of one possible interaction protocol is
presented.  This mechanism provides a foundation on which
protocols would be constructed for particular services,
simplifying the process of creating services which are easy
to implement and maintain, and appear reliable and
responsive to the customer.  This presentation is meant to
serve as an introduction to a specific instance of such a
protocol, called the RRP, which is defined in one of the
references.

テンプレートとしてこのモデルを使用して、1つの可能な相互作用プロトコルの一般的なアーキテクチャは提示されます。 このメカニズムはプロトコルが実装して、維持するのが簡単であり作成サービスのプロセスを簡素化して、特定のサービスのために構成されて、顧客にとって信頼できて敏感に見える基礎を提供します。 このプレゼンテーションは序論として参照の1つで定義されるRRPと呼ばれるそのようなプロトコルの特定のインスタンスに機能することになっています。

                                -1-
II. OVERVIEW AND TERMINOLOGY

-1II。 概要AND用語

     This paper considers the interaction of two programs
which support some network service.  It develops a model of
the interactions of a class of such applications, and
includes some thoughts on desirable goals and
characteristics of implementations.  The model is derived
from a proposal [Reference 2] for mail-handling
systems.  Terminology, as introduced, is highlighted by
capitalization.

この紙は何らかのネットワークがサービスであるとサポートする2つのプログラムの相互作用を考えます。 それは、そのようなアプリケーションのクラスの相互作用のモデルを開発して、実装の望ましい目標と特性に関するいくつかの考えを含んでいます。 メール取り扱いシステムのための提案[参照2]からモデルを得ます。資源化で紹介される用語を強調します。

     Many uses of computer networks involve communication
directly between programs, without human intervention or
monitoring.  Some examples would include an advanced
mail-handling system, or any kind of multi-site data base
manager.

コンピュータネットワークの多くの用途が人間の介入もモニターなしで直接プログラムのコミュニケーションを伴います。 いくつかの例が高度なメール取り扱いシステム、またはどんな種類のマルチサイトデータベースのマネージャも含んでいるでしょう。

     Such programs will be termed SERVERs.  They are the
users of some mechanism which provides the needed
communication and synchronization.  The particular facility
which the servers implement will be termed a SERVICE.
Servers for any particular service may be written in several
languages, operate in various system environments on
different kinds of computers.  The entity which utilizes the
service will be termed the CUSTOMER.

そのようなプログラムはSERVERsと呼ばれるでしょう。 彼らは必要なコミュニケーションと同期を提供する何らかのメカニズムのユーザです。 サーバが実装する特定の施設はSERVICEと呼ばれるでしょう。 どんな特定のサービスのためのサーバも多言語で書かれているかもしれなくて、様々なシステム環境で異種のコンピュータを動作させてください。 サービスを利用する実体はCUSTOMERと呼ばれるでしょう。

     Servers interact during ENCOUNTERs, which are the
periods when two servers are in communication.  An encounter
begins when one server establishes a CHANNEL, a
bidirectional communication link with another server.  The
interaction between servers is effected by the exchange of
information over the channel.  The conventions used in such
an exchange are defined by the PROTOCOLs for the
interaction.

サーバはENCOUNTERsの間、相互作用します。(ENCOUNTERsは2つのサーバがコミュニケーションにある期間です)。 1つのサーバがCHANNELを設立すると、遭遇は始まります、別のサーバがある双方向の通信リンク。チャンネルの上の情報交換でサーバの間の相互作用は作用します。 そのような交換に使用されるコンベンションは相互作用のためにPROTOCOLsによって定義されます。

     The theme of this paper is a model for a particular
class of process interactions which may be used as a basis
for many possible services, where the interactions are
fairly simple.  Services which fit in this category interact
in a manner which can be modeled by a REQUEST-REPLY
DISCIPLINE, which is defined herein.

この紙のテーマは多くの可能なサービスの基礎として使用されるかもしれない特定のクラスのプロセス相互作用のためのモデルです。(そこでは、相互作用がかなり簡単です)。 このカテゴリをうまくはめ込むサービスがここに定義されるREQUEST-REPLY DISCIPLINEがモデル化できる方法で相互作用します。

     A set of guidelines and goals is developed, which
address issues relevant to ease or implementation and
reliability of operation of servers.  These guidelines may
be used to assist in the formulation of protocols specific
to appropriate services.

1セットのガイドラインと目標は開発されていて、どのアドレスがサーバの操作の容易さか実装と信頼性に関連している問題であるか。 これらのガイドラインは、サービスを当てるために特定のプロトコルの定式化を助けるのに使用されるかもしれません。

                                -2-
     Additionally, the guidelines presented may be used as a
basis for a general process interaction protocol, by
extracting the primitives and operational concepts which
would be common to a protocol constructed for virtually any
such service.

-2 -さらに、提示されたガイドラインは一般的なプロセス相互作用プロトコルの基礎として基関数を抜粋することによって、使用されたかもしれなくて、プロトコルに共通の操作上の概念は実際にはどんなそのようなもののためにもサービスを構成しました。

     From these ideas, a protocol which provides a
foundation can be constructed, to be extended for particular
services by adding primitives specific to each.  The RRP
[Reference 4] is one such possible protocol.  It
provides basic primitives to control the interaction between
servers, and a mechanism for extending the primitives to
include service-specific operations.

これらの考えから、特定のサービスのためにそれぞれに特定の基関数を加えることによって広げられるために基礎を提供するプロトコルは構成できます。 RRP[参照4]はそのようなプロトコルの可能な1つです。 それは、サーバの間で相互作用を制御して、サービス特有の操作を含むように基関数を広げるためにメカニズムを制御するために基本の基関数を提供します。

     The discussion here is primarily intended to explain
the basis for the design of the RRP, and to present some
general issues of design of services.

ここでの議論は、RRPのデザインの基礎について説明して、サービスのデザインのいくつかの一般答弁を提示することを主として意図します。

III. THE REQUEST-REPLY DISCIPLINE

III。 要求回答規律

     The class of services relevant to this discussion are
those whose interactions could be performed in the following
manner.

この議論に関連しているサービスのクラスは以下の方法で相互作用を実行できたそれらです。

     Two servers have established a channel by some external
means.  A single interaction between servers begins with one
server, called the REQUESTER, issuing a request.  The server
receiving that request, the RESPONDER, issues a REPLY.  The
requester interprets the reply sequence to determine whether
the request was successful, failed, or partially failed, and
takes appropriate action.  Such a sequence of events is
termed an EXCHANGE.  This is analogous to a subroutine call
in a simple single-processor operating system.

2つのサーバがいくつかの外部の手段でチャンネルを確立しました。 サーバの間の単一の相互作用は要求を出すREQUESTERと呼ばれる1つのサーバで始まります。 その要求を受け取るサーバ(RESPONDER)はREPLYを発行します。 リクエスタは、要求がうまくいった、失敗された、または部分的に失敗されていたかを決定するために回答系列を解釈して、適切な行動を取ります。 イベントのそのような系列はEXCHANGEと呼ばれます。 これは簡単な単一のプロセッサオペレーティングシステムでサブルーチン呼出しに類似しています。

     This model is termed a REQUEST-REPLY DISCIPLINE of
program interaction.  It should be noted that this is only a
model of program behavior, and does not necessarily exclude
services which require, for example, some measure of
pipelining of requests for efficiency in long-delay
situation;.  In fact, most network services would require
such measures, put their interactions can still be reduced
to the request-reply model.

このモデルはプログラム相互作用のREQUEST-REPLY DISCIPLINEと呼ばれます。 これがプログラムの振舞いのモデルだけであり、必ず例えば長時間の遅延状況における効率を求める要求のある程度のパイプライン処理を必要とするサービスを除くというわけではないことに注意されるべきです; 事実上、ほとんどのネットワーク・サービスがそのような測定を必要として、置かれて、まだそれらの相互作用は要求回答モデルに変えることができます。

     At any time, one of the partners is in control of the
interaction, and is termed the MASTER of the interaction.
The other partner is called the SLAVE.  In the simplest
cases, the requester is always the master, although this is
not always true in particular implementations, such as the
RRP [Reference 4].

いつでも、パートナーのひとりは、相互作用のコントロールにはいて、相互作用のMASTERと呼ばれます。 もう片方のパートナーはSLAVEと呼ばれます。 最も簡単な場合では、いつもリクエスタはマスターです、これが特定の実装でいつも本当であるというわけではありませんが、RRP[参照4]などのように。

                                -3-
IV. CHARACTERISTICS OF AN INTERACTION MECHANISM

-3IV。 相互作用メカニズムの特性

     The following set of characteristics desirable in an
interaction mechanism is the result of experience with
program communication in various ARPANET applications, such
as message services, file transfer, Datacomputer, and remote
job entry applications.

相互作用メカニズムで望ましい特性の以下のセットは様々なアルパネットアプリケーションにおけるプログラムコミュニケーションの経験の結果です、メッセージサービスや、ファイル転送や、Datacomputerや、リモートジョブエントリアプリケーションなどのように。

     In attempting to produce such systems, several
qualities recurred which would be desirable in the
substructure upon which the systems are built.  These
characteristics would promote ease of writing and debugging
servers, maintaining reliability, and providing services
which are responsive to customer needs, while avoiding
disruptions of service.

そのようなシステムを作成するのを試みる際に、いくつかのシステムが組立している基礎で望ましい品質が再発しました。 これらの特性はサーバを書いて、デバッグする容易さを促進するでしょう、信頼性を維持して、サービスの分裂を避けている間顧客の要望に敏感なサービスを提供して。

     The qualities desired in the interaction mechanism are
presented along with a discussion of the effects which they
are intended to produce in the associated services.  It must
be emphasized that this discussion is related to a class of
simple services, and might not be appropriate for more
complex applications.

相互作用メカニズムで必要な品質は彼らが関連サービスで生産することを意図する効果の議論と共に提示されます。 この議論が簡単にサービスのクラスに関連して、より複雑なアプリケーションには、適切でないかもしれないと強調しなければなりません。

     1/ Servers must be able to transfer data in a precise
        fashion, retaining the structure and semantic
        meaning of the data, despite the dissimilarities of
        the computer systems in which they function.

1/サーバは正確なファッションによるデータを移すことができなければなりません、データの構造と意味意味を保有して、それらが機能するコンピュータ・システムの相違点にもかかわらず。

     2/ Synchronization and timing problems due to the
        characteristics of the communications link must be
        isolated and handled separately from any which
        might be characteristic of the service itself.

2/同期と別々にいずれからもコミュニケーションリンクの特性への支払われるべきものを隔離されて、扱わなければならないことにおける独特であるかもしれないサービス自体のタイミング問題。

     3/ Since services may wish to provide expanded
        facilities as they are used and developed, a
        mechanism must be included to enable the service
        protocol to evolve.

3 サービスが提供したがっているかもしれないので、それらが使用されて、開発されるとき、/は設備を拡張していて、メカニズムはサービスプロトコルが発展するのを可能にするために含まなければなりません。

     4/ Since various programs which act as servers may
        undergo simultaneous development, care must be
        taken to insure that servers with different
        capabilities interact reliably, maintaining at
        least the same level of service as existed
        previously.

4 サーバが同時展開を受けるとき作動する様々なプログラム以来の/、異なった能力があるサーバが確かに相互作用するのを保障するために注意しなければなりません、以前に少なくとも存在することに対する同じレベルのサービスを維持して。

     5/ The mechanisms for extending the facilities must
        avoid requiring servers to be modified when new
        capabilities are introduced, but not impede
        progress by maintainers who are anxious to provide
        a new or experimental service.

5 施設を広げるためのメカニズムが変更されて、新しい能力が導入しますが、新しいか実験的なサービスを提供することを切望していた状態で維持装置による進歩を妨害しないとサーバは必要であることを避けなければならない/。

                                -4-
     These qualities may be placed in three categories, data
precision (1), process synchronization (2), and service
enhancement (3, 4, 5).  Each will be discussed separately in
the following sections.  The significance of each quality
and its effect on the associated service characteristics
will be included, with some references to related problems
with current and past services.

-4 -これらの品質は3つのカテゴリ、データ精度(1)、プロセス同期(2)、およびサービス増進(3、4、5)に置かれるかもしれません。 別々に以下のセクションでそれぞれについて議論するでしょう。 関連サービスの特性への各品質とその効果の意味は含まれるでしょう、電流とサービスの先における関連する問題のいくつかの参照で。

     Since these considerations are common to many possible
services, it is appropriate for the interaction protocol to
include them within its machinery as much as possible.  This
permits services to be implemented which, if carefully
designed, inherit these properties from the interaction
substrate.

これらの問題が多くの可能なサービスに共通であるので、相互作用プロトコルが機械の中にそれらをできるだけ含んでいるのは、適切です。 これは相互作用基板からこれらの特性を実装される入念に設計されるなら世襲されるサービスに可能にします。

V. PRECISE DATA TRANSFER

V。 正確な資料転送

     Precision in data transfer permits semantic and
structural information which exists in the sender's instance
of a datum to be reproduced in the receiver's image of the
datum, even though it may be represented in the systems
involved in entirely different fashions.

データ転送による精度は、送付者のデータのインスタンスで存在する意味的で構造的な情報が受信機のデータのイメージで再生することを許可します、それは完全に異なったファッションにかかわるシステムで表されるかもしれませんが。

     For programs to provide powerful, reliable
capabilities, they must be able to interact using data which
is meaningful to the particular service involved.  The
interaction mechanism must permit services to define their
own relevant data types, and transfer such items efficiently
and precisely.  This facility provides a 'standard' for data,
permitting the service's designers to concentrate on
higher-level issues of concern to the service itself.

プログラムが強力で、信頼できる能力を提供するように、それらはかかわった特定のサービスに重要なデータを使用することで相互作用できなければなりません。 相互作用メカニズムは、サービスがそれら自身の関連データ型を定義するのを可能にして、効率的に正確にそのような商品を移さなければなりません。 この施設はデータの'規格'を提供します、サービスのデザイナーがサービス自体に重要なよりハイレベルの問題に集中することを許可して。

     Data of a given type should be recognizable as such
without need for context.  The mechanism should also permit
new data types to be handled by older servers without error,
even though they cannot interpret the semantics of the new
data.

与えられたタイプのデータは文脈の必要性なしでそういうものとして認識可能であるべきです。 また、メカニズムは、新しいデータ型が、より古いサーバによって誤りなしで扱われるのを可能にするはずです、彼らが新しいデータの意味論を解釈できませんが。

     These characteristic permits services to be designed in
terms of the abstract data they need to function, without
continued detailed concern for the particular formats in
which it is represented within various machines.

これらの特性は、サービスが彼らが機能するように必要とする抽象的なデータで設計されていることを許可します、それが様々なマシンの中に表される特定の形式に関する継続的な詳細な心配なしで。

     For example, servers may need to transfer a datum
identifying a particular date, which may be represented
internally within systems in different forms.  The data
transfer mechanism should be capable of transferring such a
datum as a date per se, rather than a strict pattern or bits
or characters.

例えば、サーバは、システムの中に異なったフォームで内部的に表されるかもしれない特定の期日を特定するデータを移す必要があるかもしれません。データ転送メカニズムは厳しいパターンよりそういうものと、むしろ日付、ビットまたはキャラクタのようなデータを移すことができるべきです。

                                -5-
     For example, in current FTP-based mail systems,
messages often contain information with significant semantic
meaning, which is lost or obscured when transferred between
sites.  An example might be a file specification, which
effectively loses all identity as such when translated into
a simple character stream.  People can usually recognize
such streams as file names, but it is often extremely
difficult, time-consuming, and inefficient to construct a
program to do so reliably.  As a result, services which
should be easy to provide to the customer, such as automatic
retrieval of relevant files, become difficult and
unreliable.

-5 -例えば、現在のFTPベースのメールシステムでは、メッセージはしばしば重要な意味意味がある情報を含んでいます。(サイトの間に移すと、失うか、または意味をあいまいにします)。 例はファイル仕様であるかもしれません。(簡単なキャラクタストリームに翻訳されると、事実上、その仕様はそういうもののすべてのアイデンティティを失います)。 人々は、そのようなストリームがファイル名であると通常認めることができますが、あまりに確かにするプログラムを建築するのは、しばしば非常に難しく、手間がかかっていて、効率が悪いです。 その結果、関連ファイルの自動検索などの顧客に提供するのが簡単であるはずであるサービスは難しく頼り無くなります。

     Some success has been achieved in handling certain
data, such as dates and times, by defining a particular
character pattern which, if seen in a particular context,
can be recognized as a date or time.  Each of these cases
has been done on an individual basis, by defining a format
for the individual data of concern.  Generally, the format
depends to some extent on the datum occurring within a
particular context, and is not unique enough to be
identifiable outside of that context.

何らかの成功が、あるデータを扱う際に遂げられました、日付や回のように、特定の文脈で見られるなら日付か時間として認識できる特定のキャラクタパターンを定義することによって。 それぞれに関するこれらのケースは個別的に完了していました、関心の個々のデータのために書式を定義することによって。 一般に、形式は、特定の文脈の中に現れるデータにある程度よって、外でその文脈で身元保証可能であることができるくらいにはユニークではありません。

     A particular service can achieve data precision by
meticulous specification of the protocols by which data is
transferred.  This need is widespread enough, however, that
it is appropriate to consider inclusion of a facility to
provide data precision within the interaction mechanism
itself.

特定のサービスはデータがわたっているプロトコルの細心な仕様でデータ精度を実現できます。 しかしながら、この必要性は施設の包含が相互作用メカニズム自体の中でデータ精度を提供すると考えるのが適切であるほど広範囲です。

     The major effect of this would be to facilitate the
design of reliable, responsive services, by relieving the
service's designers from the need to consider very low-level
details of data representation, which are usually the least
interesting, but highly critical, aspects of the design.  By
isolating the data transfer mechanism, thIs architecture
also promotes modularity or implementations, which can
reduce the cost and time needed to implement or modify
services.

この主要な効果は信頼できて、敏感にサービスのデザインを容易にするだろうことです、非常に重要でない中で通常、どんなものであるも最もおもしろいデータ表現の非常に低レベルである詳細を考える必要性からサービスのデザイナーを救うことによって、デザインの局面。 また、データ転送メカニズムを隔離することによって、thIsアーキテクチャはモジュール方式か実装を促進します。(サービスを実装するか、または変更するのが必要である場合、実装はコストと時間を削減できます)。

VI. PROCESS SYNCHRONIZATION

VI。 プロセス同期

     A major source of problems in many services involved
synchronization of server; interacting over a relatively
low-bandwidth, high-delay communications link.

多くのサービスにおける問題の主要な源はサーバの同期にかかわりました。 aの上に相互作用する、比較的、低バンド幅の、そして、高い遅れのコミュニケーションはリンクされます。

     Interactions in most services involve issuing a command
and waiting for a response.  The number of responses which
can be elicited by a given command often varies, and there
is usually no way to determine if all replies have arrived.
Programs can easily issue a request before the responses to
a previous request have completed, and get out of
synchronization in a response is incorrectly matched to a
request.  Each server program must be meticulously designed
to be capable of recovering if an unexpected reply arrives
after a subsequent command is issued.

ほとんどのサービスにおける相互作用は、コマンドを発行して、応答を待つことを伴います。 与えられたコマンドで引き出すことができる応答の数はしばしば異なります、そして、通常、すべての回答が到着したかどうか決定する方法が全くありません。 プログラムは容易に、前の要求への応答が同期から終了して、得られる前にaでは、応答が不当に要求に合われているという要求を出すことができます。 その後のコマンドを発行した後に予期しない返答が到着するなら回復できるようにそれぞれのサーバプログラムをきちょうめんに設計しなければなりません。

                                -6-
     Note that, for reliable operation, it is always
necessary that each response cause a reply to occur, at
least in the sense that the request ts confirmed at some
point.  No service should perform a critical operation, such
as deleting a file, which depends on the success of a
previous request unless it has been confirmed.  Requests in
current protocols which do not appear to cause a reply may
be viewed as confirmed later when a subsequent request is
acknowledged, while such protocols work, they are more
opaque than desirable, and consequently more difficult to
implement.

回答が各応答で起こるのがいつも必要です、少なくとも要求tが何らかのポイントで確認した意味で信頼できる操作に-6メモ。 どんなサービスも重要な操作を実行するべきではありません、ファイルを削除するのなどように。(それが確認されていない場合、ファイルは前の要求の成功によります)。 それらは、回答を引き起こすように見えない現在のプロトコルにおける要求がその後の要求が後で承諾されるとき、確認されるように見られるかもしれません、そのようなプロトコルが働いていますが望ましいというよりも不透明であって、その結果、実装するのは、より難しいです。

     These characteristics of protocols have often resulted
in implementation of ad hoc methods for interaction, such as
timeouts or sufficient length to assure correctness in an
acceptably high percentage of situations.  Often this has
required careful tuning of programs as experience in using a
protocol shows which commands are most likely to cause
problems.  Such methods generally result in a service which
is less responsive, powerful, or efficient than desirable,
and expensive to build and maintain.

プロトコルのこれらの特性はしばしば相互作用のための臨時のメソッドの実装をもたらしました、許容できて高い百分率における正当性に状況を保証できるくらいのタイムアウトや長さのように。 プロトコルを使用する経験が、どのコマンドが最も問題を起こしそうであるかを示すとき、しばしば、これはプログラムの慎重な調整を必要としました。一般に、そのようなメソッドは敏感であるか、強力であるか、効率的であるというよりも望ましくて、建てて、維持するために高価なサービスをもたらします。

     Additionally, protocol specifications for services have
often been incomplete, in that an enumeration of the
responses which may occur for a given command is inaccurate
or non-existent.  This greatly complicates the task of the
programmer trying to construct an intelligent server.  In
most cases, servers are slowly improved over time as
experience shows which responses are common in each
instance.

さらに、サービスのためのプロトコル仕様はしばしば不完全です、与えられたコマンドのために起こるかもしれない応答の列挙が不正確であるか、または実在しないので。 これはプログラマが知的なサーバを構成しようとするタスクを大いに複雑にします。多くの場合、経験が、どの応答がどの場合にも一般的であるかを示すとき、サーバは時間がたつにつれて、ゆっくり改良されます。

     The synchronization problems mentioned above are in
addition to those which naturally occur as part of the
service operation.  Thus, problems of synchronization may
be split into two classes, those inherent in the service,
and those associated with the interaction mechanism itself.

前記のように同期問題はサービス操作の一部として自然に起こるものに加えています。 したがって、同期の問題は2つのクラス、サービスに固有のそれら、および相互作用メカニズム自体に関連づけられたものに分けられるかもしれません。

     Construction of reliable, responsive servers can be
assisted by careful design of the interaction mechanism and
protocols.  An unambiguous, completely specified mapping
between commands and responses is desirable.
Synchronization considerations of the two types can be
attacked separately.  An interaction mechanism which handles
its own synchronization can be provided as a base for
service' designers to use, relieving them of considerations
of the low-level, protocol-derived problems, by providing
primitives which encourage the design of reliable services.

相互作用メカニズムとプロトコルの慎重なデザインは信頼できて、敏感なサーバの工事を促進できます。 コマンドと応答の間の明白で、完全に指定されたマッピングは望ましいです。 別々に2つのタイプの同期問題を攻撃できます。 'サービス'デザイナーが使用するベースとしてそれ自身の同期を扱う相互作用メカニズムは提供できます、低レベルで、プロトコルで派生している問題の問題を彼らに取り除いて、信頼できるサービスのデザインを奨励する基関数を提供することによって。

     To achieve a reasonable effective bandwidth, it is
usually desirable to permit interacting programs to operate
in a full-duplex fashion.  Significant amounts of data are
often in transit at any time.  This magnifies the problems
associated with interaction by introducing parallelism.  The
interaction mechanism can also be structured to provide ways
of handling these problems, and to provide a basis on which
servers which exploit parallelism can be constructed.

妥当な有効な帯域幅を達成するために、通常、全二重ファッションで操作するプログラムを相互作用させるのを許容するのは望ましいです。 かなりの量のデータがしばしばいつでもトランジットでそうです。 これは平行関係を導入することによって相互作用に関連している問題を拡大します。 また、これらの問題を取り扱いの方法に提供して、平行関係を利用するサーバを構成できる基礎を提供するために相互作用メカニズムを構造化できます。

                                -7-
     Many of these problems are too complex to warrant their
consideration in any but the most active services.  As a
result, services are often constructed which avoid
problems by inefficiencies in their operation, as mentioned
above.  Provision of an interaction mechanism and primitives
for use by such services would promote efficiency interaction
even by simple services which do not have the resources to
consider all the problems in detail.

-7 -これらの問題の多くがいずれにもかかわらず、最も活発なサービスにおける彼らの考慮を保証できないくらい複雑です。 その結果、上に言及されるように彼らの操作における非能率で問題を避けるサービスがしばしば構成されます。 そのようなサービスによる使用のための相互作用メカニズムと基関数の支給は、詳細にすべての問題を考えるためにリソースを持っていない簡単なサービスによるさえ効率相互作用を促進するでしょう。

VII. SERVICE ENHANCEMENT

VII。 サービス増進

     When particular programs implementing a service are
undergoing development simultaneously by several
organizations, or are maintained at many distributed sites.
many problems can develop concerning the compatibility of
dissimilar servers.

特定であるときに、サービスを実装するプログラムが、同時にいくつかの組織で開発を受けるか、または多くの分配されたサイトで維持されます。多くの問題が異なったサーバの互換性に関して発生できます。

     This situation occurs in the initial phase of
implementing a service, as well as whenever the protocols
are modified to fix problems or expand the service.
Virtually every interaction protocol is modified from time
to time to add new capabilities.  Two particular examples
arc the TELNET protocol and mail header formats.

サービスを実装して、プロトコルが問題を解決するか、またはサービスを広げるように変更されるときはいつも、この状況は初期位相で起こります。 実際にはあらゆる相互作用プロトコルが、新しい能力を加えるように時々変更されます。 TELNETが議定書の中で述べて、メールヘッダがフォーマットする2の特定の例のアーク。

     In most cases, the basic protocol had no facility for
implementing changes in an invisible fashion.  This has had
several consequences.

多くの場合、基本プロトコルには、目に見えないファッションにおける変化を実装するための施設が全くありませんでした。 これには、いくつかの結果がありました。

     First, it is very difficult to change a protocol unless
the majority of concerned maintainers are interested in the
changes and therefore willing to exert effort to change the
programs involved.  This situation has occurred in previous
cases because any change necessarily impacts all servers.
The services involved therefore often stagnate, and it
becomes inappropriately difficult to provide a customer with
a seemingly simple enhancement.

まず最初に、関係がある維持装置の大部分が変化に関心があってしたがって、プログラムがかかわった変化に取り組みを出すことを望んでいない場合、プロトコルを変えるのは非常に難しいです。 どんな変化も必ずすべてのサーバに影響を与えるので、この状況は先の事件で起こりました。 したがって、かかわるサービスはしばしば停滞します、そして、外観上簡単な増進を顧客に提供するのは不適当に難しくなります。

     Second, when protocols change by will of the majority,
existing servers often stop working or behave erratically
which they suddenly find their partner speaking a new
language.  This is equally disconcerting to the service
customer, as well as annoying to the maintainers of the
servers at the various sites affected.

プロトコルが大部分について存在することによって変化するとき、2番目に、サーバは、しばしば仕事を中止するか、または彼らが突然新しい言語を話しているパートナーを見つけるものをめくらめっぽうに、振る舞わせます。 これは等しく影響を受ける様々なサイトでサーバの維持装置にいらいらさせることと同様にサービス顧客に混乱させられています。

     These problems can be easily avoided, or at least
significantly reduced, by careful design of the interaction
protocols.  In particular, the interaction mechanism itself
can be structured to avoid the problem entirely, leaving
only those problems associated with the particular service
operations themselves.

これらの問題は、容易に避けるか、または相互作用プロトコルの慎重なデザインで少なくともかなり減少できます。 特に、問題を完全に避けるために相互作用メカニズム自体を構造化できます、それらの問題だけを特定の戦務活動自体に関連づけられたままにして。

     The interaction machinery should be structured so that
the mechanisms of the interaction substrate itself may be
improved or expanded in a fashion which is absolutely
invisible to current servers.

相互作用機械は、現在のサーバに絶対に目に見えないファッションで相互作用基板自体のメカニズムを改良するか、または広げることができるように構造化されるべきです。

                                -8-
     1/ No server should be required to implement a change
        which is unimportant to its customers.

-8- 1/いいえ、サーバが、顧客にとって、重要でない変化を実装するのに必要であるべきです。

     2/ No server should be prevented from utilizing a new
        facility when interacting with a willing partner.

2/いいえ、サーバは望んでいるパートナーと対話するとき、新しい施設を利用するのが防がれるべきです。

     3/ Service should not be degraded in any way when a
        new protocol facility is made available.

新しいプロトコル施設を利用可能にするとき、3/サービスを何らかの方法で下がらせるべきではありません。

     In cases where a single service is provided by
different server programs at many sites, it is desirable for
the various sites to be able to participate at a level
appropriate to them.  A new server program should be able to
participate quickly, using only simple mechanisms of the
protocol, and evolve into more advanced, powerful, or
efficient interaction as desired.  Sites wishing to utilize
advanced or experimental features must be allowed to do so
without imposing implementation of such features on others.
Conversely, sites wishing to participate in a minimal
fashion must not prevent others from using advanced
features.  In all cases, the various servers must be capable
of continued interaction at the highest level supported by
both.

ただ一つのサービスが多くのサイトで異なったサーバプログラムで提供される場合では、様々なサイトがそれらに、適切なレベルで参加できるのは、望ましいです。 新しいサーバプログラムは、プロトコルの簡単なメカニズムだけを使用して、すぐに参加して、望まれているように高度であるか、強力であるか、効率的な相互作用に発展できるはずです。 そのような特徴の実装を他のものに課さないで、高度であるか実験している特徴を利用したがっているサイトにそうさせなければなりません。 逆に、最小量のファッションに参加したがっているサイトは、他のものが高度な特徴を使用するのを防いではいけません。 すべての場合では、様々なサーバは両方によって上層部によってサポートされた継続的な相互作用ができなければなりません。

     The goal is an evolving system which maintains
reliability as well as both upward and downward
compatibility.  The protocol itself should have these
characteristics, and it should provide the mechanisms to
service interaction protocols to be defined which
inherit these qualities.

目標は、上向きに両方と同様に信頼性を維持する発展システムと下位互換です。 プロトコル自体には、これらの特性があるべきです、そして、それはこれらの品質を引き継ぐ定義されるべきサービス相互作用プロトコルにメカニズムを提供するべきです。

VIII. STRUCTURING AN INTERACTION MECHANISM

VIII。 相互作用メカニズムを構造化します。

     The qualities presented previously should provide at
least a starting point for implementation of services which
avoid the problems mentioned.  The rest of this paper
addresses issues of a particular possible architecture of an
interaction mechanism.

以前に提示された品質は言及された問題を避けるサービスの実装のための少なくとも出発点を提供するべきです。 この紙の残りは相互作用メカニズムの特定の可能なアーキテクチャの問題を扱います。

     The design architecture splits the service-specific
conventions from those of the interaction per se.  An
interaction protocol is provided which implements the
machinery of the request-reply model, and includes handling
of the problems of data precision, synchronization, and
enhancement.  This protocol is not specific to any service,
but rather provides primitives, in the form of
service-designed requests and replies, on which a particular
service protocol is built.

デザインアーキテクチャはそういうものとして相互作用のものからのサービス特有のコンベンションを分割します。 どれが要求回答モデルの機械を実装して、データ精度の問題の取り扱い、同期を含むか、そして、増進を相互作用プロトコルに提供します。 このプロトコルは、どんなサービスにも特定ではありませんが、むしろサービスで設計された要求と回答の形に基関数を供給します。(その時、特定のサービスプロトコルは組立しています)。

     An actual implementation for a particular service could
merge the code of the interaction protocol with the service
itself, or the interaction protocol could be provided as a
'service' whose customer is the service being implemented.

特定のサービスのための実際の実装が相互作用プロトコルのコードをサービス自体に合併するかもしれませんか、または顧客が実装されるサービスである'サービス'として相互作用プロトコルを提供できました。

                                -9-
     The goals of this design architecture follow.

-9 -このデザインアーキテクチャの目標は従います。

     1/ Provision of a general interaction mechanism to be
        used by services which follow a request-reply
        discipline.  Services would design their protocols
        using the primitives of the mechanism as a
        foundation.

要求回答規律に従うサービスで使用されるべき一般的な相互作用メカニズムに関する1/条項。 サービスは、基礎としてメカニズムに関する基関数を使用することでそれらのプロトコルを設計するでしょう。

     2/ INTERACTION MECHANISM EXTENSIBILITY.  The
        interaction mechanism may be expanded as desired
        without impacting on existing servers unless they
        wish to use the new features.

2/相互作用メカニズム伸展性。 相互作用メカニズムは新機能を使用したいと思わないなら既存のサーバで影響を与えないで望まれているように広げられるかもしれません。

     3/ SERVER EXTENSIBILITY.  Servers can be implemented
        using the most basic primitives.  Implementations
        may later be extended to utilize additional
        capabilities to negate some of the inefficiency
        inherent in a strict request-reply structure.

3/サーバ伸展性。 最も基本の基関数を使用することでサーバを実装することができます。 実装は、後で厳しい要求回答構造で固有の何らかの非能率を否定する追加能力を利用するために広げられるかもしれません。

     4/ SERVICE EXTENSIBILITY.  The primitives permit a
        service to be expanded as desired without impacting
        on existing servers in any way unless they wish to
        use the new features.

4/サービス伸展性。 基関数は、新機能を使用したいと思わないなら既存のサーバで何らかの方法で影響を与えないで望まれているようにサービスが広げられるのを許容します。

     5/ SERVER COMPATIBILITY.  Within the set of servers of
        a given application, it is possible to have
        different servers operating at different levels of
        sophistication, and still maintain the ability for
        any pair of servers to interact successfully.

5/サーバの互換性。 与えられたアプリケーションのサーバのセットの中では、異なったレベルに関する洗練で作動する異なったサーバを持って、まだどんな組のサーバも首尾よく相互作用する能力を維持しているのは可能です。

     These goals involve two basic areas of design.  First,
the interaction mechanism itself is designed to meet the
goals.  Secondly, guidelines for structure of the particular
service' protocols are necessary, in order for it to inherit
the qualities needed to meet the goals.

これらの目標はデザインの2つの基本的な領域にかかわります。 まず最初に、相互作用メカニズム自体は、目標を達成するように設計されます。 '第二に、特定の'サービスプロトコルの構造のためのガイドラインが必要です、目標を達成するのに必要である品質を引き継ぐために。

IX. PARTITIONING THE PROBLEM

IX。 問題を仕切ります。

     In defining the interaction mechanism itself, the
problem may be simplified by considering two areas of
concern separately.

相互作用メカニズム自体を定義する際に、2つの領域が重要であると考えることによって、問題は別々に簡素化されるかもしれません。

     1/ The characteristics and format of the data conveyed
        by the channel may be defined.

1 データの特性と形式がチャンネルで運んだ/は定義されるかもしれません。

     2/ The conventions used to define the interaction may
        be defined, in terms of the available data
        supported by the channel.

2 コンベンションが相互作用を定義するのに使用した/は定義されるかもしれません、チャンネルによってサポートされた利用可能なデータに関して。

                                -10-
     For purposes of this paper, the data repertoire and
characteristics of the channel are assumed to be as
described in [Reference 3] and summarized in an
appendix.  Discussions of the interaction between servers
will use only the abstract concepts of primitive and
semantic data items, to isolate the issues of interaction
from those of data formats and communication details, and
therefore simplify the problem.

-10 -この紙の目的のために、チャンネルのデータレパートリーと特性が[参照3]で説明されて、付録にまとめられるようにあると思われます。 サーバの間の相互作用の議論は、データ形式とコミュニケーションの詳細のものから相互作用の問題を隔離するのに原始的で意味のデータ項目に関する抽象概念だけを使用して、したがって、問題を簡素化するでしょう。

     Additionally, actual implementation of a mechanism
following the ideas presented here can be accomplished in a
modular fashion, isolating code which is concerned with the
channel itself from code concerned with the interaction
behavior.

さらに、モジュール方式でここに提示された考えに従うメカニズムの実際の実装を達成できます、相互作用の振舞いに関するコードからチャンネル自体に関するコードを隔離して。

     The interaction mechanism provides primitives to the
service' designer which are likewise defined in terms of the
data items available.  Service designers are encouraged, but
not required, to define interactions in terms of these data
only.

'相互作用メカニズムはサービス'デザイナーへの利用可能なデータ項目で同様に定義される基関数を提供します。 サービスデザイナーは、奨励されますが、これらのデータだけに関して相互作用を定義する必要はありません。

X. THE PRIMITIVES

X。 基関数

     The interaction mechanism assumes the existence of a
channel [Reference 3] between two servers.  Two
new semantic data types are defined to implement the
interaction.  These are, unsurprisingly, called CONTROL
REQUESTs and CONTROL REPLYs.  Each of these data items
contains at least two elements.

相互作用メカニズムは2つのサーバの間のチャンネル[参照3]の存在を仮定します。 2つの新しい意味データ型が、相互作用を実装するために定義されます。 これらは当然ながらCONTROL REQUESTsとCONTROL REPLYsと呼ばれます。 それぞれのこれらのデータ項目は少なくとも2つの要素を含んでいます。

     1/ The TYPE element identifies a particular type of
        request or reply.

1/、TYPE要素は特定のタイプの要求か回答を特定します。

     2/ The SEQUENCE element is used to match replies to
        their corresponding request.

2 SEQUENCE要素が使用されている/は彼らの対応する要求に回答に合っています。

     Other elements may appear.  Their interpretation
depends on the particular type of request or reply in which
they appear.

他の要素は現れるかもしれません。 彼らの解釈は彼らが現れる特定のタイプの要求か回答によります。

     The interaction protocol itself is defined in terms of
control requests and control replies.  A very small number
of request and reply types is defined as the minimal
implementation level.  Additional request and reply types
are also defined, for use by more advanced servers, to
Provide additional capabilities to the service, or simply to
increase efficiency of operation.

相互作用プロトコル自体はコントロール要求とコントロール回答で定義されます。 非常に少ない数の要求と回答タイプが最小限の器具レベルと定義されます。 また、追加要求と回答タイプは、サービスへのProvideの追加能力への、より高度なサーバによる使用か単に操作の効率を増強するために定義されます。

                                -11-
     Two additional data items are defined, called USER
REQUESTs and USER REPLYs.  These are structured like
requests and replies, but the various types are defined by
the service itself, to implement the primitives needed in
its operation.

USER REQUESTsとUSER REPLYsは、-11-2つの追加データ項目が定義されると呼びました。 これらは要求と回答のように構造化されますが、様々なタイプは、稼働中であり必要である基関数を実装するためにサービス自体で定義されます。

     Control and user requests and replies are generically
referenced as simply REQUESTs and REPLYs.

同じくらい単に参照をつけられて、コントロール、ユーザ要求、および回答は一般的にそうです。REQUESTsとREPLYs。

     The protocol of the interaction has several
characteristics which form the basis of the request-reply
model, and attempt to meet the goals mentioned previously.

相互作用のプロトコルには、要求回答モデルの基礎を形成して、以前に言及された目標を達成するのを試みるいくつかの特性があります。

     1/ Every request elicits a reply.

1/、あらゆる要求が回答を引き出します。

     2/ Every reply is associated unambiguously with a
        previous request.

2/、あらゆる回答が明白に前の要求に関連しています。

     3/ Each server always knows the state of the
        interaction, such as whether or not more data is
        expected from its partner.

3/、各サーバはいつも相互作用の状態を知っています、より多くのデータがパートナーから予想されるのなどように。

     4/ The protocol definition includes enumeration of the
        possible responses for each request.  Service
        protocols are encouraged to do likewise for user
        requests and user replies.

4 それぞれのための可能な応答のプロトコル定義インクルード列挙が要求する/。 サービスプロトコルが同様にユーザ要求とユーザ回答のためにするよう奨励されます。

     5/ Servers who receive requests of unknown type issue
        a response which effectively refuses the request.
        Servers attempting to use advanced features of a
        protocol 'rephrase' their requests in simpler terms
        where possible to maintain the previous level of
        service.

未知のタイプの要求を受け取る5/サーバが事実上、要求を拒否する応答を発行します。 プロトコルの高度な特徴を使用するのを試みるサーバが前のサービスのレベルを維持するのにおいて可能であるところで、より簡単な用語による彼らの要求を'言い直します'。

     The minimal implementation will support interaction
almost exactly along the lines of the request-reply
discipline.

最小限の器具はほとんどちょうど要求回答規律の系列に沿って相互作用をサポートするでしょう。

     Extensions to the minimal configuration are defined for
two reasons.  First, the strict request-reply discipline
model is inefficient for use in high-volume situations
because of the delays involved.  Several extensions are
defined to cope with this problem.  Thus, although the
interaction is based on such a discipline, it does not
necessarily implement the interaction in that fashion.
Second, additional primitives are defined which provide some
standard process synchronization operations, for use by the
services.

最小量の構成への拡大は2つの理由で定義されます。 大容量状況における使用に、まず最初に、厳しい要求回答規律モデルはかかわった遅れのために効率が悪いです。 いくつかの拡大が、この問題に対処するために定義されます。 したがって、相互作用はそのような規律に基づいていますが、それは必ずそのファッションで相互作用を実装するというわけではありません。 2番目に、追加基関数は定義されます(サービスで使用のためのいくつかの標準のプロセス同期操作を提供します)。

     The protocol architecture presented here is defined in
detail in an associated document.  [Reference 4]

ここに提示されたプロトコルアーキテクチャは関連文書で詳細に定義されます。 [参照4]

                                -12-

-12-

Appendix I -- The Channel

付録I--チャンネル

     The following discussion is a summary of the ideas
presented in [Reference 3], which should be
consulted for further detail.

以下の議論は詳細のために相談されるべきである[参照3]に提示された考えの概要です。

     The communication link between two servers is termed a
CHANNEL.  Channels provide bidirectional communications
capabilities, and will usually be full-duplex.  The programs
involved establish the channel as their individual
applications require, using some form of initial connection
protocol.

2つのサーバの間の通信リンクはCHANNELと呼ばれます。 チャンネルは双方向のコミュニケーション能力を提供します、そして、通常全二重でしょう。 何らかのフォームの初期の接続プロトコルを使用して、彼らの個々のアプリケーションが必要であるようにかかわったプログラムはチャンネルを確立します。

     The channel acts as an interface between servers.  It
conveys abstract data items whose semantics are understood
by the programmers involved, such as INTEGERs, STRINGs, FILE
PATH NAMEs, and so on.  Because the users of the channel may
operate in dissimilar computer environments, their
communication is defined only in terms of such abstract data
items, which are the atomic units of information carried on
the channel.  The program implementing the channel at each
site converts the data between an encoded transmission
format appropriate to the particular communication link
involved, and whatever internal representational form is
appropriate in the computer itself.

チャンネルはサーバの間のインタフェースとして務めます。 それは意味論がINTEGERs、STRINGs、FILE PATH NAMEsなどなどのようにかかわるプログラマに解釈される抽象的なデータ項目を伝えます。 チャンネルのユーザが異なったコンピュータ環境で働くかもしれないので、それらのコミュニケーションは単にそのような抽象的なデータ項目で定義されます。(データ項目はチャンネルで運ばれた原子力ユニットの情報です)。 各サイトでチャンネルを実装するプログラムは特定の通信リンクに適切な形式がかかわったコード化されたトランスミッションと、いかなるコンピュータ自体で適切な具象主義の内部のフォームの間のデータを変換します。

     The channel protocol provides a mechanism for
definition of various types of data items of semantic value
for the particular service concerned, for example, possibly,
user-name, set, syllable, sentence, and other data items of
interest to the particular service.  The channel provides a
mechanism for transportation of such user-defined data from
host to host.

チャンネルプロトコルは特定のサービスに興味がある例えばことによると関する特定のサービス、ユーザ名、セット、音節、文、および他のデータ項目のために様々なタイプの意味価値のデータ項目の定義にメカニズムを提供します。 チャンネルはホストからのそのようなユーザによって定義されたデータの輸送がホスティングするメカニズムを提供します。

     The channel may actually be implemented by one or more
separate encoding mechanisms which would be used in
different conditions, initially, the channel machinery would
provide a rudimentary facility based on a single mechanism
such as the MSDTP [Reference 3].

チャンネルは実際により1時までに異なった状態で使用されるメカニズムをコード化しながら、別々の状態で実装されるかもしれません、と初めは、チャンネル機械がMSDTP[参照3]などのただ一つのメカニズムに基づく初歩的な施設を前提とするでしょう。

     The mechanism is not dependent on the existence of
actual line-style network connections but will operate in
other environments, such as a message-oriented (as opposed
to connection-oriented) communications architecture, and in
fact is more naturally structured for such an environment.

メカニズムは、実際の系列スタイルネットワーク接続の存在に依存していませんが、メッセージ指向(接続指向と対照的に)のコミュニケーションアーキテクチャなどの他の環境で作動して、事実上、そのような環境のために、より自然に構造化されます。

                             -13-

-13-

XI. REFERENCES

ξ。 参照

[1] Network Information Center, ARPANET Protocol Handbook,
April, 1976.

[1] 1976年4月にインフォメーション・センター、アルパネットプロトコルハンドブックをネットワークでつないでください。

[2] Broos, Haverty, Vezza, Message Services Protocol
proposal, December, 1975.

[2] 嗜好、Haverty、Vezza、Message Servicesプロトコル提案、1975年12月。

[3] Haverty, Jack, Message Services Data Transfer Protocol,
NWG RFC 713, NIC 34729, April, 1976.

[3] Haverty、ジャック、メッセージサービスデータ転送プロトコル、NWG RFC713、NIC34729、1976年4月。

[4] Haverty, Jack, RRP, A Process Communication Protocol for
Request-reply Disciplines, NWG RFC 723, NIC 36807, (to
be issued)

[4] Haverty、ジャック、小売希望価格、要求回答規律、NWG RFC723、NIC36807のためのプロセス通信プロトコル(発行される)

                             -14-

-14-