RFC955 日本語訳

Network Working Group                                          R. Braden
Request for Comments: 955                                       UCLA OAC
                                                          September 1985

コメントを求めるワーキンググループR.ブレーデン要求をネットワークでつないでください: 955 UCLA OAC1985年9月

                    Towards a Transport Service for
                  Transaction Processing Applications

トランザクション処理アプリケーションのための輸送サービスに向かって

STATUS OF THIS MEMO

このメモの状態

   This RFC is concerned with the possible design of one or more new
   protocols for the ARPA-Internet, to support kinds of applications
   which are not well supported at present.  The RFC is intended to spur
   discussion in the Internet research community towards the development
   of new protocols and/or concepts, in order to meet these unmet
   application requirements.  It does not represent a standard, nor even
   a concrete protocol proposal.  Distribution of this memo is
   unlimited.

現在のところよくサポートされないアプリケーションの種類をサポートすることをARPA-インターネットへの1つ以上の新しいプロトコルの可能なデザインにこのRFCを心配させます。 RFCがインターネット研究団体で新しいプロトコル、そして/または、概念の開発に向かって議論を刺激することを意図します、これらのunmetアプリケーション要件を満たすために。 それは規格、および具体的なプロトコル提案さえ表しません。 このメモの分配は無制限です。

1.  INTRODUCTION

1. 序論

   The DoD Internet protocol suite includes two alternative transport
   service [1] protocols, TCP and UDP, which provide virtual circuit and
   datagram service, respectively [RFC-793, RFC-768].  These two
   protocols represent points in the space of possible transport service
   attributes which are quite "far apart".  We want to examine an
   important class of applications, those which perform what is often
   called "transaction processing".  We will see that the communication
   needs for these applications fall into the gap "between" TCP and UDP
   -- neither protocol is very appropriate.

DoDインターネット・プロトコル群は2代替手段の輸送サービス[1]のプロトコル、TCP、およびUDP[RFC-793、RFC-768]を含んでいます。(UDPはそれぞれ仮想の回路とデータグラムサービスを提供します)。 これらの2つのプロトコルがかなり「かけ離れている」可能な輸送サービス属性のスペースにポイントを表します。 重要なクラスのアプリケーション、しばしば「トランザクション処理」と呼ばれることを実行するものを調べたいと思います。 私たちは、これらのアプリケーションのコミュニケーションの必要性がギャップの“between" TCPとUDPになるのを見るでしょう--どちらのプロトコルもそれほど適切ではありません。

   We will then characterize the attributes of a possible new
   transport-level protocol, appropriate for these ill-served
   transaction-processing applications.

そして、私たちはこれらのほとんど役立たれなかったトランザクション処理アプリケーションに、適切な可能な新しい輸送レベルプロトコルの属性を特徴付けるつもりです。

   In writing this memo, the author had in mind several assumptions
   about Internet protocol development.

このメモを書くと、作者は、インターネットプロトコル開発に関するいくつかの仮定を考えていました。

      *  Assumption 1: The members of the Internet research community
         now understand a great deal about protocols, and given a list
         of consistent attributes we can probably generate a reasonable
         protocol to meet that specification.

* 仮定1: インターネット研究団体のメンバーは現在プロトコルに関して多くを理解しています、そして、一貫した属性のリストを考えて、私たちはその仕様を満たすためにたぶん妥当なプロトコルを生成することができます。

         This is not to suggest that design of good protocols is easy.
         It does reflect an assumption (perhaps wrong) that the set of
         basic protocol techniques we have invented so far is sufficient
         to give a good solution for any point in the attribute space,
         and that we can forsee (at least in a general way) many of the
         consequences of particular protocol design choices.

これは、良いプロトコルのデザインが簡単であると示唆しないためのものです。 それは特定のプロトコルデザイン選択の結果についてforsee(少なくとも一般的な方法で)多く私たちが今までのところ発明した基本プロトコルのテクニックのセットが属性スペースの任意な点に良いソリューションを与えることができるくらい私たちがそうすることができるという仮定(恐らく間違った)を反映します。

Braden                                                          [Page 1]

ブレーデン[1ページ]

RFC 955                                                   September 1985
Transaction Protocol

RFC955 1985年9月のトランザクションプロトコル

      *  Assumption 2: We need to develop appropriate service
         requirements for a "transaction processing protocol".

* 仮定2: 私たちは、「トランザクション処理プロトコル」のための適切なサービス要件を開発する必要があります。

         The classifications "virtual circuit" and "datagram"
         immediately define in our minds the most important attributes
         of TCP and UDP.  We have no such immediate agreement about the
         services to be provided for transaction processing.  The
         existing and proposed transaction-oriented protocols show a
         number of alternative choices [e.g., Cour81, BiNe84, Coop84,
         Cher85, Crow85, Gurw85, Mill85].

