RFC955 日本語訳
0955 Towards a transport service for transaction processingapplications. R.T. Braden. September 1985. (Format: TXT=22497 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
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ページ]
一覧
スポンサーリンク
