RFC1045 日本語訳
1045 VMTP: Versatile Message Transaction Protocol: Protocolspecification. D.R. Cheriton. February 1988. (Format: TXT=272058 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group David Cheriton
Request for Comments: 1045 Stanford University
February 1988
ネットワークワーキンググループデヴィッドCheritonはコメントのために以下を要求します。 1045 スタンフォード大学1988年2月
VMTP: VERSATILE MESSAGE TRANSACTION PROTOCOL
Protocol Specification
VMTP: 多能なメッセージトランザクションプロトコルプロトコル仕様
STATUS OF THIS MEMO
このメモの状態
This RFC describes a protocol proposed as a standard for the Internet community. Comments are encouraged. Distribution of this document is unlimited.
このRFCはインターネットコミュニティの規格として提案されたプロトコルについて説明します。 コメントは奨励されます。 このドキュメントの分配は無制限です。
OVERVIEW
概要
This memo specifies the Versatile Message Transaction Protocol (VMTP) [Version 0.7 of 19-Feb-88], a transport protocol specifically designed to support the transaction model of communication, as exemplified by remote procedure call (RPC). The full function of VMTP, including support for security, real-time, asynchronous message exchanges, streaming, multicast and idempotency, provides a rich selection to the VMTP user level. Subsettability allows the VMTP module for particular clients and servers to be specialized and simplified to the services actually required. Examples of such simple clients and servers include PROM network bootload programs, network boot servers, data sensors and simple controllers, to mention but a few examples.
このメモはVersatile Message Transactionプロトコル(VMTP)[1988年2月19日のバージョン0.7]を指定します、コミュニケーションのトランザクションモデルをサポートするように明確に設計されたトランスポート・プロトコル、遠隔手続き呼び出し(RPC)で例示されるように。 セキュリティのサポート、リアルタイムで、非同期な交換処理、ストリーミング、マルチキャスト、およびidempotencyを含むVMTPの完全な機能はVMTPユーザレベルに豊かな選択を提供します。 Subsettabilityは、特定のクライアントとサーバが実際に必要であるサービスに専門にされて、簡素化されるためにVMTPモジュールを許容します。 そのような純真なクライアントとサーバに関する例はPROMネットワークbootloadプログラム、ネットワークブート・サーバー、データセンサ、および簡単なコントローラを含んでいます、言及にもかかわらず、いくつかの例に。
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
Table of Contents
目次
1. Introduction 1
1. 序論1
1.1. Motivation 2
1.1.1. Poor RPC Performance 2
1.1.2. Weak Naming 3
1.1.3. Function Poor 3
1.2. Relation to Other Protocols 4
1.3. Document Overview 5
1.1. 動機、2 1.1 .1。 貧しいRPCパフォーマンス2 1.1.2。 1.1に.3に3を命名する弱者 機能貧しい3 1.2。 他のプロトコル4 1.3との関係。 ドキュメント概要5
2. Protocol Overview 6
2. プロトコル概要6
2.1. Entities, Processes and Principals 7
2.2. Entity Domains 9
2.3. Message Transactions 10
2.4. Request and Response Messages 11
2.5. Reliability 12
2.5.1. Transaction Identifiers 13
2.5.2. Checksum 14
2.5.3. Request and Response Acknowledgment 14
2.5.4. Retransmissions 15
2.5.5. Timeouts 15
2.5.6. Rate Control 18
2.6. Security 19
2.7. Multicast 21
2.8. Real-time Communication 22
2.9. Forwarded Message Transactions 24
2.10. VMTP Management 25
2.11. Streamed Message Transactions 25
2.12. Fault-Tolerant Applications 28
2.13. Packet Groups 29
2.14. Runs of Packet Groups 31
2.15. Byte Order 32
2.16. Minimal VMTP Implementation 33
2.17. Message vs. Procedural Request Handling 33
2.18. Bibliography 34
2.1. 実体、プロセス、および主体7 2.2。 実体ドメイン9 2.3。 メッセージトランザクション10 2.4。 要求と応答メッセージ11 2.5。 信頼性、12 2.5 .1。 トランザクション識別子13 2.5.2。 チェックサム、14 2.5 .3。 要求と応答承認14 2.5.4。 Retransmissions、15 2.5 .5。 タイムアウト、15 2.5 .6。 コントロール18が2.6であると評定してください。 セキュリティ19 2.7。 マルチキャスト21 2.8。 瞬時通信22 2.9。 メッセージトランザクション24 2.10を進めました。 VMTP管理25 2.11。 メッセージトランザクション25 2.12を流しました。 フォールトトレラントアプリケーション28 2.13。 パケットグループ29 2.14。 パケットグループ31 2.15の走行。 バイトオーダー32 2.16。 最小量のVMTP実装33 2.17。 メッセージ対手続き上の要求取り扱33 2.18い 図書目録34
3. VMTP Packet Formats 37
3. VMTPパケット・フォーマット37
3.1. Entity Identifier Format 37 3.2. Packet Fields 38
3.1. エンティティ識別名形式37 3.2。 パケット分野38
Cheriton [page i]
Cheriton[ページi]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
3.3. Request Packet 45 3.4. Response Packet 47
3.3. パケット45 3.4を要求してください。 応答パケット47
4. Client Protocol Operation 49
4. クライアントプロトコル操作49
4.1. Client State Record Fields 49
4.2. Client Protocol States 51
4.3. State Transition Diagrams 51
4.4. User Interface 52
4.5. Event Processing 53
4.6. Client User-invoked Events 54
4.6.1. Send 54
4.6.2. GetResponse 56
4.7. Packet Arrival 56
4.7.1. Response 58
4.8. Management Operations 61
4.8.1. HandleNoCSR 62
4.9. Timeouts 64
4.1. 属国記録分野49 4.2。 クライアントプロトコルは4.3に51を述べます。 4.4に変遷ダイヤグラム51を述べてください。 ユーザーインタフェース52 4.5。 イベント処理53 4.6。 クライアントユーザによって呼び出されたイベント54 4.6.1。 4.6に.2に54を送ってください。 GetResponse56 4.7。 パケット到着56 4.7.1。 応答58 4.8。 管理操作61 4.8.1。 HandleNoCSR62 4.9。 タイムアウト64
5. Server Protocol Operation 66
5. サーバプロトコル操作66
5.1. Remote Client State Record Fields 66
5.2. Remote Client Protocol States 66
5.3. State Transition Diagrams 67
5.4. User Interface 69
5.5. Event Processing 70
5.6. Server User-invoked Events 71
5.6.1. Receive 71
5.6.2. Respond 72
5.6.3. Forward 73
5.6.4. Other Functions 74
5.7. Request Packet Arrival 74
5.8. Management Operations 78
5.8.1. HandleRequestNoCSR 79
5.9. Timeouts 82
5.1. 属国の遠く離れた記録分野66 5.2。 リモートクライアントプロトコルは5.3に66を述べます。 5.4に変遷ダイヤグラム67を述べてください。 ユーザーインタフェース69 5.5。 イベント処理70 5.6。 イベント71 5.6に.1をサーバーのユーザと同じくらい呼び出しました。 5.6に.2に71を受け取ってください。 72を5.6に.3に反応させてください。 5.6に.4に73を進めてください。 他の機能74 5.7。 パケット到着74 5.8を要求してください。 管理操作78 5.8.1。 HandleRequestNoCSR79 5.9。 タイムアウト82
6. Concluding Remarks 84
6. 結びの言葉84
I. Standard VMTP Response Codes 85
I. 標準のVMTP応答コード85
II. VMTP RPC Presentation Protocol 87
II。 VMTP RPCプレゼンテーションプロトコル87
Cheriton [page ii]
Cheriton[ページii]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
II.1. Request Code Management 87
II.1。 コード管理87を要求してください。
III. VMTP Management Procedures 89
III。 VMTP管理手順89
III.1. Entity Group Management 100 III.2. VMTP Management Digital Signatures 101
III.1。 実体集団経営100III.2。 VMTP管理デジタル署名101
IV. VMTP Entity Identifier Domains 102
IV。 VMTPエンティティ識別名ドメイン102
IV.1. Domain 1 102 IV.2. Domain 3 104 IV.3. Other Domains 105 IV.4. Decentralized Entity Identifier Allocation 105
IV.1。 ドメイン1 102IV.2。 ドメイン3 104IV.3。 他のドメイン105IV.4。 分散エンティティ識別名配分105
V. Authentication Domains 107
V。 認証ドメイン107
V.1. Authentication Domain 1 107 V.2. Other Authentication Domains 107
V.1。 認証ドメイン1 107V.2。 他の認証ドメイン107
VI. IP Implementation 108
VI。 IP実装108
VII. Implementation Notes 109
VII。 実装注意109
VII.1. Mapping Data Structures 109 VII.2. Client Data Structures 111 VII.3. Server Data Structures 111 VII.4. Packet Group transmission 112 VII.5. VMTP Management Module 113 VII.6. Timeout Handling 114 VII.7. Timeout Values 114 VII.8. Packet Reception 115 VII.9. Streaming 116 VII.10. Implementation Experience 117
VII.1。 データ構造109VII.2を写像します。 クライアントデータ構造111VII.3。 サーバデータ構造111VII.4。 パケットGroupトランスミッション112VII.5。 VMTP管理モジュール113VII.6。 タイムアウト取り扱114いVII.7。 タイムアウトは114VII.8を評価します。 パケットレセプション115VII.9。 116VII.10を流します。 実装経験117
VIII. UNIX 4.3 BSD Kernel Interface for VMTP 118
VIII。 VMTP118のためのUNIX4.3BSDカーネルインタフェース
Index 120
インデックス120
Cheriton [page iii]
Cheriton[ページiii]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
List of Figures
数字のリスト
Figure 1-1: Relation to Other Protocols 4 Figure 3-1: Request Packet Format 45 Figure 3-2: Response Packet Format 47 Figure 4-1: Client State Transitions 52 Figure 5-1: Remote Client State Transitions 68 Figure III-1: Authenticator Format 92 Figure VII-1: Mapping Client Identifier to CSR 109 Figure VII-2: Mapping Server Identifiers 110 Figure VII-3: Mapping Group Identifiers 111
図1-1: 他のプロトコル4図3-1との関係: パケット・フォーマット45図3-2を要求してください: 応答パケット・フォーマット47は4-1に計算されます: 属国変遷52は5-1に計算されます: リモート属国変遷68はIII-1について計算します: 固有識別文字形式92はVII-1について計算します: クライアント識別子をCSRに写像して、109はVII-2について計算します: マッピングサーバ識別子110はVII-3について計算します: グループ識別子111を写像します。
Cheriton [page iv] RFC 1045 VMTP February 1988
Cheriton[ページiv]RFC1045VMTP1988年2月
1. Introduction
1. 序論
The Versatile Message Transaction Protocol (VMTP) is a transport protocol designed to support remote procedure call (RPC) and general transaction-oriented communication. By transaction-oriented communication, we mean that:
Versatile Message Transactionプロトコル(VMTP)は、遠隔手続き呼び出し(RPC)をサポートするように設計されたトランスポート・プロトコルと一般的なトランザクション指向のコミュニケーションです。 トランザクション指向のコミュニケーションで、私たちは、以下のことと言っています。
- Communication is request-response: A client sends a request
for a service to a server, the request is processed, and the
server responds. For example, a client may ask for the next
page of a file as the service. The transaction is terminated
by the server responding with the next page.
- コミュニケーションは要求応答です: クライアントはサーバに対するサービスを求める要求を送ります、そして、要求は処理されます、そして、サーバは反応します。 例えば、クライアントはサービスとしてファイルの次のページを求めるかもしれません。 トランザクションは次のページで反応するサーバによって終えられます。
- A transaction is initiated as part of sending a request to a
server and terminated by the server responding. There are no
separate operations for setting up or terminating associations
between clients and servers at the transport level.
- トランザクションは、要求をサーバに送る一部として開始されて、サーバの応じることで終えられます。 輸送レベルでクライアントとサーバとの仲間をセットアップするか、または終えるためのどんな別々の操作もありません。
- The server is free to discard communication state about a
client between transactions without causing incorrect behavior
or failures.
- 不正確な振舞いか失敗を引き起こさないで、サーバはトランザクションの間のクライアントに関して無料でコミュニケーション状態を捨てることができます。
The term message transaction (or transaction) is used in the reminder of this document for a request-response exchange in the sense described above.
用語メッセージトランザクション(または、トランザクション)は上で説明された意味における要求応答交換にこのドキュメントを思い出させるもので使用されます。
VMTP handles the error detection, retransmission, duplicate suppression and, optionally, security required for transport-level end-to-end reliability.
VMTPは輸送レベル終わりから終わりへの信頼性に必要である誤り検出、「再-トランスミッション」、写し抑圧、および任意にセキュリティを扱います。
The protocol is designed to provide a range of behaviors within the transaction model, including:
プロトコルはトランザクションモデル、包含の中でさまざまな振舞いを提供するように設計されています:
- Minimal two packet exchanges for short, simple transactions.
- 短くて、簡単なトランザクションへの2回の最小量のパケット交換。
- Streaming of multi-packet requests and responses for efficient
data transfer.
- 効率的なデータ転送のためのマルチパケット要求と応答のストリーミング。
- Datagram and multicast communication as an extension of the
transaction model.
- トランザクションの拡大としてのデータグラムとマルチキャストコミュニケーションはモデル化されます。
Example Uses:
例の用途:
- Page-level file access - VMTP is intended as the transport
level for file access, allowing simple, efficient operation on
a local network. In particular, VMTP is appropriate for use
by diskless workstations accessing shared network file
- ページレベルファイルアクセス--VMTPはファイルアクセスのための輸送レベルとして意図します、企業内情報通信網で簡単で、効率的な操作を許して。 使用に、VMTPは共用回線網ファイルにアクセスするディスクレスワークステーションで特に、適切です。
Cheriton [page 1]
Cheriton[1ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
servers.
サーバ。
- Distributed programming - VMTP is intended to provide an
efficient transport level protocol for remote procedure call
implementations, distributed object-oriented systems plus
message-based systems that conform to the request-response
model.
- 分配されたプログラミング--VMTPが要求応答モデルに一致している遠隔手続き呼び出し実装のための平らなプロトコル、分散オブジェクト指向のシステム、およびメッセージベースのシステムを効率的な輸送に提供することを意図します。
- Multicast communication with groups of servers to: locate a
specific object within the group, update a replicated object,
synchronize the commitment of a distributed transaction, etc.
- サーバのグループとの以下へのマルチキャストコミュニケーション グループの中で特定のオブジェクトの場所を見つけてください、そして、模写されたオブジェクトをアップデートしてください、そして、分配されたトランザクションの委任などを同期させてください。
- Distributed real-time control with prioritized message
handling, including datagrams, multicast and asynchronous
calls.
- データグラムを含んでいて、最優先するメッセージハンドリングがマルチキャストであって非同期の分配された実時間制御は呼びます。
The protocol is designed to operate on top of a simple unreliable datagram service, such as is provided by IP.
プロトコルは、IPによって提供されるような簡単な頼り無いデータグラムサービスの上で作動するように設計されています。
1.1. Motivation
1.1. 動機
VMTP was designed to address three categories of deficiencies with existing transport protocols in the Internet architecture. We use TCP as the key current transport protocol for comparison.
VMTPは、既存のトランスポート・プロトコルがインターネットアーキテクチャにある状態で欠乏の3つのカテゴリを扱うように設計されました。 私たちは比較に主要な現在のトランスポート・プロトコルとしてTCPを使用します。
1.1.1. Poor RPC Performance
1.1.1. 不十分なRPCパフォーマンス
First, current protocols provide poor performance for remote procedure call (RPC) and network file access. This is attributable to three key causes:
まず最初に、現在のプロトコルは遠隔手続き呼び出し(RPC)とネットワークファイルアクセスのための不十分な性能を提供します。 これは3つの主要な原因に起因しています:
- TCP requires excessive packets for RPC, especially for
isolated calls. In particular, connection setup and clear
generates extra packets over that needed for VMTP to support
RPC.
- TCPはRPCと、特に孤立している呼び出しのために過度のパケットを必要とします。 特定の接続セットアップで明確では、VMTPがRPCをサポートするのに必要であるそれの上で付加的なパケットを生成します。
- TCP is difficult to implement, speaking purely from the
empirical experience over the last 10 years. VMTP was
designed concurrently with its implementation, with focus on
making it easy to implement and providing sensible subsets of
its functionality.
- ここ10年間純粋に実証的な経験に基づいて話して、TCPは実装するのが難しいです。 VMTPは同時に実装で設計されました、焦点がそれを実装するのが簡単にして、機能性の分別がある部分集合を提供するところにある状態で。
- TCP handles packet loss due to overruns poorly. We claim that
overruns are the key source of packet loss in a
high-performance RPC environment and, with the increasing
- TCPは超過によるパケット損失を不十分に扱います。 そして、私たちが、超過が高性能RPC環境におけるパケット損失の主要な源であると主張する、増加
Cheriton [page 2]
Cheriton[2ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
performance of networks, will continue to be the key source.
(Older machines and network interfaces cannot keep up with new
machines and network interfaces. Also, low-end network
interfaces for high-speed networks have limited receive
buffering.)
ネットワークの性能、意志はずっと主要なソースです。 (より古いマシンとネットワーク・インターフェースは新しいマシンとネットワーク・インターフェースについて行くことができません。 また、高速ネットワークのためのネットワーク・インターフェースが制限したローエンドはバッファリングを受けます。)
VMTP is designed for ease of implementation and efficient RPC. In addition, it provides selective retransmission with rate-based flow control, thus addressing all of the above issues.
VMTPは実装と効率的なRPCの容易さのために設計されています。 さらに、レートベースのフロー制御を選択している「再-トランスミッション」に提供して、その結果、上記の問題のすべてを扱います。
1.1.2. Weak Naming
1.1.2. 弱い命名
Second, current protocols provide inadequate naming of transport-level endpoints because the names are based on IP addresses. For example, a TCP endpoint is named by an Internet address and port identifier. Unfortunately, this makes the endpoint tied to a particular host interface, not specifically the process-level state associated with the transport-level endpoint. In particular, this form of naming causes problems for process migration, mobile hosts and multi-homed hosts. VMTP provides host-address independent names, thereby solving the above mentioned problems.
2番目に、名前がIPアドレスに基づいているので、現在のプロトコルは輸送レベル終点の不十分な命名を提供します。 例えば、TCP終点はインターネット・アドレスとポート識別子によって命名されます。 残念ながら、これは明確にプロセスレベル状態ではなく、輸送レベル終点に関連している特定のホスト・インターフェースに結ばれた終点になります。 そして、モバイルホスト、特に、この形式の命名がプロセス移行のために問題を起こす、マルチ、家へ帰り、ホスト。 VMTPはホスト・アドレスの独立している名を提供して、その結果、上記の問題を解決します。
In addition, TCP provides no security and reliability guarantees on the dynamically allocated names. In particular, other than well-known ports, (host-addr, port-id)-tuples can change meaning on reboot following a crash. VMTP provides large identifiers with guarantee of stability, meaning that either the identifier never changes in meaning or else remains invalid for a significant time before becoming valid again.
さらに、TCPはダイナミックに割り当てられた名前でセキュリティがなくて信頼性の保証を提供します。 クラッシュに続いて、ウェルノウンポートを除いて、特に、(ホスト-addr、ポートイド)-tuplesはリブートのときに意味を変えることができます。 VMTPは安定性の保証を大きい識別子に提供します、識別子が意味で変化するか、または再び有効になる前に重要な時間無効のままで決して残っていないことを意味して。
1.1.3. Function Poor
1.1.3. 機能の貧乏人
TCP does not support multicast, real-time datagrams or security. In fact, it only supports pair-wise, long-term, streamed reliable interchanges. Yet, multicast is of growing importance and is being developed for the Internet (see RFC 966 and 988). Also, a datagram facility with the same naming, transmission and reception facilities as the normal transport level is a powerful asset for real-time and parallel applications. Finally, security is a basic requirement in an increasing number of environments. We note that security is natural to implement at the transport level to provide end-to-end security (as opposed to (inter)network level security). Without security at the transport level, a transport level protocol cannot guarantee the standard transport level service definition in the presence of an intruder. In particular, the intruder can interject packets or modify
TCPはマルチキャスト、リアルタイムのデータグラムまたはセキュリティを支えません。 事実上、それは対状、長期的で、流された信頼できる置き換えをサポートするだけです。 しかし、マルチキャストは、増加している重要性があって、インターネットに開発していることにされます(RFC966と988を見てください)。 また、正常な輸送レベルとしての同じ命名、トランスミッション、およびレセプション施設があるデータグラム施設はリアルタイムで平行なアプリケーションのための強力な資産です。 最終的に、セキュリティは増加する数の環境で基本的な要件です。 私たちは、セキュリティが終わりから終わりへのセキュリティ((埋葬します)ネットワークレベルセキュリティと対照的に)を提供するために輸送レベルで実装するために当然であることに注意します。 輸送レベル、平らなプロトコルが標準の輸送を保証できない輸送におけるセキュリティがなければ、侵入者の面前でサービス定義を平らにしてください。 特に、侵入者がパケットを挿入できる、変更
Cheriton [page 3]
Cheriton[3ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
packets while updating the checksum, making mockery out of the transport-level claim of "reliable delivery".
チェックサムをアップデートする作成あざけりをパケットは「信頼できる配信」の輸送レベルクレームからゆったり過ごします。
In contrast, VMTP provides multicast, real-time datagrams and security, addressing precisely these weaknesses.
対照的に、正確にこれらの弱点を扱って、VMTPはマルチキャスト、リアルタイムのデータグラム、およびセキュリティを提供します。
In general, VMTP is designed with the next generation of communication systems in mind. These communication systems are characterized as follows. RPC, page-level file access and other request-response behavior dominates. In addition, the communication substrate, both local and wide-area, provides high data rates, low error rates and relatively low delay. Finally, intelligent, high-performance network interfaces are common and in fact required to achieve performance that approximates the network capability. However, VMTP is also designed to function acceptably with existing networks and network interfaces.
一般に、VMTPは通信系の次世代と共に念頭に設計されています。 これらの通信系は以下の通り特徴付けられます。 RPC、ページレベルファイルアクセス、および他の要求応答の振舞いは支配されます。 さらに、ともに地方の、そして、広い領域であるコミュニケーション基板は、高いデータ信号速度、低誤り率、および比較的低い遅れを提供します。 最終的に、知的で、高い性能のネットワーク・インターフェースが、一般的であり、事実上、ネットワーク能力に近似する性能を達成するのに必要です。 しかしながら、また、VMTPは、既存のネットワークとネットワーク・インターフェースで許容できて機能するように設計されています。
1.2. Relation to Other Protocols
1.2. 他のプロトコルとの関係
VMTP is a transport protocol that fits into the layered Internet protocol environment. Figure 1-1 illustrates the place of VMTP in the protocol hierarchy.
VMTPは層にされたインターネットプロトコル環境に収まるトランスポート・プロトコルです。 図1-1はプロトコル階層でVMTPの場所を例証します。
+-----------+ +----+ +-----------------+ +------+
|File Access| |Time| |Program Execution| |Naming|... Application
+-----------+ +----+ +-----------------+ +------+ Layer
| | | | |
+-----------+-----------+-------------+------+
|
+------------------+
| RPC Presentation | Presentation
+------------------+ Layer
|
+------+ +--------+
| TCP | | VMTP | Transport
+------+ +--------+ Layer
| |
+-----------------------------------+
| Internet Protocol & ICMP | Internetwork
+-----------------------------------+ Layer
+-----------+ +----+ +-----------------+ +------+ |ファイルアクセス| |時間| |プログラム実行| |命名|... アプリケーション+-----------+ +----+ +-----------------+ +------+ 層| | | | | +-----------+-----------+-------------+------+ | +------------------+ | RPCプレゼンテーション| プレゼンテーション+------------------+ 層| +------+ +--------+ | TCP| | VMTP| 輸送+------+ +--------+ 層| | +-----------------------------------+ | インターネットプロトコルとICMP| インターネットワーク+-----------------------------------+ 層
Figure 1-1: Relation to Other Protocols
図1-1: 他のプロトコルとの関係
The RPC presentation level is not currently defined in the Internet suite of protocols. Appendix II defines a proposed RPC presentation level for use with VMTP and assumed for the definition of the VMTP management procedures. There is also a need for the definition of the
RPCプレゼンテーションレベルは現在、プロトコルのインターネットスイートで定義されません。 付録IIはVMTPとの使用に平らでVMTP管理手順の定義のために想定された提案されたRPCプレゼンテーションを定義します。 また、定義の必要があります。
Cheriton [page 4]
Cheriton[4ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
Application layer protocols listed above.
応用層プロトコルは上に記載しました。
If internetwork services are not required, VMTP can be used without the IP layer, layered directly on top of the network or data link layers.
相互ネットワーク・サービスは必要でないなら、ネットワークかデータ・リンク層の直接上で層にされたIP層なしでVMTPを使用できます。
1.3. Document Overview
1.3. ドキュメント概要
The next chapter gives an overview of the protocol, covering naming, message structure, reliability, flow control, streaming, real-time, security, byte-ordering and management. Chapter 3 describes the VMTP packet formats. Chapter 4 describes the client VMTP protocol operation in terms of pseudo-code for event handling. Chapter 5 describes the server VMTP protocol operation in terms of pseudo-code for event handling. Chapter 6 summarizes the state of the protocol, some remaining issues and expected directions for the future. Appendix I lists some standard Response codes. Appendix II describes the RPC presentation protocol proposed for VMTP and used with the VMTP management procedures. Appendix III lists the VMTP management procedures. Appendix IV proposes initial approaches for handling entity identification for VMTP. Appendix V proposes initial authentication domains for VMTP. Appendix VI provides some details for implementing VMTP on top of IP. Appendix VII provides some suggestions on host implementation of VMTP, focusing on data structures and support functions. Appendix VIII describes a proposed program interface for UNIX 4.3 BSD and its descendants and related systems.
次の章はプロトコルの概要を与えます、命名、メッセージ構造、信頼性、フロー制御、ストリーミングの、そして、リアルタイムのセキュリティ、バイト順、および管理を含んでいて。 第3章はVMTPパケット・フォーマットについて説明します。 第4章はイベント取り扱いのために中間コードに関してクライアントVMTPプロトコル操作について説明します。 第5章はイベント取り扱いのために中間コードに関してサーバVMTPプロトコル操作について説明します。 第6章はいくつかのプロトコルの事情、残された問題、および予想された方向を未来へまとめます。 付録Iはいくつかの標準のResponseコードを記載します。 付録IIはVMTPのために提案されて、VMTP管理手順で使用されるRPCプレゼンテーションプロトコルについて説明します。 付録IIIはVMTP管理手順を記載します。 付録IVはVMTPのために取り扱い実体識別のための初期のアプローチを提案します。 付録VはVMTPのために初期の認証ドメインを提案します。 付録VIはIPの上でVMTPを実装するためのいくつかの詳細を明らかにします。 データ構造と支援機能に焦点を合わせて、付録VIIはVMTPのホスト導入のときにいくつかの提案を提供します。 付録VIIIはそのUNIX4.3BSD、子孫、および関連系のために提案されたプログラムインタフェースについて説明します。
Cheriton [page 5]
Cheriton[5ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
2. Protocol Overview
2. プロトコル概要
VMTP provides an efficient, reliable, optionally secure transport service in the message transaction or request-response model with the following features:
VMTPは以下の特徴と共に効率的で、信頼できて、任意に安全な輸送サービスをメッセージトランザクションか要求応答モデルに供給します:
- Host address-independent naming with provision for multiple
forms of names for endpoints as well as associated (security)
principals. (See Sections 2.1, 2.2, 3.1 and Appendix IV.)
- 複数のフォームの名前への支給で関連(セキュリティ)主体と同様に終点にアドレスから独立している命名を主催してください。 (セクション2.1、2.2、3.1と付録IVを見てください。)
- Multi-packet request and response messages, with a maximum
size of 4 megaoctets per message. (Sections 2.3 and 2.14.)
- マルチパケット要求と1メッセージあたりの4megaoctetsの最大サイズがある応答メッセージ。 (セクション2.3と2.14。)
- Selective retransmission. (Section 2.13.) and rate-based flow
control to reduce overrun and the cost of overruns. (Section
2.5.6.)
- 選択している「再-トランスミッション」。 (セクション2.13。) そして、超過とコストを削減するレートベースのフロー制御は氾濫します。 (セクション2.5.6。)
- Secure message transactions with provision for a variety of
encryption schemes. (Section 2.6.)
- さまざまな暗号化体系への支給でメッセージトランザクションを保証してください。 (セクション2.6。)
- Multicast message transactions with multiple response messages
per request message. (Section 2.7.)
- 複数の1要求メッセージあたりの応答メッセージがあるマルチキャストメッセージトランザクション。 (セクション2.7。)
- Support for real-time communication with idempotent message
transactions with minimal server overhead and state (Section
2.5.3), datagram request message transactions with no
response, optional header-only checksum, priority processing
of transactions, conditional delivery and preemptive handling
of requests (Section 2.8)
- 最小量のサーバオーバーヘッドと状態(セクション2.5.3)があるベキ等元メッセージトランザクション、応答、任意のヘッダーだけチェックサム、要求のトランザクション、条件付きの配送、および先買いの取り扱いの優先順位処理のないデータグラム要求メッセージトランザクションとのリアルタイムのコミュニケーションのサポート(セクション2.8)
- Forwarded message transactions as an optimization for certain
forms of nested remote procedure calls or message
transactions. (Section 2.9.)
- あるフォームの入れ子にされた遠隔手続き呼び出しかメッセージトランザクションのための最適化としてメッセージトランザクションを進めました。 (セクション2.9。)
- Multiple outstanding (asynchronous) message transactions per
client. (Section 2.11.)
- 複数の1クライアントあたりの傑出している(非同期な)メッセージトランザクション。 (セクション2.11。)
- An integrated management module, defined with a remote
procedure call interface on top of VMTP providing a variety of
communication services (Section 2.10.)
- さまざまな通信サービスを提供しながらVMTPの上で遠隔手続き呼び出しインタフェースで定義された統一管理モジュール(セクション2.10。)
- Simple subset implementation for simple clients and simple
servers. (Section 2.16.)
- 純真なクライアントと簡単なサーバのための簡単な部分集合実装。 (セクション2.16。)
This chapter provides an overview of the protocol as introduction to the basic ideas and as preparation for the subsequent chapters that describe the packet formats and event processing procedures in detail.
本章は基本的な考え方への序論として準備として詳細にパケット・フォーマットとイベント現像処理を説明するすぐ次の章にプロトコルの概要を提供します。
Cheriton [page 6]
Cheriton[6ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
In overview, VMTP provides transport communication between network- visible entities via message transactions. A message transaction consists of a request message sent by the client, or requestor, to a group of server entities followed by zero or more response messages to the client, at most one from each server entity. A message is structured as a message control portion and a segment data portion. A message is transmitted as one or more packet groups. A packet group is one or more packets (up to a maximum of 32 packets) grouped by the protocol for acknowledgment, sequencing, selective retransmission and rate control.
概要に、VMTPはメッセージトランザクションでネットワークの目に見える実体の輸送コミュニケーションを提供します。 要請者、メッセージトランザクションがクライアントによって送られた要求メッセージから成ったか、またはサーバ実体のグループに、クライアントへの応答メッセージはゼロか以上で従っていました、それぞれのサーバ実体からのほとんどの1つで。 メッセージはメッセージ制御部分とセグメントデータ部として構造化されます。 1つ以上のパケットが分類されるとき、メッセージは送られます。 パケットグループは承認、配列、選択している「再-トランスミッション」、および速度制御のためにプロトコルによって分類された1つ以上のパケット(最大最大32のパケット)です。
Entities and VMTP operations are managed using a VMTP management mechanism that is accessed through a procedural interface (RPC) implemented on top of VMTP. In particular, information about a remote entity is obtained and maintained using the Probe VMTP management operation. Also, acknowledgment information and requests for retransmission are sent as notify requests to the management module. (In the following description, reference to an "acknowledgment" of a request or a response refers to a management-level notify operation that is acknowledging the request or response.)
実体とVMTP操作は、VMTPの上で実装された手続き上のインタフェース(RPC)を通してアクセスされるVMTP管理メカニズムを使用することで管理されます。 リモート実体の情報は、Probe VMTP管理操作を使用することで特に、得られて、保守されます。 また、管理モジュールに要求に通知するとき、「再-トランスミッション」を求める承認情報と要求を送ります。 (中では、以下の記述、応答が参照する要求かaの「承認」a管理者の各レベルの参照は要求か応答を承諾している操作に通知します。)
2.1. Entities, Processes and Principals
2.1. 実体、プロセス、および主体
VMTP defines and uses three main types of identifiers: entity identifiers, process identifiers and principal identifiers, each 64-bits in length. Communication takes place between network-visible entities, typically mapping to, or representing, a message port or procedure invocation. Thus, entities are the VMTP communication endpoints. The process associated with each entity designates the agent behind the communication activity for purposes of resource allocation and management. For example, when a lock is requested on a file, the lock is associated with the process, not the requesting entity, allowing a process to use multiple entity identifiers to perform operations without lock conflict between these entities. The principal associated with an entity specifies the permissions, security and accounting designation associated with the entity. The process and principal identifiers are included in VMTP solely to make these values available to VMTP users with the security and efficiency provided by VMTP. Only the entity identifiers are actively used by the protocol.
VMTPは3つの主なタイプに関する識別子を定義して、使用します: 長さにおけるそれぞれ64ビットのエンティティ識別名、プロセス識別子、および主要な識別子。 撮影が目に見えるネットワーク実体、通常マッピングの間で入賞するか、または表しているaメッセージが移植するコミュニケーションか手順実施。 したがって、実体はVMTPコミュニケーション終点です。 各実体に関連しているプロセスは資源配分と管理の目的のためのコミュニケーション活動の後ろでエージェントを任命します。 錠がファイルの上で要求されているとき、例えば、錠は要求実体ではなく、プロセスに関連しています、プロセスがこれらの実体の間のロック闘争なしで操作を実行するのに複数のエンティティ識別名を使用するのを許容して。 実体に関連している校長は実体に関連している許容、セキュリティ、および会計名称を指定します。 プロセスと主要な識別子は、唯一これらの値をセキュリティと効率がVMTPによって提供されている状態でVMTPユーザにとって利用可能にするようにVMTPに含まれています。 エンティティ識別名だけがプロトコルによって活発に使用されます。
Entity identifiers are required to have three properties;
エンティティ識別名が3つの特性を持つのに必要です。
Uniqueness Each entity identifier is uniquely defined at any given
time. (An entity identifier may be reused over time.)
ユニークさのEachエンティティ識別名はその時々で唯一定義されます。 (エンティティ識別名は時間がたつにつれて、再利用されるかもしれません。)
Stability An entity identifier does not change between valid
安定性Anエンティティ識別名は有効であることの間で変化しません。
Cheriton [page 7]
Cheriton[7ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
meanings without suitable provision for removing
references to the entity identifier. Certain entity
identifiers are strictly stable, (i.e. never changing
meaning), typically being administratively assigned
(although they need not be bound to a valid entity at
all times), often called well-known identifiers. All
other entity identifiers are required to be T-stable,
not change meaning without having remained invalid for
at least a time interval T.
エンティティ識別名の参照を取り除くことへの適当な支給のない意味。 あるエンティティ識別名が厳密に安定している、割り当てられて、しばしばよく知られる識別子と呼ばれて、(すなわち、意味を決して変えません)は行政上通常、こと(それらはいつも有効な実体に縛られなければならないというわけではありませんが)です。 他のすべてのエンティティ識別名が、少なくとも時間間隔Tの間、無効のままで残っていなくて意味を変えるのではなく、T安定しているのに必要です。
Host address independent
An entity identifier is unique independent of the host
address of its current host. Moreover, an entity
identifier is not tied to a single Internet host
address. An entity can migrate between hosts, reside on
a mobile host that changes Internet addresses or reside
on a multi-homed host. It is up to the VMTP
implementation to determine and maintain up to date the
host addresses of entities with which it is
communicating.
ホスト・アドレスの独立しているAnエンティティ識別名は現在のホストのホスト・アドレスの如何にかかわらずユニークです。 そのうえ、エンティティ識別名はただ一つのインターネットホスト・アドレスに結ばれません。 実体がホストの間を移住するか、インターネット・アドレスを変えるモバイルホストの上に住んでいるか、またはaにあることができる、マルチ、家へ帰り、ホスト。 最新にそれが交信する予定である実体のホスト・アドレスを決定して、維持するのはVMTP実装まで達しています。
The stability of entity identifiers guarantees that an entity identifier represents the same logical communication entity and principal (in the security sense) over the time that it is valid. For example, if an entity identifier is authenticated as having the privileges of a given user account, it continues to have those privileges as long as it is continuously valid (unless some explicit notice is provided otherwise). Thus, a file server need not fully authenticate the entity on every file access request. With T-stable identifiers, periodically checking the validity of an entity identifier with period less than T seconds detects a change in entity identifier validity.
エンティティ識別名の安定性は、エンティティ識別名がそれが有効であることの時間同じ論理的なコミュニケーション実体と主体(セキュリティ意味における)を表すのを保証します。 例えば、エンティティ識別名が与えられたユーザアカウントの特権を持っていると認証されるなら、それは、それが絶え間なく有効である(何らかの明白な通知が別の方法で提供されない場合)限り、それらの特権を持ち続けています。 したがって、ファイルサーバーはあらゆるファイルアクセス要求のときに完全に実体を認証しなければならないというわけではありません。 T安定した識別子で、定期的にエンティティ識別名の正当性について期間に問い合わせて、T秒以下はエンティティ識別名の正当性における変化を検出します。
A group of entities can form an entity group, which is a set of zero or more entities identified by a single entity identifier. For example, one can have a single entity identifier that identifies the group of name servers. An entity identifier representing an entity group is drawn from the same name space as entity identifiers. However, single entity identifiers are flagged as such by a bit in the entity identifier, indicating that the identifier is known to identify at most one entity. In addition to the group bit, each entity identifier includes other standard type flags. One flag indicates whether the identifier is an alias for an entity in another domain (See Section 2.2 below.). Another flag indicates, for an entity group identifier, whether the identifier is a restricted group or not. A restricted group is one in which an entity can be added only by another entity with group management authorization. With an unrestricted group, an entity is allowed to add itself. If an entity identifier does not represent a
実体のグループは実体グループを結成できます、とどれが1セットのゼロであるか、そして、より多くの実体が単一体識別子で特定しました。 例えば、1つはネームサーバのグループを特定する単一体識別子を持つことができます。 エンティティ識別名と同じ名前スペースから実体グループを代表するエンティティ識別名を得ます。 しかしながら、単一体識別子はエンティティ識別名でそういうものとして少し旗を揚げられます、識別子が、ある実体を高々特定するのが知られているのを示して。 グループビットに加えて、各エンティティ識別名は他の標準体型旗を含んでいます。 1個の旗が、別のドメインの実体のために識別子が別名であるかどうかを示します(以下のセクション2.2を見てください。)。 別の旗は、実体グループ識別子のために識別子が制限されたグループであるかどうかを示します。 制限されたグループは集団経営承認がある別の実体だけで実体を加えることができるものです。 無制限なグループと共に、実体はそれ自体を加えることができます。 エンティティ識別名がaを表さないなら
Cheriton [page 8]
Cheriton[8ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
group, a type bit indicates whether the entity uses big-endian or little-endian data representation (corresponding to Motorola 680X0 and VAX byte orders, respectively). Further specification of the format of entity identifiers is contained in Section 3.1 and Appendix IV.
分類してください、と実体がビッグエンディアンかリトルエンディアンデータ表現(モトローラ680X0とVAXバイトオーダーに対応しますそれぞれ)を使用するか否かに関係なく、タイプビットは示します。 エンティティ識別名の形式のさらなる仕様はセクション3.1とAppendix IVに含まれています。
An entity identifier identifies a Client, a Server or a group of Servers <1>. A Client is always identified by a T-stable identifier. A server or group of servers may be identified by a a T-stable identifier (group or single entity) or by strictly stable (statically assigned) entity group identifier. The same T-stable identifier can be used to identify a Client and Server simultaneously as long as both are logically associated with the same entity. The state required for reliable, secure communication between entities is maintained in client state records (CSRs), which include the entity identifier of the Client, its principal, its current or next transaction identifier and so on.
エンティティ識別名はServers<1>のClient、Serverまたはグループを特定します。 ClientはいつもT安定した識別子によって特定されます。 サーバのサーバかグループが識別子(グループか単一体)か厳密に安定した(静的に割り当てられた)実体によるT-うまやのグループ識別子によって特定されるかもしれません。 両方が同じ実体に論理的に関連している限り、同時にClientとServerを特定するのに同じT安定した識別子を使用できます。 実体の信頼できて、安全なコミュニケーションに必要である状態は属国記録(CSRs)で維持されます。(記録はそのClientか主体か電流か次のトランザクション識別子などに関するエンティティ識別名を含んでいます)。
2.2. Entity Domains
2.2. 実体ドメイン
An entity domain is an administration or an administration mechanism that guarantees the three required entity identifier properties of uniqueness, stability and host address independence for the entities it administers. That is, entity identifiers are only guaranteed to be unique and stable within one entity domain. For example, the set of all Internet hosts may function as one domain. Independently, the set of hosts local to one autonomous network may function as a separate domain. Each entity domain is identified by an entity domain identifier, Domain. Only entities within the same domain may communicate directly via VMTP. However, hosts and entities may participate in multiple entity domains simultaneously, possibly with different entity identifiers. For example, a file server may participate in multiple entity domains in order to provide file service to each domain. Each entity domain specifies the algorithms for allocation, interpretation and mapping of entity identifiers.
実体ドメインは、3がそれが管理する実体のためにユニークさ、安定性、およびホスト・アドレス独立のエンティティ識別名の特性を必要としたのを保証する管理か管理メカニズムです。 すなわち、エンティティ識別名は、1つの実体ドメインの中でユニークであって、安定しているために保証されるだけです。 例えば、すべてのインターネット・ホストのセットは1つのドメインとして機能するかもしれません。 独自に、1つの自治のネットワークへの地元のホストのセットは別々のドメインとして機能するかもしれません。 Domain、それぞれの実体ドメインは実体ドメイン識別子によって特定されます。 同じドメインの中の実体だけがVMTPを通して直接伝達するかもしれません。 しかしながら、ホストと実体は同時に、ことによると異なったエンティティ識別名で複数の実体ドメインに参加するかもしれません。 例えば、ファイルサーバーは、各ドメインに対するファイルサービスを提供するために複数の実体ドメインに参加するかもしれません。 それぞれの実体ドメインはエンティティ識別名に関する配分、解釈、およびマッピングにアルゴリズムを指定します。
Domains are necessary because it does not appear feasible to specify one universal VMTP entity identification administration that covers all entities for all time. Domains limit the number of entities that need to be managed to maintain the uniqueness and stability of the entity
時間中にすべての実体をカバーする1つの普遍的なVMTP実体識別機関を指定するのが可能に見えないので、ドメインが必要です。 ドメインは実体のユニークさと安定性を維持するために管理される必要がある実体の数を制限します。
_______________
_______________
<1> Terms such as Client, Server, Request, Response, etc. are capitalized in this document when they refer to their specific meaning in VMTP.
本書では彼らがVMTPでの自分達の特定の意味を示すとき、Client、Server、Request、Responseなどの<1>用語は大文字で書かれます。
Cheriton [page 9]
Cheriton[9ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
name space. Domains can also serve to separate entities of different security levels. For instance, allocation of a unclassified entity identifier cannot conflict with secret level entity identifiers because the former is interpreted only in the unclassified domain, which is disjoint from the secret domain.
スペースを命名してください。 また、ドメインは、異なったセキュリティー・レベルの実体を切り離すのに役立つことができます。 例えば、前者が非分類されたドメイン(秘密のドメインからばらばらになることである)だけで解釈されるので、非分類されたエンティティ識別名の配分は秘密の平らなエンティティ識別名と衝突できません。
It is intended that there be a small number of domains. In particular, there should be one (or a few) domains per installation "type", rather than per installation. For example, the Internet is expected to use one domain per security level, resulting in at most 8 different domains. Cluster-based internetwork architectures, those with a local cluster protocol distinct from the wide-area protocol, may use one domain for local use and one for wide-area use.
そこに、いてください。意図する、それ、少ない数のドメイン。 特に、インストール単位でというよりむしろインストール「タイプ」あたり1つ(または、いくつか)のドメインがあるべきです。 例えば、8つの異なったドメインを高々もたらして、インターネットが1セキュリティー・レベルあたり1つのドメインを使用すると予想されます。 クラスタベースのインターネットワークアーキテクチャ(広い領域プロトコルと異なったローカルのクラスタプロトコルがあるそれら)は地方の使用のための1つのドメインと広い領域使用のための1つを使用するかもしれません。
Additional details on the specification of specific domains is provided in Appendix IV.
特定のドメインの仕様に関する追加詳細はAppendix IVに明らかにされます。
2.3. Message Transactions
2.3. メッセージトランザクション
The message transaction is the unit of interaction between a Client that initiates the transaction and one or more Servers. A message transaction starts with a request message generated by a client. At the service interface, a server becomes involved with a transaction by receiving and accepting the request. A server terminates its involvement with a transaction by sending a response message. In a group message transaction, the server entity designated by the client corresponds to a group of entities. In this case, each server in the group receives a copy of the request. In the client's view, the transaction is terminated when it receives the response message or, in the case of a group message transaction, when it receives the last response message. Because it is normally impractical to determine when the last response message has been received. the current transaction is terminated by VMTP when the next transaction is initiated.
メッセージトランザクションはトランザクションを開始するClientと1Serversとの相互作用のユニットです。 メッセージトランザクションはクライアントによって生成された要求メッセージから始まります。 サービスインタフェースでは、サーバは受信して、要請を受け入れることによってトランザクションにかかわるようになります。 サーバは、応答メッセージを送ることによって、トランザクションへのかかわり合いを終えます。 グループメッセージトランザクションでは、クライアントによって指定されたサーバ実体は実体のグループに対応しています。 この場合、グループにおける各サーバは要求のコピーを受けます。 応答メッセージを受けるとき、クライアントの意見では、トランザクションが終えられるか、またはそれであることのグループメッセージトランザクションの場合では、最後の応答メッセージは受信されています。 最後の応答メッセージがいつ受け取られたかを決定するのが通常非実用的であるので、次のトランザクションが開始されるとき. 経常取引はVMTPによって終えられます。
Within an entity domain, a transaction is uniquely identified by the tuple (Client, Transaction, ForwardCount). where Transaction is a 32-bit number and ForwardCount is a 4-bit value. A Client uses monotonically increasing Transaction identifiers for new message transactions. Normally, the next higher transaction number, modulo 2**32, is used for the next message transaction, although there are cases in which it skips a small range of Transaction identifiers. (See the description of the STI control flag.) The ForwardCount is used when a message transaction is forwarded and is zero otherwise.
実体ドメインの中では、トランザクションはtuple(クライアント、Transaction、ForwardCount)によって唯一特定されます。どこTransactionは32ビットの数であるか、そして、ForwardCountは4ビットの値です。 Clientは新しいメッセージトランザクションに増加するTransaction識別子を単調に使用します。 通常、次の、より大きいトランザクション番号(法2**32)は次のメッセージトランザクションに使用されます、それが小さい範囲に関するTransaction識別子をスキップする場合がありますが。 (STI指揮旗の記述を見てください。) メッセージトランザクションを進めるとき、使用されています。そうでなければ、ForwardCountはゼロです。
A Client generates a stream of message transactions with increasing transaction identifiers, directed at a diversity of Servers. We say a
Clientは増加するServersの多様性が向けられたトランザクション識別子でメッセージトランザクションのストリームを生成します。 私たちはaを言います。
Cheriton [page 10]
Cheriton[10ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
Client has a transaction outstanding if it has invoked a message transaction, but has not received the last Response (or possibly any Response). Normally, a Client has only one transaction outstanding at a time. However, VMTP allows a Client to have multiple message transactions outstanding simultaneously, supporting streamed, asynchronous remote procedure call invocations. In addition, VMTP supports nested calls where, for example, procedure A calls procedure B which calls procedure C, each on a separate host with different client entity identifiers for each call but identified with the same process and principal.
クライアントは、それがメッセージトランザクションを呼び出したなら未払いのトランザクションを持っていますが、最後のResponse(または、ことによるとどんなResponseも)を受け取っていません。 通常、Clientには、一度に未払いの1つのトランザクションしかありません。 しかしながら、流されて、非同期な遠隔手続き呼び出し実施をサポートして、VMTPはClientに同時に未払いの複数のメッセージトランザクションを持たせます。 さらに、VMTPサポートは、それぞれ各呼び出しのための異なったクライアントエンティティ識別名をもっている別々のホストの上で例えば、手順Aが、手順Cと呼ぶ手順Bと呼ぶところで呼び出しを入れ子にしましたが、同じプロセスと主体を同一視しました。
2.4. Request and Response Messages
2.4. 要求と応答メッセージ
A message transaction consists of a request message and one or more Response messages. A message is structured as message control block (MCB) and segment data, passed as parameters, as suggested below.
メッセージトランザクションは要求メッセージと1つ以上のResponseメッセージから成ります。 メッセージはメッセージ制御ブロック(MCB)とパラメタ、以下で示されることとして渡されたセグメントデータとして構造化されます。
+-----------------------+ | Message Control Block | +-----------------------+ +-----------------------------------+ | segment data | +-----------------------------------+
+-----------------------+ | メッセージ制御ブロック| +-----------------------+ +-----------------------------------+ | セグメントデータ| +-----------------------------------+
In the request message, the MCB specifies control information about the request plus an optional data segment. The MCB has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ServerEntityId (8 octets) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | RequestCode | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + CoresidentEntity (8 octets) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > User Data (12 octets) < +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MsgDelivery | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SegmentSize | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
要求メッセージでは、MCBは要求に関する制御情報と任意のデータ・セグメントを指定します。 MCBには、以下の形式があります: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1++++++++++++++++++++++++++++++++++ServerEntityId(8つの八重奏)++++++++++++++++++++++++++++++++++| 旗| RequestCode| 八重奏..八重奏| MsgDelivery| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SegmentSize| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The ServerEntityId is the entity to which the Request MCB is to be sent (or was sent, in the case of reception). The Flags indicate various options in the request and response handling as well as whether the
ServerEntityIdはRequest MCBが送られることになっている(または、レセプションの場合では、送りました)実体です。 Flagsはまた、要求と応答取り扱いにおける様々なオプションを示します。
Cheriton [page 11]
Cheriton[11ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
CoresidentEntity, MsgDelivery and SegmentSize fields are in use. The RequestCode field specifies the type of Request. It is analogous to a packet type field of the Ethernet, acting as a switch for higher-level protocols. The CoresidentEntity field, if used, designates a subgroup of the ServerEntityId group to which the Request should be routed, namely those members that are co-resident with the specified entity (or entity group). The primary intended use is to specify the manager for a particular service that is co-resident with a particular entity, using the well-known entity group identifier for the service manager in the ServerEntityId field and the identifier for the entity in the CoresidentEntity field. The next 12 octets are user- or application-specified.
CoresidentEntity、MsgDelivery、およびSegmentSize分野は使用中です。 RequestCode分野はRequestのタイプを指定します。 上位レベル・プロトコルのためのスイッチとして機能して、それはイーサネットのパケットタイプ分野に類似しています。 使用されるなら、CoresidentEntity分野はRequestが発送されるべきであるServerEntityIdグループのサブグループ、すなわち、指定された実体(または、実体グループ)をもっているコレジデントであるそれらのメンバーを任命します。 プライマリ意図している使用は特定の実体をもっているコレジデントである特定のサービスにマネージャを指定することです、実体にCoresidentEntity分野でServerEntityId分野と識別子でサービス・マネージャへのよく知られる実体グループ識別子を使用して。 次の12の八重奏が、ユーザかアプリケーションによって指定されています。
The MsgDelivery field is optionally used by the RPC or user level to specify the portions of the segment data to transmit and on reception, the portions received. It provides the client and server with (optional) access to, and responsibility for, a simple selective transmission and reception facility. For example, a client may request retransmission of just those portions of the segment that it failed to receive as part of the original Response. The primary intended use is to support highly efficient multi-packet reading from a file server. Exploiting user-level selective retransmission using the MsgDelivery field, the file server VMTP module need not save multi-packet Responses for retransmission. Retransmissions, when needed, are instead handled directly from the file server buffers.
MsgDelivery分野はRPCかユーザレベルによって任意に使用されて、伝わるようにセグメントデータの部分を指定した、レセプションでは、部分は受信されました。 (任意)のアクセスがあるクライアントとサーバを提供する、責任、簡単な選択式変速機とレセプション施設。 例えば、クライアントはまさしくそれがオリジナルのResponseの一部として受けなかったセグメントのそれらの部分の「再-トランスミッション」を要求するかもしれません。 プライマリ意図している使用はファイルサーバーからの高能率的なマルチパケット読書をサポートすることです。MsgDelivery分野を使用することでユーザレベルの選択している「再-トランスミッション」を利用して、ファイルサーバーVMTPモジュールは、「再-トランスミッション」のためにマルチパケットResponsesを取っておく必要はありません。 必要であると、Retransmissionsは代わりに直接ファイルサーバーバッファから扱われます。
The SegmentSize field indicates the size of the data segment, if present. The CoresidentEntity, MsgDelivery and SegmentSize fields are usable as additional user data if they are not otherwise used.
存在しているなら、SegmentSize分野はデータ・セグメントのサイズを示します。 それらが別の方法で使用されないなら、CoresidentEntity、MsgDelivery、およびSegmentSize分野は追加利用者データとして使用可能です。
The Flags field provides a simple mechanism for the user level to communicate its use of VMTP options with the VMTP module as well as for VMTP modules to communicate this use among themselves. The use of these options is generally fixed for each remote procedure so that an RPC mechanism using VMTP can treat the Flags as an integral part of the RequestCode field for the purpose of demultiplexing to the correct stub.
ユーザレベルがVMTPモジュールとVMTPオプションの使用を伝えて、VMTPモジュールが自分たちの中でこの使用を伝えるように、Flags分野は簡単なメカニズムを提供します。 一般に、VMTPを使用するRPCメカニズムが正しいスタッブへの逆多重化の目的のためにRequestCode分野の不可欠の地域としてFlagsを扱うことができて、これらのオプションの使用はそれぞれのリモート手順のために修理されています。
A Response message control block follows the same format except the Response is sent from the Server to the Client and there is no Coresident Entity field (and thus 20 octets of user data).
Responseメッセージ制御ブロックはResponse以外の形式がServerから送られる同じくらいClientに続きます、そして、Coresident Entity分野(そして、その結果、利用者データの20の八重奏)が全くありません。
2.5. Reliability
2.5. 信頼性
VMTP provides reliable, sequenced transfer of request and response messages as well as several variants, such as unreliable datagram requests. The reliability mechanisms include: transaction identifiers,
VMTPは要求の信頼できて、配列された転送といくつかの異形と同様にあてにならないデータグラム要求などの応答メッセージを供給します。 信頼性のメカニズムは: トランザクション識別子
Cheriton [page 12]
Cheriton[12ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
checksums, positive acknowledgment of messages and timeout and retransmission of lost packets.
チェックサム、無くなっているパケットのメッセージ、タイムアウト、および「再-トランスミッション」の肯定応答。
2.5.1. Transaction Identifiers
2.5.1. トランザクション識別子
Each message transaction is uniquely identified by the pair (Client, Transaction). (We defer discussion of the ForwardCount field to Section 2.9.) The 32-bit transaction identifier is initialized to a random value when the Client entity is created or allocated its entity identifier. The transaction identifier is incremented at the end of each message transaction. All Responses with the same specified (Client, Transaction) pair are associated with this Request.
それぞれのメッセージトランザクションは組(クライアント、Transaction)によって唯一特定されます。 (私たちはForwardCount分野の議論をセクション2.9に延期します。) Client実体は作成するか、またはエンティティ識別名を割り当てるとき、32ビットのトランザクション識別子を無作為の値に初期化します。 トランザクション識別子はそれぞれのメッセージトランザクションの終わりで増加されます。 同じ指定された(クライアント、Transaction)組があるすべてのResponsesがこのRequestに関連しています。
The transaction identifier is used for duplicate suppression at the Server. A Server maintains a state record for each Client for which it is processing a Request, identified by (Client, Transaction). A Request with the same (Client, Transaction) pair is discarded as a duplicate. (The ForwardCount field must also be equal.) Normally, this record is retained for some period after the Response is sent, allowing the Server to filter out subsequent duplicates of this Request. When a Request arrives and the Server does not have a state record for the sending Client, the Server takes one of three actions:
トランザクション識別子はServerでの写し抑圧に使用されます。Serverはそれが(クライアント、Transaction)によって特定されたRequestを処理している各Clientのための州の記録を保守します。 同じ(クライアント、Transaction)組があるRequestは写しとして捨てられます。 (また、ForwardCount分野も等しいに違いありません。) 通常、Responseを送った後にいつかの期間、この記録を保有します、ServerがこのRequestのその後の写しを無視するのを許容して。 Requestが到着して、Serverが発信しているClientのために状態を記録させないとき、Serverは3つの動作の1つを取ります:
1. The Server may send a Probe request, a simple query
operation, to the VMTP management module associated with the
requesting Client to determine the Client's current
Transaction identifier (and other information), initialize a
new state record from this information, and then process the
Request as above.
1. ServerはProbe要求を送るかもしれません、簡単な質問操作、管理モジュールがClientの現在のTransaction識別子(そして、他の情報)を決定して、この情報からの新しい州の記録を初期化して、次に、Requestを処理するために同じくらい上で要求しているClientに関連づけたVMTPに。
2. The Server may reason that the Request must be a new request
because it does not have a state record for this Client if it
keeps these state records for the maximum packet lifetime of
packets in the network (plus the maximum VMTP retransmission
time) and it has not been rebooted within this time period.
That is, if the Request is not new either the Request would
have exceeded the maximum packet lifetime or else the Server
would have a state record for the Client.
2. Serverは、州が、このClientのためにそれでネットワーク(最大のVMTP retransmission時間)でパケットの最大のパケット生存期間のこれらの州の記録をつけるかどうか記録しないのでRequestが新しい要求であるに違いないと推論するかもしれません、そして、それはこの期間中にリブートされていません。 すなわち、Requestが新しくないなら、Requestが最大のパケット生存期間を超えていただろうか、またはServerはClientのために状態を記録させるでしょう。
3. The Server may know that the Request is idempotent or can be
safely redone so it need not care whether the Request is a
duplicate or not. For example, a request for the current
time can be responded to with the current time without being
concerned whether the Request is a duplicate. The Response
is discarded at the Client if it is no longer of interest.
3. Requestはベキ等元であるか安全にやり直すことができるのでRequestが写しであるかどうか気にかける必要はないのを、Serverは、知るかもしれません。 例えば、Requestが写しであるか否かに関係なく、関係がなくて、現在の時間で現在の時間を求める要求に応じることができます。 それはもう興味がないなら、ResponseがClientで捨てられます。
Cheriton [page 13]
Cheriton[13ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
2.5.2. Checksum
2.5.2. チェックサム
Each VMTP packet contains a checksum to allow the receiver to detect corrupted packets independent of lower level checks. The checksum field is 32 bits, providing greater protection than the standard 16-bit IP checksum (in combination with an improved checksum algorithm). The large packets, high packet rates and general network characteristics expected in the future warrant a stronger checksum mechanism.
それぞれのVMTPパケットは下のレベルチェックの如何にかかわらず崩壊したパケットを検出するために受信機を許容するチェックサムを含んでいます。 チェックサム分野は32ビットです、標準の16ビットのIPチェックサム(改良されたチェックサムアルゴリズムと組み合わせた)より大きい保護を提供して。 将来予想された大きいパケット、高いパケットレート、および一般的なネットワークの特性は、より強いチェックサムメカニズムを保証します。
The checksum normally covers both the VMTP header and the segment data. Optionally (for real-time applications), the checksum may apply only to the packet header, as indicated by the HCO control bit being set in the header. The checksum field is placed at the end of the packet to allow it to be calculated as part of a software copy or as part of a hardware transmission or reception packet processing pipeline, as expected in the next generation of network interfaces. Note that the number of header and data octets is an integral multiple of 8 because VMTP requires that the segment data be padded to be a multiple of 64 bits. The checksum field is appended after the padding, if any. The actual algorithm is described in Section 3.2.
通常、チェックサムはVMTPヘッダーとセグメントデータの両方をカバーしています。 任意に(リアルタイムのアプリケーションのために)、チェックサムはパケットのヘッダーだけに適用されるかもしれません、ヘッダーに設定されるHCOコントロールビットによって示されるように。 チェックサム野原はそれがソフトウェアコピーの一部として、または、ハードウェアトランスミッションかレセプションパケット処理パイプラインの一部として計算されるのを許容するためにパケットの端に置かれます、ネットワーク・インターフェースの次世代で予想されるように。 VMTPが、セグメントデータが64ビットの倍数になるように水増しされるのを必要とするのでヘッダーとデータ八重奏の数が8の不可欠の倍数であることに注意してください。 詰め物の後にもしあればチェックサム野原を追加します。 実際のアルゴリズムはセクション3.2で説明されます。
A zero checksum field indicates that no checksum was transmitted with the packet. VMTP may be used without a checksum only when there is a host-to-host error detection mechanism and the VMTP security facility is not being used. For example, one could rely on the Ethernet CRC if communication is restricted to hosts on the same Ethernet and the network interfaces are considered sufficiently reliable.
チェックサムがさばくゼロは、チェックサムが全くパケットで伝えられなかったのを示します。 ホストからホストへの誤り検出メカニズムがあるときだけ、VMTPはチェックサムなしで使用されるかもしれません、そして、VMTPセキュリティ施設は使用されていません。 例えば、コミュニケーションが同じイーサネットでホストに制限されて、ネットワーク・インターフェースが十分信頼できると考えられるなら、人はイーサネットCRCを当てにするかもしれません。
2.5.3. Request and Response Acknowledgment
2.5.3. 要求と応答承認
VMTP assumes an unreliable datagram network and internetwork interface. To guarantee delivery of Requests and Response, VMTP uses positive acknowledgments, retransmissions and timeouts.
VMTPは頼り無いデータグラム・ネットワークとインターネットワークインタフェースを仮定します。 RequestsとResponseの配送を保証するために、VMTPは肯定応答、「再-トランスミッション」、およびタイムアウトを使用します。
A Request is normally acknowledged by receipt of a Response associated with the Request, i.e. with the same (Client, Transaction). With streamed message transactions, it may also be acknowledged by a subsequent Response that acknowledges previous Requests in addition to the transaction it explicitly identifies. A Response may be explicitly acknowledged by a NotifyVmtpServer operation requested of the manager for the Server. In the case of streaming, this is a cumulative acknowledgment, acknowledging all Responses with a lower transaction identifier as well.) In addition, with non-streamed communication, a subsequent Request from the same Client acknowledges Responses to all previous message transactions (at least in the sense that either the client received a Response or is no longer interested in Responses to
通常、Requestはすなわち、Request、同じくらいに関連しているResponse(クライアント、Transaction)の領収書で承認されます。 また、流されたメッセージトランザクションで、それはそれが明らかに特定するトランザクションに加えて前のRequestsを承認するその後のResponseによって承認されるかもしれません。 ResponseはServerのためにマネージャに要求されたNotifyVmtpServer操作で明らかに承認されるかもしれません。ストリーミングの場合では、これは累積している承認です、また、低いトランザクション識別子があるすべてのResponsesを承認して)。 非流されたコミュニケーションで、さらに、同じClientからのその後のRequestが前のすべてのメッセージトランザクションにResponsesを承認する、(クライアントがResponseを受けるか、またはもうResponsesに興味を持っていないという少なくとも意味
Cheriton [page 14]
Cheriton[14ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
those earlier message transactions). Finally, a client response timeout (at the server) acknowledges a Response at least in the sense that the server need not be prepared to retransmit the Response subsequently. Note that there is no end-to-end guarantee of the Response being received by the client at the application level.
それらの以前のメッセージトランザクション) 最終的にサーバが少なくとも意味でResponseでなければなりませんが、次にResponseを再送するように準備されて、タイムアウト(サーバにおける)が承諾するクライアント応答。 アプリケーションレベルでクライアントによって受け取られるResponseの終わりから終わりへの保証が全くないことに注意してください。
2.5.4. Retransmissions
2.5.4. Retransmissions
In general, a Request or Response is retransmitted periodically until acknowledged as above, up to some maximum number of retransmissions. VMTP uses parameters RequestRetries(Server) and ResponseRetries(Client) that indicate the number of retransmissions for the server and client respectively before giving up. We suggest the value 5 be used for both parameters based on our experience with VMTP and Internet packet loss. Smaller values (such as 3) could be used in low loss environments in which fast detection of failed hosts or communication channels is required. Larger values should be used in high loss environments where transport-level persistence is important.
一般に、RequestかResponseが同じくらい上で「再-トランスミッション」の何らかの最大数まで承認されるまで定期的に再送されます。 VMTPはあきらめる前にサーバとクライアントのためにそれぞれ「再-トランスミッション」の数を示すパラメタRequestRetries(サーバ)とResponseRetries(クライアント)を使用します。 私たちは、値5がVMTPの私たちの経験に基づくパラメタとインターネットパケット損失の両方に使用されることを提案します。 失敗したホストか通信チャネルの速い検出が必要である低損失環境で、より小さい値(3などの)を使用できました。 より大きい値は輸送レベル固執が重要である高い損失環境で使用されるべきです。
In a low loss environment, a retransmission only includes the MCB and not the segment data of the Request or Response, resulting in a single (short) packet on retransmission. The intended recipient of the retransmission can request selective retransmission of all or part of the segment data as necessary. The selective retransmission mechanism is described in Section 2.13.
低損失環境では、「再-トランスミッション」はセグメントデータではなく、RequestかResponseのMCBを含んでいるだけです、「再-トランスミッション」で単一(短い)のパケットをもたらして。 「再-トランスミッション」の意図している受取人は必要に応じてすべての選択している「再-トランスミッション」かセグメントデータの一部を要求できます。 選択している「再-トランスミッション」メカニズムはセクション2.13で説明されます。
If a Response is specified as idempotent, the Response is neither retransmitted nor stored for retransmission. Instead, the Client must retransmit the Request to effectively get the Response retransmitted. The server VMTP module responds to retransmissions of the Request by passing the Request on to the server again to have it regenerate the Response (by redoing the operation), rather than saving a copy of the Response. Only Request packets for the last transaction from this client are passed on in this fashion; older Request packets from this client are discarded as delayed duplicates. If a Response is not idempotent, the VMTP module must ensure it has a copy of the Response for retransmission either by making a copy of the Response (either physically or copy-on-write) or by preventing the Server from continuing until the Response is acknowledged.
Responseがベキ等元として指定されるなら、Responseは「再-トランスミッション」のために再送されないで、また保存されません。 代わりに、Clientは、事実上、Responseを再送させるためにRequestを再送しなければなりません。 サーバVMTPモジュールは、Responseのコピーを保存するよりResponse(操作をやり直すのによる)をむしろ、作り直させるために再びRequestをサーバに渡すことによって、Requestの「再-トランスミッション」に応じます。 このクライアントからの最後のトランザクションのためのRequestパケットだけがこんなやり方で伝えられます。 このクライアントからの、より古いRequestパケットは遅れた写しとして捨てられます。 または、VMTPモジュールが、Responseがベキ等元でないなら、それには「再-トランスミッション」のためのResponseのコピーがResponseのコピーを作ることによってあるのを確実にしなければならない、(どちらか、物理的である、コピーする、書く、)、または、Responseが続くまでServerが続くのを防ぐことによって、承認されています。
2.5.5. Timeouts
2.5.5. タイムアウト
There is one client timer for each Client with an outstanding transaction. Similarly, there is one server timer for each Client transaction that is "active" at the server, i.e. there is a transaction
各Clientあたり1個のクライアントタイマが傑出しているトランザクションと共にあります。 同様に、それぞれのサーバで「アクティブな」Clientトランザクションあたり1個のサーバタイマがあります、すなわち、トランザクションがあります。
Cheriton [page 15]
Cheriton[15ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
record for a Request from the Client.
Requestには、Clientから、記録してください。
When the client transmits a new Request (without streaming), the client timer is set to roughly the time expected for the Response to be returned. On timeout, the Request is retransmitted with the APG (Acknowledge Packet Group) bit set. The timeout is reset to the expected roundtrip time to the Server because an acknowledgment should be returned immediately unless a Response has been sent. The Request may also be retransmitted in response to receipt of a VMTP management operation indicating that selected portions of the Request message segment need to be retransmitted. With streaming, the timeout applies to the oldest outstanding message transaction in the run of outstanding message transactions. Without streaming, there is one message transaction in the run, reducing to the previous situation. After the first packet of a Response is received, the Client resets the timeout to be the time expected before the next packet in the Response packet group is received, assuming it is a multi-packet Response. If not, the timer is stopped. Finally, the client timer is used to timeout waiting for second and subsequent Responses to a multicast Request.
クライアントが新しいRequest(ストリーミングのない)を伝えるとき、およそResponseのために予想された時間にクライアントタイマが返されるように設定されます。 タイムアウトでは、APG(Packet Groupを承認する)ビットがセットした状態で、Requestは再送されます。 タイムアウトは、すぐResponseを送らない場合承認を返すべきであるので、予想された往復の時間までServerにリセットされます。 また、Requestはそれが再送されるべきRequestメッセージ・セグメントの必要性の部分を選択したのを示すVMTP管理操作の領収書に対応して再送されるかもしれません。 ストリーミングで、タイムアウトは傑出しているメッセージトランザクションの走行で最も古い傑出しているメッセージトランザクションに適用されます。 ストリーミングがなければ、前の状況に減少して、走行には1つのメッセージトランザクションがあります。 Responseの最初のパケットが受け取られていた後に、ClientはResponseパケットグループにおける次のパケットが受け取られている前に予想された時間になるようにタイムアウトをリセットします、それがマルチパケットResponseであると仮定して。 そうでなければ、タイマは止められます。 最終的に、クライアントタイマは2番目の、そして、その後のResponsesをマルチキャストRequestに待つタイムアウトに使用されます。
The client timer is set at different times to four different values:
クライアントタイマはいろいろな時間に4つの異価に設定されます:
TC1(Server) The expected time required to receive a Response from
the Server. Set on initial Request transmission plus
after its management module receives a NotifyVmtpClient
operation, acknowledging the Request.
期待のTC1(サーバ)時間がServerからResponseを受け取るのが必要です。管理モジュールがNotifyVmtpClient操作を受けた後に初期のRequestトランスミッションのときにそのうえ、セットしてください、Requestを承認して。
TC2(Server) The estimated round trip delay between the client and
the server. Set when retransmitting after receiving no
Response for TC1(Server) time and retransmitting the
Request with the APG bit set.
クライアントとサーバの間の旅行遅れの周りの概算のTC2(サーバ)TC1(サーバ)時間にResponseを全く受けないで、APGビットがセットした状態でRequestを再送した後に再送するときには、セットしてください。
TC3(Server) The estimated maximum expected interpacket time for
multi-packet Responses from the Server. Set when
waiting for subsequent Response packets within a packet
group before timing out.
TC3(サーバ)はServerからのマルチパケットResponsesのためにinterpacketに調節しますおよそ最大が、予想した。外で調節する前にパケットグループの中でその後のResponseパケットを待つときには、セットしてください。
TC4 The time to wait for additional Responses to a group
Request after the first Response is received. This is
specified by the user level.
グループRequestに追加Responsesを待つ最初のResponseが受け取られていた後に時間のTC4。 これはユーザレベルによって指定されます。
These values are selected as follows. TC1 can be set to TC2 plus a constant, reflecting the time within which most servers respond to most requests. For example, various measurements of VMTP usage at Stanford indicate that 90 percent of the servers respond in less than 200 milliseconds. Setting TC1 to TC2 + 200 means that most Requests receive a Response before timing out and also that overhead for retransmission
これらの値は以下の通り選択されます。 ほとんどのサーバがほとんどの要求に応じる時を反映して、TC1はTC2と定数に用意ができることができます。 例えば、スタンフォードのVMTP用法の様々な測定値は、サーバの90パーセントが200ミリセカンド未満で応じるのを示します。 TC2+200にTC1を設定するのは、ほとんどのRequestsが「再-トランスミッション」のために外で調節する前のResponseとそのオーバーヘッドも受け取ることを意味します。
Cheriton [page 16]
Cheriton[16ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
for long running transactions is insignificant. A sophisticated implementation may make the estimation of TC1 further specific to the Server.
長い間トランザクションを実行するのがわずかであるので。 洗練された実装で、TC1に関する見積りはServerにさらに特定になるかもしれません。
TC2 may be estimated by measuring the time from when a Probe request is sent to the Server to when a response is received. TC2 can also be measured as the time between the transmission of a Request with the APG bit set to receipt of a management operation acknowledging receipt of the Request.
TC2は、Probe要求がServerに送られる時から応答が受け取られている時までの時間を測定することによって、見積もられるかもしれません。 また、Requestの領収書を受け取ったことを知らせながら、時間としてRequestのトランスミッションの間で管理操作の領収書に設定されたAPGビットでTC2を測定できます。
When the Server is an entity group, TC1 and TC2 should be the largest of the values for the members of the group that are expected to respond. This information may be determined by probing the group on first use (and using the values for the last responses to arrive). Alternatively, one can resort to default values.
Serverが実体グループであるときに、値で応じると予想されるグループのメンバーにとって、TC1とTC2は最も大きいはずです。 この情報は、最初に、使用に関するグループを調べることによって、決定するかもしれません(到着する最後の応答に値を使用して)。 あるいはまた、人はデフォルト値に訴えることができます。
TC3 is set initially to 10 times the transmission time for the maximum transmission unit (MTU) to be used for the Response. A sophisticated implementation may record TC3 per Server and refine the estimate based on measurements of actual interpacket gaps. However, a tighter estimate of TC3 only improves the reaction time when a packet is lost in a packet group, at some cost in unnecessary retransmissions when the estimate becomes overly tight.
TC3は初めは、マキシマム・トランスミッション・ユニット(MTU)がResponseに使用されるトランスミッション時間の10回に用意ができています。 洗練された実装は、1ServerあたりのTC3を記録して、実際のinterpacketギャップの測定値に基づく見積りを洗練するかもしれません。 しかしながら、見積りがひどくきつくなると、TC3の、よりきつい見積りはパケットが不要な「再-トランスミッション」の何らかの費用でパケットグループで失われている反応時間を改良するだけです。
The server timer, one per active Client, takes on the following values:
サーバタイマ(アクティブなClientあたり1つ)は以下の値を呈します:
TS1(Client) The estimated maximum expected interpacket time. Set
when waiting for subsequent Request packets within a
packet group before timing out.
概算のTS1(クライアント)最大はinterpacket時間を予想しました。 外で調節する前にパケットグループの中でその後のRequestパケットを待つときには、セットしてください。
TS2(Client) The time to wait to hear from a client before
terminating the server processing of a Request. This
limits the time spent processing orphan calls, as well
as limiting how out of date the server's record of the
Client state can be. In particular, TS2 should be
significantly less than the minimum time within which it
is reasonable to reuse a transaction identifier.
TS2、(クライアント)Requestのサーバ処理を終える前にクライアントから連絡をいただくのを待つ時間。 これは親のない呼び出しを処理しながら費やされた時間を制限します、サーバのClient状態に関する記録がどれくらい時代遅れであるかの状態で制限するとしてよくそうであることができるように。 特に、TS2はトランザクション識別子を再利用するのが妥当である最小の時よりかなり少ないはずです。
TS3(Client) Estimated roundtrip time to the Client,
TS3(クライアント)は往復の時間をClientに見積もっていました。
TS4(Client) The time to wait after sending a Response (or last
hearing from a client) before discarding the state
associated with the Request which allows it to filter
duplicate Request packets and regenerate the Response.
TS4(クライアント)はフィルターにかけるそれを許容するRequestに関連している状態を捨てる前にResponse(最後にクライアントから連絡をいただいて)を送った後の待ちへの時にRequestパケットをコピーして、Responseを作り直します。
TS5(Client) The time to wait for an acknowledgment after sending a
Response before retransmitting the Response, or giving
Response、または付与を再送する前にResponseを送った後の承認のための待ちへの時間のTS5(クライアント)
Cheriton [page 17]
Cheriton[17ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
up (after some number of retransmissions).
上がります(「再-トランスミッション」の何らかの数の後の)。
TS1 is set the same as TC3.
TS1はTC3として同じように用意ができています。
The suggested value for TS2 is TC1 + 3*TC2 for this server, giving the Client time to timeout waiting for a Response and retransmit 3 Request packets, asking for acknowledgments.
TS2のための提案された値はこのサーバのためのTC1+3*TC2です、Responseを待つタイムアウトと3つのRequestパケットを再送して、承認を求めることへのClient時間を与えて。
TS3 is estimated the same as TC1 except that refinements to the estimate use measurements of the Response-to-acknowledgment times.
見積りへの気品がResponseから承認への時間の測定を使用するのを除いて、TS3はTC1として同じように見積もられています。
In the general case, TS4 is set large enough so that a Client issuing a series of closely-spaced Requests to the same Server reuses the same state record at the Server end and thus does not incur the overhead of recreating this state. (The Server can recreate the state for a Client by performing a Probe on the Client to get the needed information.) It should also be set low enough so that the transaction identifier cannot wrap around and so that the Server does not run out of CSR's. We suggest a value in the range of 500 milliseconds. However, if the Server accepts non-idempotent Requests from this Client without doing a Probe on the Client, the TS4 value for this CSR is set to at least 4 times the maximum packet lifetime.
一般的な場合では、TS4が十分大きいセットであるので、一連の密接に区切られたRequestsを同じServerに発行するClientはServerエンドのときに同じ州の記録を再利用して、その結果、この状態を休養させるオーバーヘッドを被りません。 (ClientにProbeを実行するのによるClientが必要な情報を得るように、Serverは状態を休養させることができます。) また、それが十分低く設定されるべきであるので、トランザクション識別子は巻きつけられることができないで、ServerはCSRのものを使い果たしません。 私たちは500ミリセカンドの範囲で値を勧めます。 しかしながら、ServerがこのClientからClientでProbeをしないで非ベキ等元Requestsを受け入れるなら、このCSRのためのTS4値は最大のパケット生存期間の少なくとも4倍に設定されます。
TS5 is TS3 plus the expected time for transmission and reception of the Response. We suggest that the latter be calculated as 3 times the transmission time for the Response data, allowing time for reception, processing and transmission of an acknowledgment at the Client end. A sophisticated implementation may refine this estimate further over time by timing acknowledgments to Responses.
TS5はTS3とResponseのトランスミッションとレセプションのための予想された時間です。 私たちは、Clientでの承認のResponseデータ、レセプションのための時間を許容する、処理、および送信のためのトランスミッション時間の3回が終わっている間後者が計算されることを提案します。 洗練された実装は時間がたつにつれて、Responsesへのタイミング承認でこの見積りをさらに洗練するかもしれません。
2.5.6. Rate Control
2.5.6. 速度制御
VMTP is designed to deal with the present and future problem of packet overruns. We expect overruns to be the major cause of dropped packets in the future. A client is expected to estimate and adjust the interpacket gap times so as to not overrun a server or intermediate nodes. The selective retransmission mechanism allows the server to indicate that it is being overrun (or some intermediate point is being overrun). For example, if the server requests retransmission of every Kth block, the client should assume overrun is taking place and increase the interpacket gap times. The client passes the server an indication of the interpacket gap desired for a response. The client may have to increase the interval because packets are being dropped by an intermediate gateway or bridge, even though it can handle a higher rate. A conservative policy is to increase the interpacket gap whenever a packet is lost as part of a multi-packet packet group.
VMTPは、パケット超過の現在の、そして、将来の問題に対処するように設計されています。 私たちは、将来超過が下げられたパケットの主な原因であると予想します。 クライアントは、サーバか中間的ノードを増刷しないようにinterpacketギャップ回数を見積もって、調整すると予想されます。 選択している「再-トランスミッション」メカニズムで、サーバは、それがオーバランしているのを示すことができます(何らかの中間的ポイントが走っています)。 例えば、サーバがあらゆるKthブロックの「再-トランスミッション」を要求するなら、クライアントは、超過が行われることであると仮定して、interpacketギャップ回数を増強するべきです。 クライアントは応答のために望まれていたinterpacketギャップのしるしをサーバに通過します。 パケットが中間ゲートウェイかブリッジによって下げられているので、クライアントは間隔を増強しなければならないかもしれません、より高いレートを扱うことができますが。 保守政策はパケットがマルチパケットパケットグループの一部として失われているときはいつも、interpacketギャップを増強することです。
Cheriton [page 18]
Cheriton[18ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
The provision of selective retransmission allows the rate of the client and the server to "push up" against the maximum rate (and thus lose packets) without significant penalty. That is, every time that packet transmission exceeds the rate of the channel or receiver, the recovery cost to retransmit the dropped packets is generally far less than retransmitting from the first dropped packet.
選択している「再-トランスミッション」の設備は最高率(その結果、パケットを失う)に対して重要な刑罰なしで「押し上げる」クライアントとサーバのレートを許容します。 一般に、すなわち、そのパケット伝送がチャンネルか受信機のレートを超えているときはいつも、下げられたパケットを再送する回復費用は最初の下げられたパケットから再送するよりはるかに少ないです。
The interpacket gap is expressed in 1/32nd's of the MTU packet transmission time. The minimum interpacket gap is 0 and the maximum gap that can be described in the protocol is 8 packet times. This places a limit on the slowest receivers that can be efficiently used on a network, at least those handling multi-packet Requests and Responses. This scheme also limits the granularity of adjustment. However, the granularity is relative to the speed of the network, as opposed to an absolute time. For entities on different networks of significantly different speed, we assume the interconnecting gateways can buffer packets to compensate<2>. With different network speeds and intermediary nodes subject to packet loss, a node must adjust the interpacket gap based on packet loss. The interpacket gap parameter may be of limited use.
interpacketギャップはMTUパケット伝送時間について32 1/第年代で言い表されます。 最小のinterpacketギャップは0です、そして、プロトコルで説明できる最大のギャップは8パケット回です。 これはネットワークで効率的に使用できる中で最も遅い受信機、少なくともそれらの取り扱いマルチパケットRequests、およびResponsesに限度を設けます。 また、この体系は調整の粒状を制限します。 しかしながら、粒状はネットワークの速度に比例して絶対時間と対照的にいます。 かなり異なった速度の異なったネットワークの実体のために、私たちは、内部連絡ゲートウェイが<2>を代償するパケットをバッファリングできると思います。 パケット損失を条件とした異なったネットワーク速度と仲介者ノードで、ノードはパケット損失に基づくinterpacketギャップを調整しなければなりません。 interpacketギャップパラメタは限られて役に立つかもしれません。
2.6. Security
2.6. セキュリティ
VMTP provides an (optional) secure mode that protects against the usual security threats of peeking, impostoring, message tampering and replays. Secure VMTP must be used to guarantee any of the transport-level reliability properties unless it is guaranteed that there are no intruders or agents that can modify packets and update the packet checksums. That is, non-secure VMTP provides no guarantees in the presence of an intelligent intruder.
VMTPは覗き見する普通の軍事的脅威から守る(任意)の安全なモード、impostoring、メッセージ改ざん、および再生を提供します。 パケットを変更して、パケットチェックサムをアップデートできるどんな侵入者もエージェントもいないのは保証されない場合、輸送レベル信頼性の特性のどれかを保証するのに安全なVMTPを使用しなければなりません。すなわち、安全な非VMTPは知的な侵入者の面前で保証を全く提供しません。
The design closely follows that described by Birrell [1]. Authenticated information about a remote entity, including an encryption/decryption key, is obtained and maintained using a VMTP management operation, the authenticated Probe operation, which is executed as a non-secure VMTP message transaction. If a server receives a secure Request for which the server has no entity state, it sends a Probe request to the VMTP
デザインは密接にビレル[1]によって説明されたそれに続きます。 暗号化/復号化キーを含むリモート実体の認証された情報は、VMTP管理操作、非安全なVMTPメッセージトランザクションとして実行される認証されたProbe操作を使用することで得られて、保守されます。 サーバがサーバには実体状態が全くない安全なRequestを受けるなら、それはProbe要求をVMTPに送ります。
_______________
_______________
<2> Gateways must also employ techniques to preserve or intelligently modify (if appropriate) the interpacket gaps. In particular, they must be sure not to arbitrarily remove interpacket gaps as a result of their forwarding of packets.
<2>ゲートウェイは、また、保持するテクニックを使わなければならないか、または知的にinterpacketギャップを変更しなければなりません(適切であるなら)。 それらは、彼らのパケットの推進の結果、任意にinterpacketギャップを取り除かないように特に、確かでなければなりません。
Cheriton [page 19]
Cheriton[19ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
management module of the client, "challenging" it to provide an authenticator that both authenticates the client as being associated with a particular principal as well as providing a key for encryption/decryption. The principal can include a real and effective principal, as used in UNIX <3>. Namely, the real principal is the principal on whose behalf the Request is being performed whereas the effective principal is the principal of the module invoking the request or remote procedure call.
クライアントの管理モジュール、それを固有識別文字に提供するようにそれに「挑戦」であることが特定の元本に関連していて、暗号化/復号化にキーを提供しているとともにクライアントを認証します。 主体はUNIX<3>で使用されるように本当の、そして、有効な元本を含むことができます。 すなわち、本当の主体はRequestが利益に実行されている主体ですが、有効な主体は要求か遠隔手続き呼び出しを呼び出すモジュールの主体です。
Peeking is prevented by encrypting every Request and Response packet with a working Key that is shared between Client and Server. Impostoring and replays are detected by comparing the Transaction identifier with that stored in the corresponding entity state record (which is created and updated by VMTP as needed). Message tampering is detected by encryption of the packet including the Checksum field. An intruder cannot update the checksum after modifying the packet without knowing the Key. The cost of fully encrypting a packet is close to the cost of generating a cryptographic checksum (and of course, encryption is needed in the general case), so there is no explicit provision for cryptographic checksum without packet encryption.
覗き見はClientとServer. Impostoringの間で共有される働くKeyと共にあらゆるRequestとResponseパケットを暗号化することによって、防がれます、そして、再生は対応する実体州の記録(必要に応じてVMTPによって作成されて、アップデートされる)に保存されたそれとTransaction識別子を比べることによって、検出されます。 メッセージ改ざんはChecksum分野を含むパケットの暗号化で検出されます。 Keyを知らないでパケットを変更した後に、侵入者はチェックサムをアップデートできません。 暗号のチェックサムを生成する費用の近くにパケットを完全に暗号化する費用があるので(もちろん、暗号化が一般的な場合で必要です)、暗号のチェックサムへのどんな明白な支給もパケット暗号化なしでありません。
A Client determines the Principal of the Server and acquires an authenticator for this Server and Principal using a higher level protocol. The Server cannot decrypt the authenticator or the Request packets unless it is in fact the Principal expected by the Client.
Clientは、より高い平らなプロトコルを使用することでServerのプリンシパルを決定して、このServerとプリンシパルのために固有識別文字を習得します。 Serverは事実上、Clientによって予想されて、それがプリンシパルでないなら固有識別文字かRequestパケットを解読することができません。
An encrypted VMTP packet is flagged by the EPG bit in the VMTP packet header. Thus, encrypted packets are easily detected and demultiplexed from unencrypted packets. An encrypted VMTP packet is entirely encrypted except for the Client, Version, Domain, Length and Packet Flags fields at the beginning of the packet. Client identifiers can be assigned, changed and used to have no real meaning to an intruder or to only communicate public information (such as the host Internet address). They are otherwise just a random means of identification and demultiplexing and do not therefore divulge any sensitive information. Further secure measures must be taken at the network or data link levels if this information or traffic behavior is considered sensitive.
暗号化されたVMTPパケットはVMTPパケットのヘッダーのEPGビットによって旗を揚げられます。 したがって、暗号化されたパケットは、容易に検出されて、非暗号化されたパケットから反多重送信されます。 Client、バージョン、Domain、Length、およびPacket Flags分野を除いて、暗号化されたVMTPパケットはパケットの始めに完全に暗号化されます。 真の意義を全く侵入者に持っていないか、または公開情報(ホストインターネット・アドレスなどの)を伝えるだけであるためにクライアント識別子を割り当てて、変えられて、使用できます。 彼らは、そうでなければ、ただ識別と逆多重化の無作為の手段であり、したがって、少しの機密情報も明かしません。 この情報か交通現象が敏感であると考えられるなら、さらなる安全な対策はネットワークかデータリンク・レベルで実施されなければなりません。
VMTP provides multiple authentication domains as well as an encryption qualifier to accommodate different encryption algorithms and their
そして、VMTPが複数の認証にドメインを提供して、異なった暗号化アルゴリズムを対応する暗号化資格を与える人に提供する、それら
_______________
_______________
<3> Principal group membership must be obtained, if needed, by a higher level protocol.
より高い平らなプロトコルが必要であるなら、<3の>の主要なグループ会員資格を得なければなりません。
Cheriton [page 20]
Cheriton[20ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
corresponding security/performance trade-offs. (See Appendix V.) A separate key distribution and authentication protocol is required to handle generation and distribution of authenticators and keys. This protocol can be implemented on top of VMTP and can closely follow the Birrell design as well.
対応するセキュリティ/性能トレードオフ。 (付録V.を見ます) 別々の主要な分配と認証プロトコルが、固有識別文字とキーの生成と分配を扱うのに必要です。 このプロトコルは、VMTPの上で実装することができて、密接にまた、ビレルデザインに従うことができます。
Security is optional in the sense that messages may be secure or non-secure, even between consecutive message transactions from the same client. It is also optional in that VMTP clients and servers are not required to implement secure VMTP (although they are required to respond intelligently to attempts to use secure VMTP). At worst, a Client may fail to communicate with a Server if the Server insists on secure communication and the Client does not implement security or vice versa. However, a failure to communicate in this case is necessary from a security standpoint.
セキュリティはメッセージが安全であるか、または非安全であるかもしれないという意味で任意です、同じクライアントからの連続したメッセージトランザクションの間でさえ。 また、VMTPクライアントとサーバは安全なVMTPを実装するのに必要でないので(彼らが知的に安全なVMTPを使用する試みに応じなければなりませんが)、それも任意です。 最悪の場合は、Serverが安全なコミュニケーションを主張するなら、ClientはServerとコミュニケートしないかもしれません、そして、Clientはセキュリティを実装しないか、逆もまた同様です。 しかしながら、この場合交信しないことがセキュリティ見地から必要です。
2.7. Multicast
2.7. マルチキャスト
The Server entity identifier in a message transaction can identify an entity group, in which case the Request is multicast to every Entity in this group (on a best-efforts basis). The Request is retransmitted until at least one Response is received (or an error timeout occurs) unless it is a datagram Request. The Client can receive multiple Responses to the Request.
メッセージトランザクションにおけるServerエンティティ識別名は実体グループを特定できます、その場合、Requestがこのグループ(最善努力原則の)におけるあらゆるEntityへのマルチキャストです。 少なくとも1Responseが受け取られているまで(誤りタイムアウトは起こります)、RequestはそれがデータグラムRequestでないなら再送されます。 Clientは複数のResponsesをRequestに受けることができます。
The VMTP service interface does not directly provide reliable multicast because it is expensive to provide, rarely needed by applications, and can be implemented by applications using the multiple Response feature. However, the protocol itself is adequate for reliable multicast using positive acknowledgments. In particular, a sophisticated Client implementation could maintain a list of members for each entity group of interest and retransmit the Request until acknowledged by all members. No modifications are required to the Server implementations.
複数のResponseの特徴を使用しながら、VMTPサービスインタフェースは、提供するのが高価であるので直接信頼できるマルチキャストを提供しないで、アプリケーションでめったに必要でなく、アプリケーションで実装することができます。 しかしながら、信頼できるマルチキャストに、プロトコル自体は肯定応答を使用するのにおいて適切です。 すべてのメンバーによって承認されるまで、洗練されたClient実装は、特に、興味深いそれぞれの実体グループのための会員名簿を維持して、Requestを再送するかもしれません。 変更は全くServer実装に必要ではありません。
VMTP supports a simple form of subgroup addressing. If the CRE bit is set in a Request, the Request is delivered to the subgroup of entities in the Server group that are co-resident with one or more entities in the group (or individual entity) identified by the CoresidentEntity field of the Request. This is commonly used to send to the manager entity for a particular entity, where Server specifies the group of such managers. Co-resident means "using the same VMTP module", and logically on the same network host. In particular, a Probe request can be sent to the particular VMTP management module for an entity by specifying the VMTP management group as the Server and the entity in question as the CoResidentEntity.
VMTPは単純形のサブグループアドレシングをサポートします。 CREビットがRequestに設定されるなら、Requestは1つ以上の実体でRequestのCoresidentEntity分野によって特定されたグループ(または、個々の実体)でコレジデントであるServerグループにおける実体のサブグループに提供されます。 これは特定の実体のためにマネージャ実体に発信するのに一般的に使用されます、Serverがそのようなマネージャのグループを指定するところで。 コレジデントは、同じネットワークホストで論理的に「同じVMTPモジュールを使用する」と言っています。 特に、実体のために特定のVMTP管理モジュールにProbe要求をCoResidentEntityとして問題のServerと実体としてVMTP経営者集団を指定することによって、送ることができます。
Cheriton [page 21]
Cheriton[21ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
As an experimental aspect of the protocol, VMTP supports the Server sending a group Response which is sent to the Client as well as members of the destination group of Servers to which the original Request was sent. The MDG bit indicates whether the Client is a member of this group, allowing the Server module to determine whether separately addressed packet groups are required to send the Response to both the Client and the Server group. Normally, a Server accepts a group Response only if it has received the Request and not yet responded to the Client. Also, the Server must explicitly indicate it wants to accept group Responses. Logically, this facility is analogous to responding to a mail message sent to a distribution list by sending a copy of the Response to the distribution list.
プロトコルの実験局面として、VMTPは、Server発信がオリジナルのRequestが送られたServersの目的地グループのメンバーと同様にClientに送られるグループResponseであるとサポートします。 MDGビットは、Clientがこのグループのメンバーであるかどうかを示します、Serverモジュールが、別々に扱われたパケットグループがClientとServerグループの両方にResponseを送るのに必要であるかどうか決定するのを許容して。 通常、Requestを受けて、まだClientに応じていない場合にだけ、ServerはグループResponseを受け入れます。 また、Serverは、グループResponsesを受け入れたがっているのを明らかに示さなければなりません。 この施設はResponseのコピーを発送先リストに送ることによって発送先リストに送られたメール・メッセージに応じるのに論理的に、類似しています。
2.8. Real-time Communication
2.8. 瞬時通信
VMTP provides three forms of support for real-time communication, in addition to its standard facilities, which make it applicable to a wide range of real-time applications. First, a priority is transmitted in each Request and Response which governs the priority of its handling. The priority levels are intended to correspond roughly to:
VMTPはリアルタイムのコミュニケーションのための3つの形式のサポートを提供します、標準の施設に加えて。施設はそれをさまざまなリアルタイムのアプリケーションに適切にします。 まず最初に、優先は取り扱いの優先権を決定する各RequestとResponseで伝えられます。 以下のことのために優先順位がおよそ相当することを意図します。
- urgent/emergency.
- 緊急の/非常時。
- important
- 重要
- normal
- 標準
- background.
- バックグラウンド。
with additional gradations for each level. The interpretation and implementation of these priority levels is otherwise host-specific, e.g. the assignment to host processing priorities.
各レベルのための追加段階で。 そうでなければ、これらの優先順位の解釈と実装はホスト特有であり、例えば、ホスト・プロセッシングへの課題はプライオリティです。
Second, datagram Requests allow the Client to send a datagram to another entity or entity group using the VMTP naming, transmission and delivery mechanism, but without blocking, retransmissions or acknowledgment. (The client can still request acknowledgment using the APG bit although the Server does not expect missing portions of a multi-packet datagram Request to be retransmitted even if some are not received.) A datagram Request in non-streamed mode supersedes all previous Requests from the same Client. A datagram Request in stream mode is queued (if necessary) after previous datagram Requests on the same stream. (See Section 2.11.)
2番目に、データグラムRequestsは、ClientがVMTP命名、トランスミッション、および排紙機構を使用することで別の実体か実体グループにデータグラムを送りますが、ブロッキングも、「再-トランスミッション」もまたは承認なしで送るのを許容します。 (クライアントはServerが、マルチパケットデータグラムの一部を逃して、或るものがあっても再送されるべきRequestが受信しなかったと予想しませんが、APGビットを使用することでまだ承認を要求できます。) 非流されたモードによるデータグラムRequestは同じClientから前のすべてのRequestsに取って代わります。 (必要なら、)同じくらいの前のデータグラムRequestsが流れた後にストリームモードによるデータグラムRequestは列に並ばせられます。 (セクション2.11を見てください。)
Finally, VMTP provides several control bit flags to modify the handling of Requests and Responses for real-time requirements. First, the
最終的に、VMTPは、リアルタイムの要件のためにRequestsとResponsesの取り扱いを変更するために数個の制御ビット旗を提供します。 最初に
Cheriton [page 22]
Cheriton[22ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
conditional message delivery (CMD) flag causes a Request to be discarded if the recipient is not waiting for it when it arrives, similarly for the Response. This option allows a client to send a Request that is contingent on the server being able to process it immediately. The header checksum only (HCO) flag indicates that the checksum has been calculated only on the VMTP header and not on the data segment. Applications such as voice and video can avoid the overhead of calculating the checksum on data whose utility is insensitive to typical bit errors without losing protection on the header information. Finally, the No Retransmission (NRT) flag indicates that the recipient of a message should not ask for retransmission if part of the message is missing but rather either use what was received or discard it.
Responseのために同様に到着するとき、(CMD)が旗を揚げさせる条件付きのメッセージ配送で、受取人がそれを待っていないなら、Requestを捨てます。 このオプションで、クライアントはサーバ次第であるRequestがすぐにそれを処理できるのをさせることができます。 (HCO)だけ、が旗を揚げさせるヘッダーチェックサムは、データ・セグメントで計算されたのではなく、VMTPヘッダーだけの上にチェックサムについて計算してあるのを示します。 声やビデオなどのアプリケーションはユーティリティがヘッダー情報で損をしている保護なしで典型的な噛み付いている誤りに神経が鈍いデータでチェックサムについて計算するオーバーヘッドを避けることができます。 最終的に、いいえRetransmission(NRT)旗は、メッセージの受取人が「再-トランスミッション」のために何が受け取られたかをメッセージの部分がなくなっているか、しかし、むしろどちらの使用にも尋ねるべきではありませんし、またそれを捨てるべきでないのを示します。
None of these facilities introduce new protocol states. In fact, the total processing overhead in the normal case is a bit flag test for CMD, HCO or NRT plus assignment of priority on packet transmission and reception. (In fact, CMD and NRT are not tested in the normal case.) The additional code complexity is minimal. We feel that the overhead for providing these real-time facilities is minimal and that these facilities are both important and adequate for a wide class of real-time applications.
これらの施設のいずれも新しいプロトコル州を導入しません。 事実上、正常な場合におけるオーバーヘッドを処理する合計はパケット伝送とレセプションで優先権のCMDかHCOかNRTと課題のためのテストに少し旗を揚げさせることです。 (事実上、CMDとNRTは正常な場合でテストされません。) 追加コードの複雑さは最小限です。 私たちはこれらの施設がこれらのリアルタイムの施設を提供するためのオーバーヘッドが最小限であり、かつ重要であって、かつ広いクラスのリアルタイムのアプリケーションに、適切であると感じます。
Several of the normal facilities of VMTP appear useful for real-time applications. First, multicast is useful for distributed, replicated (fault-tolerant) real-time applications, allowing efficient state query and update for (for example) sensors and control state. Second, the DGM or idempotent flag for Responses has some real-time benefits, namely: a Request is redone to get the latest values when the Response is lost, rather than just returning the old values. The desirability of this behavior is illustrated by considering a request for the current time of day. An idempotent handling of this request gives better accuracy in returning the current time in the case that a retransmission is necessary. Finally, the request-response semantics (in the absence of streaming) of each new Request from a Client terminating the previous message transactions from that Client, if any, provides the "most recent is most important" handling of processing that most real-time applications require.
VMTPのいくつかの正常な施設がリアルタイムのアプリケーションの役に立つように見えます。 まず最初に、マルチキャストは分配されて、模写された(フォールトトレラント)リアルタイムのアプリケーションの役に立ちます、(例えば、)センサとコントロール状態に効率的な州の質問とアップデートを許して。 2番目に、ResponsesのためのDGMかベキ等元旗にはいくつかのリアルタイムの利益がある、すなわち: Requestは、Responseがただ古い値を返すよりむしろ無くなるとき、最新の値を得るためにやり直されます。 この振舞いの願わしさは、現在の時刻を求める要求を考えることによって、例証されます。 この要求のベキ等元取り扱いは「再-トランスミッション」が必要であることで、現在の時間を返す際に、より良い精度を与えます。 大部分は重要です。最終的に、もしあればそのClientからの前のメッセージトランザクションを終えるClientからのそれぞれの新しいRequestの要求応答意味論(ストリーミングが不在のとき)が提供される、「最新である、」 最もリアルタイムのアプリケーションが必要とする処理の取り扱い。
In general, a key design goal of VMTP was provide an efficient general-purpose transport protocol with the features required for real-time communication. Further experience is required to determine whether this goal has been achieved.
一般に、VMTPの主要なデザイン目標はリアルタイムのコミュニケーションに必要である特徴に効率的な汎用トランスポート・プロトコルを提供することでした。 さらなる経験が、この目標が達成されたかどうか決定するのに必要です。
Cheriton [page 23]
Cheriton[23ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
2.9. Forwarded Message Transactions
2.9. 進められたメッセージトランザクション
A Server may invoke another Server to handle a Request. It is fairly common for the invocation of the second Server to be the last action performed by the first Server as part of handling the Request. For example, the original Server may function primarily to select a process to handle the Request. Also, the Server may simply check the authorization on the Request. Describing this situation in the context of RPC, a nested remote procedure call may be the last action in the remote procedure and the return parameters are exactly those of the nested call. (This situation is analogous to tail recursion.)
Serverは、Requestを扱うために別のServerを呼び出すかもしれません。 第2Serverの実施がRequestを扱う一部として最初のServerによって実行された最後の動作であることはかなり一般的です。 例えば、オリジナルのServerは、主としてRequestを扱うためにプロセスを選択するために機能するかもしれません。 また、ServerはRequestで単に承認をチェックするかもしれません。 RPCの文脈のこの状況について説明して、入れ子にされた遠隔手続き呼び出しはリモート手順において最後の動作であるかもしれません、そして、リターンパラメタはまさに入れ子にされた呼び出しのものです。 (この状況は再帰に尾を付けるために類似しています。)
As an optimization to support this case, VMTP provides a Forward operation that allows the server to send the nested Request to the other server and have this other server respond directly to the Client.
本件を支える最適化として、VMTPはサーバに入れ子にされたRequestをもう片方のサーバに送って、この他のサーバを直接Clientに反応させるForward操作を、提供します。
If the message transaction being forwarded was not multicast, not secure or the two Servers are the same principal and the ForwardCount of the Request is less than the maximum forward count of 15, the Forward operation is implemented by the Server sending a Request onto the next Server with the forwarded Request identified by the same Client and Transaction as the original Request and a ForwardCount one greater than the Request received from the Client. In this case, the new Server responds directly to the Client. A forwarded Request is illustrated in the following figure.
Requestの同じ主体とForwardCountが進めているのは、マルチキャストでした、安全でないということであるメッセージトランザクションか2Serversがそうであるなら15の最大の前進のカウント以下である、Forward操作が進められたRequestがオリジナルのRequestとして同じClientとTransactionによって特定されて、ForwardCount1がRequestがClientから受信したよりすばらしい状態で次のServerにRequestを送るServerによって実装されます。 この場合、新しいServerは直接Clientに応じます。 進められたRequestは以下の図で例証されます。
+---------+ Request +----------+
| Client +---------------->| Server 1 |
+---------+ +----------+
^ |
| | forwarded Request
| V
| Response +----------+
+----------------------| Server 2 |
+----------+
+---------+ 要求+----------+ | クライアント+---------------->| サーバ1| +---------+ +----------+ ^ | | | 進められたRequest| V| 応答+----------+ +----------------------| サーバ2| +----------+
If the message transaction does not meet the above requirements, the Server's VMTP module issues a nested call and simply maps the returned Response to a Response to original Request without further Server-level processing. In this case, the only optimization over a user-level nested call is one fewer VMTP service operation; the VMTP module handles the return to the invoking call directly. The Server may also use this form of forwarding when the Request is part of a stream of message transactions. Otherwise, it must wait until the forwarded message transaction completes before proceeding with the subsequent message transactions in the stream.
メッセージトランザクションが上記の必要条件を満たさないなら、ServerのVMTPモジュールは、入れ子にされた呼び出しを発行して、さらなるServer-レベル処理なしでオリジナルのRequestへのResponseに返されたResponseを単に写像します。 この場合、ユーザレベルの入れ子にされた呼び出しの上の唯一の最適化がVMTPサービスもう1つの操作減です。 VMTPモジュールは直接呼び出し呼び出しへのリターンを扱います。 また、Requestがメッセージトランザクションのストリームの一部であるときに、Serverはこの形式の推進を使用するかもしれません。 さもなければ、進められたメッセージトランザクションが進行の前に中にその後のメッセージトランザクションがあるストリームを完成するまで、それは待たなければなりません。
Cheriton [page 24]
Cheriton[24ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
Implementation of the user-level Forward operation is optional, depending on whether the server modules require this facility. Handling an incoming forwarded Request is a minor modification of handling a normal incoming Request. In particular, it is only necessary to examine the ForwardCount field when the Transaction of the Request matches that of the last message transaction received from the Client. Thus, the additional complexity in the VMTP module for the required forwarding support is minimal; the complexity is concentrated in providing a highly optimized user-level Forward primitive, and that is optional.
サーバモジュールがこの施設を必要とするかどうかによって、ユーザレベルForward操作の実装は任意です。 入って来る進められたRequestを扱うのは、正常な入って来るRequestを扱う小さい方の変更です。 RequestのTransactionがClientから受け取られた最後のメッセージトランザクションのものに合っているとき、単にForwardCount分野を調べるのが特に、必要です。 したがって、必要な推進サポートのためのVMTPモジュールにおける追加複雑さは最小限です。 複雑さは原始的に非常に最適化されたユーザレベルForwardを提供する際に集結されます、そして、それは任意です。
2.10. VMTP Management
2.10. VMTP管理
VMTP management includes operations for creating, deleting, modifying and querying VMTP entities and entity groups. VMTP management is logically implemented by a VMTP management server module that is invoked using a message transaction addressed to the Server, VMTP_MANAGER_GROUP, a well-known group entity identifier, in conjunction with Coresident Entity mechanism introduced in Section 2.7. A particular Request may address the local module, the module managing a particular entity, the set of modules managing those entities contained in a specific group or all management modules, as appropriate.
VMTP経営者側はVMTP実体と実体グループを作成して、削除して、変更して、質問するための操作を含んでいます。 VMTP管理はServerに扱われたメッセージトランザクションを使用することで呼び出されるVMTP管理サーバーモジュールで論理的に実装されます、VMTP_マネージャ_GROUP、よく知られるグループエンティティ識別名、セクション2.7で紹介されたCoresident Entityメカニズムに関連して。 特定のRequestはローカルのモジュールを扱うかもしれません、モジュールが特定の実体を管理して、特定のグループに含まれたそれらの実体かすべての管理モジュールを管理するモジュールのセット、適宜。
The VMTP management procedures are specified in Appendix III.
VMTP管理手順はAppendix IIIで指定されます。
2.11. Streamed Message Transactions
2.11. 流されたメッセージトランザクション
Streamed message transactions refer to two or more message transactions initiated by a Client before it receives the response to the first message transaction, with each transaction being processed and responded to in order but asynchronous relative to the initiation of the transactions. A Client streams messages transactions, and thereby has multiple message transactions outstanding, by sending them as part of a single run of message transactions. A run of message transactions is a sequence of message transactions with the same Client and Server and consecutive Transaction identifiers, with all but the first and last Requests and Responses flagged with the NSR (Not Start Run) and NER (Not End Run) control bits. (Conversely, the first Request and Response does not have the NSR set and the last Request and Response does not have the NER bit set.) The message transactions in a run use
流されたメッセージトランザクションは最初のメッセージトランザクションへの応答を受ける前にClientによって開始された2つ以上のメッセージトランザクションについて言及します、各トランザクションがトランザクションの開始に比例して整然としますが、非同期に処理されて、反応していて。 Clientはメッセージトランザクションを流して、その結果、メッセージトランザクションのただ一つの走行の一部としてそれらを送るのによる未払いの複数のメッセージトランザクションを持っています。 メッセージトランザクションの走行は同じClient、Server、および連続したTransaction識別子、1番目を除いたすべて、最後のRequests、およびResponsesがNSR(Start Runでない)とNER(End Runでない)コントロールビットで旗を揚げられているメッセージトランザクションの系列です。 (逆に、最初のRequestとResponseにはNSRセットと最後のRequestがなくて、またResponseはNERビットを設定させません。) 走行使用でのメッセージトランザクション
Cheriton [page 25]
Cheriton[25ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
consecutive transaction identifiers (except if the STI bit <4> is used in one, in which case the transaction identifier for the next message transaction is 256 greater, rather than 1).
連続したトランザクション識別子(STIが<4>に噛み付いたなら、中古のコネ1(その場合では、次のメッセージトランザクションのためのトランザクション識別子は256です)は1よりむしろすばらしいです)。
The Client retains a record for each outstanding transaction until it gets a Response or is timed out in error. The record provides the information required to retransmit the Request. On retransmission timeout, the client retransmits the last Request for which it has not received a Response the same as is done with non-streamed communication. (I.e. there need be only one timeout for all the outstanding message transactions associated with a single client.)
それが返事をもらうか、または誤りで調節されるまで、Clientはそれぞれの傑出しているトランザクションのための記録を保有します。 記録はRequestを再送するのに必要である情報を提供します。 再送タイムアウトでは、クライアントはそれが同じようにそのままで非流されたコミュニケーションでしていた状態でResponseを受けていない最後のRequestを再送します。 (すなわち、すべての傑出しているメッセージトランザクションのためのタイムアウトが独身のクライアントに関連づけた1つしかあってはいけません。)
The consecutive transaction identifiers within a run of message transactions are used as sequence numbers for error control. The Server handles each message transaction in the sequence specified by its transaction identifier. When it receives a message transaction that is not marked as the beginning of a run, it checks that it previously received a message transaction with the predecessor transaction identifier, either 1 less than the current one or 256 less if the previous one had the STI bit set. If not, the Server sends a NotifyVmtpClient operation to the Client's manager indicating either: (1) the first message transaction was not fully received, or else (2) it has no record of the last one received. If the NRT control flag is set, it does not await nor expect retransmission but proceeds with handling this Request. This flag is used primarily when datagram Requests are used as part of a stream of message transactions. If NRT was not specified, the Client must retransmit from the first message transaction not fully received (either at all or in part) before the Server can proceed with handling this run of Requests or else restart the run of message transactions.
メッセージトランザクションの走行の中の連続したトランザクション識別子は誤り制御に一連番号として使用されます。 Serverはトランザクション識別子によって指定された系列のそれぞれのメッセージトランザクションを扱います。 走行の始まりとしてマークされないメッセージトランザクションを受けるとき、前のものでSTIビットを設定したなら、以前に現在のものか256ほど前任者トランザクション識別子、どちらの1でもメッセージトランザクションを受けなかったのはチェックします。 そうでなければ、Serverはどちらかを示すClientのマネージャにNotifyVmtpClient操作を送ります: (1) (2) 完全に最初のメッセージトランザクションを受け取ったというわけではありませんか、またはそれは最後のものに関する記録を全く受け取りません。 NRT指揮旗が設定されるなら、それは「再-トランスミッション」を待って、予想するのではなく、このRequestを扱う売り上げを予想します。 データグラムRequestsがメッセージトランザクションのストリームの一部として使用されるとき、この旗は主として使用されます。 NRTが指定されなかったなら、Serverが取り扱いでRequestsのこの走行を続かせるか、またはメッセージトランザクションの走行を再開できる前にClientは完全に受け取られたというわけではない(全くか一部)最初のメッセージトランザクションから再送しなければなりません。
The Client expects to receive the Responses in a consecutive sequence, using the Transaction identifier to detect missing Responses. Thus, the Server must return Responses in sequence except possibly for some gaps, as follows. The Server can specify in the PGcount field in a Response, the number of consecutively previous Responses that this Response
なくなったResponsesを検出するのにTransaction識別子を使用して、Clientは、連続した系列でResponsesを受け取ると予想します。 したがって、連続してことによると以下のいくつかのギャップを除いて、ServerはResponsesを返さなければなりません。 ServerがResponseのPGcount分野で指定できて、連続して前のResponsesの数がそれである、このResponse
_______________
_______________
<4> The STI bit is used by the Client to effectively allocate 255 transaction identifiers for use by the Server in returning a large Response or stream of Responses.
STIが噛み付いた<4>は、事実上、Responsesの大きいResponseか流れを返す際にServerによる使用のために255のトランザクション識別子を割り当てるのにClientによって使用されます。
Cheriton [page 26]
Cheriton[26ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
corresponds to, up to a maximum of 255 previous Responses <5>. Thus, for example, a Response with Transaction identifier 46 and PGcount 3 represents Responses 43, 44, 45 and 46. This facility allows the Server to eliminate sending Responses to Requests that require no Response, effectively batching the Responses into one. It also allows the Server to effectively maintain strictly consecutive sequencing when the Client has skipped 256 Transaction identifiers using the STI bit and the Server does not have that many Responses to return.
前の最大255Responses<5>まで相当しています。 このようにして、例えば、Transaction識別子46とPGcount3とResponseはResponses43、44、45、および46を表します。 ServerはResponseを全く必要としないRequestsにResponsesを送りながら、この施設で排泄できて、事実上バッチングは1つへのResponsesです。 また、それで、事実上、Serverは、戻るためにClientがSTIビットとServerを使用することで256のTransaction識別子をスキップしたとき、厳密に連続した配列にはそんなに多くのResponsesがないと主張できます。
If the Client receives a Response that is not consecutive, it retransmits the Request(s) for which the Response(s) is/are missing (unless, of course, the corresponding Requests were sent as datagrams). The Client should wait at the end of a run of message transactions for the last one to complete.
Clientが連続していないResponseを受けるなら、それはResponse(s)による/がなくなるという(対応するRequestsがもちろんデータグラムとして送られなかったなら)ことであるRequest(s)を再送します。 Clientは最後のものが完了するメッセージ取引の走行の終わりに待つはずです。
When a Server receives a Request with the NSR bit clear and a higher transaction identifier than it currently has for the Client, it terminates all processing and discards Responses associated with the previous Requests. Thus, a stream of message transactions is effectively aborted by starting a new run, even if the Server was in the middle of handling the previous run.
ServerがNSRビットが明確のRequestと現在Clientのために持っているより高いトランザクション識別子を受け取るとき、それは、すべての処理を終えて、前のRequestsに関連しているResponsesを捨てます。 したがって、事実上、メッセージトランザクションのストリームは新しい走行を始めることによって、中止されます、Serverが前の走行を扱う中央にあったとしても。
Using a mixture of datagram and normal Requests as part of a stream of message transactions, particularly with the use of the NRT bit, can lead to complex behavior under packet loss. It is recommended that a run of message transactions be all of one type to avoid problems, i.e. all normal or all datagrams. Finally, when a Server forwards a Request that is part of a run, it must suspend further processing of the subsequent Requests until the forwarded Request has been handled, to preserve order of processing. The simplest handling of this situation is to use a real nested call when forwarding with streamed message transactions.
ストリームの一部としてメッセージトランザクションと、特にNRTビットの使用でデータグラムと正常なRequestsの混合物を使用するのは複雑な振舞いにパケット損失で通じることができます。 メッセージトランザクションの走行が問題、すなわち、すべての標準を避ける1つのタイプかすべてのデータグラムのすべてであることがお勧めです。Serverが走行の一部であるRequestを進めるとき、最終的に、進められたRequestが処理の注文を保存するために扱われるまで、それはその後のRequestsのさらなる処理を中断させなければなりません。 この状況の最も簡単な取り扱いは流されたメッセージと共にトランザクションを進めるとき、全く入れ子にされた呼び出しを使用することです。
Flow control of streamed message transactions relies on rate control at the Client plus receipt (or non-receipt) of management notify operations indicating the presence of overrunning. A Client must reduce the number of outstanding message transactions at the Server when it receives a NotifyVmtpServer operation with the MSGTRANS_OVERFLOW ResponseCode. The transact parameter indicates the last packet group that was accepted.
流されたメッセージトランザクションのフロー制御はClientで速度制御に依存します、そして、領収書の、そして、(非領収書)の経営者側は氾濫の存在を示す操作に通知します。 MSGTRANS_OVERFLOW ResponseCodeとのNotifyVmtpServer操作を受けるとき、ClientはServerで傑出しているメッセージトランザクションの数を減少させなければなりません。 パラメタを商取引してください。受け入れられた最後のパケットグループを示します。
_______________
_______________
<5> PGcount actually corresponds to packet groups which are described in Section 2.13. This (simplified) description is accurate when there is one Request or Response per packet group.
<5>PGcountは実際にセクション2.13で説明されるパケットグループに対応しています。 パケットグループあたり1RequestかResponseがあるとき、この(簡易型)の記述は正確です。
Cheriton [page 27]
Cheriton[27ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
The implementation of multiple outstanding message transactions requires the ability to record, timeout and buffer multiple outstanding message transactions at the Client end as well as the Server end. However, this facility is optional for both the Client and the Server. Client systems with heavy-weight processes and high network access cost are most likely to benefit from this facility. Servers that serve a wide variety of client machines should implement streaming to accommodate these types of clients.
複数の傑出しているメッセージトランザクションの実装はClientの複数の傑出しているメッセージトランザクションがServerエンドと同様に終わらせる記録する能力、タイムアウト、およびバッファを必要とします。 しかしながら、ClientとServerの両方に、この施設は任意です。ヘビー級のプロセスと高いネットワークアクセス費用があるクライアントシステムはこの施設の最も利益を得そうです。 さまざまなクライアントマシンに役立つサーバは、これらのタイプのクライアントを収容するためにストリーミングを実装するべきです。
2.12. Fault-Tolerant Applications
2.12. フォールトトレラントアプリケーション
One approach to fault-tolerant systems is to maintain a log of all messages sent at each node and replay the messages at a node when the node fails, after restarting it from the last checkpoint <6>. As an experimental facility, VMTP provides a Receive Sequence Number field in the NotifyVmtpClient and NotifyVmtpServer operations as well as the Next Receive Sequence (NRS) flag in the Response packet to allow a sender to log a receive sequence number with each message sent, allowing the packets to be replayed at a recovering node in the same sequence as they were originally received, thereby recovering to the same state as before.
フォールト・トレラント・システムへの1つのアプローチは、ノードが失敗すると、各ノードで送られたすべてのメッセージに関するログを維持して、ノードでメッセージを再演することです、最後のチェックポイント<6>からそれを再開した後に。 実験施設として、VMTPはNotifyVmtpClientのReceive Sequence Number野原を供給します、そして、(NRS)が送付者がaを登録するのを許容するためにResponseパケットで旗を揚げさせるNext Receive Sequenceと同様にNotifyVmtpServer操作は各メッセージを送って一連番号を受けます、パケットが回復ノードで元々それらを受け取ったような同じ系列で再演されるのを許容して、その結果、従来と同様同じ状態に回復します。
Basically, each sending node maintains a receive sequence number for each receiving node. On sending a Request to a node, it presume that the receive sequence number is one greater than the one it has recorded for that node. If not, the receiving node sends a notify operation indicating the receive sequence number assigned the Request. The NRS in the Response confirms that the Request message was the next receive sequence number, so the sender can detect if it failed to receive the notify operation in the previous case. With Responses, the packets are ordered by the Transaction identifier except for multicast message transactions, in which there may be multiple Responses with the same identification. In this case, NotifyVmtpServer operations are used to provide receive sequence numbers.
基本的に、それぞれの送付ノードは、aがそれぞれの受信ノードのために一連番号を受けると主張します。 受信してください。a Requestをノードに送るときそれを推定する、一連番号はそれが持っているのがそのノードのために記録したよりすばらしい1つです。 そうでなければ、ノードがaを送る受信が操作表示に通知する、Requestが割り当てられた一連番号を受けてください。 ResponseのNRSが、Requestメッセージが次が一連番号を受けるので送付者が、それが受信しなかったかどうか検出できるということであったと確認する、先の事件で操作に通知してください。 Responsesと共に、マルチキャストメッセージトランザクション以外のTransaction識別子はパケットを注文します。そこには、同じ識別がある複数のResponsesがあるかもしれません。 この場合、NotifyVmtpServer操作は使用されて、提供するのが一連番号を受けるということです。
This experimental extension of the protocol is focused on support for fault-tolerant real-time distributed systems required in various critical applications. It may be removed or extended, depending on further investigations.
プロトコルのこの実験的な拡大は様々な重要なアプリケーションで必要であるフォールトトレラントのリアルタイムの分散システムのサポートに焦点を合わせられます。 さらなる調査によって、それを取り除くか、または広げるかもしれません。
_______________
_______________
<6> The sender-based logging is being investigated by Willy Zwaenepoel of Rice University.
送付者ベースの<6>伐採はライス大学のウィリーZwaenepoelによって調査されています。
Cheriton [page 28]
Cheriton[28ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
2.13. Packet Groups
2.13. パケットグループ
A message (whether Request or Response) is sent as one or more packet groups. A packet group is one or more packets, each containing the same transaction identification and message control block. Each packet is formatted as below with the message control block logically embedded in the VMTP header.
1つ以上のパケットが分類されるとき、メッセージ(RequestかResponseであることにかかわらず)を送ります。 パケットグループはそれぞれ同じトランザクション識別とメッセージ制御ブロックを含む1つ以上のパケットです。 各パケットはメッセージ制御ブロックがVMTPヘッダーに論理的に埋め込まれている状態で以下でフォーマットされます。
+------------------------------------++---------------------+ | VMTP Header || | +------------+-----------------------|| segment data | |VMTP Control| Message Control Block || | +------------+-----------------------++---------------------+
+------------------------------------++---------------------+ | VMTPヘッダー|| | +------------+-----------------------|| セグメントデータ| |VMTPコントロール| メッセージ制御ブロック|| | +------------+-----------------------++---------------------+
The some fields of the VMTP control portion of the packet and data segment portion can differ between packets within the same packet group.
いくつかの分野、VMTPコントロールでは、パケットとデータ・セグメント部分の部分は同じパケットグループの中でパケットの間で異なることができます。
The segment data portion of a packet group represents up to 16 kilooctets of the segment specified in the message control block. The portion contained in each packet is indicated by the PacketDelivery field contained in the VMTP header. The PacketDelivery field as a bit mask has a similar interpretation to the MsgDelivery field in that each bit corresponds to a segment data block of 512 octets. The PacketDelivery field limits a packet group to 16 kilooctets and a maximum of 32 VMTP packets (with a minimum of 1 packet). Data can be sent in fewer packets by sending multiple data blocks per packet. We require that the underlying datagram service support delivery of (at minimum) the basic 580 octet VMTP packet <7>. To illustrate the use of the PacketDelivery field, consider for example the Ethernet which has a MTU of 1536 octets. so one would send 2 512-octet segment data blocks per packet. (In fact, if a third block is last in the segment and less than 512 octets and fits in the packet without making it too big, an Ethernet packet could contain three data blocks. Thus, an Ethernet packet group for a segment of size 0x1D00 octets (14.5 blocks) and MsgDelivery 0x000074FF consists of 6 packets indicated as follows <8>.
パケットグループのセグメントデータ部はメッセージ制御ブロックで指定されたセグメントの最大16kilooctetsを表します。 各パケットに含まれた部分はVMTPヘッダーに含まれたPacketDelivery分野によって示されます。 マスクが各ビット単位でそれにMsgDelivery分野に同様の解釈を少し持つとき、PacketDelivery分野は512の八重奏に関するセグメントデータ・ブロックに対応しています。 PacketDelivery分野はパケットグループを16kilooctetsと最大32のVMTPパケット(最低1つのパケットがある)に制限します。 複数の1パケットあたりのデータ・ブロックを送りながら、より少ないパケットでデータを送ることができます。 私たちは、基本的なデータグラムサービスが、(最小限における)基本的な580八重奏VMTPパケットの配送が<7>であるとサポートするのを必要とします。 PacketDelivery分野の使用を例証するには、例えば1536の八重奏のMTUを持っているイーサネットを考えてください。1つは1パケットあたり2つの512八重奏のセグメントデータ・ブロックを送るでしょう。 事実上、3番目のブロックが最後に、セグメントと512未満の八重奏にはあって、それをあまりに大きくしないでパケットをうまくはめ込むなら、イーサネットパケットは3データ・ブロックを含むかもしれません。(その結果、サイズ0x1D00八重奏(14.5ブロック)とMsgDelivery 0x000074FFのセグメントが6つのパケットから成るので、イーサネットパケットグループは以下の通り<8>を示しました。
_______________
_______________
<7> Note that with a 20 octet IP header, a VMTP packet is 600 octets. We propose the convention that any host implementing VMTP implicitly agrees to accept IP/VMTP packets of at least 600 octets.
20八重奏IPヘッダーと共に、VMTPパケットが600の八重奏であるという<7>メモ。 私たちはどんなホストもそれとなくVMTPを実装して、少なくとも600の八重奏のIP/VMTPパケットを受け入れるのに同意するコンベンションを提案します。
<8> We use the C notation 0xHHHH to represent a hexadecimal number.
私たちがC記法0xHHHHを使用する<8>は16進数を表します。
Cheriton [page 29]
Cheriton[29ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
Packet
Delivery 1 1 1 1 1 1 1 1 0 0 1 0 1 0 1 0 0 0 0 0 0 . . .
0000 0400 0800 0C00 1000 1400 1800 1C00
+----+----+----+----+----+----+----+-+
Segment |....|....|....|....|....|....|....|.|
+----+----+----+----+----+----+----+-+
: : : : : : : / / :
v v v v v v v /| v
+----+----+----+----+ +----+ +---+
Packets | 1 | 2 | 3 | 4 | | 5 | | 6 |
+----+----+----+----+ +----+ +---+
パケット配信1 1 1 1 1 1 1 1 0 0 1 0 1 0 1 0 0 0 0 0 0. . . 0000 0400 0800 0C00 1000 1400 1800 1C00+----+----+----+----+----+----+----++セグメント|....|....|....|....|....|....|....|.| +----+----+----+----+----+----+----+-+ : : : : : : : / / : v v v対v v/に| +に対して----+----+----+----+ +----+ +---+ パケット| 1 | 2 | 3 | 4 | | 5 | | 6 | +----+----+----+----+ +----+ +---+
Each '.' is 256 octets of data. The PacketDelivery masks for the 6 packets are: 0x00000003, 0x0000000C, 0x00000030, 0x000000C0, 0x00001400 and 0x00006000, indicating the segment blocks contained in each of the packets. (Note that the delivery bits are in little endian order.)
'それぞれ''データの256の八重奏がそうですか? 6つのパケットのためのPacketDeliveryマスクは以下の通りです。 それぞれのパケットに含まれたセグメントブロックを示す0×00000003、0x0000000C、0×00000030、0x000000C0、0×00001400、および0×00006000。 (配送ビットがリトルエンディアンオーダーにあることに注意してください。)
A packet group is sent as a single "blast" of packets with no explicit flow control. However, the sender should estimate and transmit at a rate of packet transmission to avoid congesting the network or overwhelming the receiver, as described in Section 2.5.6. Packets in a packet group can be sent in any order with no change in semantics.
パケットの単一の「爆破」として明白なフロー制御なしでパケットグループを送ります。 しかしながら、送付者は、ネットワークを充血させるか、または受信機を圧倒するのを避けるためにパケット伝送のレートで見積もって、伝わるべきです、セクション2.5.6で説明されるように。 意味論における変化なしでパケットグループにおけるパケットを順不同に送ることができます。
When the first packet of a packet group is received (assuming the Server does not decide to discard the packet group), the Server saves a copy of the VMTP packet header, indicates it is currently receiving a packet group, initializes a "current delivery mask" (indicating the data in the segment received so far) to 0, accepts this packet (updating the current delivery mask) and sets the timer for the packet group. Subsequent packets in the packet group update the current delivery mask.
パケットグループの最初のパケットが受け取られているとき(Serverを仮定するのは、パケットグループを捨てると決めません)、ServerはVMTPパケットのヘッダーのコピーを保存して、現在パケットグループを受け取っているのを示して、「現在の配送マスク」を0に初期化して(今までのところ受け取られているセグメントでデータを示します)、このパケットを受け入れて(現在の配送マスクをアップデートします)、パケットグループにタイマを設定します。 パケットグループにおけるその後のパケットは現在の配送マスクをアップデートします。
Reception of a packet group is terminated when either the current delivery mask indicates that all the packets in the packet group have been received or the packet group reception timer expires (set to TC3 or TS1). If the packet group reception timer expires, if the NRT bit is set in the Control flags then the packet group is discarded if not complete unless MDM is set. In this case, the MsgDelivery field in the message control block is set to indicate the segment data blocks actually received and the message control block and segment data received is delivered to application level.
現在の配送マスクが、パケットグループにおけるすべてのパケットが受け取られたのを示すか、またはパケットグループレセプションタイマが期限が切れるとき(TC3かTS1に設定します)、パケットグループの受付は終えられます。 NRTビットがControl旗で設定されるならパケットグループレセプションタイマが期限が切れて、MDMが設定されない場合、パケットグループは、捨てられるか、または完全です。 この場合、メッセージ制御ブロックのMsgDelivery分野が、実際に受け取られたデータ・ブロック、メッセージ制御ブロック、およびセグメントデータが受けたセグメントがアプリケーションレベルに提供されるのを示すように設定されます。
If NRT is not set and not all data blocks have been received, a NotifyVmtpClient (if a Request) or NotifyVmtpServer (if a Response) is sent back with a PacketDelivery field indicating the blocks received. The source of the packet group is then expected to retransmit the missing blocks. If not all blocks of a Request are received after RequestAckRetries(Client) retransmissions, the Request is discarded and
NRTが用意ができないで、すべてのデータ・ブロックを受け取るというわけではなかったなら、PacketDelivery分野が、ブロックが受信されたのを示していて、NotifyVmtpClient(Requestであるなら)かNotifyVmtpServer(Responseであるなら)を返送します。 そして、パケットグループの源がなくなったブロックを再送すると予想されます。 そしてそうでなければ、RequestAckRetries(クライアント)「再-トランスミッション」の後にRequestのすべてのブロックを受け取って、Requestが捨てる。
Cheriton [page 30]
Cheriton[30ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
a NotifyVmtpClient operation with an error response code is sent to the client's manager unless MDM is set. With a Response, there are ResponseAckRetries(Server) retransmissions and then, if MDM is not set, the requesting entity is returned the message control block with an indication of the amount of segment data received extending contiguously from the start of the segment. E.g. if the sender sent 6 512-octet blocks and only the first two and the last two arrived, the receiver would be told that 1024 octets were received. The ResponseCode field is set to BAD_REPLY_SEGMENT. (Note that VMTP is only able to indicate the specific segment blocks received if MDM is set.)
MDMを設定しない場合、誤り応答コードによるNotifyVmtpClient操作をクライアントのマネージャに送ります。 Responseと共に、ResponseAckRetries(サーバ)「再-トランスミッション」があります、そして、次に、MDMを設定しないなら、セグメントの始まりから近接して広がりながら、メッセージ制御ブロックを要求実体にセグメントデータの量のしるしを受けていて返します。 例えば、送付者が6つの512八重奏のブロックを送って、最初の2だけと最後の2が到着するなら、受信機は1024の八重奏が受けられたと言われるでしょうに。 ResponseCode分野はBAD_REPLY_SEGMENTに設定されます。 (VMTPが、MDMが設定されるなら特定のセグメントブロックが受信されたのを示すことができるだけであることに注意してください。)
The parameters RequestAckRetries(Client) and ResponseAckRetries(Server) could be set on a per-client and per-server basis in a sophisticated implementation based on knowledge of packet loss.
パラメタRequestAckRetries(クライアント)とResponseAckRetries(サーバ)はパケット損失に関する知識に基づく洗練された実装におけるクライアントとサーバあたり1個のベースのセットであるかもしれません。
If the APG flag is set, a NotifyVmtpClient or NotifyVmtpServer operation is sent back at the end of the packet group reception, depending on whether it is a Request or a Response.
APG旗が設定されるなら、NotifyVmtpClientかNotifyVmtpServer操作がパケットグループレセプションの終わりに返送されます、それがRequestかそれともResponseであるかによって。
At minimum, a Server should check that each packet in the packet group contains the same Client, Server, Transaction identifier and SegmentSize fields. It is a protocol error for any field other than the Checksum, packet group control flags, Length and PacketDelivery in the VMTP header to differ between any two packets in one packet group. A packet group containing a protocol error of this nature should be discarded.
最小限では、Serverは、パケットグループにおける各パケットが同じClient、Server、Transaction識別子、およびSegmentSize分野を含むのをチェックするはずです。 それはVMTPヘッダーのパケット集団経営のChecksum、旗、Length、およびPacketDelivery以外のどんな分野も1つのパケットグループにおけるどんな2つのパケットの間でも異なるプロトコル誤りです。 この種のプロトコル誤りを含むパケットグループは捨てられるべきです。
Notify operations should be sent (or invoked) in the manager whenever there is a problem with a unicast packet. i.e. negative acknowledgments are always sent in this case. In the case of problems with multicast packets, the default is to send nothing in response to an error condition unless there is some clear reason why no other node can respond positively. For example, the packet might be a Probe for an entity that is known to have been recently existing on the receiving host but now invalid and could not have migrated. In this case, the receiving host responds to the Probe indicating the entity is nonexistent, knowing that no other host can respond to the Probe. For packets and packet groups that are received and processed without problems, a Notify operation is invoked only if the APG bit is set.
ユニキャストパケットに関する問題があるときはいつも、送られた(または、呼び出される)コネがマネージャであったなら操作に通知してください。この場合いつもすなわち、否定応答を送ります。 マルチキャストパケットに関する問題の場合では、デフォルトは他のどんなノードも積極的に対応できない何らかの明確な理由がない場合エラー条件に対応して何も送らないことです。 例えば、パケットは、最近受信ホストの上に存在しているのが知られている実体にもかかわらず、現在の病人のためのProbeであるかもしれなく、移行することができませんでした。 この場合、受信ホストは実体が実在しないのを示すProbeに応じます、他のどんなホストもProbeに応じることができないのを知っていて。 問題なしで受け取られて、処理されるパケットとパケットグループにおいて、APGビットが設定される場合にだけ、Notify操作は呼び出されます。
2.14. Runs of Packet Groups
2.14. パケットグループの走行
A run of packet groups is a sequence of packet groups, all Request packets or all Response packets, with the same Client and consecutive transaction identifiers, all but the first and last packets flagged with the NSR (Not Start Run) and NER (Not End Run) control bits. When each packet group in the run corresponds to a single Request or Response, it
パケットグループの走行はパケットグループ、すべてのRequestパケットまたはすべてのResponseパケットの系列です、同じClientと連続したトランザクション識別子で、NSR(Start Runでない)とNER(End Runでない)コントロールビットで旗を揚げられた1番目と最後のパケット以外のすべて。 走行におけるそれぞれのパケットグループが独身のRequestかResponseに一致しているとそれ
Cheriton [page 31]
Cheriton[31ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
is identical to a run of message transactions. (See Section 2.11) However, a Request message or a Response message may consists of up to 256 packet groups within a run, for a maximum of 4 megaoctets of segment data. A message that is continued in the next packet group in the run is flagged in the current packet group by the CMG flag. Otherwise, the next packet group in the run (if any) is treated as a separate Request or Response.
メッセージトランザクションの走行と同じです。 (セクション2.11を見ます) しかしながら、RequestメッセージかResponseメッセージは成るかもしれません。セグメントデータの最大4megaoctetsのための走行の中の最大256のパケットグループから成ります。 走行における次のパケットグループで続けられているメッセージは現在のパケットグループでCMG旗で旗を揚げられます。 さもなければ、走行(もしあれば)における次のパケットグループは別々のRequestかResponseとして扱われます。
Normally, each Request and Response message is sent as a single packet group and each run consists of a single packet group. In this case neither NSR or NER are set. For multi-packet group messages, the PacketDelivery mask in the i-th packet group of a message corresponds to the portion of the segment offset by i-1 times 16 kilooctets, designating the the first packet group to have i = 1.
通常、ただ一つのパケットグループと各走行がただ一つのパケットグループから成るとき、それぞれのRequestとResponseメッセージを送ります。 この場合、NSRもNERも用意ができていません。 マルチパケットグループメッセージに関しては、PacketDeliveryがコネにマスクをかける、i、-、メッセージのパケットグループはi-1回16のkilooctetsによって相殺されたセグメントの部分に一致しています、i=1を持つ最初のパケットグループを指定して第
2.15. Byte Order
2.15. バイトオーダー
For purposes of transmission and reception, the MCB is treated as consisting of 8 32-bit fields and the segment is a sequence of bytes. VMTP transmits the MCB in big-endian order, performing byte-swapping, if necessary, before transmission. A little-endian host must byte-swap the MCB on reception. (The data segment is transmitted as a sequence of bytes with no reordering.) The byte order of the sender of a message is indicated by the LEE bit in the entity identifier for the sender, the Client field if a Request and the Server field if a Response. The sender and receiver of a message are required to agree in some higher level protocol (such as an RPC presentation protocol) on who does further swapping of the MCB and data segment if required by the types of the data actually being transmitted. For example, the segment data may contain a record with 8-bit, 16-bit and 32-bit fields, so additional transformation is required to move the segment from a host of one byte order to another.
トランスミッションとレセプションの目的のために、MCBは8つの32ビットの分野から成るとして扱われます、そして、セグメントはバイトの系列です。 必要なら、トランスミッションの前にバイトスワッピングを実行して、VMTPはビッグエンディアンオーダーでMCBを伝えます。 リトルエンディアンホストはレセプションのMCBをバイト交換しなければなりません。 (データ・セグメントはバイトの系列として再命令なしで伝えられます。) メッセージの送付者のバイトオーダーは送付者へのエンティティ識別名のビット、ClientがRequestであるならさばいて、ServerがResponseであるならさばくLEEによって示されます。 だれが必要なら実際に送られるデータのタイプでMCBとデータ・セグメントのスワッピングを促進するかに関する何らかのより高い平らなプロトコル(RPCプレゼンテーションプロトコルなどの)でメッセージの送付者と受信機は同意しなければなりません。 例えば、セグメントデータが8ビットの、そして、16ビットの、そして、32ビットの分野がある記録を含むかもしれないので、追加変換が1つのバイトオーダーのホストから別のホストまでセグメントを動かすのに必要です。
VMTP to date has used a higher-level presentation protocol in which segment data is sent in the native order of the sending host and byte-swapped as necessary by the receiving host. This approach minimizes the byte-swapping overhead between machines of common byte order (including when the communication is transparently local to one host), avoids a strong bias in the protocol to one byte-order, and allows for the sending entity to be sending to a group of hosts with different byte orders. (Note that the byte-swap overhead for the MCB is minimal.) The presentation-level overhead is minimal because most common operations, such as file access operations, have parameters that fit the MCB and data segment data types exactly.
これまでのVMTPは必要に応じて、受信ホストでセグメントデータが送付ホストの固有の注文で送られてバイトと交換されているよりハイレベルのプレゼンテーションプロトコルを使用しました。 このアプローチは、一般的なバイトオーダー(1人のホストにとって、コミュニケーションがいつ透過的にローカルであるかを含んでいる)のマシンの間のバイトを交換するオーバーヘッドを最小にして、1つのバイトオーダーとしてプロトコルの強い偏見を避けて、送付実体が異なったバイトオーダーと共にホストのグループに発信するのを許容します。 (MCBのためのバイトスワッピングオーバーヘッドが最小限であることに注意してください。) ファイルアクセス操作などの一般的なほとんどの操作にはMCBに合うパラメタとデータ・セグメントデータ型がまさにあるので、プレゼンテーションレベルオーバーヘッドは最小限です。
Cheriton [page 32]
Cheriton[32ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
2.16. Minimal VMTP Implementation
2.16. 最小量のVMTP実装
A minimal VMTP client needs to be able to send a Request packet group and receive a Response packet group as well as accept and respond to Requests sent to its management module, including Probe and NotifyClient operations. It may also require the ability to invoke Probe and Notify operations to locate a Server and acknowledge responses. (the latter only if it is involved in transactions that are not idempotent or datagram message transactions. However, a simple sensor, for example, can transmit VMTP datagram Requests indicating its current state with even less mechanism.) The minimal client thus requires very little code and is suitable as a basis for (e.g.) a network boot loader.
最小量のVMTPクライアントは、管理モジュールに送られたRequestsにRequestパケットグループを送って、Responseパケットグループを受け取って、受け入れて、応じることができる必要があります、ProbeとNotifyClient操作を含んでいて。 また、Serverの場所を見つけて、応答を承諾するのがProbeとNotify操作を呼び出す能力を必要とするかもしれません。 (後者はそれである場合にだけベキ等元でないトランザクションかデータグラムメッセージトランザクションにかかわります。 しかしながら、例えば、簡単なセンサはさらに少ないメカニズムで現状を示すVMTPデータグラムRequestsを伝えることができます。) 最小量のクライアントは、その結果、ほとんどコードを必要としないで、(例えば、)ネットワークブーツ荷物を積む人の基礎として適当です。
A minimal VMTP server implements idempotent, non-encrypted message transactions, possibly with no segment data support. It should use an entity state record for each Request but need only retain it while processing the Request. Without segment data larger than a packet, there is no need for any timers, buffering (outside of immediate request processing) or queuing. In particular, it needs only as many records as message transactions it handles simultaneously (e.g. 1). The entity state record is required to recognize and respond to Request retransmissions during request processing.
最小量のVMTPサーバはことによるとセグメントデータサポートなしでベキ等元、非暗号化メッセージトランザクションを実装します。 それは、各Requestに実体州の記録を使用するべきですが、Requestを処理している間それを保有するだけでよいです。 パケットより大きいセグメントデータがなければ、どんなタイマ、(即座の要求処理の外部)をバッファリングするか、または列を作りの必要も全くありません。 特に、それはせいぜいそれが同時に扱うメッセージトランザクション(例えば、1)記録だけを必要とします。 実体州の記録が、Request retransmissionsに認識して、応じるのに要求処理の間、必要です。
The minimal server need only receive Requests and and be able to send Response packets. It need have only a minimal management module supporting Probe operations. (Support for the NotifyVmtpClient operation is only required if it does not respond immediately to a Request.) Thus the VMTP support for say a time server, sensor, or actuator can be extremely simple. Note that the server need never issue a Probe operation if it uses the host address of the Request for the Response and does not require the Client information returned by the Probe operation. The minimal server should also support reception of forwarded Requests.
そして、そして、最小量のサーバがRequestsを受けるだけでよい、パケットをResponseに送ることができてください。 それには、Probeに操作をサポートする最小量の管理モジュールしかあってはいけません。 (すぐRequestに応じない場合にだけ、NotifyVmtpClient操作のサポートが必要です。) したがって、たとえば、時間サーバ、センサ、または作動装置のVMTPサポートは非常に簡単である場合があります。 ResponseにRequestのホスト・アドレスを使用して、Probe操作で返されたClient情報を必要としないならサーバの必要性がProbe操作を決して発行しないことに注意してください。 また、最小量のサーバは進められたRequestsのレセプションをサポートするべきです。
2.17. Message vs. Procedural Request Handling
2.17. メッセージ対手続き上の要求取り扱い
A request-response protocol can be used to implement two forms of semantics on reception. With procedural handling of a Request, a Request is handled by a process associated with the Server that effectively takes on the identity of the calling process, treating the Request message as invoking a procedure, and relinquishing its association to the calling process on return. VMTP supports multiple nested calls spanning multiple machines. In this case, the distributed call stack that results is associated with a single process from the standpoint of authentication and resource management, using the ProcessId field supported by VMTP. The entity identifiers effectively
レセプションで2つのフォームの意味論を実装するのに要求応答プロトコルを使用できます。 Request、Requestの手続き上の取り扱いと共に、手順を呼び出すとしてRequestメッセージを扱って、事実上、呼び出しプロセスのアイデンティティを呈するServerに関連しているプロセスによって扱われて、リターンの呼び出しプロセスに協会を放棄するのがあります。 VMTPは複数のマシンにかかる複数の入れ子にされた呼び出しをサポートします。 この場合、結果として生じる分配された呼び出しスタックは認証と資源管理の見地から単一のプロセスに関連しています、VMTPによってサポートされたProcessId分野を使用して。 エンティティ識別名、事実上
Cheriton [page 33]
Cheriton[33ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
link these call frames together. That is, the Client field in a Request is effectively the return link to the previous call frame.
これらの呼び出しフレームを結びつけてください。 事実上、すなわち、RequestのClient分野は前の呼び出しフレームへのリターンリンクです。
With message handling of a Request, a Request message is queued for a server process. The server process dequeues, reads, processes and responds to the Request message, executing as a separate process. Subsequent Requests to the same server are queued until the server asks to receive the next Request.
Requestのメッセージハンドリングで、Requestメッセージはサーバプロセスのために列に並ばせられます。 サーバは処理されます。Requestメッセージ、別々のプロセスとしての実行にデキューして、読み込んで、処理して、反応します。 サーバが、次のRequestを受け取るように頼むまで、同じサーバへのその後のRequestsは列に並ばせられます。
Procedural semantics have the advantage of allowing each Request (up to the resource limits of the Server) to execute concurrently at the Server, with Request-specific synchronization. Message semantics have the advantage that Requests are serialized at the Server and that the request processing logically executes with the priority, protection and independent execution of a separate process. Note that procedural and message handling of a request appear no differently to the client invoking the message transaction, except possibly for differences in performance.
手続き上の意味論には、同時にServerで実行する各Request(Serverのリソース限界までの)を許容する利点があります、Request特有の同期で。 Requestsは利点ですが、メッセージ意味論はServerで連載されていた状態で実行しました、そして、要求処理は優先権、保護、および独立者で別々のプロセスの実行を論理的に実行します。 そんなに手続き上の注意と要求のメッセージハンドリングはメッセージトランザクションを呼び出しているクライアントにとっていいえに異なって現れます、ことによると性能の違いを除いて。
We view the two Request handling approaches as appropriate under different circumstances. VMTP supports both models.
私たちは、2つのRequest取り扱いアプローチが異なった状況で適切であるとみなします。 VMTPは両方のモデルをサポートします。
2.18. Bibliography
2.18. 図書目録
The basic protocol is similar to that used in the original form of the V kernel [3, 4] as well as the transport protocol of Birrell and Nelson's [2] remote procedure call mechanism. An earlier version of the protocol was described in SIGCOMM'86 [6]. The rate-based flow control is similar to the techniques of Netblt [9]. The support for idempotency draws, in part, on the favorable experience with idempotency in the V distributed system. Its use was originally inspired by the Woodstock File Server [11]. The multicast support draws on the multicast facilities in V [5] and is designed to work with, and is now implemented using, the multicast extensions to the Internet [8] described in RFC 966 and 988. The secure version of the protocol is similar to that described by Birrell [1] for secure RPC. The use of runs of packet groups is similar to Fletcher and Watson's delta-T protocol [10]. The use of "management" operations implemented using VMTP in place of specialized packet types is viewed as part of a general strategy of using recursion to simplify protocol architectures [7].
基本プロトコルはビレルのトランスポート・プロトコルと同様にVカーネル[3、4]とネルソン[2]の遠隔手続き呼び出しメカニズムの原型で使用されるそれと同様です。 プロトコルの以前のバージョンはSIGCOMM86年に説明されました。[6]。 レートベースのフロー制御はNetblt[9]のテクニックと同様です。 idempotencyのサポートはidempotencyの好ましい経験のときにV分散システムで一部描きます。 使用は元々、ウッドストックFile Server[11]によって奮い立たせられました。 マルチキャストサポートは、使用、RFC966と988で説明されたインターネット[8]へのマルチキャスト拡大であるとV[5]のマルチキャスト施設の上で引き起こして、働くように設計されていて、今、実装されます。 プロトコルの安全なバージョンは安全なRPCのためにビレル[1]によって説明されたそれと同様です。 パケットグループの走行の使用はフレッチャーとワトソンのデルタTプロトコル[10]と同様です。 専門化しているパケットタイプに代わってVMTPを使用することで実装された「管理」操作の使用はプロトコルアーキテクチャ[7]を簡素化するのに再帰を使用する一般的な戦略の一部として見なされます。
Finally, this protocol was designed, in part, to respond to the requirements identified by Braden in RFC 955. We believe that VMTP satisfies the requirements stated in RFC 955.
最終的に、このプロトコルは、RFC955でブレーデンによって特定された要件に応じるように一部設計されました。 私たちは、VMTPがRFC955に述べられた要件を満たすと信じています。
Cheriton [page 34]
Cheriton[34ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
[1] A.D. Birrell, "Secure Communication using Remote Procedure
Calls", ACM. Trans. on Computer Systems 3(1), February, 1985.
[1] A.D.ビレル、「遠隔手続き呼び出しを使用する安全なコミュニケーション」、ACM。 移-. コンピュータシステムズ3(1)、1985年2月に。
[2] A. Birrell and B. Nelson, "Implementing Remote Procedure Calls",
ACM Trans. on Computer Systems 2(1), February, 1984.
[2] A.ビレルとB.ネルソン、「遠隔手続き呼び出しを実装します」、ACM、移-. コンピュータシステムズ2(1)、1984年2月に。
[3] D.R. Cheriton and W. Zwaenepoel, "The Distributed V Kernel and its
Performance for Diskless Workstations", In Proceedings of the 9th
Symposium on Operating System Principles, ACM, 1983.
[3] D.R.はCheritonされます、そして、W.はZwaenepoelと、「Distributed V KernelとDiskless Workstationsのためのそのパフォーマンス」をCheritonします、In Proceedings。Operating Systemプリンシプルズ、ACM、1983の第9Symposiumについて。
[4] D.R. Cheriton, "The V Kernel: A Software Base for Distributed
Systems", IEEE Software 1(2), April, 1984.
[4] D.R.Cheriton、「Vカーネル:」 「分散システムのためのソフトウェア基盤」、IEEEソフトウェア1(2)、1984年4月。
[5] D.R. Cheriton and W. Zwaenepoel, "Distributed Process Groups in
the V Kernel", ACM Trans. on Computer Systems 3(2), May, 1985.
[5] D.R.CheritonとW.Zwaenepoel、「Vカーネルにおける分配されたプロセスグループ」、ACM、移-. コンピュータシステムズ3(2)、1985年5月に。
[6] D.R. Cheriton, "VMTP: A Transport Protocol for the Next
Generation of Communication Systems", In Proceedings of
SIGCOMM'86, ACM, Aug 5-7, 1986.
[6] D.R.Cheriton、「VMTP:」 SIGCOMM86年、ACM、1986年8月5日〜7日の議事における「通信系の次世代のためのトランスポート・プロトコル。」
[7] D.R. Cheriton, "Exploiting Recursion to Simplify an RPC
Communication Architecture", in preparation, 1988.
[7] 準備、1988年に「RPC通信アーキテクチャを簡素化するのに再帰を利用する」D.R.Cheriton。
[8] D.R. Cheriton and S.E. Deering, "Host Groups: A Multicast
Extension for Datagram Internetworks", In 9th Data Communication
Symposium, IEEE Computer Society and ACM SIGCOMM, September, 1985.
[8] D.R.Cheritonと東南デアリング、「グループをホスティングしてください」 1985年9月の第9データ通信シンポジウム、IEEEコンピュータ社会、およびACM SIGCOMMの「データグラムインターネットワークのためのマルチキャスト拡大。」
[9] D.D. Clark and M. Lambert and L. Zhang, "NETBLT: A Bulk Data
Transfer Protocol", Technical Report RFC 969, Defense Advanced
Research Projects Agency, 1985.
[9] D.D.クラーク、M.ランバート、およびL.チャン、「NETBLT:」 「バルク・データ転送プロトコル」、技術報告書RFC969、ディフェンス先端研究は政府機関、1985を映し出します。
[10] J.G. Fletcher and R.W. Watson, "Mechanism for a Reliable Timer-
based Protocol", Computer Networks 2:271-290, 1978.
[10] J.G.フレッチャーとR.W.ワトソン、「Reliable Timerのためのメカニズムはプロトコルを基礎づけた」271-290、コンピュータNetworks2:1978
Cheriton [page 35]
Cheriton[35ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
[11] D. Swinehart and G. McDaniel and D. Boggs, "WFS: A Simple File
System for a Distributed Environment", In Proc. 7th Symp.
Operating Systems Principles, 1979.
[11] D.Swinehart、G.マクダニエル、およびD.ボッグズ、「WFS:」 Procの「分散環境の簡単なファイルシステム。」 第7Symp。 オペレーティングシステム原則、1979。
Cheriton [page 36]
Cheriton[36ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
3. VMTP Packet Formats
3. VMTPパケット・フォーマット
VMTP uses 2 basic packet formats corresponding to Request packets and Response packets. These packet formats are identical in most of the fields to simplify the implementation.
VMTPはRequestパケットとResponseパケットに対応する2つの基本的なパケット・フォーマットを使用します。 これらのパケット・フォーマットは実装を簡素化する分野の大部分が同じです。
We first describe the entity identifier format and the packet fields that are used in general, followed by a detailed description of each of the packet formats. These fields are described below in detail. The individual packet formats are described in the following subsections. The reader and VMTP implementor may wish to refer to Chapters 4 and 5 for a description of VMTP event handling and only refer to this detailed description as needed.
私たちは最初にエンティティ識別名形式と一般に、使用されるパケット分野について説明します、それぞれのパケット・フォーマットの詳述があとに続いていて。 これらの分野は以下で詳細に説明されます。 個々のパケット・フォーマットは以下の小区分で説明されます。 読者とVMTP作成者は、VMTPイベント取り扱いの記述について第4章と第5章を参照して、必要に応じてこの詳述について言及するだけでありたいかもしれません。
3.1. Entity Identifier Format
3.1. エンティティ識別名形式
The 64-bit non-group entity identifiers have the following substructure.
64ビットの非グループエンティティ識別名には、以下の基礎があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| |L|R|
|A|0|E|E| Domain-specific structure
|E| |E|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Domain-specific structure |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| |L|R| |A|0|E|E| ドメイン特有の構造|E| |E|S| +++++++++++++++++++++++++++++++++ドメイン特有の構造| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The field meanings are as follows:
分野意味は以下の通りです:
RAE Remote Alias Entity - the entity identifier identifies
an entity that is acting as an alias for some entity
outside this entity domain. This bit is used by
higher-level protocols. For instance, servers may take
extra security and protection measures with aliases.
RAE RemoteアリアEntity--エンティティ識別名は、この実体ドメインの外の何らかの実体のために行動している実体が別名であると認識します。 このビットは上位レベル・プロトコルによって使用されます。 例えば、サーバは別名がある特別なセキュリティと保護方策を取るかもしれません。
GRP Group - 0, for non-group entity identifiers.
GRP Group--0 非グループエンティティ識別名のために。
LEE Little-Endian Entity - the entity transmits data in
little-endian (VAX) order.
LEEリトル-エンディアンEntity--実体はリトルエンディアン(VAX)オーダーにおけるデータを送ります。
RES Reserved - must be 0.
RES Reserved--0でなければなりません。
The 64-bit entity group identifiers have the following substructure.
64ビットの実体グループ識別子には、以下の基礎があります。
Cheriton [page 37]
Cheriton[37ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| |U|R|
|A|1|G|E| Domain-specific structure
|E| |P|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Domain-specific structure |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| |U|R| |A|1|G|E| ドメイン特有の構造|E| |P|S| +++++++++++++++++++++++++++++++++ドメイン特有の構造| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The field meanings are as follows:
分野意味は以下の通りです:
RAE Remote Alias Entity - same as for non-group entity
identifier.
RAE RemoteアリアEntity--非グループエンティティ識別名のように、同じです。
GRP Group - 1, for entity group identifiers.
GRP Group--1 実体グループ識別子のために。
UGP Unrestricted Group - no restrictions are placed on
joining this group. I.e. any entity can join limited
only by implementation resources.
UGP Unrestricted Group--このグループに加わることに関して制限は全く課されません。 実装リソースだけによって制限されて、すなわちどんな実体も接合できます。
RES Reserved - must be 0.
RES Reserved--0でなければなりません。
The all-zero entity identifier is reserved and guaranteed to be unallocated in all domains. In addition, a domain may reserve part of the entity identifier space for statically allocated identifiers. However, this is domain-specific.
オールゼロエンティティ識別名は、すべてのドメインに「非-割り当て」られるために予約されて、保証されます。 さらに、ドメインは静的に割り当てられた識別子のためにエンティティ識別名スペースの一部を予約するかもしれません。 しかしながら、これはドメイン特有です。
Description of currently defined entity identifier domains is provided in Appendix IV.
現在定義されたエンティティ識別名ドメインの記述をAppendix IVに提供します。
3.2. Packet Fields
3.2. パケット分野
Client 64-bit identifier for the client entity associated with
this packet. The structure, allocation and binding of
this identifier is specific to the specified Domain. An
entity identifier always includes 4 types bits as
specified in Section 3.1.
このパケットに関連しているクライアント実体のためのクライアントの64ビットの識別子。 この識別子の構造、配分、および結合は指定されたDomainに特定です。 エンティティ識別名はいつもセクション3.1における指定されるとしての4タイプビットを含んでいます。
Version The 3-bit identifier specifying the version of the
protocol. Current version is version 0.
バージョン、プロトコルのバージョンを指定する3ビットの識別子。 最新版はバージョン0です。
Domain The 13-bit identifier specifying the naming and
administration domain for the client and server named in
the packet.
ドメイン、パケットで指定されたクライアントとサーバに命名と管理ドメインを指定する13ビットの識別子。
Cheriton [page 38]
Cheriton[38ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
Packet Flags: 3 bits. (The normal case has none of the flags set.)
パケット旗: 3ビット。 (正常なケースで、旗のいずれも設定しません。)
HCO Header checksum only - checksum has only been calculated
on the header. This is used in some real-time
applications where the strict correctness of the data is
not needed.
HCO Headerチェックサム専用--チェックサムはヘッダーの上に計算されるだけでした。 これはデータの厳しい正当性が必要でないいくつかのリアルタイムのアプリケーションで使用されます。
EPG Encrypted packet group - part of a secure message
transaction.
EPG Encryptedパケットグループ--安全なメッセージトランザクションの一部。
MPG Multicast packet group - packet was multicast on
transmission.
MPG Multicastパケットグループ--パケットはトランスミッションでのマルチキャストでした。
Length A 13-bit field that specifies the number of 32-bit words
in the segment data portion of the packet (if any),
excluding the checksum field. (Every VMTP packet is
required to be a multiple of 64 bits, possibly by
padding out the segment data.) The minimum legal Length
is 0, the maximum length is 4096 and it must be an even
number.
チェックサム分野を除いて、パケット(もしあれば)のセグメントデータ部の32ビットの単語の数を指定する長さのA13ビットの分野。 (あらゆるVMTPパケットが64ビットの倍数になるのにことによるとセグメントデータを広げることによって、必要です。) 最小の法的なLengthは0歳です、そして、最大の長さは4096です、そして、それは偶数であるに違いありません。
Control Flags: 9 bits. (The normal case has none of the flags set.)
コントロールは弛みます: 9ビット。 (正常なケースで、旗のいずれも設定しません。)
NRS Next Receive Sequence - the associated Request message
(in a Response) or previous Response (if a Request) was
received consecutive with the last Request from this
entity. That is, there was no interfering messages
received.
NRS Next Receive Sequence--この実体からの最後のRequestについて連続していた状態で関連Requestメッセージ(Responseの)か前のResponse(Requestであるなら)を受け取りました。 すなわち、メッセージが受けた干渉がありませんでした。
APG Acknowledge Packet Group - Acknowledge packet group on
receipt. If a Request, send back a Request to the
client's manager providing an update on the state of the
transaction as soon as the request packet group is
received, independent of the response being available.
If a Response, send an update to the server's manager as
soon as possible after response packet group is received
providing an update on the state of the transaction at
the client
APG Acknowledge Packet Group--領収書に関するパケットグループを承認してください。 Requestであるなら、利用可能な応答の如何にかかわらずリクエスト・パケットグループを受け取るとすぐに、トランザクションの状態に関する最新情報を提供するクライアントのマネージャにRequestを返送してください。 Responseであるなら、応答パケットグループがクライアントでトランザクションの状態に関する最新情報を提供するのにおいて受け取られていた後にできるだけ早く、サーバのマネージャにアップデートを送ってください。
NSR Not Start Run - 1 if this packet is not part of the
first packet group of a run of packet groups.
NSR Not Start Run--1 このパケットがパケットグループの走行の最初のパケットグループの一部でないなら。
NER Not End Run - 1 if this packet is not part of the last
packet group of a run of packet groups.
NER Not End Run--1 このパケットがパケットグループの走行の最後のパケットグループの一部でないなら。
NRT No Retransmission - do not ask for retransmissions of
this packet group if not all received within timeout
NRTノーRetransmission--このパケットグループかタイムアウトの中に受け取られたすべての「再-トランスミッション」を求めないでください。
Cheriton [page 39]
Cheriton[39ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
period, just deliver or discard.
以上、まさしく配送するか、または捨ててください。
MDG Member of Destination Group - this packet is sent to a
group and the client is a member of this group.
Destination GroupのMDGメンバー--このパケットをグループに送って、クライアントはこのグループのメンバーです。
CMG Continued Message - the message (Request or Response) is
continued in the next packet group. The next packet
group has to be part of the same run of packet groups.
CMG Continued Message--メッセージ(要求かResponse)は次のパケットグループで続けられています。 次のパケットグループはパケットグループの同じ走行の一部でなければなりません。
STI Skip Transaction Identifiers - the next transaction
identifier that the Client plans to use is the current
transaction plus 256, if part of the same run and at
least this big if not. In a Request, this authorizes
the Server to send back up to 256 packet groups
containing the Response.
STI Skip Transaction Identifiers--同じくらいの一部が稼働しているか、そして、まして、Clientが使用するのを計画している次のトランザクション識別子は、大きく経常取引と、256と、少なくともこれです。 Requestでは、これは、ServerがResponseを含む最大256のパケットグループを返送するのを認可します。
DRT Delay Response Transmission - set by request sender if
multiple responses are expected (as indicated by the MRD
flag in the RequestCode) and it may be overrun by
multiple responses. The responder(s) should then
introduce a short random delay in sending the Response
to minimize the danger of overrunning the Client. This
is normally only used for responding to multicast
Requests where the Client may be receiving a large
number of Responses, as indicated by the MRD flag in the
Request flags. Otherwise, the Response is sent
immediately.
DRT Delay Response Transmission--要求送付者で、複数の応答が予想されて(RequestCodeのMRD旗で示されるように)、それが複数の応答でオーバランするかもしれないなら、セットしてください。 そして、応答者はClientをオーバランさせるという危険を最小にするためにResponseを送る少し無作為の遅れを導入するべきです。 通常、これはClientが多くのResponsesを受けているかもしれないマルチキャストRequestsに応じるのに使用されるだけです、Request旗でMRD旗で示されるように。 さもなければ、すぐに、Responseを送ります。
RetransmitCount:
3 bits - the ordinal number of transmissions of this
packet group prior to this one, modulo 8. This field is
used in estimation of roundtrip times. This count may
wrap around during a message transaction. However, it
should be sufficient to match acknowledgments and
responses with a particular transmission.
RetransmitCount: 3ビット--このパケットのトランスミッションの序数の数はこの、法8の前に分類されます。 この分野は往復の回に関する見積りに使用されます。 このカウントはメッセージトランザクションの間、巻きつけられるかもしれません。 しかしながら、特定のトランスミッションに承認と応答に合っているのは十分であるべきです。
ForwardCount: 4 bits indicating the number of times this Request has
been forwarded. The original Request is always sent
with a ForwardCount of 0.
ForwardCount: このRequestが送られた回数を示す4ビット。 0のForwardCountと共にオリジナルのRequestをいつも送ります。
Interpacket Gap: 8 bits.
Indicates the recommended time to use between subsequent
packet transmissions within a multi-packet packet group
transmission. The Interpacket Gap time is in 1/32nd of
a network packet transmission time for a packet of size
MTU for the node. (Thus, the maximum gap time is 8
packet times.)
Interpacketギャップ: 8ビット。 マルチパケットパケットグループ送信の中でその後のパケット伝送の間で費やすお勧めの時間を示します。 ノードのためのサイズMTUのパケットのためのネットワークパケット伝送時間の1/32番目に、Interpacket Gap時間があります。 (その結果、最大のギャップ時間は8パケット回です。)
Cheriton [page 40]
Cheriton[40ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
PGcount: 8 bits
The number of packet groups that this packet group
represents in addition to that specified by the
Transaction field. This is used in acknowledging
multiple packet groups in streamed communication.
PGcount: 8ビット、このパケットグループが代表するパケットグループの数はTransaction分野のそばでそこへ持ってきて指定しました。 これは流されたコミュニケーションの複数のパケットグループを承認する際に使用されます。
Priority 4-bit identifier for priority for the processing of this
request both on transmission and reception. The
interpretation is:
トランスミッションとレセプションにおけるこの要求の処理のための優先権のための優先権の4ビットの識別子。 解釈は以下の通りです。
1100 urgent/emergency
1100年の緊急の/非常時
1000 important
1000、重要
0000 normal
0000年の標準
0100 background
0100年のバックグラウンド
Viewing the higher-order bit as a sign bit (with 1
meaning negative), low values are high priority and high
values are low priority. The low-order 2 bits indicate
additional (lower) gradations for each level.
符号ビット(1つの意味が否定的の)であると高次なビットをみなして、低値は高い優先度です、そして、高い値は低い優先度です。 下位の2ビットは各レベルのために追加している(下側の)段階を示します。
Function Code: 1 bit - types of VMTP packets. If the low-order bit of
the function code is 0, the packet is sent to the
Server, else it is sent to the Client.
機能コード: 1ビット--VMTPパケットのタイプ。 機能コードの下位のビットが0であるなら、パケットをServerに送って、ほかに、それをClientに送ります。
0 Request
0要求
1 Response
1 応答
Transaction: 32 bits:
Identifier for this message transaction.
トランザクション: 32ビット: このメッセージトランザクションのための識別子。
PacketDelivery: 32 bits:
Delivery indicates the segment blocks contained in this
packet. Each bit corresponds to one 512-octet block of
segment data. A 1 bit in the i-th bit position
(counting the LSB as 0) indicates the presence of the
i-th segment block.
PacketDelivery: 32ビット: 配送はこのパケットに含まれたセグメントブロックを示します。 各ビットは1つの512八重奏のブロックのセグメントデータに対応しています。 噛み付かれた1、i、-、ビット位置(0にLSBをみなす)が存在を第示す、i、-、セグメント第ブロック。
Server: 64 bits
Entity identifier for the server or server group
associated with this transaction. This is the receiver
when a Request packet and the sender when a Response
packet.
サーバ: このトランザクションに関連しているサーバかサーバグループのための64ビットのEntity識別子。 Requestパケットと送付者であるときに、Responseパケットであるときに、これは受信機です。
Cheriton [page 41]
Cheriton[41ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
Code: 32 bits The Request Code and Response Code, set either at the
user level or VMTP level depending on use and packet
type. Both the Request and Response codes include 8
high-order bits from the following set of control bits:
コード: 32ビット、Request CodeとResponse Code、ユーザのレベルかVMTPのセットは使用によって、パケットタイプを平らにします。 RequestとResponseコードの両方が以下のセットのコントロールビットから8高位のビットを含んでいます:
CMD Conditional Message Delivery - only deliver the request
or response if the receiving entity is waiting for it at
the time of delivery, otherwise drop the message.
受信実体が販売時にそれを待っているなら、単に要求か応答を提供してください。CMD Conditional Message Delivery--さもなければ、メッセージを下げてください。
DGM DataGram Message - indicates that the message is being
sent as a datagram. If a Request message, do not wait
for reply, or retransmit. If a Response message, treat
this message transaction as idempotent.
DGM DataGram Message--メッセージがデータグラムとして送られるのを示します。 Requestメッセージであるなら、回答を待たないでください、または再送しないでください。 Responseメッセージであるなら、このメッセージトランザクションをベキ等元として扱ってください。
MDM Message Delivery Mask - indicates that the MsgDelivery
field is being used. Otherwise, the MsgDelivery field
is available for general use.
MDM Message Delivery Mask--MsgDelivery分野が使用されているのを示します。 さもなければ、MsgDelivery分野は一般的使用に利用可能です。
SDA Segment Data Appended - segment data is appended to the
message control block, with the total size of the
segment specified by the SegmentSize field. Otherwise,
the segment data is null and the SegmentSize field is
not used by VMTP and available for user- or RPC-level
uses.
SDA Segment Data Appended--セグメントデータをメッセージ制御ブロックに追加します、セグメントの総サイズがSegmentSize分野によって指定されている状態で。 SegmentSize分野は、さもなければ、セグメントデータがヌルであり、VMTPによって使用されないで、ユーザかRPC-レベル用途に利用可能です。
CRE CoResident Entity - indicates that the CoResidentEntity
field in the message should be interpreted by VMTP.
Otherwise, this field is available for additional user
data.
CRE CoResident Entity--メッセージのCoResidentEntity分野がVMTPによって解釈されるはずであるのを示します。 さもなければ、この分野は追加利用者データに利用可能です。
MRD Multiple Responses Desired - multiple Responses are
desired to to this Request if it is multicast.
Otherwise, the VMTP module can discard subsequent
Responses after the first Response.
MRD Multiple Responses Desired--ResponsesがそれであるならこのRequestに望まれている倍数はマルチキャストです。 さもなければ、VMTPモジュールは最初のResponseの後にその後のResponsesを捨てることができます。
PIC Public Interface Code - Values for Code with this bit
set are reserved for definition by the VMTP
specification and other standard protocols defined on
top of VMTP.
PIC Public Interface Code--このビットがあるCodeがセットしたので、値は定義のためにVMTPの上で定義されたVMTP仕様と他の標準プロトコルによって予約されます。
RES Reserved for future use. Must be 0.
今後の使用のためのRES Reserved。 0はそうであるに違いありませんか?
CoResidentEntity
64-bit Identifier for an entity or group of entities
with which the Server entity or entities must be
co-resident, i.e. route only to entities (identified by
Server) on the same host(s) as that specified by
すなわち、実体の実体かグループのためのServer実体か実体がコレジデントであるに違いないCoResidentEntityの64ビットのIdentifier、それとしての(s)が指定した同じホストの上の実体(Serverによって特定される)だけへのルート
Cheriton [page 42]
Cheriton[42ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
CoResidentEntity, Only meaningful if CRE is set in the
Code field.
CoResidentEntityで、Only重要である、CREがCode分野で用意ができているなら。
User Data 12 octets Space in the header for the VMTP user to
specify user-specific control and data.
VMTPユーザがユーザ特有のコントロールとデータを指定するヘッダーというユーザData12八重奏Space。
MsgDelivery: 32 bits
The segment blocks being transmitted (in total) in this
packet group following the conventions for the
PacketDelivery field. This field is ignored by the
protocol and treated as an additional user data field if
MDM is 0. On transmission, the user level sets the
MsgDelivery to indicate those portions of the segment to
be transmitted. On receipt, the MsgDelivery field is
modified by the VMTP module to indicate the segment data
blocks that were actually received before the message
control block is passed to the user or RPC level. In
particular, the kernel does not discard the packet group
if segment data blocks are missing. A Server or Client
entity receiving a message with a MsgDelivery in use
must check the field to ensure adequate delivery and
retry the operation if necessary.
MsgDelivery: PacketDelivery分野へのコンベンションに続いて、セグメントが妨げるこのパケットで伝えられる(合計で)32ビットは分類されます。 この分野は、MDMが0であるならプロトコルによって無視されて、追加ユーザデータ・フィールドとして扱われます。 トランスミッションのときに、ユーザレベルは、MsgDeliveryに伝えられるためにセグメントのそれらの部分を示すように設定します。 領収書では、MsgDelivery分野は、メッセージ制御ブロックがユーザかRPCレベルに渡される前に実際に受け取られたセグメントデータ・ブロックを示すようにVMTPモジュールで変更されます。 セグメントデータ・ブロックがなくなるなら、特に、カーネルはパケットグループを捨てません。 MsgDeliveryが使用中の状態でメッセージを受け取るServerかClient実体が、適切な配送を確実にして、必要なら、操作を再試行するために分野をチェックしなければなりません。
SegmentSize: 32 bits
Size of segment in octets, up to a maximum of 16
kilooctets without streaming and 4 megaoctets with
streaming, if SDA is set. Otherwise, this field is
ignored by the protocol and treated as an additional
user data field.
SegmentSize: ストリーミングと4megaoctetsのないSDAが用意ができているなら流れる最大16kilooctetsまでの八重奏におけるセグメントの32ビットのSize。 さもなければ、この分野は、プロトコルによって無視されて、追加ユーザデータ・フィールドとして扱われます。
Segment Data: 0-16 kilooctets
0 octets if SDA is 0, else the portion of the segment
corresponding to the Delivery Mask, limited by the
SegmentSize and the MTU, padded out to a multiple of 64
bits.
セグメントデータ: 0-16 SDAであるならkilooctets0八重奏が0である、ほかに、SegmentSizeとMTUによって制限されたDelivery Maskに対応するセグメントの部分は64の倍数にビットを広げました。
Checksum: 32 bits.
The 32-bit checksum for the header and segment data.
チェックサム: 32ビット。 ヘッダーとセグメントデータのための32ビットのチェックサム。
The VMTP checksum algorithm <9> develops a 32-bit checksum by computing
VMTPチェックサムアルゴリズム<9>はコンピューティングで32ビットのチェックサムを開発します。
_______________
_______________
<9> This algorithm and description are largely due to Steve Deering of Stanford University.
主にスティーブ・デアリングのためにこのアルゴリズムと記述がある<9>、スタンフォード大学。
Cheriton [page 43]
Cheriton[43ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
two 16-bit, ones-complement sums (like IP), each covering different parts of the packet. The packet is divided into clusters of 16 16-bit words. The first, third, fifth,... clusters are added to the first sum, and the second, fourth, sixth,... clusters are added to the second sum. Addition stops at the end of the packet; there is no need to pad out to a cluster boundary (although it is necessary that the packet be an integral multiple of 64 bits; padding octets may have any value and are included in the checksum and in the transmitted packet). If either of the resulting sums is zero, it is changed to 0xFFFF. The two sums are appended to the transmitted packet, with the first sum being transmitted first. Four bytes of zero in place of the checksum may be used to indicate that no checksum was computed.
それぞれパケットの異なった一部をカバーする16ビットの2つのもの補数の合計(IPのような)。 パケットは16の16ビットの単語のクラスタに分割されます。 … 1番目、3番目に、5番目に、クラスタは最初の合計、および2番目に加えられます、4番目、6番目… クラスタは2番目の合計に加えられます。 追加はパケットの端に止まります。 クラスタ境界に広げる必要は全くありませんパケットが64ビットの不可欠の倍数であることが必要です; 詰め物八重奏は、どんな値も持っているかもしれなくて、チェックサムと伝えられたパケットに含まれていますが()。 結果として起こる合計のどちらかがゼロであるなら、それは0xFFFFに変わります。 最初の合計が最初に伝えられている状態で、2つの合計を伝えられたパケットに追加します。 チェックサムに代わったゼロの4バイトは、チェックサムが全く計算されなかったのを示すのに使用されるかもしれません。
The 16-bit, ones-complement addition in this algorithm is the same as used in IP and, therefore, subject to the same optimizations. In particular, the words may be added up 32-bits at a time as long as the carry-out of each addition is added to the sum on the following addition, using an "add-with-carry" type of instruction. (64-bit or 128-bit additions would also work on machines that have registers that big.)
このアルゴリズムによる16ビットのもの補数の追加はIPに使用されてしたがって同じ最適化を条件として同じです。 それぞれの追加の持ち返り用が以下の追加での合計に加えられる限り、特に、単語はaの32ビットの時間に加えられるかもしれません、指示の「キャリーで、加えてください」タイプを使用して。 (また、64ビットの、または、128ビットの追加は、レジスタをそんなに大きくするマシンに働いているでしょう。)
A particular weakness of this algorithm (shared by IP) is that it does not detect the erroneous swapping of 16-bit words, which may easily occur due to software errors. A future version of VMTP is expected to include a more secure algorithm, but such an algorithm appears to require hardware support for efficient execution.
このアルゴリズム(IPによって共有される)の特定の弱点はソフトウェア誤りのため容易に現れるかもしれない16ビットの単語の誤ったスワッピングを検出しないということです。 VMTPの将来のバージョンが、より安全なアルゴリズムを含んでいると予想されますが、そのようなアルゴリズムは効率的な実行のハードウェアサポートを必要とするように見えます。
Not all of these fields are used in every packet. The specific packet formats are described below. If a field is not mentioned in the description of a packet type, its use is assumed to be clear from the above description.
これらの分野のすべてがあらゆるパケットで使用されるというわけではありません。 特定のパケット・フォーマットは以下で説明されます。 パケットタイプの記述で分野について言及しないなら、使用が上の記述によって明確であると思われます。
Cheriton [page 44]
Cheriton[44ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
3.3. Request Packet
3.3. リクエスト・パケット
The Request packet (or packet group) is sent from the client to the server or group of servers to solicit processing plus the return of zero or more responses. A Request packet is identified by a 0 in the LSB of the fourth 32-bit word in the packet.
ゼロか、より多くの応答の処理と復帰に請求するために、Requestパケット(または、パケットグループ)をサーバのクライアントからサーバかグループに送ります。 Requestパケットはパケットにおける4番目の32ビットの単語のLSBの0時までに特定されます。
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Client (8 octets) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver | |H|E|M| | |sion | Domain |C|P|P| Length | | | |O|G|G| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|A|N|N|N|M|C|S|D|Retra|Forward| Inter- | |R|R|R| | |R|P|S|E|R|D|M|T|R|nsmit| Count | Packet | Prior |E|E|E|0| |S|G|R|R|T|G|G|I|T|Count| | Gap | -ity |S|S|S| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transaction | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PacketDelivery | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Server (8 octets) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C|D|M|S|R|C|M|P| | |M|G|D|D|E|R|R|I| RequestCode | |D|M|M|A|S|E|D|C| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + CoResidentEntity (8 octets) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > User Data (12 octets) < +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MsgDelivery | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SegmentSize | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > segment data, if any < +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1++++++++++++++++++++++++++++++++++クライアント(8つの八重奏)++++++++++++++++++++++++++++++++++|Ver| |H|E|M| | |sion| ドメイン|C|P|P| 長さ| | | |O|G|G| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|A|N|N|N|M|C|S|D|Retra|転送| 相互| |R|R|R| | |R|P|S|E|R|D|M|T|R|nsmit| カウント| パケット| 先|E|E|E|0| |S|G|R|R|T|G|G|I|T|カウント| | ギャップ| -ity|S|S|S| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | トランザクション| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PacketDelivery| サーバ..八重奏|C|D|M|S|R|C|M|P| | |M|G|D|D|E|R|R|I| RequestCode| |D|M|M|A|S|E|D|C| | 八重奏..八重奏| MsgDelivery| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SegmentSize| セグメント..データ| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3-1: Request Packet Format
図3-1: リクエスト・パケット形式
The fields of the Request packet are set according to the semantics described in Section 3.2 with the following qualifications.
セクション3.2で以下の資格で説明された意味論によると、Requestパケットの分野は設定されます。
Cheriton [page 45]
Cheriton[45ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
InterPacketGap The estimated interpacket gap time the client would like
for the Response packet group to be sent by the Server
in responding to this Request.
ResponseパケットグループがこのRequestに応じる際に送られるクライアントがそうするおよそinterpacketギャップ時間がServerが好きであるInterPacketGap。
Transaction Identifier for transaction, at least one greater than
the previously issued Request from this Client.
トランザクション、少なくともこのClientからの以前に発行されたRequestよりすばらしい1つのためのトランザクションIdentifier。
Server Server to which this Request is destined.
このRequestが運命づけられているサーバServer。
RequestCode Request code for this request, indicating the operation
to perform.
働くために操作を必要とするこの要求のためのRequestCode Requestコード。
Cheriton [page 46]
Cheriton[46ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
3.4. Response Packet
3.4. 応答パケット
The Response packet is sent from the Server to the Client in response to a Request, identified by a 1 in the LSB of the fourth 32-bit word in the packet.
パケットにおける4番目の32ビットの単語のLSBの1時までに特定されたRequestに対応してResponseパケットをServerからClientに送ります。
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Client (8 octets) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver | |H|E|M| | |sion | Domain |C|P|P| Length | | | |O|G|G| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|A|N|N|N|R|C|S|R|Retra|Forward| | |R|R|R| | |R|P|S|E|R|E|M|T|E|nsmit| Count | PGcount | Prior |E|E|E|1| |S|G|R|R|T|S|G|I|S|Count| | | -ity |S|S|S| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transaction | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PacketDelivery | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Server (8 octets) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C|D|M|S|R|R|R|R| | |M|G|D|D|E|E|E|E| ResponseCode | |D|M|M|A|S|S|S|S| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > UserData (20 octets) < +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MsgDelivery | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Segment Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > segment data, if any < +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1++++++++++++++++++++++++++++++++++クライアント(8つの八重奏)++++++++++++++++++++++++++++++++++|Ver| |H|E|M| | |sion| ドメイン|C|P|P| 長さ| | | |O|G|G| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|A|N|N|N|R|C|S|R|Retra|転送| | |R|R|R| | |R|P|S|E|R|E|M|T|E|nsmit| カウント| PGcount| 先|E|E|E|1| |S|G|R|R|T|S|G|I|S|カウント| | | -ity|S|S|S| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | トランザクション| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PacketDelivery| サーバ..八重奏|C|D|M|S|R|R|R|R| | |M|G|D|D|E|E|E|E| ResponseCode| |D|M|M|A|S|S|S|S| | 八重奏| MsgDelivery| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | セグメントサイズ| セグメント..データ| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3-2: Response Packet Format
図3-2: 応答パケット・フォーマット
The fields of the Response packet are set according to the semantics described in Section 3.2 with the following qualifications.
セクション3.2で以下の資格で説明された意味論によると、Responseパケットの分野は設定されます。
Client, Version, Domain, Transaction
Match those in the Request packet group to which this is
クライアント、バージョン、Domain、Requestパケットのものがこれがどれであるかと分類するTransaction Match
Cheriton [page 47]
Cheriton[47ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
a response.
応答。
STI 1 if this Response is using one or more of the
transaction identifiers skipped by the Client after the
Request to which this is a Response. STI in the Request
essentially allocates up to 256 transaction identifiers
for the Server to use in a run of Response packet
groups.
このResponseがトランザクション識別子の1つ以上を使用しているなら、STI1はこれがResponseであるRequestの後のClientのそばでスキップしました。 RequestのSTIは本質的にはServerがResponseパケットグループの走行に使用する最大256のトランザクション識別子を割り当てます。
RetransmitCount The retransmit count from the last Request packet
received to which this is a response.
RetransmitCount、Requestパケットが受けた最終からのこれが応答であるカウントを再送してください。
ForwardCount The number of times the corresponding Request was
forwarded before this Response was generated.
ForwardCount、回の対応するRequestがこのResponseの前に送られた数は生成されました。
PGcount The number of consecutively previous packet groups that
this response is acknowledging in addition to the one
identified by the Transaction identifier.
Transaction識別子によって特定されたものに加えて承認する連続して前のパケットの数が分類するこの応答があるPGcount。
Server Server sending this response. This may differ from that
originally specified in the Request packet if the
original Server was a server group, or the request was
forwarded.
この応答を送るサーバServer。 これがオリジナルのServerがサーバグループであったなら元々Requestパケットで指定されたそれと異なるかもしれませんか、または要求を転送しました。
The next two chapters describes the protocol operation using these packet formats, with the the Client and the Server portions described separately.
次の2つの章はこれらのパケット・フォーマットを使用することでプロトコル操作について説明します、ClientとServer部分が別々に説明されている状態で。
Cheriton [page 48]
Cheriton[48ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
4. Client Protocol Operation
4. クライアントプロトコル操作
This chapter describes the operation of the client portion of VMTP in terms of the procedures for handling VMTP user events, packet reception events, management operations and timeout events. Note that the client portion of VMTP is separable from the server portion. It is feasible to have a node that only implements the client end of VMTP.
本章は取り扱いVMTPユーザイベント、パケットレセプションイベント、管理操作、およびタイムアウトイベントのために手順でVMTPのクライアント部分の操作について説明します。 VMTPのクライアント部分がサーバ部分から分離できることに注意してください。 VMTPのクライアント端を実装するだけであるノードを持っているのは可能です。
To simplify the description, we define a client state record (CSR) plus some standard utility routines.
記述を簡素化するために、私たちは属国記録(CSR)といくつかの標準のユーティリティルーチンを定義します。
4.1. Client State Record Fields
4.1. 属国記録分野
In the following protocol description, there is one client state record (CSR) per (client,transaction) outstanding message transaction. Here is a suggested set of fields.
以下のプロトコル記述には、(クライアント、トランザクション)傑出しているメッセージトランザクションあたり1つの属国記録(CSR)があります。 ここに、提案されたセットの分野があります。
Link Link to next CSR when queued in one of the transmission,
timeout or message queues.
トランスミッション、タイムアウトまたはメッセージキューの1つで列に並ばせられたら、次のCSRにLinkをリンクしてください。
QueuePtr Pointer to queue head in which this CSR is contained or
NULL if none. Queue could be one of transmission queue,
timeout queue, server queue or response queue.
なにもであるならこのCSRが含まれているヘッドかNULLを列に並ばせるQueuePtr Pointer。 待ち行列は1であるかもしれません。トランスミッション待ち行列、タイムアウト待ち行列、サーバ待ち行列または応答待ち行列について。
ProcessIdentification
The process identification and address space.
ProcessIdentification、プロセス識別とアドレス空間。
Priority Priority for processing, network service, etc.
処理のための優先権Priority、ネットワーク・サービスなど
State One of the client states described below.
以下で説明された属国の1つを述べてください。
FinishupFunc Procedure to be executed on the CSR when it is completes
its processing in transmission or timeout queues.
それが実行されるべきであるときCSRで実行されるべきFinishupFunc Procedureは、トランスミッションかタイムアウト待ち行列で処理するのを完了します。
TimeoutCount Time to remain in timeout queue.
タイムアウトに残るTimeoutCount Timeは列を作ります。
TimeoutLimit User-specified time after which the message transaction
is aborted. The timeout is infinite if set to zero.
メッセージトランザクションが中止されるTimeoutLimit Userによって指定された時。 ゼロに設定されるなら、タイムアウトは無限です。
RetransCount Number of retransmissions since last hearing from the
Server.
最後に以来Serverから連絡をいただく「再-トランスミッション」のRetransCount Number。
LastTransmitTime
The time at which the last packet was sent. This field
is used to calculate roundtrip times, using the
RetransmitCount to match the responding packet to a
LastTransmitTime、最後のパケットが送られた時。 応じるパケットをaに合わせるのにRetransmitCountを使用して、この分野は、往復の回について計算するのに使用されます。
Cheriton [page 49]
Cheriton[49ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
particular transmission. I.e. Response or management
NotifyVmtpClient operation to Request and a management
NotifyVmtpServer operation to a Response.
特定のトランスミッション。 すなわち Requestへの応答か管理NotifyVmtpClient操作とResponseへの管理NotifyVmtpServer操作。
TimetoLive Time to live to be used on transmission of IP packets.
生きて、IPパケットのトランスミッションのときに使用されるTimetoLive Time。
TransmissionMask
Bit mask indicating the portions of the segment to
transmit. Set before entering the transmission queue
and cleared incrementally as the 512-byte segment blocks
of the segment are transmitted.
伝わるようにセグメントの部分を示すTransmissionMask Bitマスク。 セグメントの512バイトのセグメントブロックが伝えられるように、トランスミッション待ち行列に入って、増加してクリアされる前にセットしてください。
LocalClientLink Link to next CSR hashing to same hash index in the
ClientMap.
同じハッシュへの次のCSRの論じ尽くすことへのLocalClientLink LinkはClientMapで索引をつけます。
LocalClient Entity identifier for client when this CSR is used to
send a Request packet.
このCSRであるときに、クライアントへのLocalClient Entity識別子は、Requestパケットを送るのに使用されます。
LocalTransaction
Transaction identifier for current message transaction
the local client has outstanding.
地元のクライアントが傑出するようにする現在のメッセージトランザクションのためのLocalTransaction Transaction識別子。
LocalPrincipal Account identification, possibly including key and key
timeout.
ことによると主要で主要なタイムアウトを含むLocalPrincipal Account識別。
LocalDelivery Bit mask of segment blocks that have not been
acknowledged in the Request or have been received in the
Response, depending on the state.
状態によって、Requestで承認されていないか、またはResponseに受け取られたセグメントブロックのLocalDelivery Bitマスク。
ResponseQueue Queue of CSR's representing the queued Responses for
this entity.
CSRがこの実体のために列に並ばせられたResponsesを表すResponseQueue Queue。
VMTP Header Prototype VMTP header, used to generate and store the
header portion of a Request for transmission and
retransmission on timeout.
トランスミッションと「再-トランスミッション」のためにタイムアウトにRequestのヘッダー部分を生成して、保存するのにおいて中古のVMTP Header Prototype VMTPヘッダー。
SegmentDesc Description of the segment data associated with the CSR,
either the area storing the original Request data, the
area for receiving Request data, or the area storing the
Response data that is returned.
セグメントデータのSegmentDesc記述はCSRと交際しました、Requestデータを受け取るためにオリジナルのRequestデータ、領域を保存する領域か領域のどちらかが返されるResponseデータを保存して。
HostAddr The network or internetwork host address to which the
Client last transmitted. This field also indicates the
type of the address, e.g. IP, Ethernet, etc.
ネットワークかインターネットワークホストがClientが持続するものに扱うHostAddrは伝わりました。 また、この分野はアドレスのタイプ、IP、例えばイーサネットなどを示します。
Note: the CSR can be combined with a light-weight process descriptor with considerable benefit if the process is designed to block when it
以下に注意してください。 それであるときに、プロセスがブロックに設計されるなら、かなりの利益で軽量のプロセス記述子にCSRを結合できます。
Cheriton [page 50]
Cheriton[50ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
issues a message transaction. In particular, by combining the two descriptors, the implementation saves time because it only needs to locate and queue one descriptor with various operations (rather than having to locate two descriptors). It also saves space, given that the VMTP header prototype provides space such as the user data field which may serve to store processor state for when the process is preempted. Non-preemptive blocking can use the process stack to store the processor state so only a program counter and stack pointer may be required in the process descriptor beyond what we have described. (This is the approach used in the V kernel.)
メッセージトランザクションを発行します。 様々な操作(2つの記述子の場所を見つけなければならないよりむしろ)で1つの記述子を場所を見つけて、列に並ばせるのが必要であるだけであるので、2つの記述子を結合することによって、特に、実装は時間を節約します。 また、それは記憶空間を節約します、VMTPヘッダープロトタイプがプロセスが先取りされる時の間、プロセッサ状態を保存するのに役立つかもしれないユーザデータ・フィールドなどのスペースを提供するなら。 非割込み型ブロッキングがプロセッサ状態を保存するのにプロセススタックを使用できるので、プロセス記述子で私たちが説明したことを超えてプログラムカウンタとスタックポインタだけを必要としてもよいです。 (これはVカーネルに使用されるアプローチです。)
4.2. Client Protocol States
4.2. クライアントプロトコル州
A Client State Record records the state of message transaction generated by this host, identified by the (Client, Transaction) values in the CSR. As a client originating a transaction, it is in one of the following states.
Client州RecordはCSRの(クライアント、Transaction)値によって特定されたこのホストによって生成されたメッセージトランザクションの状態を記録します。 トランザクションを溯源するクライアントとして、それは以下の州の1つにあります。
AwaitingResponse
Waiting for a Response packet group to arrive with the
same (Client,Transaction) identification.
ResponseパケットのためのAwaitingResponse Waitingは、同じ(クライアント、Transaction)識別と共に到着するように分類します。
ReceivingResponse
Waiting for additional packets in the Response packet
group it is currently receiving.
Responseパケットの追加パケットがそれを分類するので、ReceivingResponse Waitingは現在、受信しています。
"Other" Not waiting for a response, which can be Processing or
some other operating system state, or one of the Server
states if it also acts as a server.
応答の「他」のNotの待ち、Processingかある他のオペレーティングシステム状態がどれであるかもしれないか、そして、Serverのひとりはまた、それがサーバとして機能するかどうかと述べます。
This covers all the states for a client.
これはクライアントのためにすべての州をカバーしています。
4.3. State Transition Diagrams
4.3. 状態遷移ダイヤグラム
The client state transitions are illustrated in Figure 4-1. The client goes into the state AwaitingResponse on sending a request unless it is a datagram request. In the AwaitingResponse state, it can timeout and retry and eventually give up and return to the processing state unless it receives a Response. (A NotifyVmtpClient operation resets the timeout but does not change the state.) On receipt of a single packet response, it returns to the processing state. Otherwise, it goes to ReceivingResponse state. After timeout or final response packet is received, the client returns to the processing state. The processing state also includes any other state besides those associated with issuing a message transaction.
属国変遷は図4-1で例証されます。 それがデータグラム要求でないなら要求を送るとき、クライアントは州のAwaitingResponseに入ります。 そして、AwaitingResponse状態では、そうすることができる、タイムアウト、再試行してください、そして、結局、あきらめてください、そして、Responseを受けない場合、処理状態に戻ってください。 (NotifyVmtpClient操作は、タイムアウトをリセットしますが、状態を変えません。) ただ一つのパケット応答を受け取り次第、それは処理状態に戻ります。 さもなければ、それはReceivingResponse状態に行きます。 タイムアウトか最終的な応答パケットが受け取られていた後に、クライアントは処理状態に戻ります。 また、処理州はメッセージトランザクションを発行すると関連づけられたもの以外にいかなる他の状態も含めます。
Cheriton [page 51]
Cheriton[51ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
+------------+
| Processing |<--------------------|
| |<-------------| |
| |<---| | |
+|------^--^-+ Single Last |
Transmit | | Packet Response |
| | | Response Packet |
| | | | | |
+-DGM->+ Timeout | | Final timeout
| | | | |
+V-----------+ | +-----------+
| Awaiting |----+ | Receiving |->Response-+
| Response |->Response->| Response | |
| | (multi- | |<----------+
+-|--------^-+ packet) +----------^+
V | | |
+-Timeout+ +>Timeout+
+------------+ | 処理| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| | <、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| | <、-、--、|、|、| +|------^--^+ただ一つの最終| 伝わってください。| | パケット応答| | | | 応答パケット| | | | | | | +-DGM>+タイムアウト| | 最終的なタイムアウト| | | | | + V-----------+ | +-----------+ | 待ちます。|----+ | 受信します。|->応答+| 応答|->応答、->| 応答| | | | (マルチ、|、| <、-、-、-、-、-、-、-、-、--、+ +、-、|、-、-、-、-、-、-、--、^+パケット) +----------^+V| | | +タイムアウト++>タイムアウト+
Figure 4-1: Client State Transitions
図4-1: 属国変遷
4.4. User Interface
4.4. ユーザーインタフェース
The RPC or user interface to VMTP is implementation-dependent and may use systems calls, functions or some other mechanism. The list of requests that follow is intended to suggest the basic functionality that should be available.
VMTPへのRPCかユーザーインタフェースが、実装依存していて、システム呼び出し、機能またはある他のメカニズムを使用するかもしれません。 続く要求のリストが利用可能であるべき基本機能を示すことを意図します。
Send( mcb, timeout, segptr, segsize )
Initiate a message transaction to the server and request
message specified by mcb and return a response in mcb,
if it is received within the specified timeout period
(or else return USER_TIMEOUT in the Code field). The
segptr parameter specifies the location from which the
segment data is sent and the location into which the
response data is to be delivered. The segsize field
indicates the maximum length of this area.
mcbによって指定されたサーバと要求メッセージへのメッセージトランザクションを開始に送ってください、そして、(mcb、タイムアウト、segptrはsegsizeされます)mcbで応答を返してください、指定されたタイムアウト時間中にそれを受け取るなら(Code分野でUSER_TIMEOUTを返してください)。 segptrパラメタはセグメントデータが送られる位置と提供される応答データがことである位置を指定します。 segsizeする、分野はこの領域の最大の長さを示します。
GetResponse( responsemcb, timeout, segptr, segsize )
Get the next response sent to this client as part of the
current message transaction, returning the segment data,
if any, into the memory specified by segptr and segsize.
GetResponse(responsemcb、タイムアウト、segptrはsegsizeされる)はもしあればsegptrによって指定されたメモリにセグメントデータを返して、現在のメッセージトランザクションの一部として次の応答をこのクライアントに送らせて、segsizeします。
This interface assumes that there is a client entity associated with the invoking process that is to be used with these operations. Otherwise, the client entity must be specified as an additional parameter.
このインタフェースは、これらの操作と共に使用されることになっている呼び出しプロセスに関連しているクライアント実体があると仮定します。 さもなければ、追加パラメタとしてクライアント実体を指定しなければなりません。
Cheriton [page 52]
Cheriton[52ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
4.5. Event Processing
4.5. イベント処理
The following events may occur in the VMTP client:
以下のイベントはVMTPクライアントに起こるかもしれません:
- User Requests
- ユーザ要求
* Send
* 発信してください。
* GetResponse
* GetResponse
- Packet Arrival
- パケット到着
* Response Packet
* 応答パケット
* Request
* 要求
The minimal Client implementation handles Request packets for
its VMTP management (server) module and sends NotifyVmtpClient
requests in response to others, indicating the specified
server does not exist.
最小量のClient実装は、VMTP管理(サーバ)モジュールのためにRequestパケットを扱って、他のものに対応して要求をNotifyVmtpClientに送ります、指定されたサーバが存在しないのを示して。
- Management Operation - NotifyVmtpClient
- 管理操作--NotifyVmtpClient
- Timeouts
- タイムアウト
* Client Retransmission Timeout
* クライアント再送タイムアウト
The handling of these events is described in detail in the following subsections.
これらのイベントの取り扱いは以下の小区分で詳細に説明されます。
We first describe some conventions and procedures used in the description. A field of the received packet is indicated as (for example) p.Transaction, for the Transaction field. Optional portions of the code, such as the streaming handling code are prefixed with a "|" in the first column.
私たちは最初に、記述で用いられたいくつかのコンベンションと手順について説明します。 容認されたパケットの分野はTransaction分野への(例えば、)p.Transactionとして示されます。 「コードのストリーミングの取り扱いコードなどの任意の部分はaで前に置かれています」|「最初のコラム。」
MapClient( client )
Return pointer to CSR for client with the specified
clientId, else NULL.
MapClient(クライアント)は指定されたclientId、NULLをもっているほかのクライアントのために指針をCSRに返します。
SendPacketGroup( csr )
Send the packet group (Request, Response) according to
that specified by the CSR.
CSRによって指定されたそれに応じて、SendPacketGroup(csr)はパケットグループ(要求、Response)を送ります。
NotifyClient( csr, p, code )
Invoke the NotifyVmtpClient operation with the
parameters csr.RemoteClient, p.control,
NotifyClient(csr、p、コード)はパラメタcsr.RemoteClientとのNotifyVmtpClient操作、p.コントロールを呼び出します。
Cheriton [page 53]
Cheriton[53ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
csr.ReceiveSeqNumber, csr.RemoteTransaction and
csr.RemoteDelivery, and code. If csr is NULL, use
p.Client, p.Transaction and p.PacketDelivery instead and
the global ReceiveSequenceNumber, if supported. This
function simplifies the description over calling
NotifyVmtpClient directly in the procedural
specification below. (See Appendix III.)
csr.ReceiveSeqNumber、csr.RemoteTransaction、csr.RemoteDelivery、およびコード。 csrがNULLであるなら、サポートされるなら、p.Client、p.Transaction、代わりにp.PacketDelivery、およびグローバルなReceiveSequenceNumberを使用してください。 この機能は直接以下の手続き上の仕様にNotifyVmtpClientと呼ぶ上で記述を簡素化します。 (付録IIIを見てください。)
NotifyServer( csr, p, code )
Invoke the NotifyVmtpServer operation with the
parameters p.Server, csr.LocalClient,
csr.LocalTransaction, csr.LocalDelivery and code. Use
p.Client, P.Transaction and 0 for the clientId, transact
and delivery parameters if csr is NULL. This function
simplifies the description over calling NotifyVmtpServer
directly in the procedural specification below. (See
Appendix III.)
NotifyServer(csr、p、コード)はパラメタp.Server、csr.LocalClient、csr.LocalTransaction、csr.LocalDelivery、およびコードでNotifyVmtpServer操作を呼び出します。 csrがNULLであるならClient、P.Transaction、およびclientIdのための0が商取引するp.と配送パラメタを使用してください。 この機能は直接以下の手続き上の仕様にNotifyVmtpServerと呼ぶ上で記述を簡素化します。 (付録IIIを見てください。)
DGMset(p) True if DGM bit set in packet (or csr) else False.
(Similar functions are used for other bits.)
DGMset(p)、DGMが噛み付いたなら、本当に、パケット(または、csr)のほかのFalseにセットしてください。 (同様の機能は他のビットに使用されます。)
Timeout( csr, timeperiod, func )
Set or reset timer on csr record for timeperiod later
and invoke func if the timeout expires.
タイムアウト(csr、timeperiod、func)がセットしたか、csrの上のリセットタイマは、後でtimeperiodのために記録して、タイムアウトが期限が切れるなら、funcを呼び出します。
4.6. Client User-invoked Events
4.6. クライアントのユーザによって呼び出されたイベント
A user event occurs when a VMTP user application invokes one of the VMTP interface procedures.
VMTPユーザアプリケーションがVMTPインタフェース手順の1つを呼び出すとき、ユーザイベントは起こります。
4.6.1. Send
4.6.1. 発信してください。
Send( mcb, timeout, segptr, segsize )
map to main CSR for this client.
increment csr.LocalTransaction
Init csr and check parameters and segment if any.
Set SDA if sending appended data.
Flush queued replies from previous transaction, if any.
if local non-group server then
deliver locally
await response
return
if GroupId(server) then
Check for and deliver to local members.
if CRE request and non-group local CR entity then
このクライアントのために主なCSRに地図を送ってください(mcb、タイムアウト、segptrはsegsizeされます)。csr.LocalTransaction Init csrを増加してください、そして、もしあればパラメタとセグメントをチェックしてください。 送付がデータを追加したなら、SDAを設定してください。 そして、前のトランザクションから列に並ばせられた回答を洗い流してくださいといって、次に、ローカルの非グループサーバが局所的に配送されるならもしあれば、次に、GroupId(サーバ)Checkであるなら応答リターンを待ってください、地元会員に配送してください、そしてCRE要求と非グループの地方のCR実体です。
Cheriton [page 54]
Cheriton[54ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
await response
return
endif
set MDG if member of this group.
endif
clear csr.RetransCount
set csr.TransmissionMask
set csr.TimeLimit to timeout
set csr.HostAddr for csr.Server
SendPacketGroup( csr )
if DGMset(csr) then
return
endif
set csr.State to AwaitingResponse
Timeout( rootcsr, TC1(csr.Server), LocalClientTimeout )
return
end Send
このグループのメンバーであるなら応答リターンendifセットMDGを待ってください。AwaitingResponse Timeout(rootcsr、TC1(csr.Server)、LocalClientTimeout)へのDGMset(csr)の当時のリターンendifセットcsr.Stateが終わりのSendを返すなら、endifの明確なcsr.RetransCountセットcsr.TransmissionMaskはcsr.Server SendPacketGroup(csr)のためにタイムアウトセットcsr.HostAddrにcsr.TimeLimitを設定します。
Notes:
注意:
1. Normally, the HostAddr is extracted from the ServerHost
cache, which maps server entity identifiers to host
addresses. However, on cache miss, the client first queries
the network using the ProbeEntity operation, as specified in
Appendix III, determining the host address from the Response.
The ProbeEntity operation is handled as a separate message
transaction by the Client.
1. 通常、HostAddrはServerHostキャッシュからホスト・アドレスまで抽出されます。(キャッシュはサーバエンティティ識別名を写像します)。 しかしながら、キャッシュミスのときに、クライアントは最初にProbeEntity操作を使用することでネットワークについて質問します、Appendix IIIで指定されるように、Responseからのホスト・アドレスを決定して。 ProbeEntity操作は別々のメッセージトランザクションとしてClientによって扱われます。
The stream interface incorporates a parameter to pass a responseHandler procedure that is invoked when the message transaction completes.
ストリームインタフェースは呼び出されるresponseHandler手順にいつを通過するかパラメタを取り入れます。メッセージトランザクションは完成します。
StreamSend( mcb, timeout, segptr, segsize, responseHandler )
map to main CSR for this client.
| Allocate a new csr if root in use.
| lastcsr := First csr for last request.
| if STIset(lastcsr)
| csr.LocalTransaction := lastcsr.LocalTransaction + 256
| else
| csr.LocalTransaction := lastcsr.LocalTransaction + 1
Init csr and check parameters and segment if any.
. . . ( rest is the same as for the normal Send)
このクライアントのための主なCSRへのStreamSend(responseHandler、mcb、タイムアウト、segptrはsegsizeされる)地図。 | 使用中の根であるなら新しいcsrを割り当ててください。 | 最後の要求のためのlastcsr:=最初のcsr。 | STIset(lastcsr)です。| csr.LocalTransaction:=lastcsr.LocalTransaction+256| ほか| csr.LocalTransaction:=lastcsr.LocalTransaction+1Init csr、チェックパラメタ、およびセグメント、もしあれば。 . . . (休息は正常なSendのように同じです)
Notes:
注意:
1. Each outstanding message transaction is represented by a CSR
queued on the root CSR for this client entity. The root CSR
is used to handle timeouts, etc. On timeout, the last packet
1. それぞれの傑出しているメッセージトランザクションはこのクライアント実体のために根のCSRに列に並ばせられたCSRによって表されます。 根のCSRは、タイムアウトなどを扱うのに使用されます。 タイムアウト、最後のパケットに関して
Cheriton [page 55]
Cheriton[55ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
from the last packet group is retransmitted (with or without
the segment data).
最後のパケットから、グループは再送されます(セグメントデータのあるなしにかかわらず)。
4.6.2. GetResponse
4.6.2. GetResponse
GetResponse( req, timeout, segptr, segsize )
csr := CurrentCSR;
if responses queued then return next response
(in req, segptr to max of segsize )
if timeout is zero then return KERNEL_TIMEOUT error
set state to AWAITING_RESPONSE
Timeout( csr, timeout, ReturnKernelTimeout );
end GetResponse
GetResponse(req、タイムアウト、segptrはsegsizeされる)csr:=CurrentCSR。 応答が列を作って、タイムアウトがAWAITING_RESPONSE Timeout(csr、タイムアウト、ReturnKernelTimeout)への当時のリターンKERNEL_TIMEOUT誤りセット状態でないなら次の応答(最大限にするためにreqであって、segptrなコネはsegsizeされる)を返してください。 終わりのGetResponse
Notes:
注意:
1. GetResponse is only used with multicast Requests, which is
the only case in which multiple (different) Responses should
be received.
1. GetResponseはマルチキャストRequestsと共に使用されるだけです。(Requestsは複数の(異なる)の応答が受けられるべきである唯一の場合です)。
2. A response must remain queued until the next message
transaction is invoked to filter out duplicates of this
response.
2. 応答は次のメッセージトランザクションがこの応答の写しを無視するために呼び出されるまで列に並ばせられたままで残らなければなりません。
3. If the response is incomplete (only relevant if a
multi-packet response), then the client may wait for the
response to be fully received, including issuing requests for
retransmission (using NotifyVmtpServer operations) before
returning the response.
3. 応答が不完全である、(関連するだけ、マルチパケット応答)、そして、応答が完全に受けられるのを待っていて、応答を返す前に「再-トランスミッション」(NotifyVmtpServer操作を使用する)を求める要求を出すのを含んでいるのがクライアントはそうするかもしれません。
4. As an optimization, a response may be stored in the CSR of
the client. In this case, the response must be transferred
to a separate buffer (for duplicate suppression) before
waiting for another response. Using this optimization, a
response buffer is not allocated in the common case of the
client receiving only one response.
4. 最適化として、応答はクライアントのCSRに保存されるかもしれません。 この場合、別の応答を待つ前に、別々のバッファ(写し抑圧のための)に応答を移さなければなりません。 この最適化を使用して、応答バッファは1つの応答だけを受けるクライアントのよくある例で割り当てられません。
4.7. Packet Arrival
4.7. パケット到着
In general, on packet reception, a packet is mapped to the client state record, decrypted if necessary using the key in the CSR. It then has its checksum verified and then is transformed to the right byte order. The packet is then processed fully relative to its packet function code. It is discarded immediately if it is addressed to a different domain than the domain(s) in which the receiving host participates.
一般に、パケットレセプションでは、パケットは必要なら、CSRでキーを使用することで解読された属国記録に写像されます。 それは、次に、確かめられたチェックサムを持って、次に、正しいバイトオーダーに変えられます。 そして、パケットはパケット機能コードに比例して完全に処理されます。 受信ホストが参加するドメインと異なったドメインに扱われるなら、それはすぐに、捨てられます。
Cheriton [page 56]
Cheriton[56ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
For each of the 2 packet types, we assume a procedure called with a pointer p to the VMTP packet and psize, the size of the packet in octets. Thus, generic packet reception is:
2人のパケットタイプ各人のために、私たちは指針pでVMTPパケットとpsize(八重奏における、パケットのサイズ)に呼ばれる手順を仮定します。 したがって、ジェネリックパケットレセプションは以下の通りです。
if not LocalDomain(p.Domain) then return;
そうでなければ、次に、LocalDomain(p.Domain)は戻ります。
csr := MapClient( p.Client )
csr:=MapClient(p.クライアント)
if csr is NULL then
HandleNoCsr( p, psize )
return
csrがNULLであるなら、HandleNoCsr(p、psize)は戻ります。
if Secure(p) then
if SecureVMTP not supported then
{ Assume a Request. }
if not Multicast(p) then
NotifyClient(NULL, p, SECURITY_NOT_SUPPORTED )
return
endif
| Decrypt( csr.Key, p, psize )
そしてSecure(p)がSecureVMTPであるならその時をサポートしなかった、Requestを仮定してください、そうでなければ、Multicast(p)の当時のNotifyClient(_SUPPORTEDではなく、NULL、p、SECURITY_)はendifに戻ります。| 解読します。(csr.Key、p、psize)
if p.Checksum not null then
if not VerifyChecksum(p, psize) then return;
if OppositeByteOrder(p) then ByteSwap( p, psize )
if psize not equal sizeof(VmtpHeader) + 4*p.Length then
NotifyClient(NULL, p, VMTP_ERROR )
return
Invoke Procedure[p.FuncCode]( csr, p, psize )
Discard packet and return
次に、まして、ヌルVerifyChecksum(p、psize)ではなく、p.Checksumであるなら、戻ってください。 OppositeByteOrder(p)の当時のByteSwap(p、psize)がpsizeであるならsizeof(VmtpHeader)+4*p.Lengthと等しくないなら、NotifyClient(NULL、p、VMTP_ERROR)リターンInvoke Procedure[p.FuncCode](csr、p、psize)はパケットを捨てて、戻ります。
Notes:
注意:
1. The Procedure[p.FuncCode] refers to one of the 2 procedures
corresponding to the two different packet types of VMTP,
Requests and Responses.
1. Procedure[p.FuncCode]はVMTP、Requests、およびResponsesの2つの異なったパケットタイプにおいて、対応する2つの手順の1つについて言及します。
2. In all the following descriptions, a packet is discarded on
"return" unless otherwise stated.
2. 以下のすべての記述では、別の方法で述べられない場合、パケットは「リターン」のときに捨てられます。
3. The procedure HandleNoCSR is a management routine that
allocates and initializes a CSR and processes the packet or
else sends an error indication to the sender of the packet.
This procedure is described in greater detail in Section
4.8.1.
3. 手順HandleNoCSRはパケットの送付者にCSRを割り当てて、初期化する管理ルーチンであり、パケットを処理するか、または誤り表示を送ります。 この手順はセクション4.8.1で詳細によりすばらしい説明されます。
Cheriton [page 57]
Cheriton[57ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
4.7.1. Response
4.7.1. 応答
This procedure handles incoming Response packets.
この手順は入って来るResponseパケットを扱います。
HandleResponse( csr, p, psize )
if not LocalClient( csr ) then
if Multicast then return
| if Migrated( p.Client ) then
| NotifyServer(csr, p ENTITY_MIGRATED )
| else
NotifyServer(csr, p, ENTITY_NOT_HERE )
return
endif
HandleResponse、そして、まして、そして(csr、p、psize)LocalClient(csr)はMulticastであるなら戻ります。| そしてMigrated(p.Client)です。| NotifyServer(csr、p ENTITY_MIGRATED)| ほかに、NotifyServer(_HEREではなく、csr、p、ENTITY_)はendifを返します。
if NSRset(p) then
if Streaming not supported then
NotifyServer(csr, p, STREAMING_NOT_SUPPORTED )
return STREAMED_RESPONSE
| Find csr corresponding to p.Transaction
| if none found then
| NotifyServer(csr, p, BAD_TRANSACTION_ID )
| return
else
if csr.LocalTransaction not equal p.Transaction then
NotifyServer(csr, p, BAD_TRANSACTION_ID )
return
endif
Locate reply buffer rb for this p.Server
if found then
if rb.State is not ReceivingResponse then
{ Duplicate }
if APGset(p) or NERset(p) then
{ Send Response to stop response packets. }
NotifyServer(csr, p, RESPONSE_DISCARDED )
endif
return
endif
{ rb.State is ReceivingRequest}
if new segment data then retain in CSR segment area.
if packetgroup not complete then
Timeout( rb, TC3(p.Server), LocalClientTimeout )
return;
endif
goto EndPacketGroup
endif
{ Otherwise, a new response message. }
Streamingが、その時NotifyServerが(_SUPPORTEDではなく、csr、p、STREAMING_)であるとサポートしなかったならそしてNSRset(p)がSTREAMED_RESPONSEを返すなら| csrがp.Transactionに対応していると確かめてください。| なにもその時を見つけなかったなら| NotifyServer(csr、p、BAD_TRANSACTION_ID)| 次に、APGset(p)かNERset(p)であるならrb.StateがReceivingResponseの当時の写しでないならその時見つけられるならcsr.LocalTransactionがこのp.Serverのためにp.Transactionの当時のNotifyServer(csr、p、BAD_TRANSACTION_ID)リターンendif Locate回答バッファrbと等しくないならほかに返す、Responseを送って、応答パケットを止めてください。 次に、新しいセグメントデータが中でCSRを保有するなら、領域を区分してください。NotifyServer(csr、p、RESPONSE_DISCARDED)endifリターンendif、rb.StateがReceivingRequestである、packetgroupに完全でないなら、Timeout(rb、TC3(p.Server)、LocalClientTimeout)は戻ります。 endif goto EndPacketGroup endifそうでなければ、新しい応答メッセージ。
Cheriton [page 58]
Cheriton[58ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
if (NSRset(p) or NERset(p)) and NoStreaming then
NotifyServer(csr, p, VMTP_ERROR )
return
| if NSRset(p) then
| { Check consecutive with previous packet group }
| Find last packet group CSR from p.Server.
| if p.Transaction not
| lastcsr.RemoteTransaction+1 mod 2**32 then
| { Out of order packet group }
| NotifyServer(csr, p, BAD_TRANSACTION_ID)
| return
| endif
| if lastcsr not completed then
| NotifyServer(lastcsr, p, RETRY )
| endif
| if CMG(lastcsr) then
| Add segment data to lastcsr Response
| Notify lastcsr with new packet group.
| Clear lastcsr.VerifyInterval
| else
| if lastcsr available then
| use it for this packet group
| else allocate and initialize new CSR
| Save message and segment data in new CSR area.
| endif
| else { First packet group }
Allocate and init reply buffer rb for this response.
if allocation fails then
NotifyServer(csr, p, BUSY )
return
Set rb.State to ReceivingResponse
Copy message and segment data to rb's segment area
and set rb.PacketDelivery to that delivered.
Save p.Server host address in ServerHost cache.
endif
if packetgroup not complete then
Timeout( rb, TS1(p.Client), LocalClientTimeout )
return;
endif
endPacketGroup:
{ We have received last packet in packet group. }
if APGset(p) then NotifyServer(csr, p, OK )
| if NERset(p) and CMGset(p) then
| Queue waiting for continuation packet group.
| Timeout( rb, TC2(rb.Server), LocalClientTimeout )
| return
| endif
(NSRset(p)かNERset(p))である、NoStreamingの当時のNotifyServer(csr、p、VMTP_ERROR)は戻ります。| そしてNSRset(p)です。| 前のパケットグループについて連続したチェック| p.Serverから最後のパケットグループCSRを見つけてください。| p.トランザクションです。| そしてlastcsr.RemoteTransaction+1モッズ2**32| 不適切なパケットグループ| NotifyServer(csr、p、BAD_TRANSACTION_ID)| リターン| endif| lastcsrがその時を完成しなかったなら| NotifyServer(lastcsr、p、RETRY)| endif| そしてCMG(lastcsr)です。| セグメントデータをlastcsr Responseに加えてください。| 新しいパケットグループと共にlastcsrに通知してください。 | 明確なlastcsr.VerifyInterval| ほか| その時、lastcsr利用可能| このパケットグループにそれを使用してください。| ほかに、新しいCSRを割り当てて、初期化してください。| 新しいCSR領域にメッセージとセグメントデータを保存してください。 | endif| ほかの最初のパケットグループは割り当てて. この応答の配分が当時のNotifyServer(csr、p、BUSY)リターンSet rb.StateにReceivingResponse Copyメッセージに失敗するか、そして、rbのセグメント領域へのセグメントデータとそれへのセットrb.PacketDeliveryのためのイニット回答バッファrbは提供しました。 packetgroupの完全でない当時のTimeoutが戻るなら(rb、TS1(p.Client)、LocalClientTimeout)、p.がServerHostキャッシュendifのServerホスト・アドレスであると保存してください。 endif endPacketGroup: 私たちがパケットグループで最後のパケットを受けた、APGset(p)の当時のNotifyServer(csr、OKなp)です。| NERset(p)とそしてCMGset(p)です。| 継続パケットグループを待って、列を作ってください。 | タイムアウト(rb、TC2(rb.Server)、LocalClientTimeout)| リターン| endif
Cheriton [page 59]
Cheriton[59ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
{ Deliver response message. }
Deliver response to Client, or queue as appropriate.
end HandleResponse
応答メッセージを提供してください。 Clientへの応答を提供するか、または適宜列を作ってください。HandleResponseを終わらせてください。
Notes:
注意:
1. The mechanism for handling streaming is optional and can be
replaced with the tests for use of streaming. Note that the
server should never stream at the Client unless the Client
has streamed at the Server or has used the STI control bit.
Otherwise, streamed Responses are a protocol error.
1. 取り扱いストリーミングのためのメカニズムを任意であり、ストリーミングの使用のためのテストに取り替えることができます。 ClientがServerを流れたか、またはSTIコントロールビットを使用していない場合サーバがClientを決して流れるべきでないことに注意してください。 さもなければ、流されたResponsesはプロトコル誤りです。
2. As an optimization, a Response can be stored into the CSR for
the Client rather than allocating a separate CSR for a
response buffer. However, if multiple responses are handled,
the code must be careful to perform duplicate detection on
the Response stored there as well as those queued. In
addition, GetResponse must create a queued version of this
Response before allowing it to be overwritten.
2. 最適化として、Clientのために応答バッファのために別々のCSRを割り当てるよりむしろCSRとしてResponseを保存できます。 しかしながら、複数の応答が扱われるなら、コードはそこにそれらが列を作ったのと同じくらいよく保存されたResponseに写し検出を実行するのに慎重であるに違いありません。 さらに、GetResponseはそれが上書きされるのを許容する前に、このResponseの列に並ばせられたバージョンを作成しなければなりません。
3. The handling of Group Responses has been omitted for brevity.
Basically, a Response is accepted if there has been a Request
received locally from the same Client and same Transaction
that has not been responded to. In this case, the Response
is delivered to the Server or queued.
3. Group Responsesの取り扱いは簡潔さのために省略されました。 基本的に、同じClientから局所的に受け取られたRequestと応じていない同じTransactionがあったなら、Responseを受け入れます。 この場合、ResponseはServerに提供されるか、または列に並ばせられます。
Cheriton [page 60]
Cheriton[60ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
4.8. Management Operations
4.8. 管理操作
VMTP uses management operations (invoked as remote procedure calls) to effectively acknowledge packet groups and request retransmissions. The following routine is invoked by the Client's management module on request from the Server.
VMTPは、事実上、パケットグループを承認して、「再-トランスミッション」を要求するのに、管理操作(遠隔手続き呼び出しとして、呼び出される)を使用します。 以下のルーチンはServerからの要求に応じてClientの管理モジュールで呼び出されます。
NotifyVmtpClient( clientId,ctrl,receiveSeqNumber,transact,delivery,code)
Get csr for clientId
if none then return
if RemoteClient( csr ) and not NotifyVmtpRemoteClient then
return
| else (for streaming)
| Find csr with same LocalTransaction as transact
| if csr is NULL then return
if csr.State not AwaitingResponse then return
if ctrl.PGcount then ack previous packet groups.
select on code
case OK:
Notify ack'ed segment blocks from delivery
Clear csr.RetransCount;
Timeout( csr, TC1(csr.Server), LocalClientTimeout )
return
case RETRY:
Set csr.TransmissionMask to missing segment blocks,
as specified by delivery
SendPacketGroup( csr )
Timeout( csr, TC1(csr.Server), LocalClientTimeout )
case RETRY_ALL
Set csr.TransmissionMask to retransmit all blocks.
SendPacketGroup( csr )
Timeout( csr, TC1(csr.Server), LocalClientTimeout )
| if streaming then
| Restart transmission of packet groups,
| starting from transact+1
return
case BUSY:
if csr.TimeLimit exceeded then
Set csr.Code to USER_TIMEOUT
return Response to application
return;
Set csr.TransmissionMask for full retransmission
Clear csr.RetransCount
Timeout( csr, TC1(csr.Server), LocalClientTimeout )
return
case ENTITY_MIGRATED:
Get new host address for entity
NotifyVmtpClient、(clientId(ctrl、receiveSeqNumber)が商取引する、配送、コード)、次に、次に、NotifyVmtpRemoteClientではなく、RemoteClient(csr)が戻るならなにも戻らないなら、clientIdのためにcsrを手に入れてください。| ほかです(ストリーミングのための)。| 同じLocalTransactionとcsrを見つける、商取引| csrがNULLであるなら次に、ctrl.PGcountの当時のack前のパケットが分類されるならAwaitingResponseではなく、csr.Stateが戻るなら戻ってください。コードケースの上でOKを選択してください: 配送Clear csr.RetransCountからack'edセグメントブロックに通知してください。 タイムアウト(csr、TC1(csr.Server)、LocalClientTimeout)リターンケースRETRY: なくなったセグメントへのセットcsr.TransmissionMaskは指定されるとして_すべてのブロックを再送する配送SendPacketGroup(csr)タイムアウト(csr、TC1(csr.Server)、LocalClientTimeout)ケースRETRYによるすべてのSet csr.TransmissionMaskを妨げます。 SendPacketGroup(csr)タイムアウト(csr、TC1(csr.Server)、LocalClientTimeout)| その時ストリーミング| パケットグループの送信を再開してください。| 始まり、+1 リターンケースBUSYを商取引してください: _csr.TimeLimitが当時のSet csr.CodeをUSERに超えていたなら、TIMEOUTはアプリケーションリターンにResponseを返します。 完全なretransmission Clear csr.RetransCount Timeout(csr、TC1(csr.Server)、LocalClientTimeout)リターンケースENTITY_MIGRATEDにcsr.TransmissionMaskを設定してください: 実体のための新しいホスト・アドレスを得てください。
Cheriton [page 61]
Cheriton[61ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
Set csr.TransmissionMask for full retransmission
Clear csr.RetransCount
SendPacketGroup( csr )
Timeout( csr, TC1(csr.Server), LocalClientTimeout )
return
完全なretransmission Clear csr.RetransCount SendPacketGroup(csr)タイムアウト(csr、TC1(csr.Server)、LocalClientTimeout)リターンにcsr.TransmissionMaskを設定してください。
case STREAMING_NOT_SUPPORTED:
Record that server does not support streaming
if CMG(csr) then forget this packet group
else resend Request as separate packet group.
return
default:
Set csr.Code to code
return Response to application
return;
endselect
end NotifyVmtpClient
_SUPPORTEDではなく、STREAMING_をケースに入れてください: 次に、CMG(csr)がほかにこのパケットグループを忘れるならサーバがストリーミングをサポートしないという記録は別々のパケットグループとしてRequestを再送します。デフォルトを返してください: csr.CodeにリターンResponseをアプリケーションリターンにコード化するように設定してください。 endselect終わりのNotifyVmtpClient
Notes:
注意:
1. The delivery parameter indicates the segment blocks received
by the Server. That is, a 1 bit in the i-th position
indicates that the i-th segment block in the segment data of
the Request was received. All subsequent NotifyVmtpClient
operations for this transaction should be set to acknowledge
a superset of the segment blocks in this packet. In
particular, the Client need not be prepared to retransmit the
segment data once it has been acknowledged by a Notify
operation.
1. 配送パラメタが、セグメントブロックが. すなわち、Serverによる噛み付かれた1を受け取ったのを示す、i、-、位置がそれを第示す、i、-、Requestに関するセグメントデータでのセグメントブロックを第受け取りました。 このトランザクションのためのすべてのその後のNotifyVmtpClient操作がこのパケットでのセグメントブロックのスーパーセットを承認するように設定されるべきです。 特に、ClientはそれがNotify操作でいったん承認されたとセグメントデータを再送するように準備される必要はありません。
4.8.1. HandleNoCSR
4.8.1. HandleNoCSR
HandleNoCSR is called when a packet arrives for which there is no CSR matching the client field of the packet.
パケットのクライアント分野に合っているCSRが全くないパケットが到着するとき、HandleNoCSRは呼ばれます。
HandleNoCSR( p, psize )
if Secure(p) then
if SecureVMTP not supported then
{ Assume a Request }
if not Multicast(p) then
NotifyClient(NULL,p,SECURITY_NOT_SUPPORTED)
return
endif
HandleRequestNoCSR( p, psize )
return
endif
SecureVMTPがその時をサポートしなかったならそしてSecure(p)がRequestを仮定するか、またはMulticast(p)の当時のNotifyClient(_SUPPORTEDではなく、NULL、p、SECURITY_)がendif HandleRequestNoCSR(p、psize)を返すなら、HandleNoCSR(p、psize)はendifを返します。
Cheriton [page 62]
Cheriton[62ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
if p.Checksum not null then
if not VerifyChecksum(p, psize) then return;
if OppositeByteOrder(p) then ByteSwap( p, psize )
if psize not equal sizeof(VmtpHeader) + 4*p.Length then
NotifyClient(NULL, p, VMTP_ERROR )
return
次に、まして、ヌルVerifyChecksum(p、psize)ではなく、p.Checksumであるなら、戻ってください。 OppositeByteOrder(p)の当時のByteSwap(p、psize)がpsizeであるならsizeof(VmtpHeader)+4*p.Lengthと等しくないなら、NotifyClient(NULL、p、VMTP_ERROR)は戻ります。
if p.FuncCode is Response then
| if Migrated( p.Client ) then
| NotifyServer(csr, p ENTITY_MIGRATED )
| else
NotifyServer(csr, p, NONEXISTENT_ENTITY )
return
endif
その時p.FuncCodeがResponseであるなら| そしてMigrated(p.Client)です。| NotifyServer(csr、p ENTITY_MIGRATED)| ほかに、NotifyServer(csr、p、NONEXISTENT_ENTITY)はendifを返します。
if p.FuncCode is Request then
HandleRequestNoCSR( p, psize )
return
end HandleNoCSR
p.FuncCodeがRequestであるなら、HandleRequestNoCSR(p、psize)は終わりのHandleNoCSRを返します。
Notes:
注意:
1. The node need only check to see if the client entity has
migrated if in fact it supports migration of entities.
1. ノードは、事実上、実体の移行をサポートするならクライアント実体が移行したかどうか確認するためにはチェックするだけでよいです。
2. The procedure HandleRequestNoCSR is specified in Section
5.8.1. In the minimal client version, it need only handle
Probe requests and can do so directly without allocating a
new CSR.
2. 手順HandleRequestNoCSRはセクション5.8.1で指定されます。 最小量のクライアントバージョンでは、直接新しいCSRを割り当てないで、それが、ハンドルProbe要求だけを必要として、そうできます。
Cheriton [page 63]
Cheriton[63ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
4.9. Timeouts
4.9. タイムアウト
A client with a message transaction in progress has a single timer corresponding to the first unacknowledged request message. (In the absence of streaming, this request is also the last request sent.) This timeout is handled as follows:
メッセージトランザクションが進行しているクライアントは単一のタイマを最初の不承認の要求メッセージに対応するようにします。 (ストリーミングが不在のとき、また、この要求は送られた最後の要求です。) このタイムアウトは以下の通り扱われます:
LocalClientTimeout( csr )
select on csr.State
case AwaitingResponse:
if csr.RetransCount > MaxRetrans(csr.Server) then
terminate Client's message transactions up to
and including the current message transaction.
set return code to KERNEL_TIMEOUT
return
increment csr.RetransCount
Resend current packet group with APG set.
Timeout( csr, TC2(csr.Server), LocalClientTimeout )
return
case ReceivingResponse:
if DGMset(csr) or csr.RetransCount > Max then
if MDMset(csr) then
Set MCB.MsgDeliveryMask to blocks received.
else
Set csr.Code to BAD_REPLY_SEGMENT
return to user Client
endif
increment csr.RetransCount
NotifyServer with RETRY
Timeout( csr, TC3(csr.Server), LocalClientTimeout )
return
end select
end LocalClientTimeout
LocalClientTimeout(csr)はcsr.StateケースAwaitingResponseで以下を選択します。 csr.RetransCount>MaxRetrans(csr.Server)であるなら、現在のメッセージトランザクションを含めてClientのメッセージトランザクションを終えてください。APGがあるKERNEL_TIMEOUTリターン増分のcsr.RetransCount Resend現在のパケットグループへのセット復帰コードはセットしました。 タイムアウト(csr、TC2(csr.Server)、LocalClientTimeout)リターンケースReceivingResponse: ブロックへのSet MCB.MsgDeliveryMaskはDGMset(csr)かcsr.RetransCount>マックスであるならMDMset(csr)であるなら受信しました。SEGMENTがRETRY Timeout(csr、TC3(csr.Server)、LocalClientTimeout)リターンと共にユーザClient endif増分のcsr.RetransCount NotifyServerに返すBAD_REPLY_へのほかのSet csr.Codeは選んだ終わりのLocalClientTimeoutを終わらせます。
Notes:
注意:
1. A Client can only request retransmission of a Response if the
Response is not idempotent. If idempotent, it must
retransmit the Request. The Server should generally support
the MsgDeliveryMask for Requests that it treats as idempotent
and that require multi-packet Responses. Otherwise, there is
no selective retransmission for idempotent message
transactions.
1. ClientはResponseがベキ等元でない場合にだけResponseの「再-トランスミッション」を要求できます。 ベキ等元であるなら、それはRequestを再送しなければなりません。 ベキ等元とそれがマルチパケットResponsesを必要とするとき、一般に、Serverはそれが扱うRequestsのためにMsgDeliveryMaskをサポートするはずです。 さもなければ、ベキ等元メッセージトランザクションのためのどんな選択している「再-トランスミッション」もありません。
2. The current packet group is the last one transmitted. Thus,
with streaming, there may be several packet groups
outstanding that precede the current packet group.
2. 現在のパケットグループはあるものが伝えた最終です。 したがって、現在のパケットグループに先行する未払いのいくつかのパケットグループがストリーミングと共にあるかもしれません。
Cheriton [page 64]
Cheriton[64ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
3. The Request packet group should be retransmitted without the
segment data, resulting in a single short packet in the
retransmission. The Server must then send a
NotifyVmtpClient with a RETRY or RETRY_ALL code to get the
segment data transmitted as needed. This strategy minimizes
the overhead on the network and the server(s) for
retransmissions.
3. 「再-トランスミッション」で単一の脆いパケットをもたらして、Requestパケットグループはセグメントデータなしで再送されるべきです。 そして、Serverは、必要に応じてセグメントデータを送らせるために_すべてのコードをRETRYかRETRYとNotifyVmtpClientに送らなければなりません。 この戦略は「再-トランスミッション」のためのネットワークとサーバでオーバーヘッドを最小にします。
Cheriton [page 65]
Cheriton[65ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
5. Server Protocol Operation
5. サーバプロトコル操作
This section describes the operation of the server portion of the protocol in terms of the procedures for handling VMTP user events, packet reception events and timeout events. Each server is assumed to implement the client procedures described in the previous chapter. (This is not strictly necessary but it simplifies the exposition.)
このセクションは取り扱いVMTPユーザイベント、パケットレセプションイベント、およびタイムアウトイベントのために手順でプロトコルのサーバ部分の操作について説明します。 各サーバが前の章で説明されたクライアント手順を実装すると思われます。 (これは厳密に必要ではありませんが、それは博覧会を簡素化します。)
5.1. Remote Client State Record Fields
5.1. 属国の遠く離れた記録分野
The CSR for a server is extended with the following fields, in addition to the ones listed for the client version.
サーバのためのCSRは以下の分野で広げられます、クライアントバージョンのために記載されたものに加えて。
RemoteClient Identifier for remote client that sent the Request that
this CSR is handling.
このCSRが扱っているRequestを送ったリモートクライアントのためのRemoteClient Identifier。
RemoteClientLink
Link to next CSR hashing to same hash index in the
ClientMap.
同じハッシュへの次のCSRの論じ尽くすことへのRemoteClientLink LinkはClientMapで索引をつけます。
RemoteTransaction
Transaction identifier for Request from remote client.
リモートクライアントからのRequestのためのRemoteTransaction Transaction識別子。
RemoteDelivery The segment blocks received so far as part of a Request
or yet to be acknowledged as part of a Response.
RemoteDelivery、セグメントブロックは今までのところ、RequestかResponseの一部としてまだ承認されていない一部を受け取りました。
VerifyInterval Time interval since there was confirmation that the
remote Client was still valid.
リモートClientがそうであった確認があって、VerifyInterval Time間隔は有効な状態で静まります。
RemotePrincipal Account identification, possibly including key and key
timeout for secure communication.
ことによると安全なコミュニケーションのための主要で主要なタイムアウトを含むRemotePrincipal Account識別。
5.2. Remote Client Protocol States
5.2. 遠く離れたクライアントプロトコル州
A CSR in the server end is in one of the following states.
サーバ終わりのCSRが以下の州の1つにあります。
AwaitingRequest Waiting for a Request packet group. It may be marked as
waiting on a specific Client, or on any Client.
RequestパケットのためのAwaitingRequest Waitingは分類します。 それは特定のClientで待っているか、どんなClientの上にもマークされるかもしれません。
ReceivingRequest
Waiting to receive additional Request packets in a
multi-packet group Request.
マルチパケットで追加Requestパケットを受けるReceivingRequest WaitingはRequestを分類します。
Responded The Response has been sent and the CSR is timing out,
providing duplicate suppression and retransmission (if
反応して、Responseを送って、写し抑圧と「再-トランスミッション」を提供して、CSRが外で調節している、(
Cheriton [page 66]
Cheriton[66ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
the Response was not idempotent).
Responseがベキ等元でなかった、)
ResponseDiscarded
Response has been acknowledged or has timed out so
cannot be retransmitted. However, duplicates are still
filtered and CSR can be reused for new message
transaction.
ResponseDiscarded Responseが承認されたか、または外で調節したので、再送できません。 しかしながら、まだ写しをフィルターにかけています、そして、新しいメッセージトランザクションのためにCSRを再利用できます。
Processing Executing on behalf of the Client.
Clientを代表してExecutingを処理します。
Forwarded The message transaction has been forwarded to another
Server that is to respond directly to the Client.
進めて、直接Clientに応じることになっている別のServerにメッセージトランザクションを送りました。
5.3. State Transition Diagrams
5.3. 状態遷移ダイヤグラム
The CSR state transitions in the server are illustrated in Figure 5-1. The CSR generally starts in the AwaitingRequest state. On receipt of a Request, the Server either has an up-to-date CSR for the Client or else it sends a Probe request (as a separate VMTP message transaction) to the VMTP management module associated with the Client. In the latter case, the processing of the Request is delayed until a Response to the Probe request is received. At that time, the CSR information is brought up to date and the Request is processed. If the Request is a single-packet request, the CSR is then set in the Processing state to handle the request. Otherwise (a multi-packet Request), the CSR is put into the ReceivingResponse state, waiting to receive subsequent Request packets that constitute the Request message. It exits the ReceivingRequest state on timeout or on receiving the last Request packet. In the former case, the request is delivered with an indication of the portion received, using the MsgDelivery field if MDM is set. After request processing is complete, either the Response is sent and the CSR enters the Responded state or the message transaction is forwarded and the CSR enters the Forwarded state.
サーバにおけるCSR状態遷移は図5-1で例証されます。 一般に、CSRはAwaitingRequest状態で始まります。 Requestを受け取り次第、ServerにはClientのための最新のCSRがあるか、またはそれはProbe要求(別々のVMTPメッセージトランザクションとしての)をClientに関連しているVMTP管理モジュールに送ります。 後者の場合では、Probe要求へのResponseが受け取られているまで、Requestの処理は遅れます。 その時、CSR情報は最新の状態にされます、そして、Requestは処理されます。 そして、Requestが単一のパケット要求であるなら、CSRはProcessing状態で要求を扱うように用意ができています。 そうでなければ、(マルチパケットRequest)、ReceivingResponse状態にCSRを入れます、Requestメッセージを構成するその後のRequestパケットを受けるのを待っていて。 タイムアウトか最後のRequestパケットを受けるとき、それはReceivingRequest状態を出ます。 前の場合では、要求は部分のしるしを受けていて提供されます、MDMが設定されるならMsgDelivery分野を使用して。 要求処理が完全になった後に、Responseを送ります、そして、メッセージトランザクションを送ります、そして、CSRはResponded状態に入るか、またはCSRがForwarded状態に入れます。
In the Responded state, if the Response is not marked as idempotent, the Response is retransmitted on receipt of a retransmission of the corresponding Request, on receipt of a NotifyVmtpServer operation requesting retransmission or on timeout at which time APG is set, requesting an acknowledgment from the Client. The Response is retransmitted some maximum number of times at which time the Response is discarded and the CSR is marked accordingly. If a Request or a NotifyVmtpServer operation is received expecting retransmission of the Response after the CSR has entered the ResponseDiscarded state, a NotifyVmtpClient operation is sent back (or invoked in the Client management module) indicating that the response was discarded unless the Request was multicast, in which case no action is taken. After a
Responded状態では、Responseがベキ等元としてマークされないなら、Responseは対応するRequestの「再-トランスミッション」を受け取り次第「再-トランスミッション」を要求するNotifyVmtpServer操作を受け取り次第時間APGが用意ができているタイムアウトの上で再送されます、Clientから承認を要求して。 Responseによる再送されて、Responseが捨てられる回とCSRの何らかの最大数がそれに従って、マークされるということです。 CSRがResponseDiscarded状態に入った後にRequestかNotifyVmtpServer操作がResponseの容認されたおめでたの予定の「再-トランスミッション」であるなら、応答がRequestがマルチキャストでなかったなら捨てられて、その場合、行動が全く取られないのを示しながら、NotifyVmtpClient操作は返送されます(または、Client管理モジュールで、呼び出されます)。 aの後に
Cheriton [page 67]
Cheriton[67ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
(Retransmit Forwarded Request and NotifyVmtpClient)
Request/
Ack/
+Timeout+
V |
+-|-------^-+
| |
+-Time-| Forwarded |<-------------+
| out +-----------+ |
| |
| (Retransmit Response) |
| Request |
V Ack |
| +-Timeout-+ |
| V | |
+---------+ Ack/ +|---------^+ |
+-Time-|Response |<-Timeout--| Responded | |
| out |Discarded| +----^------+ |
| +---------+ | |
| +------------+ | |
| | |->-Send Response-+ |
| | |->-forward Request--------+
+->| Processing |<----------------------+
| | |<----------------+ |
| | |<---| | |
| +-|--------^-+ | Last |
| Receive | | Request |
| | Timeout Single Packet |
| | | Packet | Timeout
| | | Request ^ ^
| | | ^ +|-----|--+
| +-V--------|-+ | |Receiving|<-+Time
+->| Awaiting |->--+->Request->| Request |--+ out
| Request | | (multi- +---------+
+------|-----+ ^ packet)
Request |
| Response
Send Probe to
| Probe
+---V----+ |
|Awaiting| ^
|Response|-->--+
|to Probe|
+--------+
(転送された要求とNotifyVmtpClientを再送します) Request/ Ack/+タイムアウト+V| +-|-------^-+ | | +時間、-| 転送されます。| <、-、-、-、-、-、-、-、-、-、-、-、--+ | +から-----------+ | | | | (応答を再送します) | | 要求| V Ack| | +タイムアウト+| | V| | +---------+ Ack/+|---------^+ | +時間、-|応答| <、-タイムアウト--| 応じます。| | | アウト|捨てられます。| +----^------+ | | +---------+ | | | +------------+ | | | | |、-、>、-応答+を送ってください。| | | |、-、>、-前進のRequest--------+ +->| 処理| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--+ | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--+ | | | | <、-、--、|、|、|、| +-|--------^-+ | 最終| | 受信してください。| | 要求| | | タイムアウトの単一のパケット| | | | パケット| タイムアウト| | | ^ ^を要求してください。| | | ^ +|-----|--+ | +V--------|-+ | |受信します。| <、-+時間+>| 待ちます。|、-、>、--+->が要求する、->| 要求|--+ 外| 要求| | (multi- +---------+ +------|-----+ ^ packet) 要求| | 応答は探測装置を送ります。| 徹底的調査+---V----+ | |待ちます。| ^ |応答|、-->--+ |調べるために| +--------+
Figure 5-1: Remote Client State Transitions
図5-1: リモート属国変遷
timeout corresponding to the time required to filter out duplicates, the
時間に対応するタイムアウトが写しを無視するのが必要です。
Cheriton [page 68]
Cheriton[68ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
CSR returns either to the AwaitingRequest state or to the Processing state. Note that "Ack" refers to acknowledgment by a Notify operation.
CSRはAwaitingRequest州、または、Processing状態に戻ります。 "Ack"がNotify操作で承認を示すことに注意してください。
A Request that is forwarded leaves the CSR in the Forwarded state. In the Forwarded state, the forwarded Request is retransmitted periodically, expecting NotifyRemoteClient operations back from the Server to which the Request was forwarded, analogous to the Client behavior in the AwaitingResponse state. In this state, a NotifyRemoteClient from this Server acknowledges the Request or asks that it be retransmitted or reports an error. A retransmission of the Request from the Client causes a NotifyVmtpClient to be returned to the Client if APG is set. The CSR leaves the Forwarded state after timing out in the absence of NotifyRemoteClient operations from the forward Server or on receipt of a NotifyRemoteClient operation indicating the forward Server has sent a Response and received an acknowledgement. It then enters the ResponseDiscarded state.
進められるRequestはForwardedのCSRを状態に発ちます。 Forwarded状態では、進められたRequestは定期的に再送されます、Requestが送って戻されたServerからNotifyRemoteClient操作を予想して、AwaitingResponse状態のClientの振舞いに類似しています。 この状態では、このServerからのNotifyRemoteClientはRequestを承認するか、それが再送されるように頼むか、または誤りを報告します。 APGが用意ができているなら、ClientからのRequestの「再-トランスミッション」はNotifyVmtpClientをClientに返させます。 前進のServerからのNotifyRemoteClient操作がないとき外か前進のServerを示すNotifyRemoteClient操作を受け取り次第タイミングがResponseを送って、承認を受けた後にCSRはForwardedを状態に発ちます。 そして、それはResponseDiscarded状態に入ります。
Receipt of a new Request from the same Client aborts the current transaction, independent of its state, and initiates a new transaction unless the new Request is part of a run of message transactions. If it is part of a run of message transactions, the handling follows the state diagram except the new Request is not Processed until there has been a response sent to the previous transaction.
同じClientからの新しいRequestの領収書は、状態の如何にかかわらず経常取引を中止して、新しいRequestがメッセージトランザクションの走行の一部でないなら新しいトランザクションを開始します。 メッセージトランザクションの走行の一部、取り扱いが状態に続くということであるなら、前のトランザクションに送られた応答があるまで、新しいRequest以外のダイヤグラムはProcessedではありません。
5.4. User Interface
5.4. ユーザーインタフェース
The RPC or user interface to VMTP is implementation-dependent and may use systems calls, functions or some other mechanism. The list of requests that follow is intended to suggest the basic functionality that should be available.
VMTPへのRPCかユーザーインタフェースが、実装依存していて、システム呼び出し、機能またはある他のメカニズムを使用するかもしれません。 続く要求のリストが利用可能であるべき基本機能を示すことを意図します。
AcceptMessage( reqmcb, segptr, segsize, client, transid, timeout )
Accept a new Request message in the specified reqmcb
area, placing the segment data, if any, in the area
described by segptr and segsize. This returns the
Server in the entityId field of the reqmcb and actual
segment size in the segsize parameters. It also returns
the Client and Transaction for this message transaction
in the corresponding parameters. This procedure
supports message semantics for request processing. When
a server process executes this call, it blocks until a
Request message has been queued for the server.
AcceptMessage returns after the specified timeout period
if a message has not been received by that time.
AcceptMessageはもしあればsegptrによって説明された領域にセグメントデータを置いて、指定されたreqmcb領域で新しいRequestメッセージを受け入れて(reqmcb、segptrがsegsizeされます、クライアント、transid、タイムアウト)、segsizeします。 これがreqmcbと実際のセグメントのentityId分野のServerにサイズを返す、segsizeする、パラメタ。 また、それは対応するパラメタのこのメッセージトランザクションのためにClientとTransactionを返します。 この手順は要求処理のためにメッセージ意味論をサポートします。 サーバがいつ処理されるかがこの呼び出しを実行して、Requestメッセージがサーバのために列に並ばせられるまで、それはブロックです。メッセージがその時までに受け取られていないなら、AcceptMessageは指定されたタイムアウト時間の後に戻ります。
RespondMessage( responsemcb, client, transid, segptr )
RespondMessage(responsemcb、クライアント、transid、segptr)
Cheriton [page 69]
Cheriton[69ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
Respond to the client with the specified response
message and segment, again with message semantics.
指定された応答メッセージとセグメントと、再びメッセージ意味論でクライアントに応じてください。
RespondCall( responsemcb, segptr )
Respond to the client with the specified response
message and segment, with remote procedure call
semantics. This procedure does not return. The
lightweight process that executes this procedure is
matched to a stack, program counter, segment area and
priority from the information provided in a
ModifyService call, as specified in Appendix III.
RespondCall(responsemcb、segptr)は指定された応答メッセージとセグメント、遠隔手続き呼び出し意味論でクライアントに応じます。 この手順は戻りません。 この手順を実行する軽量のプロセスはModifyService呼び出しに提供された情報からのスタック、プログラムカウンタ、セグメント領域、および優先に合わせられています、Appendix IIIで指定されるように。
ForwardMessage( requestmcb, transid, segptr, segsize, forwardserver )
Forward the client to the specified forwardserver with
the request specified in mcb.
要求がmcbで指定されている状態で、ForwardMessageは指定されたforwardserverにクライアントを送ります(requestmcbに、transidに、segptrにより多くのforwardserverにsegsizeします)。
ForwardCall( requestmcb, segptr, segsize, forwardserver )
Forward the client transaction to the specified
forwardserver with the request specified by requestmcb.
This procedure does not return.
要求がrequestmcbによって指定されている状態で、ForwardCall(requestmcb、segptrはより多くのforwardserverにsegsizeされる)はクライアントトランザクションを指定されたforwardserverに送ります。 この手順は戻りません。
GetRemoteClientId()
Return the entityId for the remote client on whose
behave the process is executing. This is only
applicable in the procedure call model of request
handling.
プロセスを振る舞わせてください。GetRemoteClientId()がリモートクライアントにとって、オンなentityIdを返す、だれのもの、実行しています。 これは単に要求取り扱いの手順呼び出しモデルで適切です。
GetForwarder( client )
Return the entity that forwarded this Request, if any.
GetForwarder(クライアント)はもしあればこのRequestを進めた実体を返します。
GetProcess( client )
Return an identifier for the process associated with
this client entity-id.
GetProcess(クライアント)はこのクライアント実体イドに関連しているプロセスのための識別子を返します。
GetPrincipal( client )
Return the principal associated with this client
entity-id.
GetPrincipal(クライアント)はこのクライアント実体イドに関連している主体を返します。
5.5. Event Processing
5.5. イベント処理
The following events may occur in VMTP servers.
以下のイベントはVMTPサーバで起こるかもしれません。
- User Requests
- ユーザ要求
* Receive
* 受信してください。
Cheriton [page 70]
Cheriton[70ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
* Respond
* 応じてください。
* Forward
* 転送
* GetForwarder
* GetForwarder
* GetProcess
* GetProcess
* GetPrincipal
* GetPrincipal
- Packet Arrival
- パケット到着
* Request Packet
* リクエスト・パケット
- Management Operations
- 管理操作
* NotifyVmtpServer
* NotifyVmtpServer
- Timeouts
- タイムアウト
* Client State Record Timeout
* 属国記録タイムアウト
The handling of these events is described in detail in the following subsections. The conventions of the previous chapter are followed, including the use of the various subroutines in the description.
これらのイベントの取り扱いは以下の小区分で詳細に説明されます。 記述における様々なサブルーチンの使用を含んでいて、前の章のコンベンションは続かれています。
5.6. Server User-invoked Events
5.6. サーバーのユーザによって呼び出されたイベント
A user event occurs when a VMTP server invokes one of the VMTP interface procedures.
VMTPサーバがVMTPインタフェース手順の1つを呼び出すとき、ユーザイベントは起こります。
5.6.1. Receive
5.6.1. 受信してください。
AcceptMessage(reqmcb, segptr, segsize, client, transid, timeout)
Locate server's request queue.
if request is queued then
Remember CSR associated with this Request.
return Request in reqmcb, segptr and segsize
and client and transaction id.
Wait on server's request queue for next request
up time timeout seconds.
end ReceiveCall
列を作ってください。AcceptMessageは要求が列に並ばせられるなら、Remember CSRがRequest reqmcb、segptrのリターンRequestをこれに関連づけて、segsizeするというサーバの要求、クライアント、およびトランザクションイドの場所を見つけます(reqmcb、segptrはsegsizeされます、クライアント、transid、タイムアウト)。 次の要求のためのサーバの要求待ち行列で時間タイムアウト秒終わりのReceiveCallに待ってください。
Notes:
注意:
Cheriton [page 71]
Cheriton[71ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
1. If a multi-packet Request is partially received at the time
of the AcceptMessage, the process waits until it completes.
1. AcceptMessage時点でマルチパケットRequestを部分的に受け取るなら、それまでの待ちが完了する適性検査を受けます。
2. The behavior of a process accepting a Request as a
lightweight thread is similar except that the process
executes using the Request data logically as part of the
requesting Client process.
2. Clientが処理する要求の一部としてRequestデータを論理的に使用するプロセスが実行する軽量のスレッドとして申し込みに応じるのが同様であるプロセスの振舞い。
5.6.2. Respond
5.6.2. 応じてください。
RespondCall is described as one case of the Respond transmission procedure; RespondMessage is similar.
RespondCallは1つのケースのRespondトランスミッション手順として記述されています。 RespondMessageは同様です。
RespondCall( responsemcb, responsesegptr )
Locate csr for this client.
Check segment data accessible, if any
if local client then
Handle locally
return
endif
if responsemcb.Code is RESPONSE_DISCARDED then
Mark as RESPONSE_DISCARDED
return
SendPacketGroup( csr )
set csr.State to Responded.
if DGM reply then { Idempotent }
release segment data
Timeout( csr, TS4(csr.Client), FreeCsr );
else { Await acknowledgement or new Request else ask for ack. }
Timeout( csr, TS5(csr.Client), RemoteClientTimeout )
end RespondCall
RespondCall(responsemcb、responsesegptr)はこのクライアントのためのcsrの場所を見つけます。 アクセスしやすい状態でセグメントデータをチェックしてください、地方のクライアント当時のHandleがresponsemcb.CodeがRESPONSE_DISCARDEDであるなら局所的にendifを返すならRESPONSE_DISCARDEDがSendPacketGroup(csr)を返すのでマークがRespondedにcsr.Stateをいくらか設定したなら。DGMが返答するなら、ベキ等元はセグメントデータTimeout(csr、TS4(csr.Client)、FreeCsr)をリリースします。 ほか、承認を待ってください。さもないと、新しいほかのRequestはackを求めます。 タイムアウト(csr、TS5(csr.Client)、RemoteClientTimeout)終わりのRespondCall
Notes:
注意:
1. RespondMessage is similar except the Server process must be
synchronized with the release of the segment data (if any).
1. RespondMessageは同様です、そして、Serverプロセスはセグメントデータ(もしあれば)のリリースに連動しなければなりません。
2. The non-idempotent Response with segment data is sent first
without a request for an acknowledgement. The Response is
retransmitted after time TS5(client) if no acknowledgment or
new Request is received from the client in the meantime. At
this point, the APG bit is sent.
2. 承認を求める最初に要求なしでセグメントデータがある非ベキ等元Responseを送ります。 差し当たりクライアントからどんな承認も新しいRequestも受けないなら、時間TS5(クライアント)の後にResponseを再送します。 ここに、APGビットを送ります。
3. The MCB of the Response is buffered in the client CSR, which
remains for TS4 seconds, sufficient to filter old duplicates.
The segment data (if any) must be retained intact until: (1)
3. ResponseのMCBはクライアントCSRでバッファリングされます、古い写しをフィルターにかけるために、十分です。(CSRはTS4秒の間、残っています)。 以下まで完全な状態でセグメントデータ(もしあれば)を保有しなければなりません。 (1)
Cheriton [page 72]
Cheriton[72ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
after transmission if idempotent or (2) after acknowledged or
timeout has occurred if not idempotent. Techniques such as
copy-on-write might be used to keep a copy of the Response
segment data without incurring the cost of a copy.
後に、トランスミッションはベキ等元、後に承認された(2)またはタイムアウトであり、ベキ等元でないなら起こりました。 テクニック、コピーする、書く、コピーの費用を被らないでResponseセグメントデータの写しを取っておくのに使用されるかもしれません。
5.6.3. Forward
5.6.3. 転送
Forwarding is logically initiating a new message transaction between the Server (now acting as a Client) and the server to which the Request is forwarded. When the second server returns a Response, the same Response is immediately returned to the Client. The forwarding support in VMTP preserves these semantics while providing some performance optimizations in some cases.
推進はServer(現在、Clientとして機能する)とRequestが送られるサーバの間の新しいメッセージトランザクションを論理的に開始しています。 2番目のサーバがすぐにResponseを返すとき、同じResponseをClientに返します。 VMTPでの推進サポートはいくつかの場合、いくつかのパフォーマンスの最適化を提供している間、これらの意味論を保存します。
ForwardCall( req, segptr, segsize, forwardserver )
Locate csr for this client.
Check segment data accessible, if any
ForwardCall(req、segptrはより多くのforwardserverにsegsizeされる)はこのクライアントのためのcsrの場所を見つけます。 もしあればアクセスしやすい状態でセグメントデータをチェックしてください。
if local client or Request was multicast or secure
or csr.ForwardCount == 15 then
Handle as a new Send operation
return
if forwardserver is local then
Handle locally
return
Set csr.funccode to Request
Increment csr.ForwardCount
Set csr.State to Responded
SendPacketGroup( csr ) { To ForwardServer }
Timeout( csr, TS4(csr.Client), FreeAlien )
end ForwardCall
地元のクライアントかRequestがマルチキャストであったか新しいSend操作リターンとしての安全であるかcsr.ForwardCount=15当時のHandleがforwardserverが地方の当時のHandleであるなら局所的にSet csr.funccodeを返すなら、ForwardServerへのResponded SendPacketGroup(csr)へのRequest Increment csr.ForwardCount Set csr.Stateに、タイムアウト(csr、TS4(csr.Client)、FreeAlien)はForwardCallを終わらせます。
Notes:
注意:
1. A Forward is logically a new call or message transaction. It
must be really implemented as a new message transaction if
the original Request was multicast or secure (with the
optional further refinement that it can be used with a secure
message transaction when the Server and ForwardServer are the
same principal and the Request was not multicast).
1. Forwardはa論理的に新しい呼び出しかメッセージトランザクションです。 それは、オリジナルのRequestがマルチキャストであったなら本当に新しいメッセージトランザクションとして実装されるか、または安全であるに違いありません(さらなる任意の気品で、ServerとForwardServerが同じ主体とRequestであるときに、安全なメッセージトランザクションと共にそれを使用できるのは、マルチキャストではありませんでした)。
2. A Forward operation is never handled as an idempotent
operation because it requires knowledge that the
ForwardServer will treat the forwarded operation as
idempotent as well. Thus, a Forward operation that includes
a segment should set APG on the first transmission of the
2. ForwardServerがまた、ベキ等元として進められた操作を扱うのが知識を必要とするので、Forward操作はベキ等元操作として決して扱われません。 その結果、インクルードaセグメントが最初のトランスミッションでのAPGを設定するべきであるForward操作
Cheriton [page 73]
Cheriton[73ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
forwarded Request to get an acknowledgement for this data.
Once the acknowledgement is received, the forwarding Server
can discard the segment data, leaving only the basic CSR to
handle retransmissions from the Client.
このデータのための承認を得るためにRequestを進めました。 承認がいったん受け取られているようになると、推進Serverはセグメントデータを捨てることができます、基本的なCSRだけがClientから「再-トランスミッション」を扱うのを残して。
5.6.4. Other Functions
5.6.4. 他の機能
GetRemoteClient is a simple local query of the CSR. GetProcess and GetPrincipal also extract this information from the CSR. A server module may defer the Probe callback to the Client to get that information until it is requested by the Server (assuming it is not using secure communication and duplicate suppression is adequate without callback.) GetForwarder is implemented as a callback to the Client, using a GetRequestForwarder VMTP management operation. Additional management procedures for VMTP are described in Appendix III.
GetRemoteClientはCSRの簡単な地方の質問です。 また、GetProcessとGetPrincipalはCSRからこの情報を抜粋します。 サーバモジュールは、それがServerによって要求されるまで(安全なコミュニケーションと写し抑圧を使用していないと仮定するのはコールバックなしで適切です。)その情報を得るためにProbeコールバックをClientに延期するかもしれません。 GetRequestForwarder VMTP管理操作を使用して、GetForwarderはコールバックとしてClientに実装されます。 VMTPのための追加管理手順はAppendix IIIで説明されます。
5.7. Request Packet Arrival
5.7. リクエスト・パケット到着
The basic packet reception follows that described for the Client routines. A Request packet is handled by the procedure HandleRequest.
基本的なパケットレセプションはClientルーチンのために説明されたそれに続いて起こります。 Requestパケットは手順HandleRequestによって扱われます。
HandleRequest( csr, p, psize )
HandleRequest(csr、p、psize)
if LocalClient(csr) then
{ Forwarded Request on local Client }
if csr.LocalTransaction != p.Transaction then return
if csr.State != AwaitingResponse then return
if p.ForwardCount < csr.ForwardCount then
Discard Request and return.
Find a CSR for Client as a remote Client.
if not found then
if packet group complete then
handle as a local message transaction
return
Allocate and init CSR
goto newTransaction
{ Otherwise part of current transaction }
{ Handle directly below. }n
if csr.RemoteTransaction = p.Transaction then
{ Matches current transaction }
if OldForward(p.ForwardCount,csr.ForwardCount) then
return
if p.ForwardCount > csr.ForwardCount then
{ New forwarded transaction }
goto newTransaction
次に、csr.State!がAwaitingResponseと等しいならcsr.LocalTransaction!が次にTransactionが返すp.と等しいならLocalClient(csr)が地方のClientの上のRequestを進めたなら、p.のForwardCountの<のcsr.ForwardCountの当時のDiscard Requestとリターンであるなら戻ってください。 リモートClientとしてClientに関してCSRを見つけてください。そうでなければ、そうでなければ、a地方のメッセージトランザクションリターンのAllocateとイニットCSR goto newTransactionが経常取引を離れさせるときパケットグループが当時のハンドルを完成するならその時を設立してください、直接以下で扱う、csr.RemoteTransactionがその時p.Transactionと等しいなら次に、OldForward(p.ForwardCount、csr.ForwardCount)がそしてp.ForwardCount>csr.ForwardCountであるなら戻るならnが経常取引に合っている、新しい進められたトランザクションgoto newTransaction
Cheriton [page 74]
Cheriton[74ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
{ Otherwise part of current transaction }
if csr.State = ReceivingRequest then
if new segment data then retain in CSR segment area.
if Request not complete then
Timeout( csr, TS1(p.Client), RemoteClientTimeout )
return;
endif
goto endPacketGroup
endif
if csr.State is Responded then
{ Duplicate }
if csr.Code is RESPONSE_DISCARDED
and Multicast(p) then
return
endif
if not DGM(csr) then { Not idempotent }
if SegmentData(csr) then set APG
{ Resend Response or Request, if Forwarded }
SendPacketGroup( csr )
timeout=if SegmentData(csr) then TS5(csr.Client)
else TS4(csr.Client)
Timeout( csr, timeout, RemoteClientTimeout )
return
{ Else idempotent - fall thru to newTransaction }
else { Presume it is a retransmission }
NotifyClient( csr, p, OK )
return
else if OldTransaction(csr.RemoteTransact,p.Transaction) then
return
{ Otherwise, a new message transaction. }
newTransaction:
Abort handling of previous transactions for this Client.
そうでなければ経常取引の一部がcsr.Stateであるなら次に、新しいセグメントデータがCSRでセグメント領域を保有するならその時、ReceivingRequestと等しいです。Requestがその時を完成しないなら、Timeout(csr、TS1(p.Client)、RemoteClientTimeout)は戻ります。 csr.Stateであるなら、csrであるなら、endif goto endPacketGroup endifはRespondedの当時の写しです; コードがRESPONSE_DISCARDEDであり、次に、Multicast(p)がendifかDGM(csr)を返して、次に、SegmentData(csrする)がAPGを設定するなら次に、どんなベキ等元もForwardedであるならResponseかRequestを再送しない、SendPacketGroup(csr)タイムアウトはSegmentData(csr)の当時のTS5(csr.Client)のほかのTS4(csr.Client)であるなら等しいです; タイムアウト(csr、タイムアウト、RemoteClientTimeout)が、ほかにほかのベキ等元--newTransactionに徹底的に落下するのを返す、それが「再-トランスミッション」であると推定してください、次に、OldTransaction(csr.RemoteTransact、p.Transaction)が戻るならNotifyClient(csr、OKなp)がほかに戻る、そうでなければ、新しいメッセージトランザクション、newTransaction: このClientのための前のトランザクションのアボート取り扱い。
if (NSRset(p) or NERset(p)) and NoStreaming then
NotifyClient( csr, p, STREAMING_NOT_SUPPORTED )
return
| if NSRset(p) then { Streaming }
| { Check that consecutive with previous packet group }
| Find last packet group CSR from this client.
| if p.Transaction not lastcsr.RemoteTransaction+1 mod 2**32
| and not STIset(lastcsr) or
| p.Transaction not lastcsr.RemoteTransaction+256 mod **32
| then
| { Out of order packet group }
| NotifyClient(csr, p, BAD_TRANSACTION_ID )
| return
| endif
(NSRset(p)かNERset(p))である、NoStreamingの当時のNotifyClient(_SUPPORTEDではなく、csr、p、STREAMING_)は戻ります。| NSRset(p)の当時のストリーミング| 前のパケットグループとのそんなに連続のチェック| このクライアントから最後のパケットグループCSRを見つけてください。 | lastcsr.RemoteTransaction+1モッズ2**32ではなくp.Transactionです。| またはSTIset(lastcsr)でない。| p. lastcsr.RemoteTransaction+256モッズ**32ではなくトランザクション| その時| 不適切なパケットグループ| NotifyClient(csr、p、BAD_TRANSACTION_ID)| リターン| endif
Cheriton [page 75]
Cheriton[75ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
| if lastcsr not completed then
| NotifyClient( lastcsr, p, RETRY )
| endif
| if lastcsr available then use it for this packet group
| else allocate and initialize new CSR
| if CMG(lastcsr) then
| Add segment data to lastcsr Request
| Keep csr as record of this packet group.
| Clear lastcsr.VerifyInterval
| endif
| else { First packet group }
if MultipleRemoteClients(csr) then ScavengeCsrs(p.Client)
Set csr.RemoteTransaction, csr.Priority
Copy message and segment data to csr's segment area
and set csr.PacketDelivery to that delivered.
Clear csr.PacketDelivery
Clear csr.VerifyInterval
SaveNetworkAddress( csr, p )
endif
if packetgroup not complete then
Timeout( csr, TS3(p.Client), RemoteClientTimeout )
return;
endif
endPacketGroup:
{ We have received complete packet group. }
if APG(p) then NotifyClient( csr, p, OK )
endif
| if NERset(p) and CMG(p) then
| Queue waiting for continuation packet group.
| Timeout( csr, TS3(csr.Client), RemoteClientTimeout )
| return
| endif
{ Deliver request message. }
if GroupId(csr.Server) then
For each server identified by csr.Server
Replicate csr and associated data segment.
if CMDset(csr) and Server busy then
Discard csr and data
else
Deliver or invoke csr for each Server.
if not DGMset(csr) then queue for Response
else Timeout( csr, TS4(csr.Client), FreeCsr )
endfor
else
if CMDset(csr) and Server busy then
Discard csr and data
else
|、lastcsrはその時を完成しませんでした。| NotifyClient(lastcsr、p、RETRY)| endif| 次に、利用可能なlastcsrであるなら、このパケットグループにそれを使用してください。| ほかに、新しいCSRを割り当てて、初期化してください。| そしてCMG(lastcsr)です。| セグメントデータをlastcsr Requestに加えてください。| このパケットグループに関する記録としてcsrを保ってください。 | 明確なlastcsr.VerifyInterval| endif| MultipleRemoteClients(csr)の当時のScavengeCsrs(p.Client)がcsr.RemoteTransaction、csr.Priority Copyメッセージ、およびセグメントデータをcsrのセグメント領域に設定して、それにcsr.PacketDeliveryを設定するなら、最初のパケットグループはほかの配送されました。 packetgroupの完全でない当時のTimeoutが戻るなら(csr、TS3(p.Client)、RemoteClientTimeout)、csr.PacketDelivery Clear csr.VerifyInterval SaveNetworkAddress(csr、p)endifをきれいにしてください。 endif endPacketGroup: 私たちが完全なパケットグループを受け取った、APG(p)の当時のNotifyClient(csr、OKなp)endifです。| NERset(p)とそしてCMG(p)です。| 継続パケットグループを待って、列を作ってください。 | タイムアウト(csr、TS3(csr.Client)、RemoteClientTimeout)| リターン| CMDset(csr)とServerは当時のDiscard csrとデータのほかのDeliverと忙しくするか、または各Serverのためにcsrを呼び出します。endif、要求メッセージを提供してください、GroupId(csr.Server)の当時のForであるなら、各サーバはほかにcsr.Server Replicate csrと関連データセグメントまして、CMDset(csr)とServerが当時のDiscard csrと忙しくするなら次に、DGMset(csr)がResponseのほかのTimeout(csr、TS4(csr.Client)、FreeCsr)endforのためにほかに列を作るか、そして、データを特定しました。
Cheriton [page 76]
Cheriton[76ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
Deliver or invoke csr for this server.
if not DGMset(csr) then queue for Response
else Timeout( csr, TS4(csr.Client), FreeCsr )
endif
end HandleRequest
このサーバのためにcsrを提供するか、または呼び出してください。DGMset(csr)でないなら、ResponseのほかのTimeout(csr、TS4(csr.Client)、FreeCsr)endif終わりのHandleRequestには、列を作ってください。
Notes:
注意:
1. A Request received that specifies a Client that is a local
entity should be a Request forwarded by a remote server to a
local Server.
1. Clientを指定するRequestは受信して、ローカル要素はすなわち、リモートサーバによって地方のServerに送られたRequestであるべきです。
2. An alternative structure for handling a Request sent to a
group when there are multiple local group members is to
create a remote CSR for each group member on reception of the
first packet and deliver a copy of each packet to each such
remote CSR as each packet arrives.
2. Requestがグループに送った取り扱いのための代替の構造は、複数の地域団体のメンバーがいるとき、各パケットが到着するのに応じて、それぞれのグループのメンバーのために最初のパケットのレセプションにリモートCSRを作成して、そのようなそれぞれのリモートCSRにそれぞれのパケットのコピーを提供することです。
Cheriton [page 77]
Cheriton[77ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
5.8. Management Operations
5.8. 管理操作
VMTP uses management operations (invoked as remote procedure calls) to effectively acknowledge packet groups and request retransmissions. The following routine is invoked by the Server's management module on request from the Client.
VMTPは、事実上、パケットグループを承認して、「再-トランスミッション」を要求するのに、管理操作(遠隔手続き呼び出しとして、呼び出される)を使用します。 以下のルーチンはClientからの要求に応じてServerの管理モジュールで呼び出されます。
NotifyVmtpServer(server,clientId,transact,delivery,code)
Find csr with same RemoteTransaction and RemoteClient
as clientId and transact.
if not found or csr.State not Responded then return
if DGMset(csr) then
if transmission of Response in progress then
Abort transmission
if code is migrated then
restart transmission with new host addr.
if Retry then Report protocol error
return
endif
select on code
case RETRY:
if csr.RetransCount > MaxRetrans(clientId) then
if response data segment then
Discard data and mark as RESPONSE_DISCARDED
| if NERset(csr) and subsequent csr then
| Deallocate csr and use later csr for
| future duplicate suppression
| endif
return
endif
increment csr.RetransCount
Set csr.TransmissionMask to missing segment blocks,
as specified by delivery
SendPacketGroup( csr )
Timeout( csr, TS3(csr.Client), RemoteClientTimeout )
case BUSY:
if csr.TimeLimit exceeded then
if response data segment then
Discard data and mark as RESPONSE_DISCARDED
| if NERset(csr) and subsequent csr then
| Deallocate csr and use later csr for
| future duplicate suppression
| endif
endif
endif
Set csr.TransmissionMask for full retransmission
Clear csr.RetransCount
次に、コードがあるならResponseの進行中の当時のAbortトランスミッションの送信がその時移行したならそしてDGMset(csr)が新しいホストaddrとのトランスミッションを再開するなら、Respondedではなく、csr.Stateが戻ります。または、NotifyVmtpServer、(サーバ、clientIdが商取引する、配送、コード) clientIdとしての同じRemoteTransactionとRemoteClientと共にcsrに見つけて、商取引する、設立、Retryの当時のReportが誤りリターンendifについて議定書の中で述べるなら、コードケースの上でRETRYを選択してください: そしてcsr.RetransCount>MaxRetrans(clientId)が、応答データであるなら当時のDiscardデータを区分して、RESPONSEとして_がDISCARDEDであるとマークするなら| NERset(csr)とそしてその後のcsrです。| Deallocate csrと使用は後でcsrします。| 今後の写し抑圧| 配送SendPacketGroup(csr)タイムアウト(csr、TS3(csr.Client)、RemoteClientTimeout)ケースBUSYによって指定されるようにセグメントブロックが恋しいことへのendifリターンendif増分のcsr.RetransCount Set csr.TransmissionMask: csr.TimeLimitが、応答のデータ・セグメントの当時のDiscardデータであるならその時を超えて、RESPONSEとして_がDISCARDEDであるとマークするなら| NERset(csr)とそしてその後のcsrです。| Deallocate csrと使用は後でcsrします。| 今後の写し抑圧| 完全なretransmission Clear csr.RetransCountのためのendif endif endif Set csr.TransmissionMask
Cheriton [page 78]
Cheriton[78ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
Timeout( csr, TS3(csr.Server), RemoteClientTimeout )
return
タイムアウト(csr、TS3(csr.Server)、RemoteClientTimeout)リターン
case ENTITY_MIGRATED:
Get new host address for entity
Set csr.TransmissionMask for full retransmission
Clear csr.RetransCount
SendPacketGroup( csr )
Timeout( csr, TS3(csr.Server), RemoteClientTimeout )
return
ENTITY_MIGRATEDをケースに入れてください: 完全なretransmission Clear csr.RetransCount SendPacketGroup(csr)タイムアウト(csr、TS3(csr.Server)、RemoteClientTimeout)リターンのために実体Set csr.TransmissionMaskのための新しいホスト・アドレスを得てください。
case default:
Abort transmission of Response if in progress.
if response data segment then
Discard data and mark as RESPONSE_DISCARDED
if NERset(csr) and subsequent csr then
Deallocate csr and use later csr for
future duplicate suppression
endif
return
endselect
end NotifyVmtpServer
デフォルトをケースに入れてください: 進行中であるなら、Responseのトランスミッションを中止してください。RESPONSE_DISCARDEDとしての応答のデータ・セグメントの当時のDiscardデータとマークであるなら、今後の写し抑圧endifのためのcsrはNERset(csr)と、その後のcsr当時のDeallocate csrと後での使用であるならendselect終わりのNotifyVmtpServerを返します。
Notes:
注意:
1. A NotifyVmtpServer operation requesting retransmission of
the Response is acceptable only if the Response was not
idempotent. When the Response is idempotent, the Client must
be prepared to retransmit the Request to effectively request
retransmission of the Response.
1. Responseの「再-トランスミッション」を要求するNotifyVmtpServer操作はResponseがベキ等元でなかった場合にだけ許容できます。 Responseがベキ等元であるときに、事実上、Responseの「再-トランスミッション」を要求するためにRequestを再送するようにClientを準備しなければなりません。
2. A NotifyVmtpServer operation may be received while the
Response is being transmitted. If an error return, as an
efficiency, the transmission should be aborted, as suggested
when the Response is a datagram.
2. Responseを伝えている間、NotifyVmtpServer操作を受けるかもしれません。 誤りリターンであるなら、効率として、トランスミッションは示されるとしてResponseがデータグラムであるなら中止されるべきです。
3. A NotifyVmtpServer operation indicating OK or an error
allows the Server to discard segment data and not provide for
subsequent retransmission of the Response.
3. OKを示すNotifyVmtpServer操作か誤りで、Serverはセグメントデータを捨てて、Responseのその後の「再-トランスミッション」に備えません。
5.8.1. HandleRequestNoCSR
5.8.1. HandleRequestNoCSR
When a Request is received from a Client for which the node has no CSR, the node allocates and initializes a CSR for this Client and does a callback to the Client's VMTP management module to get the Principal, Process and other information associated with this Client. It also
RequestがいつノードにはCSRが全くないClientから受け取られていて、ノードがこのClientのためにCSRを割り当てて、初期化するということであり、プリンシパル、Process、および他の情報を手に入れるためにClientのVMTP管理モジュールにコールバックをするかはこのClientと交際しました。 それも
Cheriton [page 79]
Cheriton[79ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
checks that the TransactionId is correct in order to filter out duplicates.
TransactionIdが写しを無視するために正しいのをチェックします。
HandleRequestNoCSR( p, psize )
| if Secure(p) then
| Allocate and init CSR
| SaveSourceHostAddr( csr, p )
| ProbeRemoteClient( csr, p, AUTH_PROBE )
| if no response or error then
| delete CSR
| return
| Decrypt( csr.Key, p, psize )
| if p.Checksum not null then
| if not VerifyChecksum(p, psize) then return;
| if OppositeByteOrder(p) then ByteSwap( p, psize )
| if psize not equal sizeof(VmtpHeader) + 4*p.Length then
| NotifyClient(NULL, p, VMTP_ERROR )
| return
| HandleRequest( csr, p, psize )
| return
if Server does not exist then
NotifyClient( csr, p, NONEXISTENT_ENTITY )
return
endif
if security required by server then
NotifyClient(csr, p, SECURITY_REQUIRED )
return
endif
Allocate and init CSR
SaveSourceHostAddr( csr, p );
if server requires Authentication then
ProbeRemoteClient( csr, p, AUTH_PROBE )
if no response or error then
delete CSR
return
endif
{ Setup immediately as a new message transaction }
set csr.Server to p.Server
set csr.RemoteTransaction to p.Transaction-1
HandleRequestNoCSR(p、psize)| そしてSecure(p)です。| 割り当て、イニットCSR| SaveSourceHostAddr(csr、p)| ProbeRemoteClient(csr、p、AUTH_PROBE)| そして応答でない誤りではありません。| CSRを削除してください。| リターン| (csr.Key、p、psize)を解読してください。| そしてヌルではなく、p.Checksumです。| そうでなければ、次に、VerifyChecksum(p、psize)は戻ります。 | OppositeByteOrder(p)の当時のByteSwap(p、psize)です。| psizeがその時sizeof(VmtpHeader)+4*p.Lengthと等しくないなら| NotifyClient(NULL、p、VMTP_ERROR)| リターン| HandleRequest(csr、p、psize)| Serverが存在していなくて、セキュリティがサーバ当時のNotifyClient(csr、p、SECURITY_REQUIRED)リターンendif Allocateが必要であるなら次に、NotifyClient(csr、p、NONEXISTENT_ENTITY)がendifを返すか、そして、イニットCSR SaveSourceHostAddr(csr、p)を返してください。 次に、どんな応答も誤りもすぐ新しいメッセージトランザクションとしてのセットアップが設定したCSRリターンendifを削除しないならサーバがAuthenticationの当時のProbeRemoteClient(csr、p、AUTH_PROBE)を必要とするなら、p.Serverへのcsr.Serverはp.Transaction-1にcsr.RemoteTransactionを設定します。
HandleRequest( csr, p, psize )
endif
HandleRequest(csr、p、psize)endif
Notes:
注意:
1. A Probe request is always handled as a Request not requiring
authentication so it never generates a callback Probe to the
1. Probe要求が認証を必要としないRequestとしていつも扱われるので、それは、コールバックがProbeであると決して生成しません。
Cheriton [page 80]
Cheriton[80ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
Client.
クライアント。
2. If the Server host retains remote client CSR's for longer
than the maximum packet lifetime and the Request
retransmission time, and the host has been running for at
least that long, then it is not necessary to do a Probe
callback unless the Request is secure. A Probe callback can
take place when the Server asks for the Process or
PrincipalId associated with the Client.
2. Serverホストが最大のパケット生存期間とRequest retransmission時間より長い間リモートCSRのクライアントものを保有して、ホストが少なくともそんなに長い間上演していて、Requestが安全でない場合、Probeコールバックをするのは必要ではありません。 ServerがClientに関連しているProcessかPrincipalIdを求めるとき、Probeコールバックは行われることができます。
Cheriton [page 81]
Cheriton[81ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
5.9. Timeouts
5.9. タイムアウト
The server must implement a timeout for remote client CSRs. There is a timeout for each CSR in the server.
サーバはリモートクライアントCSRsのためにタイムアウトを実装しなければなりません。 サーバには各CSRのためのタイムアウトがあります。
RemoteClientTimeout( csr )
select on csr.State
case Responded:
if RESPONSE_DISCARDED then
mark as timed out
Make a candidate for reuse.
return
if csr.RetransCount > MaxRetrans(Client) then
discard Response
mark CSR as RESPONSE_DISCARDED
Timeout(csr, TS4(Client), RemoteClientTimeout)
return
increment csr.RetransCount
{ Retransmit Response or forwarded Request }
Set APG to get acknowledgement.
SendPacketGroup( csr )
Timeout( csr, TS3(Client), RemoteClientTimeout )
return
case ReceivingRequest:
if csr.RetransCount > MaxRetrans(csr.Client)
or DGMset(csr) or NRTset(csr) then
Modify csr.segmentSize and csr.MsgDelivery
to indicate packets received.
if MDMset(csr) then
Invoke processing on Request
return
else
discard Request and reuse CSR
(Note: Need not remember Request discarded.)
return
increment csr.RetransCount
NotifyClient( csr, p, RETRY )
Timeout( csr, TS3(Client), RemoteClientTimeout )
return
default:
Report error - invalid state for RemoteClientTimeout
endselect
end RemoteClientTimeout
RemoteClientTimeout(csr)はcsr.StateケースRespondedで以下を選択します。 次に、次に、RESPONSE_DISCARDED Timeout(csr、TS4(クライアント)、RemoteClientTimeout)リターン増分のcsr.RetransCountがResponseか進められたRequestを再送するときcsr.RetransCount>MaxRetrans(クライアント)がResponseマークCSRを捨てるならRESPONSE_DISCARDEDが、調節されるとして出ているMakeが再利用リターンの候補であるとマークするなら、APGに承認を得るように設定してください。 SendPacketGroup(csr)タイムアウト(csr、TS3(クライアント)、RemoteClientTimeout)リターンケースReceivingRequest: csr.RetransCount>MaxRetrans(csr.Client)、DGMset(csr)またはNRTset(csr)であるなら、パケットを示すModify csr.segmentSizeとcsr.MsgDeliveryは受信しました。Requestに処理するMDMset(csr)の当時のInvokeがほかに戻るなら、Requestと再利用CSR(注意: Requestが捨てたのを覚えている必要はありません。)リターン増分のcsr.RetransCount NotifyClient(csr、p、RETRY)タイムアウト(csr、TS3(クライアント)、RemoteClientTimeout)リターンデフォルトを捨ててください: レポートエラー--RemoteClientTimeout endselect終わりのRemoteClientTimeoutに、無効の状態
Notes:
注意:
1. When a CSR in the Responded state times out after discarding
1. RespondedのCSRであるときには、捨てた後に、外に回を述べてください。
Cheriton [page 82]
Cheriton[82ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
the Response, it can be made available for reuse, either by
the same Client or a different one. The CSR should be kept
available for reuse by the Client for as long as possible to
avoid unnecessary callback Probes.
Responseであり、それを同じClientか異なったもので再利用に利用可能にすることができます。 CSRは、不要なコールバックProbesを避けるためにできるだけ長い間Clientによる再利用に利用可能に保たれるべきです。
Cheriton [page 83]
Cheriton[83ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
6. Concluding Remarks
6. 結びの言葉
This document represents a description of the current state of the VMTP design. We are currently engaged in several experimental implementations to explore and refine all aspects of the protocol. Preliminary implementations are running in the UNIX 4.3BSD kernel and in the V kernel.
このドキュメントはVMTPデザインの現状の記述を表します。 私たちは、現在、プロトコルの全面を探検して、精製するためにいくつかの実験的な実装に従事しています。 予備の実装はUNIX4.3BSDカーネルとVカーネルで稼働しています。
Several issues are still being discussed and explored with this protocol. First, the size of the checksum field and the algorithm to use for its calculation are undergoing some discussion. The author believes that the conventional 16-bit checksum used with TCP and IP is too weak for future high-speed networks, arguing for at least a 32-bit checksum. Unfortunately, there appears to be limited theory covering checksum algorithms that are suitable for calculation in software.
いくつかの問題が、このプロトコルでまだ議論して、探られています。 まず最初に、チェックサム分野のサイズと計算に使用するアルゴリズムは何らかの議論を受けることです。 作者は、将来の高速ネットワークには、TCPとIPと共に使用される従来の16ビットのチェックサムが弱過ぎると信じています、少なくとも32ビットのチェックサムについて賛成の議論をして。 残念ながら、ソフトウェアにおける計算に適した限られた理論覆いチェックサムアルゴリズムは現れるでしょう。
Implementation of the streaming facilities of VMTP is still in progress. This facility is expected to be important for wide-area, long delay communication.
VMTPのストリーミングの施設の実装はまだ進行しています。 この施設が広い領域の、そして、長い遅れコミュニケーションに重要であると予想されます。
Cheriton [page 84]
Cheriton[84ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
I. Standard VMTP Response Codes
I. 標準のVMTP応答コード
The following are the numeric values of the response codes used in VMTP.
↓これはVMTPで使用される応答コードの数値です。
0 OK
0 OK
1 RETRY
1つの再試行
2 RETRY_ALL
2は_すべてを再試行します。
3 BUSY
3は忙しくします。
4 NONEXISTENT_ENTITY
4の実在しない_実体
5 ENTITY_MIGRATED
5実体_は移行しました。
6 NO_PERMISSION
6 _許可がありません。
7 NOT_AWAITING_MSG
7 _待ち_エムエスジーでない
8 VMTP_ERROR
8 VMTP_誤り
9 MSGTRANS_OVERFLOW
9MSGTRANS_オーバーフロー
10 BAD_TRANSACTION_ID
10 悪い_トランザクション_ID
11 STREAMING_NOT_SUPPORTED
11 どんな_もサポートしなかったストリーミングの_
12 NO_RUN_RECORD
12 _走行_記録がありません。
13 RETRANS_TIMEOUT
13 RETRANS_タイムアウト
14 USER_TIMEOUT
14 ユーザ_タイムアウト
15 RESPONSE_DISCARDED
15 応答_は捨てました。
16 SECURITY_NOT_SUPPORTED
16 どんな_もサポートしなかったセキュリティ_
17 BAD_REPLY_SEGMENT
17の悪い_回答_セグメント
18 SECURITY_REQUIRED
18 セキュリティ_が必要です。
19 STREAMED_RESPONSE
19 流された_応答
20 TOO_MANY_RETRIES
20 あまりに_多くの_再試行
21 NO_PRINCIPAL
21 _主体がありません。
Cheriton [page 85]
Cheriton[85ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
22 NO_KEY
22 _キーがありません。
23 ENCRYPTION_NOT_SUPPORTED
どんな_もサポートしなかった23暗号化_
24 NO_AUTHENTICATOR
24 _固有識別文字がありません。
25-63 Reserved for future VMTP assignment.
将来のVMTP課題のために予約された25-63。
Other values of the codes are available for use by higher level protocols. Separate protocol documents will specify further standard values.
コードの他の値は、より高い平らなプロトコルで使用に利用可能です。 別々のプロトコルドキュメントはさらなる基準値を指定するでしょう。
Applications are free to use values starting at 0x00800000 (hex) for application-specific return values.
アプリケーションは無料でアプリケーション特有のリターン値のために0×00800000(魔法をかける)で開始する値を使用できます。
Cheriton [page 86]
Cheriton[86ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
II. VMTP RPC Presentation Protocol
II。 VMTP RPCプレゼンテーションプロトコル
For complete generality, the mapping of the procedures and the parameters onto VMTP messages should be defined by a RPC presentation protocol. In the absence of an accepted standard protocol, we define an RPC presentation protocol for VMTP as follows.
完全な一般性において、VMTPメッセージへの手順とパラメタに関するマッピングはRPCプレゼンテーションプロトコルによって定義されるべきです。 受け入れられた標準プロトコルがないとき、私たちは以下のVMTPのためにRPCプレゼンテーションプロトコルを定義します。
Each procedure is assigned an identifying Request Code. The Request code serves effectively the same as a tag field of variant record, identifying the format of the Request and associated Response as a variant of the possible message formats.
特定Request Codeは各手順に割り当てられます。 Requestコードは異形記録のタグ・フィールドとして有効に同じように機能します、可能なメッセージ・フォーマットの異形としてRequestと関連Responseの形式を特定して。
The format of the Request for a procedure is its Request Code followed by its parameters sequentially in the message control block until it is full.
手順のためのRequestの形式はそれが完全になるまでパラメタがメッセージ制御ブロックで連続していうことになったRequest Codeです。
The remaining parameters are sent as part of the message segment data formatted according to the XDR protocol (RFC ??). In this case, the size of the segment is specified in the SegmentSize field.
XDRプロトコルによると、メッセージ・セグメントデータの一部が(RFC?)をフォーマットしたので、残っているパラメタを送ります。 この場合、セグメントのサイズはSegmentSize分野で指定されます。
The Response for a procedure consists of a ResponseCode field followed by the return parameters sequentially in the message control block, except if there is a parameter returned that must be transmitted as segment data, its size is specified in the SegmentSize field and the parameter is stored in the SegmentData field.
手順がリターンパラメタがメッセージ制御ブロックで連続してあとに続いたResponseCode分野から成る返されたセグメントデータとして伝えられます、サイズがSegmentSize分野で指定されるということであるに違いないパラメタがあるか、そして、パラメタを除いて、ResponseはSegmentData分野に保存されます。
Attributes associated with procedure definitions should indicate the Flags to be used in the RequestCode. Request Codes are assigned as described below.
手続き定義に関連している属性は、RequestCodeで使用されるためにFlagsを示すべきです。 Codesが以下で説明されるように割り当てられるよう要求してください。
II.1. Request Code Management
II.1。 コード管理を要求してください。
Request codes are divided into Public Interface Codes and application-specific, according to whether the PIC value is set. An interface is a set of request codes representing one service or module function. A public interface is one that is to be used in multiple independently developed modules. In VMTP, public interface codes are allocated in units of 256 structured as
コードがPublic Interface Codesに分割されて、PIC値が設定されるかどうかに従ってアプリケーション特有であるよう要求してください。 インタフェースは1つのサービスかモジュール機能を表す1セットの要求コードです。 公共のインタフェースは複数の独自に開発されたモジュールで使用されることになっているものです。 VMTP、256のユニットが構造化したコネがコードに割り当てられる公共のインタフェースで
+-------------+----------------+-------------------+
| ControlFlags| Interface | Version/Procedure |
+-------------+----------------+-------------------+
8 bits 16 bits 8 bits
+-------------+----------------+-------------------+ | ControlFlags| インタフェース| バージョン/手順| +-------------+----------------+-------------------+ 8ビット16ビット8ビット
An interface is free to allocate the 8 bits for version and procedure as desired. For example, all 8 bits can be used for procedures. A module requiring more than 256 Version/Procedure values can be allocated
インタフェースはバージョンと手順のために望まれているように自由に8ビットを割り当てることができます。 例えば、手順にすべての8ビットを使用できます。 256以上のバージョン/手順値を必要とするモジュールは割り当てることができます。
Cheriton [page 87]
Cheriton[87ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
multiple Interface values. They need not be consecutive Interface values.
複数のInterface値。 それらは連続したInterface値である必要はありません。
Cheriton [page 88]
Cheriton[88ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
III. VMTP Management Procedures
III。 VMTP管理手順
Standard procedures are defined for VMTP management, including creation, deletion and query of entities and entity groups, probing to get information about entities, and updating message transaction information at the client or the server.
標準手続きはVMTP管理のために定義されます、実体と実体グループの作成、削除、および質問を含んでいて、実体の情報を得るために調べて、クライアントかサーバでメッセージトランザクション情報をアップデートして。
The procedures are implemented by the VMTP manager that constitutes a portion of every complete VMTP module. Each procedure is invoked by sending a Request to the VMTP manager that handles the entity specified in the operation or the local manager. The Request sent using the normal Send operation with the Server specified as the well-known entity group VMTP_MANGER_GROUP, using the CoResident Entity mechanism to direct the request to the specific manager that should handle the Request. (The ProbeEntity operation is multicast to the VMTP_MANAGER_GROUP if the host address for the entity is not known locally and the host address is determined as the host address of the responder. For all other operations, a ProbeEntity operation is used to determine the host address if it is not known.) Specifying co-resident entity 0 is interpreted as the co-resident with the invoking process. The co-resident entity identifier may also specify a group in which case, the Request is sent to all managers with members in this group.
手順はあらゆる完全なVMTPモジュールの部分を構成するVMTPマネージャによって実装されます。 各手順は、操作で指定された実体を扱うVMTPマネージャか地元のマネージャにRequestを送ることによって、呼び出されます。 Serverとの通常のSend操作が使用させられたRequestはよく知られる実体グループVMTP_MANGER_GROUPとして指定しました、Requestを扱うべきである特定のマネージャに要求を向けるのにCoResident Entityメカニズムを使用して。 (実体のためのホスト・アドレスが局所的に知られていなくて、ホスト・アドレスが応答者のホスト・アドレスとして決定しているなら、ProbeEntity操作は_VMTP_マネージャGROUPへのマルチキャストです。 他のすべての操作において、それが知られていないなら、ProbeEntity操作は、ホスト・アドレスを決定するのに使用されます。) コレジデント実体0を指定するのは呼び出しプロセスをもっているコレジデントとして解釈されます。 また、コレジデントエンティティ識別名はその場合グループを指定するかもしれなくて、このグループでメンバーと一緒にいるすべてのマネージャにRequestを送ります。
The standard procedures with their RequestCode and parameters are listed below with their semantics. (The RequestCode range 0xVV000100 to 0xVV0001FF is reserved for use by the VMTP management routines, where VV is any choice of control flags with the PIC bit set. The flags are set below as required for each procedure.)
それらのRequestCodeとパラメタがある標準手続きは以下にそれらの意味論で記載されています。 (0xVV0001FFへのRequestCode範囲0xVV000100は使用のためにVMTP管理ルーチンで予約されます。そこでは、VVはPICビットがある旗が設定するコントロールのあらゆる選択です。 旗は必要に応じて以下に各手順に設定されます。)
0x05000101 - ProbeEntity(CREntity, entityId, authDomain) -> (code,
<staterec>)
Request and return information on the specified entity
in the specified authDomain, sending the Request to the
VMTP management module coresident with CREntity. An
error return is given if the requested information
cannot be provided in the specified authDomain. The
<staterec> returned is structured as the following
fields.
0×05000101--ProbeEntity(CREntity、entityId、authDomain)->(コード、<staterec>)要求とCREntityをもっているVMTP管理モジュールコレジデントにRequestを送る指定されたauthDomainの指定された実体のリターン情報。 指定されたauthDomainに求められた情報を提供できないなら、誤りリターンを与えます。 >が返した<staterecは以下の分野として構造化されます。
Transaction identifier
The current or next transaction
identifier being used by the probed
entity.
トランザクション識別子、調べられた実体によって使用される電流か次のトランザクション識別子。
ProcessId: 64 bits
Identifier for client process. The
meaning of this is specified as part of
ProcessId: クライアントのための64ビットのIdentifierは処理します。 この意味は部分として指定されます。
Cheriton [page 89]
Cheriton[89ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
the Domain definition.
Domain定義。
PrincipalId The identifier for the principal or
account associated with the process
specified by ProcessId. The meaning of
this field is specified as part of the
Domain definition.
プロセスに関連している主体かアカウントのための識別子がProcessIdで指定したPrincipalId。 この分野の意味はDomain定義の一部として指定されます。
EffectivePrincipalId
The identifier for the principal or
account associated with the Client port,
which may be different from the
PrincipalId especially if this is an
nested call. The meaning of this field
is specified as part of the Domain
definition.
EffectivePrincipalIdはClientポート(これが特に入れ子にされた呼び出しであるならPrincipalIdと異なるかもしれないもの)に関連している主体かアカウントのための識別子です。 この分野の意味はDomain定義の一部として指定されます。
The code field indicates whether this is an error
response or not. The codes and their interpretation
are:
コード分野は、これが誤り応答であるかどうかを示します。 コードと彼らの解釈は以下の通りです。
OK
No error. Probe was completed OK.
誤りを全く承認しないでください。 徹底的調査はOKに終了しました。
NONEXISTENT_ENTITY
Specified entity does not exist.
NONEXISTENT_ENTITY Specified実体は存在していません。
ENTITY_MIGRATED
The entity has migrated and is no longer at the host to
which the request was sent.
ENTITY_MIGRATED、実体は、移行して、もう要求が送られたいずれのホストにもありません。
NO_PERMISSION
Entity has refused to provide ProbeResponse.
いいえ_PERMISSION Entityは、ProbeResponseを提供するのを拒否しました。
VMTP_ERROR
The Request packet group was in error relative to the
VMTP protocol specification.
Requestパケットが分類するVMTP_ERRORはVMTPプロトコル仕様に比例して間違っていました。
"default"
Some type of error - discard ProbeResponse.
誤りの「デフォルト」Someタイプ--ProbeResponseを捨ててください。
0x0D000102 - AuthProbeEntity(CREntity,entityId,authDomain,randomId) ->
(code,ProbeAuthenticator,EncryptType,EntityAuthenticator)
0x0D000102--AuthProbeEntity(CREntity、entityId、authDomain、randomId)->。(コード、ProbeAuthenticator、EncryptType、EntityAuthenticator)
Request authentication of the entity specified by
entityId from the VMTP manager coresident with CREntity
in authDomain authentication domain, returning the
実体の認証がCREntityと共にauthDomain認証ドメインでentityIdでVMTPマネージャのコレジデントから指定したよう要求してください、戻ります。
Cheriton [page 90]
Cheriton[90ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
information contained in the return parameters. The
fields are set the same as that specified for the basic
ProbeResponse except as noted below.
情報はリターンにパラメタを含みました。 以下に述べられるのを除いて、それが基本的なProbeResponseに指定したように分野は同じように設定されます。
ProbeAuthenticator
20 bytes consisting of the EntityId, the
randomId and the probed Entity's current
Transaction value plus a 32-bit checksum
for these two fields (checksummed using
the standard packet Checksum algorithm),
all encrypted with the Key supplied in
the Authenticator.
EntityId、randomId、および調べられたEntityの現在のTransactionのProbeAuthenticator20バイトの成るのはそのうえ、これらの2つの分野(標準のパケットChecksumアルゴリズムを使用することで、checksummedしました)(AuthenticatorでKeyを供給している状態で暗号化されたすべて)に32ビットのチェックサムを評価します。
EncryptType An identifier that identifies the
variant of encryption method being used
by the probed Entity for packets it
transmits and packets it is able to
receive. (See Appendix V.) The
high-order 8 bits of the EncryptType
contain the XOR of the 8 octets of the
PrincipalId associated with private key
used to encrypt the EntityAuthenticator.
This value is used by the requestor or
Client as an aid in locating the key to
decrypt the authenticator.
それが伝えるパケットとそれが受けることができるパケットに調べられたEntityによって使用される暗号化メソッドの異形を特定するEncryptType An識別子。 (付録V.を見ます) EncryptTypeの高位8ビットはEntityAuthenticatorを暗号化するのに使用される秘密鍵に関連しているPrincipalIdの8つの八重奏のXORを含んでいます。 この値は援助として固有識別文字を解読するためにキーの場所を見つける際に要請者かClientによって使用されます。
EntityAuthenticator
(returned as segment data) The
ProcessId, PrincipalId,
EffectivePrincipal associated with the
ProbedEntity plus the private
encryption/decryption key and its
lifetime limit to be used for
communication with the Entity. The
authenticator is encrypted with a
private key associated with the Client
entity such that it can be neither read
nor forged by a party not trusted by the
Client Entity. The format of the
Authenticator in the message segment is
shown in detail in Figure III-1.
EntityAuthenticator(セグメントデータとして、返す)ProcessId、PrincipalId、EffectivePrincipalはEntityとのコミュニケーションに使用されるためにProbedEntity、個人的な暗号化/復号化キー、およびその生涯限界と交際しました。 固有識別文字は、Client Entityによって信じられなかったパーティーがそれを読まないで、鍛造できないように、Client実体に関連している秘密鍵で暗号化されます。 メッセージ・セグメントのAuthenticatorの書式は図III-1に詳細に示されます。
Key: 64 bits Encryption key to be used for encrypting
and decrypting packets sent to and
received from the probed Entity. This
is the "working" key for packet
transmissions. VMTP only uses private
キー: パケットを暗号化して、解読するのにおいて使用されているために主要な64ビットのEncryptionは調べられたEntityから発信して、受信しました。 これはパケット伝送に、主要な「働き」です。 VMTPは兵卒を使用するだけです。
Cheriton [page 91]
Cheriton[91ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
+-----------------------------------------------+
| ProcessId (8 octets) |
+-----------------------------------------------+
| PrincipalId (8 octets) |
+-----------------------------------------------+
| EffectivePrincipalId (8 octets) |
+-----------------------------------------------+
| Key (8 octets) |
+-----------------------------------------------+
| KeyTimeLimit |
+-----------------------------------------------+
| AuthDomain |
+-----------------------------------------------+
| AuthChecksum |
+-----------------------------------------------+
+-----------------------------------------------+ | ProcessId(8つの八重奏)| +-----------------------------------------------+ | PrincipalId(8つの八重奏)| +-----------------------------------------------+ | EffectivePrincipalId(8つの八重奏)| +-----------------------------------------------+ | 主要です(8つの八重奏)。| +-----------------------------------------------+ | KeyTimeLimit| +-----------------------------------------------+ | AuthDomain| +-----------------------------------------------+ | AuthChecksum| +-----------------------------------------------+
Figure III-1: Authenticator Format
III-1は計算します: 固有識別文字形式
key encryption for data transmission.
データ伝送のための主要な暗号化。
KeyTimeLimit: 32 bits
The time in seconds since Dec. 31st,
1969 GMT at which one should cease to
use the Key.
KeyTimeLimit: 32ビットはグリニッジ標準時1969が、どの時に12月31日にやめるべきであって以来の秒の時にKeyを使用します。
AuthDomain: 32 bits
The authentication domain in which to
interpret the principal identifiers.
This may be different from the
authDomain specified in the call if the
Server cannot provide the authentication
information in the request domain.
AuthDomain: 32ビット、主要な識別子を解釈する認証ドメイン。 これはServerが要求ドメインに認証情報を提供できないなら呼び出しで指定されたauthDomainと異なっているかもしれません。
AuthChecksum: 32 bits
Contains the checksum (using the same
Checksum algorithm as for packet) of
KeyTimeLimit, Key, PrincipalId and
EffectivePrincipalId.
AuthChecksum: 32ビットのContainsのチェックサムのKeyTimeLimitの(パケットのような同じChecksumアルゴリズムを使用します)、Key、PrincipalId、およびEffectivePrincipalId。
Notes:
注意:
1. A authentication Probe Request and Response
are sent unencrypted in general because it is
used prior to there being a secure channel.
Therefore, specific fields or groups of
fields checksummed and encrypted to prevent
unauthorized modification or forgery. In
1. それが安全なチャンネルであるのでそこの前に使用されるので一般に、非暗号化されて、認証Probe RequestとResponseを送ります。 したがって、権限のない変更か偽造を防ぐためにchecksummedされて、暗号化された分野の特定の分野かグループ。 コネ
Cheriton [page 92]
Cheriton[92ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
particular, the ProbeAuthenticator is
checksummed and encrypted with the Key.
特定であることで、ProbeAuthenticatorはKeyと共にchecksummedされて、暗号化されます。
2. The ProbeAuthenticator authenticates the
Response as responding to the Request when
its EntityId, randomId and Transaction values
match those in the Probe request. The
ProbeAutenticator is bound to the
EntityAutenticator by being encrypted by the
private Key contained in that authenticator.
2. ProbeAuthenticatorはEntityId、randomId、およびTransaction値がProbe要求におけるそれらに合っているとRequestに応じるとResponseを認証します。 その固有識別文字に含まれた個人的なKeyによって暗号化されることによって、ProbeAutenticatorはEntityAutenticatorに縛られます。
3. The authenticator is encrypted such that it
can be decrypted by a private key, known to
the Client. This authenticator is presumably
obtained from a key distribution center that
the Client trusts. The AuthChecksum prevents
undetected modifications to the
authenticator.
3. 固有識別文字は、Clientにおいて知られている秘密鍵でそれを解読することができるように暗号化されています。 おそらく、Clientが信じる主要な配送センターからこの固有識別文字を得ます。 AuthChecksumは固有識別文字への非検出された変更を防ぎます。
0x05000103 - ProbeEntityBlock( entityId ) -> ( code, entityId )
Check whether the block of 256 entity identifiers
associated with this entityId are in use. The entityId
returned should match that being queried or else the
return value should be ignored and the operation redone.
0×05000103--ProbeEntityBlock(entityId)->(コード、entityId)は、このentityIdに関連している256のエンティティ識別名のブロックが使用中であるかどうかチェックします。 返されたentityIdは質問されるか、リターンが無視されるべきであるのを評価するマッチとやり直された操作がそうするべきです。
0x05000104 - QueryVMTPNode( entityId ) -> (code, MTU, flags, authdomain,
domains, authdomains, domainlist)
Query the VMTP management module for entityId to get
various module- or node-wide parameters, including: (1)
MTU - Maximum transmission unit or packet size handled
by this node. (2) flags- zero or more of the following
bit fields:
0×05000104--entityIdが様々なモジュールの、または、ノード全体のパラメタを得るように、QueryVMTPNode(entityId)->(コード(MTU)は弛みます、authdomain、ドメイン、authdomains、domainlist)はVMTP管理モジュールを質問します、である: (1) MTU--マキシマム・トランスミッション・ユニットかこのノードによって扱われたパケットサイズ。 (2) 旗のゼロか以下のビットの以上が以下をさばきます。
1 Handles streamed Requests.
1ハンドルはRequestsを流しました。
2 Can issue streamed message transactions
for clients.
2はクライアントのために流されたメッセージトランザクションを発行できます。
4 Handles secure Requests.
4本のハンドルがRequestsを固定します。
8 Can issue secure message transactions.
8は安全なメッセージトランザクションを発行できます。
The authdomain indicates the primary authentication
domain supported. The domains and authdomains
parameters indicate the number of entity domains and
authentication domains supported by this node, which are
listed in the data segment parameter domainlist if
authdomainは、プライマリ認証ドメインがサポートしたのを示します。 ドメインとauthdomainsパラメタはこのノードによってサポートされた実体ドメインと認証ドメインの数を示します。(ドメインはデータ・セグメントパラメタdomainlistに記載されています)。
Cheriton [page 93]
Cheriton[93ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
either parameter is non-zero. (All the entity domains
precede the authentication domains in the data segment.)
どちらかのパラメタが非ゼロです。 (すべての実体ドメインがデータ・セグメントで認証ドメインに先行します。)
0x05000105 - GetRequestForwarder( CREntity, entityId1 ) -> (code,
entityId2, principal, authDomain)
Return the forwarding server's entity identifer and
principal for the forwarder of entityId1. CREntity
should be zero to get the local VMTP management module.
0×05000105--entityId1の混載業者のためのGetRequestForwarder(CREntity、entityId1)->(コード、entityId2、主体、authDomain)リターン推進サーバの実体identiferと主体。 CREntityは、ローカルのVMTP管理モジュールを得るためにはゼロであるべきです。
0x05000106 - CreateEntity( entityId1 ) -> ( code, entityId2 )
Create a new entity and return its entity identifier in
entityId2. The entity is created local to the entity
specified in entityId1 and local to the requestor if
entityId1 is 0.
0×05000106--CreateEntity(entityId1)->(コード、entityId2)は新しい実体を作成して、entityId2のエンティティ識別名を返します。 実体はentityId1が0歳であるならentityId1で指定されて要請者にとっての、地方の実体に地方で作成されます。
0x05000107 - DeleteEntity( entityId ) -> ( code )
Delete the entity specified by entityId, which may be a
group. If a group, the deletion is only on a best
efforts basis. The client must take additional measures
to ensure complete deletion if required.
0×05000107--DeleteEntity(entityId)->(コード)はグループであるかもしれないentityIdによって指定された実体を削除します。 グループであるなら、削除が最善努力原則だけにあります。 クライアントは必要なら、完全な削除を確実にする追加措置を取らなければなりません。
0x0D000108 -QueryEntity( entityId ) -> ( code, descriptor )
Return a descriptor of entityId in arg of a maximum of
segmentSize bytes.
0x0D000108 -QueryEntity(entityId)->(コード、記述子)は最大segmentSizeバイトのargでentityIdに関する記述子を返します。
0x05000109 - SignalEntity( entityId, arg )->( code )
Send the signal specified by arg to the entity specified
by entityId. (arg is 32 bits.)
0×05000109--SignalEntity(entityId、arg)->(コード)はargによってentityIdによって指定された実体に指定された信号を送ります。 (argは32ビットです。)
0x0500010A - CreateGroup(CREntity,entityGroupId,entityId,perms)->(code)
Request that the VMTP manager local to CREntity create
an new entity group, using the specified entityGroupId
with entityId as the first member and permissions
"perms", a 32-bit field described later. The invoker is
registered as a manager of the new group, giving it the
permissions to add or remove members. (Normally
CREntity is 0, indicating the VMTP manager local to the
requestor.)
0x0500010A--CREntityへの地元のVMTPマネージャが新しい実体グループを創設するというCreateGroup(CREntity、entityGroupId(entityId)はパーマをかける)->(コード)要求、最初のメンバーと許容としてentityIdと指定されたentityGroupIdを使用するのは「パーマをかけます」、後で説明された32ビットの分野。 メンバーを加えるか、または免職するために許容をそれに与えて、呼び出し元は新しいグループのマネージャの登録が済んでいます。 (通常、要請者にとっての、地元のVMTPマネージャを示して、CREntityは0歳です。)
0x0500010B - AddToGroup(CREntity, entityGroupId, entityId,
perms)->(code)
Request that the VMTP manager local to CREntity add the
specified entityId to the entityGroupId with the
specified permissions. If entityGroupId specifies a
restricted group, the invoker must have permission to
add members to the group, either because the invoker is
0x0500010B--CREntityへの地元のVMTPマネージャが指定された許容で指定されたentityIdをentityGroupIdに加えるというAddToGroup(CREntity、entityGroupId(entityId)はパーマをかける)->(コード)要求。 entityGroupIdが制限されたグループを指定するなら、呼び出し元には、メンバーをグループに追加する許可がなければなりません、呼び出し元がそうので
Cheriton [page 94]
Cheriton[94ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
a manager of the group or because it was added to the
group with the required permissions. If CREntity is 0,
then the local VMTP manager checks permissions and
forwards the request with CREntity set to entityId and
the entityId field set to a digital signature (see
below) of the Request by the VMTP manager, certifying
that the Client has the permissions required by the
Request. (If entityGroupId specifies an unrestricted
group, the Request can be sent directly to the handling
VMTP manager by setting CREntity to entityId.)
マネージャ、グループかそれが必要な許容でグループに追加されたので。 CREntityが0歳であるなら、地元のVMTPマネージャは、entityIdに用意ができているCREntityと共に許容をチェックして、要求を転送します、そして、entityId分野はVMTPマネージャによるRequestのデジタル署名(以下を見る)にセットしました、ClientがRequestに許容を必要とさせるのを公認して。 (entityGroupIdが無制限なグループを指定するなら、entityIdにCREntityを設定することによって、直接取り扱いVMTPマネージャにRequestを送ることができます。)
0x0500010C - RemoveFromGroup(CREntity, entityGroupId, entityId)->(code)
Request that the VMTP manager local to CREntity remove
the specified entityId from the group specified by
entityGroupId. Normally CREntity is 0, indicating the
VMTP manager local to the requestor. If CREntity is 0,
then the local VMTP manager checks permissions and
forwards the request with CREntity set to entityId and
the entityId field a digital signature of the Request by
the VMTP manager, certifying that the Client has the
permissions required by the Request.
0x0500010C--CREntityへの地元のVMTPマネージャがグループから指定されたentityIdを取り外すというRemoveFromGroup(CREntity、entityGroupId、entityId)->(コード)要求はentityGroupIdで指定しました。 通常、要請者にとっての、地元のVMTPマネージャを示して、CREntityは0歳です。 CREntityが0歳であるなら、地元のVMTPマネージャは、許容をチェックして、entityIdに用意ができているCREntityとentityId分野がある要求にVMTPマネージャによるRequestのデジタル署名を送ります、ClientがRequestに許容を必要とさせるのを公認して。
0x0500010D - QueryGroup( entityId )->( code, record )...
Return information on the specified entity. The
Response from each responding VMTP manager is (code,
record). The format of the record is (memberCount,
member1, member2, ...). The Responses are returned on a
best efforts basis; there is no guarantee that responses
from all managers with members in the specified group
will be received.
0x0500010D--QueryGroup(entityId)->(コード、記録)… 指定された実体の情報を返してください。 それぞれの応じているVMTPマネージャからのResponseは(コード、記録)です。 記録の形式は(memberCount、member1、member2)です。 最善努力原則でResponsesを返します。 指定されたグループのメンバーと一緒にいるすべてのマネージャからの応答を受けるという保証が全くありません。
0x0500010E - ModifyService(entityId,flags,count,pc,threadlist)->(code,
count)
Modify the service associated with the entity specified
by entityId. The flags may indicate a message service
model, in which case the call "count" parameter
indicates the maximum number of queued messages desired;
the return "count" parameter indicates the number of
queued message allowed. Alternatively, the "flags"
parameters indicates the RPC thread service model, in
which case "count" threads are requested, each with an
inital program counter as specified and stack, priority
and message receive area indicated by the threadlist.
In particular, "threadlist" consists of "count" records
of the form
(priority,stack,stacksize,segment,segmentsize), each one
assigned to one of the threads. Flags defined for the
0x0500010E--ModifyService(entityId、旗、カウント、pc、threadlist)->(コード、カウント)はentityIdによって指定される実体に関連しているサービスを変更します。 旗はメッセージサービスモデルを示すかもしれません、その場合、呼び出し「カウント」パラメタは列に並ばせられたメッセージの最大数が望んでいたのを示します。 リターン「カウント」パラメタは、列に並ばせられたメッセージの数が許容したのを示します。 あるいはまた、「旗」パラメタは、「カウント」スレッドは要求されています、それぞれ指定されるとしてのinitalプログラムカウンタでどの場合にRPCスレッドサービスモデル、スタック、優先権、およびメッセージがthreadlistによって示された領域を受けるかを示します。 特に、"threadlist"はフォームに関する「勘定」記録から成ります。(優先権(スタック)がstacksizeされる、セグメント、segmentsizeする、)、スレッドの1つに選任されたそれぞれ。 旗、定義されます。
Cheriton [page 95]
Cheriton[95ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
"flags" parameter are:
「旗」パラメタは以下の通りです。
1 THREAD_SERVICE - otherwise the message
model.
1 THREAD_SERVICE--そうでなければ、メッセージモデル。
2 AUTHENTICATION_REQUIRED - Sent a Probe
request to determine principal
associated with the Client, if not
known.
2 AUTHENTICATION_REQUIRED--知られないなら、Clientに関連している主体を決定するというProbe要求を送りました。
4 SECURITY_REQUIRED - Request must be
encrypted or else reject.
4 SECURITY_REQUIRED--暗号化していなければならないよう要求するか、廃棄物。
8 INCREMENTAL - treat the count value as
an increment (or decrement) relative to
the current value rather than an
absolute value for the maximum number of
queued messages or threads.
8INCREMENTAL--列に並ばせられたメッセージかスレッドの最大数のために絶対値よりむしろ現行価値に比例して増分(または、減少)としてカウント値を扱ってください。
In the thread model, the count must be a positive
increment or else 0, which disables the service. Only a
count of 0 terminates currently queued requests or
in-progress request handling.
スレッドモデルでは、カウントは、陽の増分か0であるに違いありません(サービスを無効にします)。 0のカウントだけが現在列に並ばせられた要求か進行中の要求取り扱いを終えます。
0x4500010F -
NotifyVmtpClient(client,cntrl,recSeq,transact,delivery,code)->()
0x4500010F--、NotifyVmtpClient、(クライアント、cntrl、recSeqが商取引する、コード) 配送、->。()
Update the state associated with the transaction
specified by client and transact, an entity identifier
and transaction identifier, respectively. This
operation is normally used only by another VMTP
management module. (Note that it is a datagram
operation.) The other parameters are as follows:
それぞれトランザクションに関連している州がクライアントで指定して、商取引するアップデート、エンティティ識別名、およびトランザクション識別子 通常、この操作は単に別のVMTP管理モジュールで使用されます。 (それがデータグラム操作であることに注意してください。) 他のパラメタは以下の通りです:
ctrl A 32-bit value corresponding to 4th
32-bit word of the VMTP header of a
Response packet that would be sent in
response to the Request that this is
responding to. That is, the control
flags, ForwardCount, RetransmitCount and
Priority fields match those of the
Request. (The NRS flag is set if the
receiveSeqNumber field is used.) The
PGCount subfield indicates the number of
previous Request packet groups being
acknowledged by this Notify operation.
(The bit fields that are reserved in
これが応じているRequestに対応して送られるResponseパケットのVMTPヘッダーの4番目の32ビットの単語に対応するctrl A32ビットの価値。 すなわち、指揮旗、ForwardCount、RetransmitCount、およびPriority分野はRequestのものに合っています。 (receiveSeqNumber分野が使用されているなら、NRS旗は設定されます。) PGCount部分体はこのNotify操作で承認される前のRequestパケットグループの数を示します。 (中で予約される噛み付いている分野
Cheriton [page 96]
Cheriton[96ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
this word in the header are also
reserved here and must be zero.)
ヘッダーのこの単語は、また、ここで予約されて、ゼロであるに違いありません。)
recSeq Sequence number of reception at the
Server if the NRS flag is set in the
ctrl parameter, otherwise reserved and
zero. (This is used for sender-based
logging of message activity for replay
in case of failure - an optional
facility.)
NRSが弛むなら、ServerのレセプションのrecSeq Sequence番号は別の方法で予約されたctrlパラメタとゼロで設定されます。 (これは失敗の場合に再生のためのメッセージ活動の送付者ベースの伐採に使用されます--任意の施設)
delivery Indicates the segment blocks of the
packet group have been received at the
Server.
Serverにセグメントが妨げるパケットグループの配送Indicatesを受け取りました。
code indicates the action the client should
take, as described below.
コードは以下で説明されるようにクライアントが取るべきである行動を示します。
The VMTP management module should take action on this
operation according to the code, as specified below.
コードによると、VMTP管理モジュールは以下で指定されるとしてこの操作を実行するべきです。
OK Do nothing at this time, continue
waiting for the response with a reset
timer.
Doを承認してください、無、このとき、リセットタイマによる応答を待ち続けてください。
RETRY Retransmit the request packet group
immediately with at least the segment
blocks that the Server failed to
receive, the complement of those
indicated by the delivery parameter.
リクエスト・パケットがすぐにServerが受け取らなかったセグメントブロック、少なくとも配送パラメタによって示されたそれらの補数で分類するRETRY Retransmit。
RETRY_ALL Retransmit the request packet group
immediately with at least the segment
blocks that the Server failed to
receive, as indicated by the delivery
field plus all subsequently transmitted
packets that are part of this packet
run. (The latter is applicable only for
streamed message transactions.)
RETRY、_リクエスト・パケットがすぐに少なくともServerが次に配送分野とすべてによって示されるように受け取らなかったセグメントブロックで分類するすべてのRetransmitがこのパケット走行の一部であるパケットを伝えました。 (流されたメッセージトランザクションだけに、後者は適切です。)
BUSY The server was unable to accept the
Request at this time. Retry later if
desired to continue with the message
transaction.
BUSY、サーバはこのとき、要請を受け入れることができませんでした。 メッセージトランザクションを続行することが望まれているなら、後で再試行してください。
NONEXISTENT_ENTITY
Specified Server entity does not exist.
NONEXISTENT_ENTITY Specified Server実体は存在していません。
Cheriton [page 97]
Cheriton[97ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
ENTITY_MIGRATED The server entity has migrated and is no
longer at the host to which the request
was sent. The Server should attempt to
determine the new host address of the
Client using the VMTP management
ProbeEntity operation (described
earlier).
ENTITY_MIGRATED、サーバ実体は、移行して、もう要求が送られたいずれのホストにもありません。 Serverは、VMTP管理ProbeEntity操作(より早く説明される)を使用することでClientの新しいホスト・アドレスを決定するのを試みるはずです。
NO_PERMISSION Server has not authorized reception of
messages from this client.
いいえ_PERMISSION Serverはこのクライアントからのメッセージのレセプションを認可していません。
NOT_AWAITING_MSG
The conditional message delivery bit was
set for the Request packet group and the
Server was not waiting for it so the
Request packet group was discarded.
_AWAITING_MSGの配送ビットがRequestパケットグループに設定されたという条件付きのメッセージとServerでないのがそれを待っていなかったので、Requestパケットグループは捨てられました。
VMTP_ERROR The Request packet group was in error
relative to the VMTP protocol
specification.
Requestパケットが分類するVMTP_ERRORはVMTPプロトコル仕様に比例して間違っていました。
BAD_TRANSACTION_ID
Transaction identifier is old relative
to the transaction identifier held for
the Client by the Server.
BAD_TRANSACTION_ID Transaction識別子はClientのためにServerによって保持されたトランザクション識別子に比例して古いです。
STREAMING_NOT_SUPPORTED
Server does not support multiple
outstanding message transactions from
the same Client, i.e. streamed message
transactions.
SUPPORTED Serverがすなわち、同じClient、流されたメッセージトランザクションから複数の傑出しているメッセージトランザクションをサポートしない_ではなく、STREAMING_。
SECURITY_NOT_SUPPORTED
The Request was secure and this Server
does not support security.
_SUPPORTED Requestではなく、SECURITY_が安全でした、そして、このServerはセキュリティをサポートしません。
SECURITY_REQUIRED
The Server is refusing the Request
because it was not encrypted.
それが暗号化されなかったので、SECURITY_REQUIRED ServerはRequestを拒否しています。
NO_RUN_RECORD Server has no record of previous packets
in this run of packet groups. This can
occur if the first packet group is lost
or if the current packet group is sent
significantly later than the last one
and the Server has discarded its client
state record.
_RUN_RECORD Serverがないのはパケットグループのこの走行で前のパケットに関する記録を全く持っていません。 最初のパケットグループが無くなるか、または後で最後のものよりかなり現在のパケットグループを送るなら、これは起こることができます、そして、Serverは属国記録を捨てました。
Cheriton [page 98]
Cheriton[98ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
0x45000110 - NotifyVmtpServer(server,client,transact,delivery,code)->()
Update the server state associated with the transaction
specified by client and transact, an entity identifier
and transaction identifier, respectively. This
operation is normally used only by another VMTP
management module. (Note that it is a datagram
operation.) The other parameters are as follows:
0×45000110 --NotifyVmtpServer、(サーバ、クライアントが商取引する、配送、コード) ->()はそれぞれトランザクションに関連している州がクライアントで指定して、商取引するサーバ、エンティティ識別名、およびトランザクション識別子をアップデートします。 通常、この操作は単に別のVMTP管理モジュールで使用されます。 (それがデータグラム操作であることに注意してください。) 他のパラメタは以下の通りです:
delivery Indicates the segment blocks of the
Response packet group that have been
received at the Client.
セグメントが妨げるClientに受け取られたResponseパケットグループの配送Indicates。
code indicates the action the Server should
take, as listed below.
コードは以下に記載されているようにServerが取るはずである行動を示します。
The VMTP management module should take action on this
operation according to the code, as specified below.
コードによると、VMTP管理モジュールは以下で指定されるとしてこの操作を実行するべきです。
OK Client is satisfied with Response data.
The Server can discard the response
data, if any.
OK ClientはResponseデータに満足しています。 Serverはもしあれば応答データを捨てることができます。
RETRY Retransmit the Response packet group
immediately with at least the segment
blocks that the Client failed to
receive, as indicated by the delivery
parameter. (The delivery parameter
indicates those segment blocks received
by the Client).
Responseパケットがすぐに少なくともClientが配送パラメタによって示されるように受け取らなかったセグメントブロックで分類するRETRY Retransmit。 (配送パラメタは、それらのセグメントブロックがClientのそばで受信されたのを示します。)
RETRY_ALL Retransmit the Response packet group
immediately with at least the segment
blocks that the Client failed to
receive, as indicated by the (complement
of) the delivery parameter. Also,
retransmit all Response packet groups
send subsequent to the specified packet
group.
パケットがすぐに少なくともClientが示されるように受け取らなかったセグメントブロックで分類するRETRY_すべてのRetransmit Response、(補数、)、配送パラメタ。 また、指定されたパケットグループにその後でグループが送るすべてのResponseパケットを再送してください。
NONEXISTENT_ENTITY
Specified Client entity does not exist.
NONEXISTENT_ENTITY Specified Client実体は存在していません。
ENTITY_MIGRATED The Client entity has migrated and is no
longer at the host to which the response
was sent.
ENTITY_MIGRATED、Client実体は、移行して、もう応答が送られたいずれのホストにもありません。
RESPONSE_DISCARDED
応答_は捨てました。
Cheriton [page 99]
Cheriton[99ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
The Response was discarded and no longer
of interest to the Client. This may
occur if the conditional message
delivery bit was set for the Response
packet group and the Client was not
waiting for it so the Response packet
group was discarded.
Responseは捨てられてもうClientに興味がありませんでした。 条件付きのメッセージ配送ビットがResponseパケットグループに設定されたなら、これは起こったかもしれなくて、Clientがそれを待っていなかったので、Responseパケットグループは捨てられました。
VMTP_ERROR The Response packet group was in error
relative to the VMTP protocol
specification.
Responseパケットが分類するVMTP_ERRORはVMTPプロトコル仕様に比例して間違っていました。
0x41000111 -
NotifyRemoteVmtpClient(client,ctrl,recSeq,transact,delivery,code->()
0×41000111 --NotifyRemoteVmtpClient、(クライアント、ctrl、recSeqが商取引する、配送、コード->。()
The same as NotifyVmtpClient except the co-resident
addressing is not used. This operation is used to
update client state that is remote when a Request is
forwarded.
コレジデントアドレシング以外のNotifyVmtpClientと同じくらいは使用されていません。 この操作は、Requestを進めるときリモートな属国をアップデートするのに使用されます。
Note the use of the CRE bit in the RequestCodes to route the request to the correct VMTP management module(s) to handle the request.
RequestCodesにおけるCREビットの使用に注意して、正しいVMTP管理モジュールに要求を発送して、要求を扱ってください。
III.1. Entity Group Management
III.1。 実体集団経営
An entity in a group has a set of permissions associated with its
membership, controling whether it can add or remove others, whether it
can remove itself, and whether others can remove it from the group. The
permissions for entity groups are as follows:
VMTP_GRP_MANAGER 0x00000001 { Manager of group. }
VMTP_REM_BY_SELF 0x00000002 { Can be removed self. }
VMTP_REM_BY_PRIN 0x00000004 { Can be rem'ed by same principal}
VMTP_REM_BY_OTHE 0x00000008 { Can be removed any others. }
VMTP_ADD_PRIN 0x00000010 { Can add by same principal. }
VMTP_ADD_OTHE 0x00000020 { Can add any others. }
VMTP_REM_PRIN 0x00000040 { Can remove same principal. }
VMTP_REM_OTHE 0x00000080 { Can remove any others. }
グループにおける実体には、会員資格に関連している許容のセットがあります、他のものを加えるか、または外すことができることにかかわらずcontrolingして、立ち退くことができて、他のものがグループからそれを取り除くことができるか否かに関係なく。 実体グループのための許容は以下の通りです: VMTP_GRP_マネージャ0x00000001、グループのマネージャ。 VMTP_REM_BY_SELF、0×00000002 取り除かれた自己はそうであることができます。 VMTP_REM_BY_プラン0x00000004が同じ主体によるrem'edであるかもしれない、VMTP_REM_BY_OTHE0x00000008、取り除かれたいずれかが他のものであったならそうすることができます。 VMTP_ADD_プラン0x00000010、同じ主体で加えることができます。 VMTP_ADD_OTHE0x00000020、どんな他のものも加えることができます。 VMTP_REM_プラン0x00000040、同じ主体を取り除くことができます。 VMTP_レム_OTHE0x00000080どんな他のものも外すことができます。
To remove an entity from a restricted group, the invoker must have permission to remove that entity and the entity must have permissions that allow it to be removed by that entity. With an unrestricted group, only the latter condition applies.
呼び出し元には、制限されたグループから実体を取り除くために、その実体を取り除く許可がなければなりません、そして、実体には、それがその実体によって取り除かれるのを許容する許容がなければなりません。 無制限なグループと共に、後者の状態だけが適用されます。
With a restricted group, a member can only be added by another entity with the permissions to add other entities. The creator of a group is given full permissions on a group. A entity adding another entity to a
メンバーは許容がある別の実体によって加えられるだけであって、制限されたグループと共に、他の実体を加えることができます。 グループで完全な許容をグループのクリエイターに与えます。 別の実体をaに加える実体
Cheriton [page 100]
Cheriton[100ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
group can only give the entity it adds a subset of its permissions. With unrestricted groups, any entity can add itself to the group. It can also add other entities to the group providing the entity is not marked as immune to such requests. (This is an implementation restriction that individual entities can impose.)
グループはそれが加える実体に許容の部分集合を与えることができるだけです。 無制限なグループと共に、どんな実体もそれ自体をグループに追加できます。 また、実体がそのような要求に免疫があるとしてマークされないなら、それは他の実体をグループに追加できます。 (これは個々の実体がでしゃばることができるという実装制限です。)
III.2. VMTP Management Digital Signatures
III.2。 VMTP管理デジタル署名
As mentioned above, the entityId field of the AddToGroup and RemoveFromGroup is used to transmit a digital signature indicating the permission for the operation has been checked by the sending kernel. The digital signature procedures have not yet been defined. This field should be set to 0 for now to indicate no signature after the CREntity parameter is set to the entity on which the operation is to be performed.
以上のように、AddToGroupとRemoveFromGroupのentityId分野は、操作のための許可が送付カーネルによってチェックされたのを示すデジタル署名を伝えるのに使用されます。 デジタル署名手順はまだ定義されていません。 当分0にCREntityパラメタが実行される操作がことである実体に設定された後にこの分野が署名を全く示さないように設定されるべきです。
Cheriton [page 101]
Cheriton[101ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
IV. VMTP Entity Identifier Domains
IV。 VMTPエンティティ識別名ドメイン
VMTP allows for several disjoint naming domains for its endpoints. The 64-bit entity identifier is only unique and meaningful within its domain. Each domain can define its own algorithm or mechanism for assignment of entity identifiers, although each domain mechanism must ensure uniqueness, stability of identifiers and host independence.
VMTPは数個を考慮します。ドメインを終点にちなんで命名するのをばらばらにならせてください。 64ビットのエンティティ識別名は、ドメインの中でユニークであるだけであって重要です。 各ドメインはエンティティ識別名の課題のためにそれ自身のアルゴリズムかメカニズムを定義できます、それぞれのドメインメカニズムがユニークさ、識別子とホスト独立の安定性を確実にしなければなりませんが。
IV.1. Domain 1
IV.1。 ドメイン1
For initial use of VMTP, we define the domain with Domain identifier 1 as follows:
VMTPの初期の使用のために、Domain識別子1は以下の通りで私たちはドメインを定義します:
+-----------+----------------+------------------------+
| TypeFlags | Discriminator | Internet Address |
+-----------+----------------+------------------------+
4 bits 28 bits 32 bits
+-----------+----------------+------------------------+ | TypeFlags| 弁別器| インターネットアドレス| +-----------+----------------+------------------------+ 4ビット28ビット32ビット
The Internet address is the Internet address of the host on which this
entity-id is originally allocated. The Discriminator is an arbitrary
value that is unique relative to this Internet host address. In
addition, the host must guarantee that this identifier does not get
reused for a long period of time after it becomes invalid. ("Invalid"
means that no VMTP module considers in bound to an entity.) One
technique is to use the lower order bits of a 1 second clock. The clock
need not represent real-time but must never be set back after a crash.
In a simple implementation, using the low order bits of a clock as the
time stamp, the generation of unique identifiers is overall limited to
no more than 1 per second on average. The type flags were described in
Section 3.1.
インターネット・アドレスはこの実体イドが元々割り当てられるホストのインターネット・アドレスです。 Discriminatorはこのインターネットホスト・アドレスに比例してユニークな任意の値です。 さらに、ホストは、無効になった長い年月の間後にこの識別子が再利用されないのを保証しなければなりません。 (どんなVMTPモジュールも考えない「無効」の手段は実体にバウンドしています。) 1つのテクニックは1 2番目のビットが時間を計る下層階級を使用することです。 しかし、時計が表す必要はない、リアルタイムで、クラッシュの後に決して遅らせてはいけません。 1秒あたり1未満に平均的に制限されて、全体的に見てスタンプ、ユニークな識別子の世代がいる時として時計の下位のビットを使用する簡単な実装で。 タイプ旗はセクション3.1で説明されました。
An entity may migrate between hosts. Thus, an implementation can heuristically use the embedded Internet address to locate an entity but should be prepared to maintain a cache of redirects for migrated entities, plus accept Notify operations indicating that migration has occurred.
実体はホストの間を移住するかもしれません。 したがって、缶がキャッシュを維持するのに、実体の場所を見つけるように扱いますが、インターネットが準備されるべきである埋め込みを発見的に使用する実装は、移行が起こったのを示すNotify操作を、移行した実体のために向け直して、受け入れます。
Entity group identifiers in Domain 1 are structured in one of two forms, depending on whether they are well-known or dynamically allocated identifiers. A well-known entity identifier is structured as:
Domain1の実体グループ識別子は2つのフォームの1つで構造化されます、それらがよく知られるかダイナミックに割り当てられた識別子であるかどうかによって。 よく知られるエンティティ識別名は以下として構造化されます。
+-----------+----------------+------------------------+
| TypeFlags | Discriminator |Internet Host Group Addr|
+-----------+----------------+------------------------+
4 bits 28 bits 32 bits
+-----------+----------------+------------------------+ | TypeFlags| 弁別器|インターネットホストグループAddr| +-----------+----------------+------------------------+ 4ビット28ビット32ビット
Cheriton [page 102]
Cheriton[102ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
with the second high-order bit (GRP) set to 1. This form of entity identifier is mapped to the Internet host group address specified in the low-order 32 bits. The Discriminator distinguishes group identifiers using the same Internet host group. Well-known entity group identifiers should be allocated to correspond to the basic services provided by hosts that are members of the group, not specifically because that service is provided by VMTP. For example, the well-known entity group identifier for the domain name service should contain as its embedded Internet host group address the host group for Domain Name servers.
2番目の高位のビットで、(GRP)は1にセットしました。 このフォームに関するエンティティ識別名は下位の32ビットで指定されたインターネット・ホストグループアドレスに写像されます。 Discriminatorは、同じインターネット・ホストグループを使用することでグループ識別子を区別します。 グループのメンバーであるホストによって提供された基本サービスに相当するようによく知られる実体グループ識別子を割り当てるべきです、そのサービスがVMTPによって明確にない提供されるので。 例えば、ドメイン名サービスのためのよく知られる実体グループ識別子は埋め込まれたインターネット・ホストグループアドレスとしてDomain Nameサーバのためのホストグループを含むべきです。
A dynamically allocated entity identifier is structured as:
ダイナミックに割り当てられたエンティティ識別名は以下として構造化されます。
+-----------+----------------+------------------------+
| TypeFlags | Discriminator | Internet Host Addr |
+-----------+----------------+------------------------+
4 bits 28 bits 32 bits
+-----------+----------------+------------------------+ | TypeFlags| 弁別器| インターネットホストAddr| +-----------+----------------+------------------------+ 4ビット28ビット32ビット
with the second high-order bit (GRP) set to 1. The Internet address in the low-order 32 bits is a Internet address assigned to the host that dynamically allocates this entity group identifier. A dynamically allocated entity group identifier is mapped to Internet host group address 232.X.X.X where X.X.X are the low-order 24 bits of the Discriminator subfield of the entity group identifier.
2番目の高位のビットで、(GRP)は1にセットしました。 下位の32ビットのインターネット・アドレスはダイナミックにこの実体グループ識別子を割り当てるホストに割り当てられたインターネット・アドレスです。 ダイナミックに割り当てられた実体グループ識別子はX.X.Xが実体グループ識別子のDiscriminator部分体の下位の24ビットであるインターネット・ホストグループアドレス232.X.X.Xに写像されます。
We use the following notation for Domain 1 entity identifiers <10> and propose it use as a standard convention.
それを提案してください。そして、私たちがDomain1エンティティ識別名<に以下の記法を使用する、10>、一般的なコンベンションとして、使用します。
<flags>-<discriminator>-<Internet address>
<が>に旗を揚げさせる、-、インターネットが>を扱う<弁別器>-<。
where <flags> are [X]{BE,LE,RG,UG}[A]
<がどこで>に旗を揚げさせるかが、[X]である、LE、RG、UG[A]
X = reserved
BE = big-endian entity
LE = little-endian entity
RG = restricted group
UG = unrestricted group
A = alias
無制限な=ビッグエンディアン実体LE=リトルエンディアン実体RG=制限されたグループUG=グループAが=別名であったなら予約されたX=
and <discriminator> is a decimal integer and <Internet address> is in standard dotted decimal IP address notation.
そして、<弁別器>は10進整数です、そして、<インターネット・アドレス>が標準のドット付き10進法IPアドレス記法であります。
Examples:
例:
_______________
_______________
<10> This notation was developed by Steve Deering.
<10>、この記法はスティーブ・デアリングによって開発されました。
Cheriton [page 103]
Cheriton[103ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
BE-25593-36.8.0.49 is big-endian entity #25593 created on host
36.8.0.49.
-25593-36.8にである.0 .49 ホスト36.8.0で作成されたビッグエンディアン実体#25593は.49ですか?
RG-1-224.0.1.0 is the well-known restricted VMTP managers group.
RG-1-224.0.1.0はよく知られる制限されたVMTP幹事グループです。
UG-565338-36.8.0.77 is unrestricted entity group #565338 created on host
36.8.0.77.
UG-565338-36.8.0.77はホスト36.8.0で.77に作成された無制限な実体グループ#565338です。
LEA-7823-36.8.0.77 is a little-endian alias entity #7823 created on host
36.8.0.77.
LEA-7823-36.8、.0、.77、リトルエンディアンが7823がホストで作成した別名実体#である、36.8、.0、.77
This notation makes it easy to communicate and understand entity identifiers for Domain 1.
この記法で、Domain1のためのエンティティ識別名を伝えて、理解しているのは簡単になります。
The well-known entity identifiers specified to date are:
これまで指定されたよく知られるエンティティ識別名は以下の通りです。
VMTP_MANAGER_GROUP RG-1-224.0.1.0
Managers for VMTP operations.
VMTP操作のためのVMTP_マネージャ_GROUP RG-1-224.0.1.0人のマネージャ。
VMTP_DEFAULT_BECLIENT BE-1-224.0.1.0
Client entity identifier to use when a (big-endian) host
has not determined or been allocated any client entity
identifiers.
(ビッグエンディアン)ホストであるときに使用するVMTP_DEFAULT_BECLIENT BE1-224.0.1.0Clientエンティティ識別名は決定しないか、または少しのクライアントエンティティ識別名も割り当てられていません。
VMTP_DEFAULT_LECLIENT LE-1-224.0.1.0
Client entity identifier to use when a (little-endian)
host has not determined or been allocated any client
entity identifiers.
(リトルエンディアン)ホストであるときに使用するVMTP_DEFAULT_LECLIENT LE-1-224.0.1.0 Clientエンティティ識別名は決定しないか、または少しのクライアントエンティティ識別名も割り当てられていません。
Note that 224.0.1.0 is the host group address assigned to VMTP and to which all VMTP hosts belong.
それに注意してください。224.0 .1 .0 ホストグループアドレスがVMTPに割り当てられて、すべてのVMTPホストが属する。
Other well-known entity group identifiers will be specified in subsequent extensions to VMTP and in higher-level protocols that use VMTP.
他のよく知られる実体グループ識別子はVMTPへのその後の拡大とVMTPを使用する上位レベル・プロトコルで指定されるでしょう。
IV.2. Domain 3
IV.2。 ドメイン3
Domain 3 is reserved for embedded systems that are restricted to a single network and are independent of IP. Entity identifiers are allocated using the decentralized approach described below. The mapping of entity group identifiers is specific to the type of network being used and not defined here. In general, there should be a simple algorithmic mapping from entity group identifier to multicast address, similar to that described for Domain 1. Similarly, the values for default client identifier are specific to the type of network and not
ドメイン3はただ一つのネットワークに制限された、IPから独立している組込み型システムのために予約されます。 以下で説明された分散アプローチを使用することでエンティティ識別名を割り当てます。 使用されて、ここで定義されないネットワークのタイプに、実体グループ識別子のマッピングは特定です。 一般に、実体グループ識別子からマルチキャストアドレスまで簡単なアルゴリズムのマッピングがあるべきです、Domain1のために説明されたそれと同様です。 そしてネットワークのタイプには、同様に、デフォルトクライアント識別子のための値が特定である。
Cheriton [page 104]
Cheriton[104ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
defined here.
ここで、定義されます。
IV.3. Other Domains
IV.3。 他のドメイン
Definition of additional VMTP domains is planned for the future. Requests for allocation of VMTP Domains should be addressed to the Internet protocol administrator.
追加VMTPドメインの定義は未来に計画されています。 VMTP Domainsの配分を求める要求はインターネットプロトコル管理者に扱われるべきです。
IV.4. Decentralized Entity Identifier Allocation
IV.4。 分散エンティティ識別名配分
The ProbeEntityBlock operation may be used to determine whether a block
of entity identifiers is in use. ("In use" means valid or reserved by a
host for allocation.) This mechanism is used to detect collisions in
allocation of blocks of entity identifiers as part of the implementation
of decentralized allocation of entity identifiers. (Decentralized
allocation is used in local domain use of VMTP such as in embedded
systems- see Domain 3.)
ProbeEntityBlock操作は、1ブロックのエンティティ識別名が使用中であるかどうか決定するのに使用されるかもしれません。 (配分のために有効であることを意味したか、またはホストによって予約された「使用」。) このメカニズムは、エンティティ識別名の分散配分の実装の一部としてブロックのエンティティ識別名の配分における衝突を検出するのに使用されます。 (分散配分は組込み型システムでDomain3を見るようなVMTPの局所領域使用で使用されます。)
Basically, a group of hosts can form a Domain or sub-Domain, a group of hosts managing their own entity identifier space or subspace, respectively. As an example of a sub-Domain, a group of hosts in Domain 1 all identified with a particular host group address can manage the sub-Domain corresponding to all entity identifiers that contain that host group address. The ProbeEntityBlock operation is used to allocate the random bits of these identifiers as follows.
基本的に、ホストのグループはDomainかサブDomainを形成できます、ホストのグループがそれぞれそれら自身のエンティティ識別名スペースか部分空間を管理して。 サブDomainに関する例として、特定のホストグループアドレスとすべて同一視されたDomain1のホストのグループはそのホストグループアドレスを含むすべてのエンティティ識別名にサブDomain対応に対処できます。 ProbeEntityBlock操作は、以下のこれらの識別子の無作為のビットを割り当てるのに使用されます。
When a host requires a new block of entity identifiers, it selects a new block (randomly or by some choice algorithm) and then multicasts a ProbeEntityBlock request to the members of the (sub-)Domain some R times. If no response is received after R (re)transmissions, the host concludes that it is free to use this block of identifiers. Otherwise, it picks another block and tries again.
ホストがエンティティ識別名の新しいブロックを必要として、新しいブロック(無作為か何らかの特選しているアルゴリズムによる)を選択して、次に、いつでa ProbeEntityBlockが要求するマルチキャストをメンバーに選択するか、(サブ、)、ドメイン、いくつかのR回。 R(re)トランスミッションの後に応答を全く受けないなら、ホストは、自由に識別子のこのブロックを使用できると結論を下します。 さもなければ、それは、別のブロックを選んで、再び試みます。
Notes:
注意:
1. A block of 256 identifiers is specified by an entity
identifier with the low-order 8 bits all zero.
1. 256の識別子のブロックは8ビットがすべて、合っているゼロ下位があるエンティティ識別名によって指定されます。
2. When a host allocates an initial block of entity identifiers
(and therefore does not yet have a specified entity
identifier to use) it uses VMTP_DEFAULT_BECLIENT (if
big-endian, else VMTP_DEFAULT_LECLIENT if little-endian) as
its client identifier in the ProbeEntityBlock Request and a
transaction identifier of 0. As soon as it has allocated a
block of entity identifiers, it should use these identifiers
2. ホストがエンティティ識別名(そして、したがって、まだ、使用する指定されたエンティティ識別名を持っていない)の初期のブロックを割り当てるとき、VMTP_DEFAULT_BECLIENTを使用する、(ビッグエンディアン、_のVMTP_DEFAULT LECLIENTである、ほかのリトルエンディアン) ProbeEntityBlock Requestのクライアント識別子と0に関するトランザクション識別子として。 1ブロックのエンティティ識別名を割り当てるとすぐに、それはこれらの識別子を使用するべきです。
Cheriton [page 105]
Cheriton[105ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
for all subsequent communication. The default client
identifier values are defined for each Domain.
すべてのその後のコミュニケーションのために。 デフォルトクライアント識別子値は各Domainのために定義されます。
3. The set of hosts using this decentralized allocation must not
be subject to network partitioning. That is, the R
transmissions must be sufficient to ensure that every host
sees the ProbeEntityBlock request and (reliably) sends a
response. (A host that detects a collision can retransmit
the response multiple times until it sees a new
ProbeEntityBlock operation from the same host/Client up to a
maximum number of times.) For instance, a set of machines
connected by a single local network may able to use this type
of allocation.
3. この分散配分を使用しているホストのセットはネットワーク仕切りを受けることがあるはずがありません。 すなわち、Rトランスミッションは、すべてのホストがProbeEntityBlock要求を見て、応答を(確かに)送るのを保証するために十分でなければなりません。 (同じホスト/クライアントから新しいProbeEntityBlock操作を最大数の倍まで見るまで、衝突を検出するホストは応答を複数の回再送できます。) 例えば、1セットのマシンはこのタイプの配分を使用できる状態で企業内情報通信網が接続するシングルを接続しました。
4. To guarantee T-stability, a host must prevent reuse of a
block of identifiers if any of the identifiers in the block
are currently valid or have been valid less than T seconds
previously. To this end, a host must remember recently used
identifiers and object to their reuse in response to a
ProbeEntityBlock operation.
4. T-安定性を保証するために、ブロックの識別子のどれかが現在、有効であるか、または以前にT秒よりそれほど有効であるなら、ホストは1ブロックの識別子の再利用を防がなければなりません。 このために、ホストは、最近中古の識別子を覚えていて、ProbeEntityBlock操作に対応して彼らの再利用に反対しなければなりません。
5. Care is required in a VMTP implementation to ensure that
Probe operations cannot be discarded due to lack of buffer
space or queued or delayed so that a response is not
generated quickly. This is required not only to detect
collisions but also to provide accurate roundtrip estimates
as part of ProbeEntity operations.
5. 注意は、応答がすぐに生成されないように、VMTP実装でバッファ領域の不足のためProbe操作を捨てることができないのを保証するのが必要である、列に並ばせられるか、または遅れます。 これが、単に衝突を検出するのではなく、ProbeEntity操作の一部として正確な往復の見積りを提供もするのに必要です。
Cheriton [page 106]
Cheriton[106ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
V. Authentication Domains
V。 認証ドメイン
A VMTP authentication domain defines the format and interpretation for principal identifiers and encryption keys. In particular, an authentication domain must specify a means by which principal identifiers are allocated and guaranteed unique and stable. The currently defined authentication domains are as follows (0 is reserved).
VMTP認証ドメインは主要な識別子と暗号化キーのための書式と解釈を定義します。 特に、認証ドメインはどの主要な識別子が割り当てられて、保証されるかによってユニークで安定した手段を指定しなければなりません。 現在定義された認証ドメインは以下の通りです(0は予約されています)。
Ideally, all entities within one entity domain are also associated with one authentication domain. However, authentication domains are orthogonal to entity domains. Entities within one domain may have different authentication domains. (In this case, it is generally necessary to have some correspondence between principals in the different domains.) Also, one entity identifier may be associated with multiple authentication domains. Finally, one authentication domain may be used across multiple entity domains.
また、理想的に、1つの実体ドメインの中のすべての実体も1つの認証ドメインに関連しています。 しかしながら、認証ドメインは実体ドメインと直交しています。 1つのドメインの中の実体には、異なった認証ドメインがあるかもしれません。 (この場合、一般に、異なったドメインに主体の間の何らかの通信を持つのが必要です。) また、1つのエンティティ識別名も複数の認証ドメインに関連しているかもしれません。 最終的に、1つの認証ドメインが複数の実体ドメインの向こう側に使用されるかもしれません。
V.1. Authentication Domain 1
V.1。 認証ドメイン1
A principal identifier is structured as follows.
主要な識別子は以下の通り構造化されます。
+---------------------------+------------------------+
| Internet Address | Local User Identifier |
+---------------------------+------------------------+
32 bits 32 bits
+---------------------------+------------------------+ | インターネットアドレス| ローカルユーザー識別子| +---------------------------+------------------------+ 32ビット32ビット
The Internet Address may specify an individual host (such as a UNIX machine) or may specify a host group address corresponding to a cluster of machines operating under a single adminstration. In both cases, there is assumed to be an adminstration associated with the embedded Internet address that guarantees the uniqueness and stability of the User Identifier relative to the Internet address. In particular, that administration is the only one authorized to allocate principal identifiers with that Internet address prefix, and it may allocate any of these identifiers.
インターネットAddressは個々のホスト(Unixマシンなどの)を指定するか、または単一のadminstrationの下で作動するマシンのクラスタに対応するホストグループアドレスを指定するかもしれません。 どちらの場合も、インターネット・アドレスに比例してUser Identifierのユニークさと安定性を保証する埋め込まれたインターネット・アドレスに関連しているadminstrationがいると仮定されます。 その管理は特に、そのインターネット・アドレス接頭語がある主要な識別子を割り当てるのが認可された唯一無二です、そして、それはこれらの識別子のいずれも割り当てるかもしれません。
In authentication domain 1, the standard EncryptionQualifiers are:
認証ドメイン1では、標準のEncryptionQualifiersは以下の通りです。
0 Clear text - no encryption.
0はテキストをクリアします--暗号化がありません。
1 use 64-bit CBC DES for encryption and decryption.
1 暗号化と復号化に64ビットのCBC DESを使用してください。
V.2. Other Authentication Domains
V.2。 他の認証ドメイン
Other authentication domains will be defined in the future as needed.
他の認証ドメインは将来、必要に応じて定義されるでしょう。
Cheriton [page 107]
Cheriton[107ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
VI. IP Implementation
VI。 IP実装
VMTP is designed to be implemented on the DoD IP Internet Datagram Protocol (although it may also be implemented as a local network protocol directly in "raw" network packets.)
VMTPは、DoD IPインターネットデータグラムプロトコルで実装されるように設計されています。(また、それは企業内情報通信網として実装されるかもしれませんが、直接「生」のネットワークパケットで議定書を作ってください。)
VMTP is assigned the protocol number 81.
プロトコル番号81はVMTPに割り当てられます。
With a 20 octet IP header and one segment block, a VMTP packet is 600 octets. By convention, any host implementing VMTP implicitly agrees to accept VMTP/IP packets of at least 600 octets.
20八重奏IPヘッダーと1つのセグメントブロックで、VMTPパケットは600の八重奏です。 コンベンションで、それとなくVMTPを実装するどんなホストも、少なくとも600の八重奏のVMTP/IPパケットを受け入れるのに同意します。
VMTP multicast facilities are designed to work with, and have been implemented using, the multicast extensions to the Internet [8] described in RFC 966 and 988. The wide-scale use of full VMTP/IP depends on the availability of IP multicast in this form.
施設が使用することで働くように設計されていて、実装されたVMTPマルチキャスト、インターネット[8]へのマルチキャスト拡大はRFCで966と988について説明しました。 完全なVMTP/IPの広いスケール使用はこのフォームでのIPマルチキャストの有用性に依存します。
Cheriton [page 108]
Cheriton[108ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
VII. Implementation Notes
VII。 実装注意
The performance and reliability of a protocol in operation is highly dependent on the quality of its implementation, in addition to the "intrinsic" quality of the protocol design. One of the design goals of the VMTP effort was to produce an efficiently implementable protocol. The following notes and suggestions are based on experience with implementing VMTP in the V distributed system and the UNIX 4.3 BSD kernel. The following is described for a client and server handling only one domain. A multi-domain client or server would replicate these structures for each domain, although buffer space may be shared.
プロトコルの性能と稼働中である信頼性は実装の品質に非常に依存しています、プロトコルデザインの「本質的な」品質に加えて。 VMTP取り組みのデザイン目標の1つが生産することであった、効率的に、実装可能は議定書を作ります。 以下の注意と提案はV分散システムとUNIX4.3BSDカーネルでVMTPを実装する経験に基づいています。 以下は1つのドメインだけを扱うクライアントとサーバのために説明されます。 バッファ領域は共有されるかもしれませんが、マルチドメインクライアントかサーバが各ドメインにこれらの構造を模写するでしょう。
VII.1. Mapping Data Structures
VII.1。 データ構造を写像します。
The ClientMap procedure is implemented using a hash table that maps to the Client State Record whether this entity is local or remote, as shown in Figure VII-1.
ClientMap手順はこの実体が地方である、またはリモートであることにかかわらず州RecordをClientに写像するハッシュ表を使用することで実装されます、図VII-1に示されるように。
+---+---+--------------------------+
ClientMap | | x | |
+---+-|-+--------------------------+
| +--------------+ +--------------+
+-->| LocalClient |--->| LocalClient |
+--------------+ +--------------+
| RemoteClient | | RemoteClient |-> ...
+--------------+ +--------------+
| | | |
| | | |
+--------------+ +--------------+
+---+---+--------------------------+ ClientMap| | x| | +---+-|-+--------------------------+ | +--------------+ +--------------+ +-->| LocalClient|、-、--、>| LocalClient| +--------------+ +--------------+ | RemoteClient| | RemoteClient|->… +--------------+ +--------------+ | | | | | | | | +--------------+ +--------------+
Figure VII-1: Mapping Client Identifier to CSR
VII-1は計算します: クライアント識別子をCSRに写像します。
Local clients are linked through the LocalClientLink, similarly for the RemoteClientLink. Once a CSR with the specified Entity Id is found, some field or flag indicates whether it is identifying a local or remote Entity. Hash collisions are handled with the overflow pointers LocalClientLink and RemoteClientLink (not shown) in the CSR for the LocalClient and RemoteClient fields, respectively. Note that a CSR representing an RPC request has both a local and remote entity identifier mapping to the same CSR.
地元のクライアントはRemoteClientLinkのためにLocalClientLinkを通して同様にリンクされます。 それが地方の、または、リモートなEntityを特定しているか否かに関係なく、何らかの分野か旗が、一度、指定されたEntity IdとCSRが見つけられるのを示します。 ハッシュ衝突はオーバーフロー指針のLocalClientLinkとRemoteClientLink(目立たない)と共にCSRでLocalClientとRemoteClient分野にそれぞれ扱われます。 RPC要求を表すCSRが地方の、そして、リモートなエンティティ識別名マッピングを同じCSRに持っていることに注意してください。
The Server specified in a Request is mapped to a server descriptor using the ServerMap (with collisions handled by the overflow pointer.). The server descriptor is the root of a queue of CSR's for handling requests plus flags that modify the handling of the Request. Flags include:
Requestで指定されたServerは、ServerMap(衝突がオーバーフロー指針によって扱われている)を使用することでサーバ記述子に写像されます。 サーバ記述子はRequestの取り扱いを変更する取り扱い要求と旗のためのCSRの待ち行列の根です。 旗は:
Cheriton [page 109]
Cheriton[109ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
+-------+---+-------------------------+
ServerMap | | x | |
+-------+-|-+-------------------------+
| +--------------+
| | OverflowLink |
| +--------------+
+-->| Server |
+--------------+
| Flags | Lock |
+--------------+
| Head Pointer |
+--------------+
| Tail Pointer |
+--------------+
+-------+---+-------------------------+ ServerMap| | x| | +-------+-|-+-------------------------+ | +--------------+ | | OverflowLink| | +--------------+ +-->| サーバ| +--------------+ | 旗| 錠| +--------------+ | ヘッド指針| +--------------+ | テール指針| +--------------+
Figure VII-2: Mapping Server Identifiers
VII-2は計算します: サーバ識別子を写像します。
THREAD_QUEUE Request is to be invoked directly as a remote procedure
invocation, rather than by a server process in the
message model.
THREAD_QUEUE Requestは直接メッセージモデルのサーバプロセスでというよりむしろリモート手順実施として呼び出されることになっています。
AUTHENTICATION_REQUIRED
Sent a Probe request to determine principal associated
with the Client, if not known.
知られないなら、REQUIRED Sent a Probeが主体を決定するよう要求するAUTHENTICATION_はClientと交際しました。
SECURITY_REQUIRED
Request must be encrypted or else reject.
暗号化されていて、REQUIRED RequestがそうしなければならないSECURITY_か廃棄物。
REQUESTS_QUEUED Queue contains waiting requests, rather than free CSR's.
Queue this request as well.
REQUESTS_QUEUED Queueは自由なCSRのものよりむしろ待ち要求を含んでいます。 また、この要求を列に並ばせてください。
SERVER_WAITING The server is waiting and available to handle incoming
Request immediately, as required by CMD.
SERVER_WAITING、サーバは、すぐに必要に応じてCMDで入って来るRequestを扱うために待って利用可能です。
Alternatively, the Server identifiers can be mapped to a CSR using the MapToClient mechanism with a pointer in the CSR refering to the server descriptor, if any. This scheme is attractive if there are client CSR's associated with a service to allow it to communicate as a client using VMTP with other services.
あるいはまた、CSR referingの指針と共にサーバ記述子にMapToClientメカニズムをもしあれば使用することでServer識別子をCSRに写像できます。 クライアントCSRのものがクライアントとしてコミュニケートするのを許すサービスに関連していた状態であれば、この体系は、他のサービスがあるVMTPを使用することで魅力的です。
Finally, a similar structure is used to expand entity group identifiers to the local membership, as shown in Figure VII-3. A group identifier is hashed to an index in the GroupMap. The list of group descriptors rooted at that index in the GroupMap contains a group descriptor for each local member of the group. The flags are the group permissions defined in Appendix III.
最終的に、類似構造物は、実体グループ識別子を地方の会員資格に広げるのに図VII-3に示されるように使用されます。 グループ識別子はGroupMapのインデックスに論じ尽くされます。 GroupMapにそのインデックスで根づいているグループ記述子のリストはグループのそれぞれの地元のメンバーへのグループ記述子を含んでいます。 旗はAppendix IIIで定義されたグループ許容です。
Cheriton [page 110]
Cheriton[110ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
+-------+---+----------------------------------+
GroupMap | | x | |
+-------+-|-+----------------------------------+
| +--------------+
| | OverflowLink |
| +--------------+
+-->|EntityGroupId |
+--------------+
| Flags |
+--------------+
| Member Entity|
+--------------+
+-------+---+----------------------------------+ GroupMap| | x| | +-------+-|-+----------------------------------+ | +--------------+ | | OverflowLink| | +--------------+ +-->|EntityGroupId| +--------------+ | 旗| +--------------+ | メンバー実体| +--------------+
Figure VII-3: Mapping Group Identifiers
VII-3は計算します: グループ識別子を写像します。
Note that the same pool of descriptors could be used for the server and group descriptors given that they are similar in size.
それらがサイズにおいて同様であるなら記述子の同じプールがサーバとグループ記述子に使用されるかもしれないことに注意してください。
VII.2. Client Data Structures
VII.2。 クライアントデータ構造
Each client entity is represented as a client state record. The CSR contains a VMTP header as well as other bookkeeping fields, including timeout count, retransmission count, as described in Section 4.1. In addition, there is a timeout queue, transmission queue and reception queue. Finally, there is a ServerHost cache that maps from server entity-id records to host address, estimated round trip time, interpacket gap, MTU size and (optimally) estimated processing time for this server entity.
それぞれのクライアント実体は属国記録として表されます。 CSRは他の簿記分野と同様にVMTPヘッダーを含んでいます、タイムアウトカウントを含んでいて、「再-トランスミッション」カウント、セクション4.1で説明されるように。 さらに、タイムアウト待ち行列、トランスミッション待ち行列、およびレセプション待ち行列があります。 最終的に、それがこのサーバ実体のためにホスト・アドレス、およそ周遊旅行時間、interpacketギャップ、MTUサイズ、およびサーバ実体イド記録から(最適に)およその処理時間まで写像するServerHostキャッシュがあります。
VII.3. Server Data Structures
VII.3。 サーバデータ構造
The server maintains a heap of client state records (CSR), one for each (Client, Transaction). (If streams are not supported, there is, at worst, a CSR per Client with which the server has communicated with recently.) The CSR contains a VMTP header as well as various bookkeeping fields including timeout count, retransmission count. The server maintains a hash table mapping of Client to CSR as well as the transmission, timeout and reception queues. In a VMTP module implementing both the client and server functions, the same timeout queue and transmission queue are used for both.
サーバは属国記録(CSR)、それぞれ(クライアント、Transaction)のためのものの山を維持します。 (ストリームがサポートされないなら、最近コミュニケートされて、サーバがそうした1Clientあたり1CSRが最悪の場合はあります。) CSRはタイムアウトを含む様々な簿記分野が重要であるのと同じくらい良いVMTPヘッダー「再-トランスミッション」カウントを含んでいます。 サーバはトランスミッション、タイムアウト、およびレセプション待ち行列と同様にCSRにClientに関するハッシュ表マッピングを維持します。 両方がクライアントであると実装するVMTPモジュールとサーバ機能では、同じタイムアウト待ち行列とトランスミッション待ち行列は両方に使用されます。
Cheriton [page 111]
Cheriton[111ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
VII.4. Packet Group transmission
VII.4。 パケットGroupトランスミッション
The procedure SendPacketGroup( csr ) transmits the packet group specified by the record CSR. It performs:
手順SendPacketGroup(csr)は記録的なCSRによって指定されたパケットグループを伝えます。 それは働きます:
1. Fragmentation of the segment data, if any, into packets.
(Note, segment data flagged by SDA bit.)
1. もしあればパケットへのセグメントデータの断片化。 (注意、SDAビットによって旗を揚げられたセグメントデータ。)
2. Modifies the VMTP header for each packet as required e.g.
changing the delivery mask as appropriate.
2. 各パケットのために必要に応じてVMTPヘッダーを変更する、例えば、適宜配送マスクを変えること。
3. Computes the VMTP checksum.
3. VMTPチェックサムを計算します。
4. Encrypts the appropriate portion of the packet, if required.
4. 必要なら、パケットの適切な部分を暗号化します。
5. Prepends and appends network-level header and trailer using
network address from ServerHost cache, or from the responding
CSR.
5. ServerHostキャッシュ、または、応じているCSRからのネットワーク・アドレスを使用することでネットワークレベルヘッダーとトレーラをPrependsして、追加します。
6. Transmits the packet with the interpacket gap specified in
the cache. This may involve round-robin scheduling between
hosts as well as delaying transmissions slightly.
6. interpacketギャップがキャッシュで指定されている状態で、パケットを伝えます。 これはトランスミッションをわずかに遅らせることと同様にホストの間で連続スケジューリングにかかわるかもしれません。
7. Invokes the finish-up procedure specified by the CSR record,
completing the processing. Generally, this finish-up
procedure adds the record to the timeout queue with the
appropriate timeout queue.
7. 処理を終了して、CSR記録によって指定された終わりの上がっている手順を呼び出します。 一般に、この終わりの上がっている手順は適切なタイムアウト待ち行列でタイムアウト待ち行列に記録を加えます。
The CSR includes a 32-bit transmission mask that indicates the portions of the segment to transmit. The SendPacketGroup procedure is assumed to handle queuing at the network transmission queue, queuing in priority order according to the priority field specified in the CSR record. (This priority may be reflected in network transmission behavior for networks that support priority.)
CSRは伝わるようにセグメントの部分を示す32ビットのトランスミッションマスクを含んでいます。 SendPacketGroup手順がネットワーク送信待ち行列における列を作りを扱うと思われます、CSR記録で指定された優先権分野に従って優先順で列を作って。 (この優先権は優先権をサポートするネットワークのためにネットワーク送信の振舞いに反映されるかもしれません。)
The SendPacketGroup procedure only looks at the following fields of a CSR
SendPacketGroup手順はCSRの以下の分野を見るだけです。
- Transmission mask
- トランスミッションマスク
- FuncCode
- FuncCode
- SDA
- SDA
- Client
- クライアント
- Server
- サーバ
Cheriton [page 112]
Cheriton[112ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
- CoResidentEntity
- CoResidentEntity
- Key
- キー
It modifies the following fields
それは以下の分野を変更します。
- Length
- 長さ
- Delivery
- 配送
- Checksum
- チェックサム
In the case of encrypted transmission, it encrypts the entire packet, not including the Client field and the following 32-bits.
暗号化されたトランスミッションの場合では、それはClient分野と以下の32ビットを含んでいるのではなく、全体のパケットを暗号化します。
If the packet group is a Response, (i.e. lower-order bit of function code is 1) the destination network address is determined from the Client, otherwise the Server. The HostAddr field is set either from the ServerHost cache (if a Request) or from the original Request if a Response, before SendPacketGroup is called.
パケットグループがResponseであるなら、(すなわち、機能コードの下層階級ビットは1です)目的地ネットワーク・アドレスはそうでなければ、Client、Serverから決定しています。HostAddr分野はResponseであるならServerHostキャッシュ(Requestであるなら)かオリジナルのRequestから設定されます、SendPacketGroupが呼ばれる前に。
The CSR includes a timeout and TTL fields indicating the maximum time to complete the processing and the time-to-live for the packets to be transmitted.
CSRはパケットが伝えられるために処理を終了する最大の時間と生きる時間を示すタイムアウトとTTL分野を含んでいます。
SendPacketGroup is viewed as the right functionality to implement for transmission in an "intelligent" network interface.
SendPacketGroupは「知的な」ネットワーク・インターフェースのトランスミッションのために実装する正しい機能性として見なされます。
Finally, it appears preferable to be able to assume that all portions of the segment remain memory-resident (no page faults) during transmission. In a demand-paged systems, some form of locking is required to keep the segment data in memory.
最終的に、セグメントのすべての部分がトランスミッションの間メモリ常駐のままで(ページフォールトがありません)残っていると仮定するのができるように望ましく見えます。 要求で呼び出されたシステムでは、何らかのフォームのロックが、メモリのセグメントデータを保つのに必要です。
VII.5. VMTP Management Module
VII.5。 VMTP管理モジュール
The implementation should implement the management operations as a separate module that is invoked from within the VMTP module. When a Request is received, either from the local user level or the network, for the VMTP management module, the management module is invoked as a remote or local procedure call to handle this request and return a response (if not a datagram request). By registering as a local server, the management module should minimize the special-case code required for its invocation. The management module is basically a case statement that selects the operation based on the RequestCode and then invokes the specified management operation. The procedure implementing the management operation, especially operations like NotifyVmtpClient and
実装は、VMTPモジュールから呼び出される別々のモジュールとして管理が操作であると実装するべきです。 VMTP管理モジュールのために地方のユーザレベルかネットワークからRequestを受け取るとき、この要求を扱って、応答を返すというリモートであるか地方の手順要求(まして、データグラム要求)として管理モジュールを呼び出します。 ローカルサーバとして登録することによって、管理モジュールは実施に必要である特別なケースコードを最小にするべきです。 管理モジュールは基本的にRequestCodeに基づく操作を選択して、次に指定された管理操作を呼び出すケースステートメントです。 そしてNotifyVmtpClientのように管理が操作、特に操作であると実装する手順。
Cheriton [page 113]
Cheriton[113ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
NotifyVmtpServer, are logically part of the VMTP module because they require full access to the basic data structures of the VMTP implementation.
NotifyVmtpServerによる彼らが満を必要とするので論理的に、VMTPモジュールの一部がVMTP実装の構造に基礎データにアクセスするということです。
The management module should be implemented so that it can respond quickly to all requests, particularly since the timing of management interactions is used to estimate round trip time. To date, all implementations of the management module have been done at the kernel level, along with VMTP proper.
管理モジュールはすばやくすべての要求に応じることができるように実装されるべきです、管理相互作用のタイミングが周遊旅行時間を見積もるのに特に使用されるので。 これまで、VMTPに伴うカーネルレベル自体で管理モジュールのすべての実装をしました。
VII.6. Timeout Handling
VII.6。 タイムアウト取り扱い
The timeout queue is a queue of CSR records, ordered by timeout count, as specified in the CSR record. On entry into the timeout queue, the CSR record has the timeout field set to the time (preferable in milliseconds or similar unit) to remain in the queue plus the finishup field set to the procedure to execute on removal on timeout from the queue. The timeout field for a CSR in the queue is the time relative to the record preceding it in the queue (if any) at which it is to be removed. Some system-specific mechanism decrements the time for the record at the front of the queue, invoking the finishup procedure when the count goes to zero.
タイムアウト待ち行列はCSR記録で指定されるようにタイムアウトカウントで注文されたCSR記録の待ち行列です。 タイムアウト待ち行列へのエントリーでは、CSR記録で待ち行列に残る時間(ミリセカンドか同様のユニットで望ましい)にタイムアウト分野を設定します、そして、finishup分野が取り外しのときに待ち行列からのタイムアウトで実行する手順にセットしました。 待ち行列におけるCSRのためのタイムアウト分野はそれが取り除かれることになっている待ち行列(もしあれば)でそれに先行する記録に比例した時間です。 何らかのシステム特有のメカニズムが待ち行列の前部で時間を公式に減少させます、カウントがゼロまで行くとき、finishup手順を呼び出して。
Using this scheme, a special CSR is used to timeout and scan CSR's for non-recently pinged CSR's. That is, this CSR times out and invokes a finishup procedure that scans for non-recently pinged CSR that are "AwaitingResponse" and signals the request processing entity and deletes the CSR. It then returns to the timeout queue.
この体系を使用して、特別なCSRは非最近確認されたCSRのものにタイムアウトとスキャンCSRのものに使用されます。 そして、すなわち、このCSR回のアウト、"AwaitingResponse"である非最近確認されたCSRと信号のために要求処理実体をスキャンするfinishup手順を呼び出して、CSRを削除します。 そして、それはタイムアウト待ち行列に戻ります。
The timeout mechanism tends to be specific to an operating system. The scheme described may have to be adapted to the operating system in which VMTP is to be implemented.
具体的に言うと、タイムアウトメカニズムはオペレーティングシステムの傾向があります。 説明された体系はVMTPが実装されることになっているオペレーティングシステムに適合させられなければならないかもしれません。
This mechanism handles client request timeout and client response timeout. It is not intended to handle interpacket gaps given that these times are expected to be under 1 millisecond in general and possibly only a few microseconds.
このメカニズムはクライアント要求タイムアウトとクライアント応答タイムアウトを扱います。 これらの回が一般に、そして、ことによるとほんの数マイクロセカンド1ミリセカンド未満であると予想されるなら、それがinterpacketギャップを扱うことを意図しません。
VII.7. Timeout Values
VII.7。 タイムアウト値
Roundtrip timeout values are estimated by matching Responses or NotifyVmtpClient Requests to Request transmission, relying on the retransmitCount to identify the particular transmission of the Request that generated the response. A similar technique can be used with Responses and NotifyVmtpServer Requests. The retransmitCount is
往復のタイムアウト値は合っているResponsesかNotifyVmtpClient RequestsによってRequestトランスミッションに見積もられています、応答を生成したRequestの特定のトランスミッションを特定するためにretransmitCountを当てにして。 ResponsesとNotifyVmtpServer Requestsと共に同様のテクニックを使用できます。 retransmitCountはそうです。
Cheriton [page 114]
Cheriton[114ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
incremented each time the Response is sent, whether the retransmission was caused by timeout or retransmission of the Request.
その都度増加されて、「再-トランスミッション」がRequestのタイムアウトか「再-トランスミッション」によって引き起こされたか否かに関係なく、Responseを送ります。
The ProbeEntity request is recommended as a basic way of getting up-to-date information about a Client as well as predictable host machine turnaround in processing a request. (VMTP assumes and requires an efficient, bounded response time implementation of the ProbeEntity operation.)
ProbeEntity要求は要求を処理することにおける予測できるホスト・マシンターンアラウンドと同様にClientに関する最新情報を得る基本的な方法としてお勧めです。 (VMTPはProbeEntity操作の効率的で、境界がある応答時間実装を仮定して、必要とします。)
Using this mechanism for measuring RTT, it is recommended that the various estimation and smoothing techniques developed for TCP RTT estimation be adapted and used.
測定RTTにこのメカニズムを使用して、TCP RTT見積りのために見いだされた様々な見積りとスムージング技術が適合させられて、使用されるのは、お勧めです。
VII.8. Packet Reception
VII.8。 パケットレセプション
Logically a network packet containing a VMTP packet is 5 portions:
VMTPパケットを含むネットワークパケットは論理的に、5つの部分です:
- network header, possibly including lower-level headers
- ことによると低レベルヘッダーを含むネットワークヘッダー
- VMTP header
- VMTPヘッダー
- data segment
- データ・セグメント
- VMTP checksum
- VMTPチェックサム
- network trailer, etc.
- ネットワークトレーラなど
It may be advantageous to receive a packet fragmented into these portions, if supported by the network module. In this case, ideally the VMTP header may be received directly into a CSR, the data segment into a page that can be mapped, rather than copied, to its final destination, with VMTP checksum and network header in a separate area (used to extract the network address corresponding to the sender).
ネットワークモジュールでサポートされるならこれらの部分に断片化されたパケットを受けるのは有利であるかもしれません。 この場合、理想的に、VMTPヘッダーを直接CSRに受け取るかもしれません、コピーされるよりむしろ写像できる1ページへのデータ・セグメント、最終的な目的地に、分離した部分(以前はよく送付者にとって、対応するネットワーク・アドレスを抜粋していた)のVMTPチェックサムとネットワークヘッダーと共に。
Packet reception is described in detail by the pseudo-code in Section 4.7.
パケットレセプションはセクション4.7の中間コードによって詳細に説明されます。
With a response, normally the CSR has an associated segment area immediately available so delivery of segment data is immediate. Similarly, server entities should be "armed" with CSR's with segment areas that provide for immediate delivery of requests. It is reasonable to discard segment data that cannot be immediately delivered in this way, providing that clients and servers are able to preallocate CSR's with segment areas for requests and responses. In particular, a client should be able to provide some number of additional CSR's for receiving multiple responses to a multicast request.
応答によって、通常、CSRにはすぐに利用可能な関連セグメント領域があるので、セグメントデータの配送は即座です。 同様に、サーバ実体は要求の即座の配送に備えるセグメント領域があるCSRのもので「軍備されるべきです」。 すぐにこのように提供できないセグメントデータを捨てるのは妥当です、要求と応答において、クライアントとサーバがセグメント領域があるpreallocate CSRのものにできるなら。 特に、クライアントは追加CSRのものの何らかの数をマルチキャスト要求への複数の応答を受けるのに提供できるべきです。
Cheriton [page 115]
Cheriton[115ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
The CSR data structure is intended to be the interface data structure for an intelligent network interface. For reception, the interface is "armed" with CSR's that may point to segment areas in main memory, into which it can deliver a packet group. Ideally, the interface handles all the processing of all packets, interacting with the host after receiving a complete Request or Response packet group. An implementation should use an interface based on SendPacketGroup(CSR) and ReceivePacketGroup(CSR) to facilitate the introduction of an intelligent network interface.
CSRデータ構造はインテリジェントネットワークインタフェースへのインタフェースデータ構造であることを意図します。 レセプションに関しては、インタフェースは主記憶装置の中でセグメント領域を示すかもしれないCSRのもので「軍備されます」。それはパケットグループを主記憶装置に提供できます。 理想的に、インタフェースはすべてのパケットのすべての処理を扱います、完全なRequestかResponseパケットグループを受け取った後にホストと対話して。 実装はインテリジェントネットワークインタフェースの導入を容易にするためにSendPacketGroup(CSR)とReceivePacketGroup(CSR)に基づくインタフェースを使用するべきです。
ReceivePacketGroup(csr) provides the interface with a CSR descriptor and zero or more bytes of main memory to receive segment data. The CSR describes whether it is to receive responses (and if so, for which client) or requests (and if so for which server).
ReceivePacketGroup(csr)は、セグメントデータを受け取るためにCSR記述子とゼロか、より多くのバイトの主記憶装置をインタフェースに提供します。 CSRが、それが応答を受けることになっているかどうか説明する、(そうだとすれば、どのクライアント、)、要求、(そうだとすれば、どのサーバ、)
The procedure ReclaimCSR(CSR) reclaims the specified record from the interface before it has been returned after receiving the specified packet group.
指定されたパケットグループを受け取った後にそれを返す前に手順ReclaimCSR(CSR)はインタフェースからの指定された記録を取り戻します。
A finishup procedure is set in the CSR to be invoked when the CSR is returned to the host by the normal processing sequence in the interface. Similarly, the timeout parameter is set to indicate the maximum time the host is providing for the routine to perform the specified function. The CSR and associated segment memory is returned to the host after the timeout period with an indication of progress after the timeout period. It is not returned earlier.
CSRでは、インタフェースの正常処理系列でCSRをホストに返すときにはfinishup手順が呼び出すように設定されます。 同様に、タイムアウトパラメタがホストが指定された機能を実行するためにルーチンに備える最大の時を示すように設定されます。 進歩のしるしはタイムアウト時間の後にタイムアウト時間の後にCSRと関連セグメントメモリをホストに返します。 それは、より早く返されません。
VII.9. Streaming
VII.9。 ストリーミング
The implementation of streaming is optional in both VMTP clients and servers. Ideally, all performance-critical servers should implement streaming. In addition, clients that have high context switch overhead, network access overhead or expect to be communicating over long delay links should also implement streaming.
ストリーミングの実装はVMTPクライアントとサーバの両方で任意です。 理想的に、すべての性能重要なサーバがストリーミングを実装するべきです。 また、さらに、高度のコンテクストスイッチオーバーヘッドを持っているか、アクセスオーバーヘッドをネットワークでつなぐか、または長時間の遅延リンクの上に交信していると予想するクライアントはストリーミングを実装するべきです。
A client stream is implemented by allocating a CSR for each outstanding message transaction. A stream of transactions is handled similarly to multiple outstanding transactions from separate clients except for the interaction between consecutive numbered transactions in a stream.
クライアントストリームは、それぞれの傑出しているメッセージトランザクションのためにCSRを割り当てることによって、実装されます。 トランザクションのストリームは同様に絶え間なく別々のクライアントからの連続した番号付のトランザクションの間の相互作用以外の複数の傑出しているトランザクションに扱われます。
For the server VMTP module, streamed message transactions to a server are queued (if accepted) subordinate to the first unprocessed CSR corresponding to this Client. Thus, streamed transactions from a given Client are always performed in the order specified by the transaction identifiers.
サーバVMTPモジュールのために、サーバへの流されたメッセージトランザクションはこのClientに対応する最初の未加工のCSRの列に並ばせられた(受け入れるなら)部下です。 与えられたClientからのこのようにして流されたトランザクションはトランザクション識別子によって指定されたオーダーでいつも実行されます。
Cheriton [page 116]
Cheriton[116ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
If a server does not implement streaming, it must refuse streamed message transactions using the NotifyVmtpClient operation. Also, all client VMTP's that support streaming must support the streamed interface to a server that does not support streaming. That is, it must perform the message transactions one at a time. Consequently, a program that uses the streaming interface to a non-streaming server experiences degraded performance, but not failure.
サーバがストリーミングを実装しないなら、それは、NotifyVmtpClient操作を使用することで流されたメッセージトランザクションを拒否しなければなりません。 また、ストリーミングをサポートするすべてのクライアントVMTPのものはストリーミングをサポートしないサーバに流されたインタフェースをサポートしなければなりません。 すなわち、それは一度に一つ、メッセージトランザクションを実行しなければなりません。 その結果、非ストリーミングサーバにストリーミングのインタフェースを使用するプログラムは失敗ではなく、降格している性能を経験します。
VII.10. Implementation Experience
VII.10。 実装経験
The implementation experience to date includes a partial implementation (minus the streaming and full security) in the V kernel plus a similar preliminary implementation in the 4.3 BSD Unix kernel. In the V kernel implementation, the CSR's are part of the (lightweight) process descriptor.
実装経験はこれまで4.3BSD UnixカーネルにおけるVカーネルと同様の予備の実装に部分的な実装(ストリーミングの、そして、完全なセキュリティを引いた)を含んでいます。 Vカーネル実装では、CSRのものは(軽量)のプロセス記述子の一部です。
The V kernel implementation is able to perform a VMTP message transaction with no data segment between two Sun-3/75's connected by 10 Mb Ethernet in 2.25 milliseconds. It is also able to transfer data at 4.7 megabits per second using 16 kilobyte Requests (but null checksums.) The UNIX kernel implementation running on Microvax II's achieves a basic message transaction time of 9 milliseconds and data rate of 1.9 megabits per second using 16 kilobyte Responses. This implementation is using the standard VMTP checksum.
Vカーネル実装は75Sun-3/年代が2.25ミリセカンドで10Mbのイーサネットで接続した2の間のデータ・セグメントなしでVMTPメッセージトランザクションを実行できます。 また、それは2番目に、16キロバイトのRequests(しかし、ヌルチェックサム。)を使用するのあたり4.7のメガビットでデータを移すことができます。 Microvax IIのものの上で作業するUNIXカーネル実装は9ミリセカンドの基本的なメッセージトランザクション時間と2番目に、16キロバイトのResponsesを使用するのあたり1.9のメガビットのデータ信号速度を実現します。 この実装は標準のVMTPチェックサムを使用しています。
We hope to report more extensive implementation experience in future revisions of this document.
私たちは、このドキュメントの今後の改正の、より大規模な実装経験を報告することを望んでいます。
Cheriton [page 117]
Cheriton[117ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
VIII. UNIX 4.3 BSD Kernel Interface for VMTP
VIII。 VMTPのためのUNIX4.3BSDカーネルインタフェース
UNIX 4.3 BSD includes a socket-based design for program interfaces to a variety of protocol families and types of protocols (streams, datagrams). In this appendix, we sketch an extension to this design to support a transaction-style protocol. (Some familiarity with UNIX 4.2/3 IPC is assumed.) Several extensions are required to the system interface, rather than just adding a protocol, because no provision was made for supporting transaction protocols in the original design. These extensions include a new "transaction" type of socket plus new system calls invoke, getreply, probeentity, recreq, sendreply and forward.
UNIX4.3BSDはさまざまなプロトコルファミリーとタイプのプロトコル(ストリーム、データグラム)にプログラムインタフェースへのソケットベースのデザインを含めます。 この付録では、私たちは、トランザクションスタイルプロトコルをサポートするためにこのデザインに拡大についてスケッチします。 (UNIX4.2/3IPCへの何らかの親しみが想定されます。) いくつかの拡大がただプロトコルを加えるよりむしろシステム・インタフェースに必要です、当初の設計におけるトランザクションプロトコルをサポートするのに備えたので。 これらの拡大はソケットのプラスの新しいシステムコールのタイプが呼び出す新しい「トランザクション」、getreply、probeentity、recreq、sendreply、およびフォワードを含んでいます。
A socket of type transaction bound to the VMTP protocol type IPPROTO_VMTP is created by the call
VMTPプロトコルタイプIPPROTO_VMTPに縛られたタイプトランザクションのソケットは呼び出しで作成されます。
s = socket(AF_INET, SOCK_TRANSACT, VMTP);
sはソケット(AF_INET、_が商取引するソックス、VMTP)と等しいです。
This socket is bound to an entity identifier by
このソケットは実体識別子に縛られます。
bind(s, &entityid, sizeof(entityid));
付いてください(s、およびentityid、sizeof(entityid))。
The first address/port bound to a socket is considered its primary name and is the one used on packet transmission. A message transaction is invoked between the socket named by s and the Server specified by mcb by
ソケットに縛られた最初のアドレス/ポートは、プライマリ名前であると考えられて、パケット伝送で使用されるものです。 メッセージトランザクションはsによって指定されたソケットとmcbによって指定されたServerの間に呼び出されます。
invoke(s, mcb, segptr, seglen, timeout );
(s、mcb、segptr、seglen、タイムアウト)を呼び出してください。
The mcb is a message control block whose format was described in Section 2.4. The message control block specifies the request to send plus the destination Server. The response message control block returned by the server is stored in mcb when invoke returns. The invoking process is blocked until a response is received or the message transaction times out unless the request is a datagram request. (Non-blocking versions with signals on completion could also be provided, especially with a streaming implementation.)
mcbは形式がセクション2.4で説明されたメッセージ制御ブロックです。 メッセージ制御ブロックは発信するという要求と目的地Serverを指定します。サーバによって返された応答メッセージ制御ブロックは中にmcbに保存されて、いつがリターンを呼び出すかということです。 応答が受け取られているか、またはメッセージトランザクション回数が出かけるまで、呼び出しプロセスは要求がデータグラム要求でないなら妨げられます。 (また、完成での信号がある非ブロッキングバージョンを特にストリーミングの実装に提供できました。)
For multicast message transactions (sent to an entity group), the next response to the current message transaction (if it arrives in less than timeout milliseconds) is returned by
マルチキャストメッセージトランザクション(実体グループに発信する)において、現在のメッセージトランザクション(タイムアウトミリセカンド以下に到着するなら)への次の応答で戻ります。
getreply( s, mcb, segptr, maxseglen, timeout );
getreply(s、mcb、segptr、maxseglen、タイムアウト)。
The invoke operation sent to an entity group completes as soon as the first response is received. A request is retransmitted until the first reply is received (assuming the request is not a datagram). Thus, the system does not retransmit while getreply is timing out even if no replies are available.
最初の応答が受け取られているとすぐに、グループが完成する実体に送られた操作を呼び出してください。 最初の回答が受け取られているまで(要求を仮定するのは、データグラムではありません)、要求は再送されます。 したがって、どんな回答も利用可能でなくてもgetreplyが外で調節されている間、システムは再送されません。
Cheriton [page 118]
Cheriton[118ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
The state of an entity associated with entityId is probed using
entityIdに関連している実体の状態は調べられた使用です。
probeentity( entityId, state );
probeentity(entityId、状態)。
A UNIX process acting as a VMTP server accepts a Request by the operation
VMTPサーバが操作で申し込みに応じるので行動するUNIXプロセス
recvreq(s, mcb, segptr, maxseglen );
recvreq(s、mcb、segptrはmaxseglenされます)。
The request message for the next queued transaction request is returned in mcb, plus the segment data of maximum length maxseglen, starting at segptr in the address space. On return, the message control block contains the values as set in invoke except: (1) the Client field indicates the Client that sent the received Request message. (2) the Code field indicates the type of request. (3) the MsgDelivery field indicates the portions of the segment actually received within the specified segment size, if MDM is 1 in the Code field. A segment block is marked as missing (i.e. the corresponding bit in the MsgDelivery field is 0) unless it is received in its entirety or it is all of the data in last segment contained in the segment.
mcbで次の列に並ばせられたトランザクション要求への要求メッセージを返します、そして、最大の長さに関するセグメントデータはmaxseglenされます、segptrでアドレス空間で始まって。 リターンでは、コネが呼び出すセットが除かれるとき、メッセージ制御ブロックは値を含んでいます: (1) Client分野は受信されたRequestメッセージを送ったClientを示します。 (2) Code分野は要求のタイプを示します。 (3) MsgDelivery分野は、セグメントの部分が実際に指定されたセグメントサイズの中で受信されたのを示します、MDMがCode分野の1であるなら。 セグメントブロックはそれを全体として受け取るか、それがデータのすべてでないなら消えるとして(すなわち、MsgDelivery分野の対応するビットは0です)セグメントに含まれた最後のセグメントで示されます。
To complete a transaction, the reply specified by mcb is sent to the client specified by the MCB using
取引を完了するために、MCB使用で指定されたクライアントにmcbによって指定された回答を送ります。
sendreply(s, mcb, segptr );
sendreply(s、mcb、segptr)。
The Client field of the MCB indicates the client to respond to.
MCBのClient分野は応じるクライアントを示します。
Finally, a message transaction specified by mcb is forwarded to newserver as though it were sent there by its original invoker using
最終的に、まるでオリジナルの呼び出し元使用でそれをそこに送るかのようにmcbによって指定されたメッセージトランザクションをnewserverに送ります。
forward(s, mcb, segptr, timeout );
フォワード(s、mcb、segptr、タイムアウト)。
Cheriton [page 119]
Cheriton[119ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
Index
インデックス
Acknowledgment 14
APG 16, 31, 39
Authentication domain 20
承認14APG16、31、39Authenticationドメイン20
Big-endian 9
ビッグエンディアン9
Checksum 14, 43
Checksum, not set 44
Client 7, 10, 38
Client timer 16
CMD 42, 110
CMG 32, 40
Co-resident entity 25
Code 42
CoResidentEntity 42, 43
CRE 21, 42
セット44Client7、10、38Clientタイマ16CMD42、110CMG32、40Co-居住者実体25Code42CoResidentEntity42、43CRE21、42ではなく、チェックサム14、43Checksum
DGM 42
Digital signature, VMTP management 95, 101
Diskless workstations 2
Domain 9, 38
Domain 1 102
Domain 3 104
DGM42Digital署名、VMTP管理95、101Disklessワークステーション2Domain9、38Domain1 102Domain3 104
Entity 7
Entity domain 9
Entity group 8
Entity identifier 37
Entity identifier allocation 105
Entity identifier, all-zero 38
EPG 20, 39
実体7Entityドメイン9Entityは8Entity識別子37Entity識別子配分105Entity識別子を分類します、オールゼロ38EPG20、39
Features 6
ForwardCount 24
Forwarding 24
FunctionCode 41
特徴6ForwardCount24推進24FunctionCode41
Group 8
Group message transaction 10
Group timeouts 16
GRP 37
グループ8Groupメッセージトランザクション10Groupタイムアウト16GRP37
HandleNoCSR 62
HandleRequestNoCSR 79
HCO 14, 23, 39
HandleNoCSR62HandleRequestNoCSR79HCO14、23、39
Cheriton [page 120]
Cheriton[120ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
Host independence 8
ホスト独立8
Idempotent 15
Interpacket gap 18, 40
IP 108
ベキ等元15Interpacket相違18、40IP108
Key 91
キー91
LEE 32, 37
Little-endian 9
陰32、37リトルエンディアン9
MCB 118
MDG 22, 40
MDM 30, 42
Message control block 118
Message size 6
Message transaction 7, 10
MPG 39
MsgDelivery 43
MSGTRANS_OVERFLOW 27
Multicast 4, 21, 120
Multicast, reliable 21
MCB118MDG22、40MDM30、42Message制御ブロック118Messageサイズ6Messageトランザクション7、10MPG39MsgDelivery43MSGTRANS_OVERFLOW27Multicast4、21、120Multicast、信頼できる21
Naming 6
Negative acknowledgment 31
NER 25, 31, 39
NRT 26, 30, 39
NSR 25, 27, 31, 39
命名6Negative承認31NER25、31、39NRT26、30、39NSR25、27、31、39
Object-oriented 2
Overrun 18
オブジェクト指向2超過18
Packet group 7, 29, 39
Packet group run 31
PacketDelivery 29, 31, 41
PGcount 26, 41
PIC 42
Principal 11
Priority 41
Process 11
ProcessId 89
Protocol number,IP 108
パケットグループ7、29、39Packetグループは31PacketDelivery29、31、41PGcount26、41PIC42プリンシパル11Priority41Process11ProcessId89プロトコル番号を実行します、IP108
RAE 37
Rate control 18
Real-time 2, 4
Realtime 22
RAE37Rateコントロール18レアル-時間2、4Realtime22
Cheriton [page 121]
Cheriton[121ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
Reliability 12
Request message 10
RequestAckRetries 30
RequestRetries 15
Response message 10
ResponseAckRetries 31
ResponseRetries 15
Restricted group 8
Retransmission 15
RetransmitCount 17
Roundtrip time 17
RPC 2
Run 31, 39
Run, message transactions 25
信頼性12のRequestメッセージ10RequestAckRetries30のRequestRetries15Responseメッセージ10ResponseAckRetries31ResponseRetries15Restrictedは8Retransmission15RetransmitCount17Roundtrip時間17RPC2Run31、39Runを分類します、メッセージトランザクション25
SDA 42
Security 4, 19
Segment block 41
Segment data 43
SegmentSize 42, 43
Selective retransmission 18
Server 7, 10, 41
Server group 8
Sockets, VMTP 118
STI 26, 40
Streaming 25, 55
Strictly stable 8
Subgroups 21
SDA42Security4、19Segmentブロック41のSegmentデータ43SegmentSize42、43Selective retransmission18Server7、10、41Serverは8Socketsを分類します、VMTP118STI26、40Streaming25、55Strictly安定した8Subgroups21
T-stable 8
TC1(Server) 16
TC2(Server) 16
TC3(Server) 16
TC4 16
TCP 2
Timeouts 15
Transaction 10, 41
Transaction identification 10
TS1(Client) 17
TS2(Client) 17
TS3(Client) 17
TS4(Client) 17
TS5(Client) 17
Type flags 8
T安定した8TC1(サーバ)16TC2(サーバ)16TC3(サーバ)16TC4 16TCP2Timeouts15Transaction10、41Transaction識別10TS1(クライアント)17TS2(クライアント)17TS3(クライアント)17TS4(クライアント)17TS5(クライアント)17個のType旗8
UNIX interface 118
Unrestricted group 8, 38
UNIXインタフェース118Unrestrictedグループ8、38
Cheriton [page 122]
Cheriton[122ページ]
RFC 1045 VMTP February 1988
RFC1045VMTP1988年2月
NotifyVmtpClient 7, 26, 27, 30
NotifyVmtpServer 7, 14, 30
User Data 43
NotifyVmtpClient7、26、27、30NotifyVmtpServer7、14、30利用者データ43
Version 38
VMTP Management digital signature 95, 101
バージョン38VMTP Managementデジタル署名95、101
Cheriton [page 123]
Cheriton[123ページ]
一覧
スポンサーリンク