分類「仮想の回路」と「データグラム」はすぐに、私たちの心でTCPとUDPの最も重要な属性を定義します。 私たちには、サービスに関するどんなそのようなトランザクション処理に提供されるべき即座の協定もありません。 存在と提案されたトランザクション指向のプロトコルは多くの代替の選択[例えば、Cour81、BiNe84、Coop84、Cher85、Crow85、Gurw85、Mill85]を示しています。

   Many of the ideas discussed here are not new.  For example, Birrell
   and Nelson [BiNe84] and Watson [Wats81] have described
   transport-level protocols appropriate for transactions.  Our purpose
   here is to urge the solution of this problem within the Internet
   protocol family.

ここで議論したアイデアの多くが新しくはありません。 例えば、ビレル、ネルソン[BiNe84]、およびワトソン[Wats81]はトランザクションに、適切な輸送レベルプロトコルについて説明しました。 ここの私たちの目的はインターネットプロトコルファミリーの中でこの問題の解決を促すことです。

2.  TRANSACTION PROCESSING COMMUNICATIONS

2. トランザクション処理コミュニケーション

   We begin by listing the characteristics of the communication patterns
   typical in "transaction processing" applications.

私たちは、「トランザクション処理」アプリケーションで典型的なコミュニケーションパターンの特性を記載することによって、始めます。

      *  Unsymmetrical Model

* Unsymmetricalモデル

         The two end points of the communication typically take
         different roles, generally called "client" and "server".  This
         leads to an unsymmetrical communication pattern.

コミュニケーションの2つのエンドポイントが異なる役割、一般に、呼ばれた「クライアント」、および「サーバ」を通常取ります。 これはunsymmetricalコミュニケーションパターンに通じます。

         For example, the client always initiates a communication
         sequence or "transaction".  Furthermore, an important subclass
         of applications uses only a simple exchange of messages, a
         "request" to the server followed by a "reply" to the client.

例えば、クライアントはいつもコミュニケーション系列か「トランザクション」を開始します。 その上、アプリケーションの重要なサブクラスはメッセージの簡単な交換だけを使用します、とサーバへの「要求」はクライアントへの「回答」で続きました。

         Other applications may require a continuing exchange of
         messages, a dialog or "conversation".  For example, a request
         to read a file from a file server might result in a series of
         messages, one per file block, in reply. More complex patterns
         may occur.

他のアプリケーションはメッセージの継続する交換、対話または「会話」を必要とするかもしれません。 例えば、ファイルサーバーからファイルを読むという要求は一連のメッセージをもたらすかもしれません、ファイルブロックあたり1つ、回答で。 より複雑なパターンは起こるかもしれません。

      *  Simplex Transfers

* シンプレクス転送

         Regardless of the pattern, it always consists of a series of
         SIMPLEX data transfers; at no time is it necessary to send data
         in both directions simultaneously.

パターンにかかわらず、一連のSIMPLEXデータ転送からいつも成ります。 いかなる時も、それは同時に、両方の方向による送信データに必要ではありません。

Braden                                                          [Page 2]

ブレーデン[2ページ]

RFC 955                                                   September 1985
Transaction Protocol

RFC955 1985年9月のトランザクションプロトコル

      *  Short Duration

* 短期間

         Transaction communication sequences generally have short
         duration, typically 100's of milliseconds up to 10's of
         seconds, but never hours.

一般に、トランザクションコミュニケーション系列には、短期間、通常10の秒のものまでの100ミリセカンド、しかし、決してどんな時間もありません。

      *  Low Delay

* 低い遅れ

         Some applications require minimal communication delay.

いくつかのアプリケーションが最小量のコミュニケーション遅れを必要とします。

      *  Few Data Packets

* わずかなデータ・パケット

         In many applications, the data to be sent can be compressed
         into one or a few IP packets.  Applications which have been
         designed with LAN's in mind are typically very careful to
         minimize the number of data packets for each request/reply
         sequence.

多くのアプリケーションでは、1かいくつかのIPパケットに送られるデータは圧縮できます。 通常、LANのもので念頭に設計されているアプリケーションはそれぞれの要求/回答系列のためにデータ・パケットの数を最小にするのに非常に慎重です。

      *  Message Orientation

* メッセージオリエンテーション

         The natural unit of data which is passed in a transaction is an
         entire message ("record"), not a stream of bytes.

トランザクションで通過されるデータの自然なユニットはバイトのストリームではなく、全体のメッセージ(「記録する」)です。

3.  EXAMPLE: NAME SERVERS

3. 例: ネームサーバ

   To focus our ideas, we will now discuss several particular types of
   distributed applications which are of pressing concern to members of
   the Internet research community, and which require
   transaction-oriented communication.

私たちの考えの焦点を合わせるために、私たちは現在、インターネット研究団体のメンバーへの差し迫った関心事があって、トランザクション指向のコミュニケーションを必要とするいくつかの特定のタイプの分配されたアプリケーションについて議論するつもりです。

   First, consider the name server/name resolver system [RFC-882,
   RFC-883] which is currently being introduced into the (research)
   Internet.  Name servers must use TCP and/or UDP as their transport
   protocol.  TCP is appropriate for the bulk transfers needed to update
   a name server's data base.  For this case, reliability is essential,
   and virtual-circuit setup overhead is negligible compared to the data
   transfer itself.  However, the choice of a transport protocol for the
   transaction traffic -- queries and responses -- is problematic.

まず最初に、現在(研究)インターネットに取り入れられているネームサーバ/ネーム・リゾルバシステム[RFC-882、RFC-883]を考えてください。 ネームサーバはそれらのトランスポート・プロトコルとしてTCP、そして/または、UDPを使用しなければなりません。 ネームサーバのデータベースをアップデートするのに必要であるバルク転送に、TCPは適切です。 このような場合、信頼性は不可欠です、そして、データ転送自体と比べて、仮想の回路セットアップオーバーヘッドは取るにたらないです。 しかしながら、トランザクショントラフィックのためのトランスポート・プロトコルの選択(質問と応答)は問題が多いです。

      *  TCP would provide reliable and flow-controlled transfer of
         arbitrary-sized queries and responses.  However, TCP exacts a
         high cost as a result of its circuit setup and teardown phases.

* TCPは任意サイズの質問と応答の信頼できて流れで制御された転送を供給するでしょう。 しかしながら、TCPはその回路セットアップと分解フェーズの結果、高い費用を強要します。

      *  UDP avoids the overhead of TCP connection setup.  However, UDP
         has two potentially-serious problems -- (1) unreliable
         communication, so that packets may be lost, duplicated, and/or

* UDPはTCP接続設定のオーバーヘッドを避けます。 そして/またはしかしながら、UDPには潜在的にコミュニケーション、パケットがそうである(1)の頼り無いそう無くなっていて、コピーされた2つの深刻な問題がある。

Braden                                                          [Page 3]

ブレーデン[3ページ]

RFC 955                                                   September 1985
Transaction Protocol

RFC955 1985年9月のトランザクションプロトコル

         reordered; and (2) the limitation of a data object
         (query/response) to the 548-byte maximum in a single UDP
         packet.

再命令しました。 (2) そして、単一のUDPパケットの548バイトの最大へのデータ・オブジェクト(質問/応答)の限界。

   At present, name servers are being operated using UDP for transaction
   communication.  Note that name server requests have a special
   property, idempotency; as a result, lost, duplicated, or reordered
   queries do not prevent the name-server system from working.  This
   would seem to favor the use of UDP.

現在のところ、ネームサーバは、トランザクションコミュニケーションにUDPを使用することで操作されています。 ネームサーバ要求には特別な性質、idempotencyがあることに注意してください。 その結果、無くなっているか、コピーされたか、再命令された質問は、ネームサーバシステムが働くのを防ぎません。 これはUDPの使用を支持するように思えるでしょう。

   However, it seems quite likely that the defects of UDP will make it
   unusable for an increasing fraction of queries.

しかしながら、UDPの欠陥でそれはかなり質問の増加する部分に使用不可能になりそうでしょう。

      *  The average size of individual replies will certainly increase,
         as the more esoteric mail lookup features are used, as the host
         population explodes (resulting in a logarithmic increase in
         domain name sizes), and as the number of alternate acceptable
         answers increases.  As a result, a single response will more
         often overflow a single UDP packet.

* 確かに、個々の回答の平均のサイズは増加するでしょう、より難解なメールルックアップ機能が使用されているとき、ホスト人口が爆発して(ドメイン名サイズの対数の増加をもたらします)、代替の歓迎すべき返答の数が増加するのに従って。 その結果、ただ一つの応答を単一のUDPパケットから、よりしばしばはみ出させるでしょう。

      *  The average end-to-end reliability will decrease as some of the
         flakier paths of the Internet are brought into use by name
         resolvers.

* インターネットの、より風変わりな経路のいくつかがネーム・リゾルバによって使用にもたらされているのに従って、終わりから終わりへの平均した信頼性は減少するでしょう。

         This will lead to a serious problem of choosing an appropriate
         retransmission timeout.  A name resolver using UDP cannot
         distinguish packet loss in the Internet from queueing delay in
         the server.  As a result, name servers we have seen have chosen
         long fixed timeouts (e.g., 30 seconds or more).  This will
         result in long delays in name resolution when packets are lost.

これは適切な再送タイムアウトを選ぶ深刻な問題に通じるでしょう。 UDPを使用しているネーム・リゾルバはサーバの待ち行列遅れとインターネットのパケット損失を区別できません。その結果、私たちが見たネームサーバは長い固定タイムアウト(例えば、30秒以上)を選びました。 パケットが無くなるとき、これは名前解決における長時間の遅延をもたらすでしょう。

         One might think that delays in name resolution might not be an
         issue since most name lookups are done by a mailer daemon.
         However, ARPANET experience with user mail interfaces has shown
         that it is always desirable to verify the correctness of each
         host name as the user enters the "To:" and "CC:" addresses for
         a message. Hence, delays due to lost UDP packets will be
         directly visible to users.

人は、名前解決の遅れがメーラ・デーモンでほとんどの名前ルックアップをするので問題でないかもしれないと思うかもしれません。 しかしながら、ユーザが「To:」に入るとき、ユーザメールインタフェースのアルパネット経験は、それぞれのホスト名の正当性について確かめるのがいつも望ましいのを示しました。 そして、「CC:」 メッセージのために、扱います。 したがって、無くなっているUDPパケットによる遅れは直接ユーザにとって目に見えるようになるでしょう。

   More generally, the use of UDP violates sound communication system
   design in two important ways:

より一般に、UDPの使用は2つの重要な方法で音の通信系デザインに違反します:

      *  The name resolver/server applications have to provide timeouts
         and retransmissions to protect against "errors" (losses) in the
         communication system.  This certainly violates network
         transparency, and requires the application to make decisions
         for which it is not well-equipped.

* ネーム・リゾルバ/サーバ・アプリケーションは、通信系における「誤り」(損失)から守るためにタイムアウトと「再-トランスミッション」を供給しなければなりません。 これは、それがよく備えられていない決定をするように確かに、ネットワーク透明に違反して、アプリケーションを必要とします。

Braden                                                          [Page 4]

ブレーデン[4ページ]

RFC 955                                                   September 1985
Transaction Protocol

RFC955 1985年9月のトランザクションプロトコル

         As a general design principle, it seems that (Inter-) network
         properties, especially bad properties, ought to a large extent
         to be hidden below the transport-service boundary [2].

一般的な設計原理として、それに見える、(相互、)、輸送サービス境界[2]の下に隠されて、特性(特に悪い特性)が大きい範囲にそうするべきであるネットワーク。

      *  The name resolver/server applications must know the maximum
         size of a UDP datagram.

* ネーム・リゾルバ/サーバ・アプリケーションはUDPデータグラムの最大サイズを知らなければなりません。

         It is clearly wrong for an application program to contain
         knowledge of the number 576 or 548!  This does not imply that
         there cannot be a limitation on the size of a message, but any
         such limitation should be imposed by the particular
         application-level protocol, not the transport or internetwork
         level.

アプリケーション・プログラムがNo.576か548に関する知識を含むのは、明確に間違っています! これは、制限がメッセージのサイズにあるはずがないのを含意しませんが、どんなそのような制限も輸送かインターネットワークレベルではなく、特定のアプリケーションレベルプロトコルによって課されるべきです。

   It seems that the TCP/UDP choice for name servers presents an ugly
   dilemma.  We suggest that the solution should be a new
   transaction-oriented transport protocol with the following features:

ネームサーバのためのTCP/UDP選択が醜いジレンマを提示するように思えます。 私たちは、ソリューションが以下の特徴がある新しいトランザクション指向のトランスポート・プロトコルであると示唆します:

      *  Reliable ("at-least-once") Delivery of Data;

* 信頼できる、(「最も一度、」、)、データの配送。

      *  No Explicit Connection Setup or Teardown Phases;

* 明白な接続設定でない分解フェーズがありません。

      *  Fragmentation and Reassembly of Messages;

* メッセージの断片化とReassembly。

      *  Minimal Idle State in both Client and Server.

* ClientとServerの両方の最小量のIdle州。

4.  ANOTHER EXAMPLE: DISTRIBUTED OPERATING SYSTEMS

4. 別の例: 分配されたオペレーティングシステム

   Distributed operating systems represent another potential application
   for a transaction-oriented transport service.  A number of examples
   of distributed operating systems have been built using high-speed
   local area networks (LAN's) for communication (e.g, Cronus, Locus,
   V-System).  Typically, these systems use private communication
   protocols above the network layer, and the private transport-level
   protocol is carefully designed to minimize latency across the LAN.
   They make use of the inherent reliability of the LAN and of simple
   transactions using single-packet exchanges.

分配されたオペレーティングシステムはトランザクション指向の輸送サービスのために別の潜在的アプリケーションを表します。 分配されたオペレーティングシステムに関する多くの例が、コミュニケーション(e.g、クロノス、Locus、V-システム)に、高速ローカル・エリア・ネットワーク(LANのもの)を使用することで築き上げられました。 通常、これらのシステムはネットワーク層を超えて私信プロトコルを使用します、そして、個人的な輸送レベルプロトコルは、LANの向こう側に潜在を最小にするように入念に設計されています。 彼らは、単一のパケット交換を使用することでLANと単純取引の固有の信頼性を利用します。

   Recently there have been efforts to extend these systems to operate
   across the Internet [Cher85, Shel85].  Since these are not "open"
   systems, there is no requirement that they use a standard transport
   protocol. However, the availability of a suitable transport protocol
   for transactions could considerably simplify development of future
   distributed systems.

最近、インターネット[Cher85、Shel85]の向こう側に作動するためにこれらのシステムを拡張するために、取り組みがありました。 これらが「開いている」システムでないので、標準のトランスポート・プロトコルを使用するという要件が全くありません。 しかしながら、トランザクションのための適当なトランスポート・プロトコルの有用性は将来の分散システムの開発をかなり簡素化するかもしれません。

   The essential requirement here seems to be packet economy.  The same

ここの必須の条件はパケット経済であるように思えます。 同じくらい

Braden                                                          [Page 5]

ブレーデン[5ページ]

RFC 955                                                   September 1985
Transaction Protocol

RFC955 1985年9月のトランザクションプロトコル

   minimal two-packet exchange used over the LAN should be possible
   across the Internet.  This leads to two requirements for supporting
   distributed operating systems:

LANの上で使用される最小量の2パケットの交換はインターネットの向こう側に可能であるべきです。 これは分配されたオペレーティングシステムを支えるための2つの要件に通じます:

      *  No Explicit Connection Setup or Teardown Phases;

* 明白な接続設定でない分解フェーズがありません。

      *  Implicit ("piggy-backed") Acknowledgments Whenever Possible.

* 可能であるときはいつも、暗黙(「背負われる」)の承認。

         This implies that the response packet will serve as an implicit
         acknowledgment to the request packet (when timing makes this
         possible).  Similarly, a new request (for the same pair of
         addressable entities) would implicitly acknowledge the previous
         response, if it came soon enough.

これは、応答パケットが暗黙の承認としてリクエスト・パケットに機能するのを含意します(これがタイミングで可能になると)。 同様に、新しい要求(アドレス可能な実体の同じ組)はそれとなく前の応答を承諾するでしょう、間に合うようにしてすぐ来たなら。

   The nature of the application imposes two other requirements:

アプリケーションの本質は他の2つの要件を課します:

      *  Reliable ("at-most-once"), Ordered Delivery

* 信頼できる、(「大部分、一度、」、)、命令された配送

         However, it should be possible to relax the reliability to take
         advantage of special cases like an idempotent request.

しかしながら、ベキ等元要求のような特別なケースを利用するために信頼性を弛緩するのは可能であるべきです。

      *  Multicast Capability

* マルチキャスト能力

         The transport service should mesh cleanly with the proposed
         Internet multicast facility, using host groups [ChDe85].

ホストグループ[ChDe85]を使用して、輸送サービスは清潔に提案されたインターネットマルチキャスト施設と合うべきです。

5.  OBJECTIVES FOR A PROTOCOL

5. プロトコルのための目的

   We believe that it is possible to design a new transport protocol for
   the Internet which is suitable for a wide variety of
   transaction-oriented applications.  Such a transport protocol would
   have the following attributes:

私たちは、さまざまなトランザクション指向のアプリケーションに適したインターネットに新しいトランスポート・プロトコルを設計するのが可能であると信じています。 そのようなトランスポート・プロトコルには、以下の属性があるでしょう:

      *  Reliable Delivery

* 信頼できる配信

         Data will be delivered reliably, i.e., exactly once, or the
         sender will be informed.  The protocol must be able to handle
         loss, duplication, and reordering of request and response
         packets.  In particular, old duplicate request packets must not
         cause erroneous actions.

送付者はすなわち、データがまさにかつて確かに提供されるだろうか、または知識があるようになるでしょう。 プロトコルは要求と応答パケットに関する損失、複製、および再命令を扱うことができなければなりません。 特に、古い写しリクエスト・パケットは誤った動作を引き起こしてはいけません。

         It should also be possible for the application programs to
         request that the reliability be relaxed for particular
         transactions.  This would allow communication economies in the
         case of idempotent requests or of notification without reply.

また、アプリケーション・プログラムが、信頼性が特定の取引のためにリラックスするよう要求するのも、可能であるべきです。 これは回答なしでベキ等元要求か通知の場合でコミュニケーション経済を許容するでしょう。

Braden                                                          [Page 6]

ブレーデン[6ページ]

RFC 955                                                   September 1985
Transaction Protocol

RFC955 1985年9月のトランザクションプロトコル

      *  Minimum Number of Packets in Simple Cases

* 簡単な場合における最小の数のパケット

         In the simplest case (small messages, no packet losses, and the
         interval between requests and replies between the same pair of
         addressable entities shorter than applicable timeouts), a
         simple two-packet exchange should result.

最も簡単な場合(適切であるよりアドレス可能な実体の同じ組少ないタイムアウトの間の要求と回答の小さいメッセージ、パケット損失がなく、および間隔)では、簡単な2パケットの交換は結果として生じるべきです。

      *  No Explicit Connection Setup or Teardown Phases

* 明白な接続設定でない分解フェーズがありません。

         The protocol will not create virtual circuits, but will provide
         what is sometimes (confusingly) called "reliable datagram"
         service.

プロトコルは、仮想の回路を作成しませんが、時々(紛らわしく)「高信頼のデータグラム」サービスと呼ばれるものを提供するでしょう。

         However, in order to provide a minimum two-packet exchange,
         there must be some implicit state or "soft" virtual circuit
         between a pair of addressable entities. In recent discussions
         this has been dubbed a "conversation", to distinguish it from a
         connection.

しかしながら、最小の2パケットの交換を供給するために、1組のアドレス可能な実体の間には、ある内在している州か仮想の「柔らかい」回路があるに違いありません。 最近の議論では、これは、接続とそれを区別するために「会話」と呼ばれました。

      *  Minimal Idle State

* 最小量の活動していない状態

         When a server is not processing a transaction, there will be no
         state kept (except enough to recognize old duplicate packets
         and to suppress unneeded ACK packets).

そのサーバが取引を処理していないとき、維持された(古い写しパケットを認識して、不要なACKパケットを抑圧できるくらい)状態が全くないでしょう。

      *  Fragmentation/Reassembly of Large Messages

* 大きいメッセージの断片化/Reassembly

         There is a range of possible objectives here. The minimum
         requirement is that the application not have to know the number
         576, 548, etc. For example, each application might establish
         its own "natural" upper limit on the size of a message, and
         always provide a buffer of that size [3].

さまざまな可能な目的がここにあります。 必要最小限はアプリケーションがNo.576、548などを知る必要はないということです。 例えば、各アプリケーションは、メッセージのサイズでそれ自身の「自然な」上限を確立して、いつもそのサイズ[3]に関するバッファを提供するかもしれません。

         At the other extreme, the protocol might allow very large
         messages (e.g., a megabyte or more).  In this case, the
         proposed protocol would, in the large-message limit, be
         performing the bulk data transfer function of TCP.  It would be
         interesting to know whether this is possible, although it is
         not necessarily a requirement.

それとは正反対に、プロトコルは非常に大きいメッセージ(例えば、1メガバイト以上)を許容するかもしれません。 この場合、大きいメッセージ限界では、提案されたプロトコルはTCPのバルク・データ転送機能を実行しているでしょう。 それは必ず要件であるというわけではありませんが、これが可能であるかどうかを知るのはおもしろいでしょう。

         The introduction of multi-packet messages leads to the complex
         issues of window sizes and flow control.  The challenge is to
         handle these efficiently in the absence of connection setup.

マルチパケットメッセージの導入はウィンドウサイズとフロー制御の複雑な問題につながります。 挑戦は接続設定がないとき効率的にこれらを扱うことです。

      *  Message Orientation

* メッセージオリエンテーション

Braden                                                          [Page 7]

ブレーデン[7ページ]

RFC 955                                                   September 1985
Transaction Protocol

RFC955 1985年9月のトランザクションプロトコル

         The basic unit of communication will be an entire message, not
         a stream of bytes.  If a message has to be segmented, it will
         be delivered in units of segments or buffers, not bytes.

コミュニケーションの原単位はバイトのストリームではなく、全体のメッセージになるでしょう。 メッセージが区分されなければならないと、それはバイトではなく、ユニットのセグメントかバッファで提供されるでしょう。

      *  Multicast Capability

* マルチキャスト能力

   Based on this discussion, we can suggest some of the key issues and
   problems in design of this protocol.

この議論に基づいて、私たちはこのプロトコルのデザインにおける主要な問題と問題のいくつかを勧めることができます。

      *  Choice of Addressable Entity

* アドレス可能な実体の選択

         What will be the addressable entity?  It must be unique in
         space; must it be unique in time (even across system crashes) ?

アドレス可能な実体は何になるでしょうか? それはスペースでユニークであるに違いありません。 それは時間内に(システムクラッシュの向こう側にさえ)、ユニークであるに違いありませんか?

      *  Timeout Dynamics

* タイムアウト力学

         Timeouts must be the key to operation of this protocol.
         Experience with TCP has shown the need for dynamic selection of
         an appropriate timeout, since Internet delays range over four
         decimal orders of magnitude.

タイムアウトはこのプロトコルの操作のキーであるに違いありません。 TCPの経験はインターネット遅れが及んで以来の10進4つ以上の桁以上の適切なタイムアウトのダイナミックな選択の必要性を示しました。

         However, the absence of connection setup and the
         typically-short duration of a single interaction seem to
         preclude the dynamic measurement of delays.

しかしながら、接続設定の欠如と通常単一の相互作用の短期間は遅れの動的測定を排除するように思えます。

      *  Multi-Packet Messages

* マルチパケットメッセージ

         How can flow control be provided for multi-packet messages, to
         provide reasonable throughput over long-delay paths without
         overrun with short-delay paths, when there is no virtual
         circuit setup?

どんな仮想の回路セットアップもないとき、少し遅れ経路と共に超過なしで長時間の遅延経路の上に妥当なスループットを提供するためにどうしたらマルチパケットメッセージにフロー制御を提供できますか?

      *  Implementation Efficiency

* 実装効率

         The protocol should lend itself to efficient (which probably
         implies simple) implementations, so that hosts will be willing
         to use it over LAN's as well as for general Internet
         communication.

プロトコルがそれ自体を効率的に貸すべきである、(どれ、たぶん含意するか、簡単である、)、実装によって、ホストが、LANの上でそれを使用しても構わないと思うのは、一般的なインターネット通信のように良いです。

   We believe further study is needed on these questions.

私たちは、さらなる研究がこれらの質問で必要であると信じています。

   The reader may wonder: how is the proposed protocol related to an RPC
   (Remote Procedure Call) facility?  The intent is that RPC facilities
   and message-passing IPC facilities will be built on top of the
   proposed transport layer.  These higher-level mechanisms will need to
   address a number of additional issues, which are not relevant to the
   communication substrate:

読者は不思議に思うかもしれません: 提案されたプロトコルはどのようにRPC(リモートProcedure Call)施設に関連しますか? 意図はRPC施設とメッセージ・パッシングIPC施設が提案されたトランスポート層の上で建設されるということです。 これらのよりハイレベルのメカニズムは、コミュニケーション基板に関連していない多くの追加設定を扱う必要があるでしょう:

Braden                                                          [Page 8]

ブレーデン[8ページ]

RFC 955                                                   September 1985
Transaction Protocol

RFC955 1985年9月のトランザクションプロトコル

      1.  Application Interface

1. HTTPサーバとNETSCAPE間のインタフェース

         This includes binding and stub generators.

これは結合とスタッブジェネレータを含んでいます。

      2.  Structured Data Encoding

2. 構造化されたzデータの符号化

      3.  Server Location and Binding

3. サーバ位置と結合

      4.  Authentication and Access Control

4. 認証とアクセスコントロール

6.  CONCLUSION

6. 結論

   Distributed processing and distributed data bases will underlie many
   of the future computer system research projects and applications
   based upon the Internet.  As a result, transaction-based
   communication will be an increasingly important activity on the
   Internet.  We claim that there is a pressing need for an appropriate
   transport protocol for transaction processing.  In this memo, we have
   given examples to support this claim, and have outlined the service
   which such a new transport protocol would provide.

分散処理と分散形データベースは将来のコンピュータ・システム研究計画とインターネットに基づくアプリケーションの多くの基礎となるでしょう。 その結果、トランザクションベースのコミュニケーションはインターネットにおけるますます重要な活動になるでしょう。 私たちは、トランザクション処理のための適切なトランスポート・プロトコルのための差し迫った必要性があると主張します。 このメモでは、私たちは、このクレームをサポートするために例を挙げて、そのような新しいトランスポート・プロトコルが提供するサービスについて概説しました。

   This memo is based upon discussions within the New End-to-End
   Protocols taskforce, and it is a pleasure to acknowledge the
   participation and sagacity of the members of that group.  I want to
   thank Dave Clark, an ex officio taskforce member, for his
   contribution to these discussions, and Robert Cole for very helpful
   suggestions.

このメモはNew Endから終わりへのプロトコルtaskforce中の議論に基づいています、そして、そのグループのメンバーの参加と明敏さを承諾するのは、喜びです。 デーブ・クラークに感謝申し上げます、元のofficio taskforceメンバー、これらの議論への彼の貢献、および非常に役立っている提案のためのロバート・コールのために。

NOTES:

注意:

   [1]  For the purposes of this RFC, in fact, the reader may consider
        "transport service" to be defined as that protocol layer which
        contains TCP and UDP, as in Figure 1 of RFC-791.  Alternatively,
        we may use the ISO definition -- the transport service is the
        lowest layer providing end-to-end service which is essentially
        independent of the characteristics of the particular (Inter-)
        network used to support the communication.

[1] 事実上、このRFCの目的のために、読者は、「輸送サービス」がTCPとUDPを含むそのプロトコル層と定義されると考えるかもしれません、RFC-791の図1のように。 あるいはまた、私たちはISO定義を使用するかもしれません--輸送サービスが終わりから終わりに対する特定の特性から本質的には独立しているサービスを提供する最も低い層である、(相互、)、ネットワークは以前はよくコミュニケーションをサポートしていました。

   [2]  This idea is implicit in the ISO definition of a transport
        service.

[2] この考えは輸送サービスのISO定義で暗黙です。

   [3]  It would be reasonable for the name server definition to specify
        an upper bound on the size of a single query or response; e.g.,
        2K bytes.  This would imply (large) limits on the number of RR's
        that could be returned per response. If that limit is exceeded,
        we are doing something wrong!

[3] ネームサーバ定義がただ一つの質問か応答のサイズで上限を指定するのは、妥当でしょう。 例えば、2Kのバイト。 これは応答単位で返すことができるだろうRRのものの数における(大きい)の限界を含意するでしょう。 その限界が超えられているなら、私たちは不具合をしています!

Braden                                                          [Page 9]

ブレーデン[9ページ]

RFC 955                                                   September 1985
Transaction Protocol

RFC955 1985年9月のトランザクションプロトコル

REFERENCES

参照

   BiNe84   Birrell, Andrew D. and Nelson, Bruce Jay, "Implementing
            Remote Procedure Calls". ACM TOCS, Vol. 2, No. 1, February
            1984.

「遠隔手続き呼び出しを実装する」BiNe84ビレルとアンドリューD.とネルソン、ブルース・ジェイ。 ACMトックス、Vol.2、No.1、1984年2月。

   ChDe85   Cheriton, David R. and Deering, Steven, "Host Groups: a
            Multicast Extension for Datagram Networks".  To be presented
            to 9th Data Communication Symposium.

ChDe85 CheritonとデヴィッドR.とデアリング、スティーブン、「グループをホスティングしてください」 「データグラム・ネットワークのためのマルチキャスト拡大。」 第9Data Communication Symposiumに提示されるために。

   Cher85   Cheriton, David R., "V Message Transaction Protocol".
            Private communication, July 1985.

Cher85 Cheriton(デヴィッドR.)は「メッセージトランザクションに対して議定書を作ります」。 1985年7月の私信。

   Cour81   Xerox Corp., "Courier: The Remote Procedure Call Protocol".
            XSIS 038112, Xerox Corp., Stamford, Conn., December 1981.

Cour81ゼロックス社、「急使:」 「遠隔手続き呼び出しプロトコル。」 XSIS038112、ゼロックス社、スタンフォード、コネチカット州、1981年12月。

   Coop84   Cooper, Eric C., "Circus: a Replicated Procedure Call
            Facility".  Proc. 4th Symposium on Reliability in
            Distributed Software and Database Systems, October 1984.

Coop84桶屋(エリックC.)、「サーカス:」 「模写された手順呼び出し施設。」 Proc。 1984年10月の分配されたソフトウェアとデータベース・システムの信頼性に関する第4シンポジウム。

   Crow85   Crowcroft, Jon, "A Sequential Exchange Protocol".  Internal
            Note 1688, Computer Science Department, University College
            London, June 1985.

Crow85クロウクロフト、ジョン、「連続した交換プロトコル。」 内部の注意1688、コンピュータ理学部、ユニバーシティ・カレッジロンドン、1985年6月。

   Gurw85   Gurwitz, Robert F., "Object Oriented Interprocess
            Communication in the Internet".  Private communication,
            April 1985.

Gurw85 Gurwitz、ロバートF.、「インターネットのオブジェクト指向プロセス間通信。」 1985年4月の私信。

   Mill85   Miller, Trudy, "Internet Reliable Transaction Protocol --
            Functional and Interface Specification".  RFC-938, February
            1985.

Mill85ミラー、ルーディ、「インターネットの信頼できるトランザクションは議定書を作ります--機能的、そして、インタフェース仕様。」 1985年2月のRFC-938。

   Shel85   Sheltzer, Alan B. , "Network Transparency in an Internetwork
            Environment", PhD Thesis, UCLA Department of Computer
            Science, July 1985.

Shel85 Sheltzer、アランB.、「インターネットワーク環境におけるネットワーク透明」、博士Thesis、UCLAコンピュータサイエンス学部、1985年7月。

   Wats81   Watson, Richard W., "Timer-based Mechanisms in Reliable
            Transport Protocol Connection Management".  Computer
            Networks, Vol. 5, pp47-56, 1981 (also distributed as
            IEN-193).

Wats81ワトソン、リチャードW.、「信頼できる輸送におけるタイマベースのメカニズムは接続管理について議定書の中で述べます」。 コンピュータNetworks、Vol.5、pp47-56、1981(また、IEN-193として、分配されます)。

Braden                                                         [Page 10]

ブレーデン[10ページ]