RFC3018 日本語訳
3018 Unified Memory Space Protocol Specification. A. Bogdanov. December 2000. (Format: TXT=177783 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group A. Bogdanov Request for Comments: 3018 NKO "ORS" Category: Experimental December 2000
Bogdanovがコメントのために要求するワーキンググループA.をネットワークでつないでください: 3018年のNKO「ORS」カテゴリ: 実験的な2000年12月
Unified Memory Space Protocol Specification
統一されたメモリスペースプロトコル仕様
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
This document specifies Unified Memory Space Protocol (UMSP), which gives a capability of immediate access to memory of the remote nodes.
このドキュメントはUnified Memory Spaceプロトコル(UMSP)を指定します。(それは、遠隔ノードに関するメモリへの即座のアクセスの能力を与えます)。
Conventions used in this document
本書では使用されるコンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC-2119[2]で説明されるように本書では解釈されることであるべきですか?
The following syntax specification uses the augmented Backus-Naur Form (ABNF) as described in RFC-2234 [3].
以下の構文仕様はRFC-2234[3]で説明されるように増大しているBN記法(ABNF)を使用します。
Table of Contents
目次
1. Introduction...................................................4
2. The UMSP Model.................................................5
2.1 128-bit Address Space.......................................5
2.2 Computing Model.............................................7
2.3 System Architecture.........................................9
3. Instruction Format............................................11
3.1 Instruction Header.........................................12
3.2 Extension Headers..........................................15
3.3 Instruction Operands.......................................17
3.4 Address Formats............................................17
4. Response of the Instructions..................................19
4.1 RSP, RSP_P.................................................20
4.2 SND_CANCEL.................................................20
5. Jobs Management...............................................21
1. 序論…4 2. UMSPはモデル化します…5の2.1 128ビットのアドレス空間…5 2.2計算モデル…7 2.3 システムアーキテクチャ…9 3. 命令形式…11 3.1指示ヘッダー…12 3.2 拡大ヘッダー…15 3.3 指示オペランド…17 3.4のアドレス形式…17 4. 指示の応答…19 4.1 RSP、RSP_P.…20 4.2SND_キャンセル…20 5. 仕事の管理…21
Bogdanov Experimental [Page 1] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[1ページ]RFC3018
5.1 Job Initiate...............................................23
5.1.1 CONTROL_REQ............................................24
5.1.2 CONTROL_CONFIRM........................................25
5.1.3 CONTROL_REJECT.........................................26
5.2 Task Initiate..............................................26
5.2.1 TASK_REG...............................................26
5.2.2 TASK_CONFIRM...........................................27
5.2.3 TASK_REJECT............................................28
5.2.4 TASK_CHK...............................................28
5.3 Establishment of session connection........................29
5.3.1 SESSION_OPEN...........................................29
5.3.2 SESSION_ACCEPT.........................................31
5.3.3 SESSION_REJECT.........................................31
5.3.4 Connection Profile.....................................32
5.4 Session Closing............................................33
5.4.1 SESSION_CLOSE..........................................34
5.4.2 SESSION_ABEND..........................................35
5.5 Task Termination...........................................35
5.5.1 TASK_TERMINATE.........................................36
5.5.2 TASK_TERMINATE_INFO....................................36
5.6 Job Completion.............................................37
5.6.1 JOB_COMPLETED..........................................37
5.6.2 JOB_COMPLETED_INFO.....................................38
5.7 Activity Control of Nodes..................................38
5.7.1 _INACTION_TIME.........................................39
5.7.2 STATE_REQ..............................................40
5.7.3 TASK_STATE.............................................41
5.7.4 NODE_RELOAD............................................42
5.8 Work without session connection............................42
6. Instructions of Exchange between VM...........................44
6.1 Data Reading/Writing Instructions..........................45
6.1.1 REQ_DATA...............................................45
6.1.2 DATA...................................................46
6.1.3 WRITE..................................................46
6.1.4 WRITE_EXT..............................................47
6.2 Comparison Instructions....................................47
6.2.1 CMP....................................................47
6.2.2 CMP_EXT................................................48
6.2.3 Response to Comparison Instructions....................48
6.3 Control Transfer Instructions..............................48
6.3.1 JUMP, CALL.............................................48
6.3.2 RETURN.................................................49
6.4 Memory Control Instructions................................50
6.4.1 MEM_ALLOC..............................................50
6.4.2 MVCODE.................................................50
6.4.3 ADDRESS................................................51
6.4.4 FREE...................................................51
6.4.5 MVRUN..................................................51
5.1仕事の開始…23 5.1 .1 _REQを制御してください…5.1.2コントロール_が確認する24…25 5.1 .3 _廃棄物を制御してください…26 5.2 開始に仕事を課してください…26 5.2 .1 _レッジに仕事を課してください…5.2.2タスク_が確認する26…27 5.2 .3 _廃棄物に仕事を課してください…28 5.2 .4 _CHKに仕事を課してください…28 5.3 セッション接続の設立…29 5.3 .1セッション_は開きます…29 5.3 .2セッション_は受け入れます…31 5.3 .3セッション_廃棄物…31 5.3 .4接続プロフィール…32 5.4セッション閉鎖…33 5.4 .1セッション_は閉じます…34 5.4 .2セッション_はアベンドします…35 5.5タスクの終了…35 5.5 .1タスク_は終わります…36 5.5 .2タスク_は_インフォメーションを終えます…36 5.6 仕事の完成…37 5.6 _が完了した.1仕事…37 5.6 .2仕事の_は_インフォメーションを完成しました…38 5.7 ノードのアクティビティ管理…38 5.7 .1_無活動_時間…39 5.7 .2 _REQを述べてください…40 5.7 .3 _状態に仕事を課してください…41 5.7 .4ノード_は再び荷を積みます…42 5.8 セッション接続なしで働いてください…42 6. VMの間の交換の指示…44 6.1 データ読書/書くことの指示…45 6.1 .1 REQ_データ…45 6.1 .2のデータ…46 6.1 .3 書いてください…46 6.1 .4 _EXTに書いてください…47 6.2 比較指示…47 6.2.1Cmp…47 6.2 .2 _Cmp EXT…48 6.2 比較命令への.3応答…48 6.3 飛越し命令を制御してください…48 6.3 .1 跳んでください、そして、電話をしてください…48 6.3 .2 戻ってください…49 6.4 メモリコントロール指示…50 6.4 .1MEM_ALLOC…50 6.4 .2MVCODE…50 6.4 .3 アドレス…51 6.4 .4 無料…51 6.4 .5MVRUN…51
Bogdanov Experimental [Page 2] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[2ページ]RFC3018
6.5 Other Instructions.........................................52
6.5.1 SYN....................................................52
6.5.2 NOP....................................................53
6.6 Work with Objects..........................................53
6.6.1 Reading/Writing of the Objects Data....................54
6.6.1.1 OBJ_REQ_DATA.......................................54
6.6.1.2 OBJ_WRITE..........................................55
6.6.1.3 OBJ_WRITE_EXT......................................56
6.6.2 Comparison Instructions of the Objects Data............56
6.6.2.1 OBJ_DATA_CMP.......................................56
6.6.2.2 OBJ_DATA_CMP_EXT...................................57
6.6.3 Execution of the Objects Procedures....................57
6.6.3.1 CALL_BNUM..........................................57
6.6.3.2 CALL_BNAME.........................................58
6.6.3.3 GET_NUM_PROC.......................................59
6.6.3.4 PROC_NUM...........................................59
6.6.4 The Objects Creation...................................59
6.6.4.1 NEW, SYS_NEW.......................................60
6.6.4.2 OBJECT.............................................61
6.6.4.3 DELETE.............................................61
6.6.5 The Objects Identification.............................61
6.6.5.1 OBJ_SEEK...........................................62
6.6.5.2 OBJ_GET_NAME.......................................62
7. Chains........................................................62
7.1 Sequence...................................................63
7.2 Transaction................................................64
7.2.1 _BEGIN_TR..............................................64
7.2.2 EXEC_TR................................................65
7.2.3 CANCEL_TR..............................................66
7.3 Fragmented instruction.....................................66
7.4 Buffering..................................................67
7.5 Acknowledgement of chains..................................69
7.6 Base-displacement Addressing...............................70
8. Extension Headers.............................................71
8.1 _ALIGNMENT.................................................71
8.2 _MSG.......................................................71
8.3 _NAME......................................................72
8.4 _DATA......................................................72
8.5 _LIFE_TIME.................................................72
9. Search of resources...........................................73
9.1 VM_REQ.....................................................75
9.2 VM_NOTIF...................................................75
10. Security Consideration.......................................77
11. Used Abbreviations...........................................78
12. References...................................................79
13. Author's Address.............................................80
14. Full Copyright Statement.....................................81
他の6.5の指示…52 6.5 .1SYN…52 6.5 .2NOP…53 6.6 オブジェクトで、働いてください…53 6.6 .1 オブジェクトデータを読むか、または主題にして書きます…54 6.6 .1 .1 OBJ_REQ_データ…54 6.6 .1 .2 OBJ_は書きます…55 6.6 .1 .3 OBJ_は_EXTに書きます…56 6.6 .2 オブジェクトデータの比較指示…56 6.6 .2 .1 OBJ_データ_Cmp…56 6.6 .2 .2 _OBJ_データCmp_EXT…57 6.6 .3 オブジェクト手順の実行…57 6.6 .3 .1 _をBNUMと呼んでください…57 6.6 .3 .2 _をBNAMEと呼んでください…58 6.6 .3 .3 _ヌム_PROCを手に入れてください…59 6.6 .3 .4 PROC_ヌム…59 6.6 .4 オブジェクト作成…59 6.6 .4 .1 新しく、SYS_新しい…60 6.6 .4 .2 反対してください…61 6.6 .4 .3 削除します。61 6.6 .5 オブジェクト識別…61 6.6 .5 .1 OBJ_は探されます…62 6.6 .5 .2 OBJ_は_名前を得ます…62 7. チェインズ…62 7.1系列…63 7.2トランザクション…64 7.2 .1 __TRを始めてください…64 7.2 .2 幹部_TR…65 7.2 .3 _TRを取り消してください…66 7.3は指示を断片化しました…66 7.4 バッファリングします。67 7.5 チェーンの承認…69 7.6 基地置換えアドレシング…70 8. 拡大ヘッダー…71 8.1_整列…71 8.2 _エムエスジー…71 8.3_名…72の8.4_データ…72 8.5_寿命_時間…72 9. リソースの検索…73 9.1VM_REQ…75 9.2VM_NOTIF…75 10. セキュリティの考慮…77 11. 略語を使用します…78 12. 参照…79 13. 作者のアドレス…80 14. 完全な著作権宣言文…81
Bogdanov Experimental [Page 3] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[3ページ]RFC3018
1 Introduction
1つの序論
UMSP is the network connection-oriented protocol. It corresponds to session and presentation layers of model OSI. The protocol is designed for implementation in a wide class of systems, from simple devices based on the dedicated processors, up to universal computers and clusters.
UMSPはネットワークの接続指向のプロトコルです。 それはモデルOSIのセッションとプレゼンテーション層に対応しています。 プロトコルは広いクラスのシステムの実装のために設計されています、専用プロセッサに基づく簡単な装置から、普遍的なコンピュータとクラスタまで。
For the data exchange, the protocol uses transport layer service with reliable delivery. It is possible to use not providing reliable delivery protocol for the transmission of not requiring acknowledgement data. This document describes use TCP and UDP.
データ交換のために、プロトコルは信頼できる配信によるトランスポート層サービスを利用します。 信頼できる配信を提供しない使用に承認データが必要さでないトランスミッションのために議定書を作っているのは、可能です。 このドキュメントは使用について説明します。TCPとUDP。
The creation of network environment for the organization 128-bit address space of memory distributed between Internet nodes is the basic purpose of the protocol UMSP. The protocol defines algorithm of the connections management and format of network primitives. It doesn't control local memory on the node.
インターネット接続装置の間に分配されたメモリの組織128ビットのアドレスのスペースへのネットワーク環境の作成はプロトコルUMSPの基本的な目的です。 プロトコルはネットワーク基関数の接続管理と形式のアルゴリズムを定義します。 それはノードに関するローカルの記憶を制御しません。
As against the traditional network protocols, the user applications on different nodes interact not by the network primitives exchanging or working with the dataflows, but by immediate data reading/write or control transfers to the code in virtual memory of the remote node. The user's application can know nothing about existence of the protocol and network, and simply use the instructions with 128-bit addresses.
伝統的ネットワークプロトコルに対比して、異なったノードにおけるユーザアプリケーションが、データフローで交換するか、または働いているネットワーク基関数で相互作用するのではなく、即座のデータ読書で相互作用するか、書きます、またはコントロールは遠隔ノードの仮想記憶におけるコードに移されます。 ユーザのアプリケーションは、プロトコルとネットワークの存在に関して何も知らないで、128ビットのアドレスと共に指示を単に使用できます。
Firstly, it is supposed to use UMSP in systems based on the virtual machines (VM), executing the pseudo-code. However, the protocol may be used in systems executing a processor code, for example, in clusters or in universal operational systems, for the organization of the distributed virtual address space. Besides, the minimal profile of the protocol may be used in simple devices, which do not have the operational system.
まず第一に、それは中間コードを実行して、仮想計算機(VM)に基づくシステムでUMSPを使用するべきです。 しかしながら、プロトコルは例えば、いくつもの群れをなしてか普遍的な基幹系システムでプロセッサコードを実行しながら、システムで使用されるかもしれません、分配された仮想アドレス空間の組織のために。 そのうえ、プロトコルの最小量のプロフィールは簡単な装置で使用されるかもしれません。(簡単な装置には、基幹系システムがありません)。
The protocol gives various means for set the connection parameters and allows building systems with a high protection level without restriction applications functionalities.
プロトコルは、セットに、様々な手段に接続パラメタを与えて、制限アプリケーションの機能性なしで高い保護レベルがあるシステム構築を許容します。
UMSP can essentially simplify the distributed systems development process. It gives an opportunity to unite not only information, but also calculating resources of the large number of polytypic computers without significant expenses for the programs standardization and development.
UMSPは本質的には分散システム開発過程を簡素化できます。 それはプログラム標準化と開発のために重要な費用なしで情報だけではなく、多くのpolytypicコンピュータの計算のリソースも結合させる機会を与えます。
Bogdanov Experimental [Page 4] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[4ページ]RFC3018
2 The UMSP Model
2 UMSPモデル
2.1 128-bit Address Space
2.1 128ビットのアドレス空間
UMSP is based on the 128-bit distributed address memory space model. The 128-bit address contains the information about the network type, network node address and local memory address. It has the following format:
UMSPは128ビットの分配されたアドレスメモリ宇宙モデルに基づいています。 128ビットのアドレスはネットワークタイプ、ネットワーク・ノードアドレス、および地方のメモリアドレスの情報を含んでいます。 それには、以下の形式があります:
Octets
0 1 16
+------+--------------+--------------------+----------------+
|Header| FREE | NODE_ADDR | MEM_ADDR |
+------+--------------+--------------------+----------------+
八重奏0 1 16+------+--------------+--------------------+----------------+ |ヘッダー| 無料| ノード_ADDR| MEM_ADDR| +------+--------------+--------------------+----------------+
Complete address length is fixed and is equal to 16 octets.
完全なアドレスの長さは、修理されていて、八重奏が16と等しいことです。
Header
ヘッダー
1 octet. Address header field completely defines the address
format. The header has the following format:
1つの八重奏。 アドレスヘッダーフィールドはアドレス形式を完全に定義します。 ヘッダーには、以下の形式があります:
Bits
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| ADDR_LENGTH | NET_TYPE | ADDR_CODE |
+-----+-----+-----+-----+-----+-----+-----+-----+
ビット0 1 2 3 4 5 6 7+-----+-----+-----+-----+-----+-----+-----+-----+ | ADDR_長さ| ネットの_タイプ| ADDR_コード| +-----+-----+-----+-----+-----+-----+-----+-----+
ADDR_LENGTH
ADDR_長さ
4 bits. The length of the network address. This field
contains the number of octets in the NODE_ADDR field. The
value 0 is not allowed.
4ビット。 ネットワーク・アドレスの長さ。 この分野はNODE_ADDR分野の八重奏の数を含んでいます。 値0は許容されていません。
NET_TYPE
ネットの_タイプ
2 bits. The network type. This field specifies a type of
network, in which the node is.
2ビット。 ネットワークタイプ。 この分野は一種のネットワークを指定します。そこでは、ノードがそうです。
ADDR_CODE
ADDR_コード
2 bits. The length code of the local memory address. The
value of this field specifies the length of the local memory
address. The following values of the field and appropriated to
them length of the field MEM_ADDR are defined:
2ビット。 地方のメモリアドレスの長さのコード。 この分野の値は地方のメモリアドレスの長さを指定します。 以下の値、分野であって彼らに当てられることでは、長さの分野MEM_ADDRは定義されます:
Bogdanov Experimental [Page 5] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[5ページ]RFC3018
%b00 - 16 bit
%b01 - 24 bit
%b10 - 32 bit
%b11 - 64 bit
%b00--16ビットの%b01--24ビットの%b10--32ビットの%b11--64ビット
The values combination of the three fields of heading is named
address format number. These fields unequivocally define a
network, in which the node is located. Format number writes as
follows:
見出しの3つの分野の値の組み合わせはアドレス形式番号と命名されます。 これらの分野は明確にネットワークを定義します。(ノードはそれで位置しています)。 形式番号は以下の通り以下を書きます。
N <ADDR_LENGTH> - <NET_TYPE> - <ADDR_CODE>
N<のADDR_長さの>--<のネットの_タイプ>--<ADDR_コード>。
For example, N 4-0-2 defines the address with length of the node
network address 4 octets and memory address with the length 32
bits. The network type 0 for such address format is defined for
the network IPv4 in the presented document. If the network type
is equal to zero, it may be missed during the writing of the
address format number. For example, format N 4-0-2 and 4-2 are
equivalent. If both fields NET_TYPE and ADDR_CODE are set to
zero, they may be omitted. Thus, a format number writes as one
figure.
例えば、N4-0-2は32ビットの長さでノードネットワーク・アドレス4八重奏とメモリアドレスの長さでアドレスを定義します。 そのようなアドレス形式のためのネットワークタイプ0は提示されたドキュメントのネットワークIPv4のために定義されます。 ネットワークタイプがゼロに合わせるために等しいなら、それはアドレス形式番号の書くことの間、逃されるかもしれません。 例えば、形式N4-0-2と4-2は同等です。 両方の分野のネット_TYPEとADDR_CODEがゼロに用意ができているなら、それらは省略されるかもしれません。 その結果数が1つの図として書く書式。
One or several address format numbers must be assigned for each
global network, included in unified system.
統一されたシステムに含まれていた各世界的なネットワークのために1かいくつかのアドレス形式番号を割り当てなければなりません。
FREE
無料
0 - 12 octets. This field is unused by the protocol. It may
contain any additional information, which is necessary for the
control system of the node memory. If this field is not used, the
zero value must be set in all octets. Using of this field results
that the network instructions must contain only complete 16 -
octet address and the short address of local memory cannot be
used.
0--12の八重奏。 この分野はプロトコルによる未使用です。 それはどんな追加情報も含むかもしれません。(それが、ノードメモリの制御システムに必要です)。 ゼロは、すべてのセットが八重奏であったに違いないなら分野がこれであるなら使用されていないのを評価します。 これが使用されると、ネットワーク指示が完全な16だけを含まなければならないという結果はさばかれます--ローカルの記憶の八重奏アドレスと短いアドレスを使用できません。
NODE_ADDR
ノード_ADDR
1 - 13 octets. The node address. The format of this field is
defined separately for each address format number. The field of
the node address should not necessary precisely correspond to the
real network address. If the real network address is longer than
this field, it is necessary to organize in the network a subset of
supporting the protocol UMSP addresses.
1--13の八重奏。 ノードアドレス。 この分野の書式はそれぞれのアドレス形式番号のために別々に定義されます。 ノードアドレスの分野がそうするべきでない、必要性、正確に本当のネットワーク・アドレスに対応してください。 本当のネットワーク・アドレスがこの分野より長いなら、ネットワークでプロトコルがUMSPアドレスであるとサポートする部分集合を組織化するのが必要です。
Bogdanov Experimental [Page 6] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[6ページ]RFC3018
MEM_ADDR
MEM_ADDR
16/24/32/64 bits. The address of local memory. This field is the
memory address in system, which is set by a field NODE_ADDR. The
node completely responds for its memory control. The protocol
does not define the order of using and format of this field.
16/24/32/64ビット。 ローカルの記憶のアドレス。 この分野はシステムのメモリアドレスです。(システムは分野NODE_ADDRによって設定されます)。ノードはメモリコントロールのために完全に応じます。 プロトコルは使用の注文とこの分野の書式を定義しません。
128-bit address for the user applications is one field. The user code cannot know about a physical arrangement of addressed memory.
ユーザアプリケーションのための128ビットのアドレスは1つの分野です。 ユーザコードは扱われたメモリの物理的なアレンジメントに関して知ることができません。
The 128-bit memory address may be transmits between nodes, as the data, for example, in the buffer of function parameters, or in the instruction of copying the data. Therefore, it must identify the given node from any other nodes unequivocal.
128ビットのメモリアドレスはそうです。例えば、データとしてノードの間を関数パラメータに関するバッファ、またはデータをコピーする指示で伝わります。 したがって、それはいかなる他のノードからもはっきりしている与えられたノードを特定しなければなりません。
Any certain algorithm, connecting real network and 128-bit address, does not exist. All used address formats must be known beforehand.
どんなあるアルゴリズム(接続の本当のネットワークと128ビットのアドレス)も、存在していません。 あらかじめ、すべての中古のアドレス形式を知っていなければなりません。
As UMSP has its own address space, it can unite several global networks. The nodes can have internal local networks or subordinated addressable devices connected with the node by the not-network communications. Any node by address format number must have an opportunity to define the gateway respond for routing of this address.
UMSPにそれ自身のアドレス空間があるとき、それはいくつかの世界的なネットワークを結合させることができます。 ノードで、ネットワークでないコミュニケーションは内部の企業内情報通信網か下位に置いているアドレス可能なデバイスをノードに接続できます。 ゲートウェイを定義する機会がこのアドレスのルーティングのために数で反応しなければならないアドレス形式によるどんなノード。
2.2 Computing Model
2.2 計算モデル
Computing model is three-layer:
計算モデルは3層です:
(1) Job
(2) Task
(3) Thread of control
(1) コントロールの仕事の(2)タスク(3)スレッド
The job corresponds to the user application. The job is distributed and can simultaneously be executed on many nodes. The job control is carried out centralize, from the node named as Job Control Point (JCP). One JCP can control the some jobs. JCP can be located on the same node, on which the job is created, or on any other addressed net point.
仕事はユーザアプリケーションに対応しています。 仕事を広げて、同時に、多くのノードの上で実行できます。 集中して、Job Control Point(JCP)としてノードから命名されて、ジョブ制御が行われます。 1JCPが制御できる、いくつかの仕事。 JCPは同じノードの上、または、ネットのポイントであると扱われたいかなる他のも上に位置できます。雇用はノードに創り出されます。
The task is the job presentation on the separate node. The task includes one or several computing threads of control. The job has only one task on each node.
タスクは別々のノードにおける仕事のプレゼンテーションです。 タスクはコントロールの1かいくつかのコンピューティングスレッドを含んでいます。 仕事には、各ノードに関する1つのタスクしかありません。
The job is finished, when the appropriate user application is finished. At the end of the job all tasks of this job on all nodes are finished.
適切なユーザアプリケーションが終わっているとき、仕事は終わっています。 仕事の終わりに、すべてのノードにおけるこの仕事のすべてのタスクが終わっています。
Bogdanov Experimental [Page 7] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[7ページ]RFC3018
The job has its isolated 128-bit address space. The address space is segmented. A segment is the local memory of one node. Besides, the protocol allows working with objects. The objects are separate associative memory of the node.
仕事には、孤立している128ビットのアドレスのスペースがあります。 アドレス空間は区分されます。 セグメントは1つのノードのローカルの記憶です。 そのうえ、プロトコルは、オブジェクトで働くのを許容します。 オブジェクトはノードの別々の連想記憶です。
The task thread represents the concrete control thread, which are executed by VM in the certain node. The thread can read and write to any address of 128-bit address space of the job. The control transfer to the address from other (remote) node, results to the creation of the new thread on the remote node. The continuous code segment cannot be distributed on several nodes. In addition, it is impossible to receive continuous memory area distributed on several nodes.
タスクスレッドは具体的なコントロールスレッドを表します(あるノードのVMによって実行されます)。 スレッドは128ビットのアドレスのどんなアドレスにも仕事のスペースを読み書きできます。 他の(リモート)のノード(遠隔ノードの上の新しいスレッドの作成への結果)からのアドレスへのコントロール転送。 いくつかのノードの上で連続したコードセグメントを分配できません。 さらに、いくつかのノードの上で分配された連続したメモリ領域を受けるのは不可能です。
The protocol does not demand to support the different tasks of not- crossed memory space from the separate VM node. The supporting of multi-thread is not also the obligatory requirement.
異なったタスクをサポートする、プロトコルが、要求しない-、別々のVMノードからの交差しているメモリスペース。 サポートする、マルチスレッド化、義務的な要件もそうです。
The 128-bit Global Job Identifier (GJID) is defined by protocol. It is assigned on JCP, which will control the job. All active GJID have the unique values in the unified system at each moment of time.
128ビットのGlobal Job Identifier(GJID)はプロトコルによって定義されます。 それはJCPに割り当てられます。(JCPは仕事を制御するでしょう)。 すべてのアクティブなGJIDには、時間の各瞬間に、統一されたシステムのユニークな値があります。
The job can contain VM code of different types. Different types VM can be situated on one or different nodes. The mechanism of association of different VM types in groups on one node is stipulated, so to the non-uniform code can be executed on one node in a context of one job. The groups are described in details in section 9. VM, incorporated in groups, must work in common memory space (to have a common subsystem of memory control).
仕事は異なったタイプのVMコードを含むことができます。 異なったタイプVMは1か異なったノードの上に位置することができます。 規定されているので、1つの仕事の文脈の1つのノードの上で1つのノードに関するグループの異なったVMタイプの協会のメカニズムを不均等なコードに実行できます。 グループはセクション9で詳細に説明されます。 グループで組み込んでいるVMは一般的なメモリスペース(メモリコントロールの一般的なサブシステムを持つ)で働かなければなりません。
Bogdanov Experimental [Page 8] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[8ページ]RFC3018
2.3 System Architecture
2.3 システム構築
System structure, based on using Virtual Machines, is given in the following figure:
以下の図でVirtual Machinesを使用するのに基づくシステム構造を与えます:
Node 1 Node 2
-------- --------
ノード1ノード2-------- --------
+--------------------+ +--------------------+
| User Application 1 | | User Application 1 |
+-----------------------+ +-----------------------+
| User Application N | | User Application N |
+--------------------+ +--------------------+
+--------------------+ +--------------------+ | ユーザアプリケーション1| | ユーザアプリケーション1| +-----------------------+ +-----------------------+ | ユーザアプリケーションN| | ユーザアプリケーションN| +--------------------+ +--------------------+
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| VM1 | | VM2 | . . . | VMn | | VM1 | | VM2 | . . . | VMn |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+
| | | | | |
+--------------------------+ +--------------------------+
| | | |
| +-----+ U M S P | | U M S P |
| | JCP | | | |
| +-----+ | +-------------+------------+
+-------------+------------+ |
| +-----+-----+
+-----+-----+ | TCP |
| TCP | +-----+-----+
+-----+-----+ |
| |
+-----------------/ |
/------------------+
/
|
+-----+-----+
Node N | TCP |
-------- +-----+-----+
|
+------------+------------+
| +-----+ |
| | JCP | U M S P |
| +-----+ |
+-------------------------+
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ | VM1| | VM2| . . . | VMn| | VM1| | VM2| . . . | VMn| +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ | | | | | | +--------------------------+ +--------------------------+ | | | | | +-----+ U M S P| | U M S P| | | JCP| | | | | +-----+ | +-------------+------------+ +-------------+------------+ | | +-----+-----+ +-----+-----+ | TCP| | TCP| +-----+-----+ +-----+-----+ | | | +-----------------/ | /------------------+ / | +-----+-----+ ノードN| TCP| -------- +-----+-----+ | +------------+------------+ | +-----+ | | | JCP| U M S P| | +-----+ | +-------------------------+
Figure 1. Structure of the system based on use VM.
図1。 システムの構造はVMを使用に基礎づけました。
Bogdanov Experimental [Page 9] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[9ページ]RFC3018
One or several VM are working on upper level for UMSP. The VM layer is not network level. Last network level is UMSP. Therefore, VM layer has no its own network primitives and uses together with UMSP the same field of operation code.
1か数個VMが上側のレベルにUMSPに勤めています。 VM層はネットワークレベルではありません。 最後のネットワークレベルはUMSPです。 したがって、VM層は、それ自身のネットワーク基関数を全く持たないで、UMSPと共に命令コードの同じ分野を使用します。
The end services user of the protocol is the user code, which is executed by the virtual machine. It has the instructions with the 128-bit address. VM translates these instructions to network commands, which are transmitted through the UMSP protocol for the executing by the remote machine. Internal organization VM, command system and API can be anyone. The protocol defines only format of primitives, which the virtual machines exchange through a network.
プロトコルの終わりのサービスユーザはユーザコードです。(そのコードは仮想計算機によって実行されます)。 それには、128ビットのアドレスによる指示があります。 VMはこれらの指示をネットワークコマンドに翻訳します。(コマンドはリモートマシンによる実行のためにUMSPプロトコルを通して伝えられます)。 内部の組織VM、指令方式、およびAPIはだれであるかもしれませんも。 プロトコルは基関数の書式だけを定義します。(仮想計算機はネットワークを通して基関数を交換します)。
The protocol does not control the jobs memory. Control of memory should realize VM. If a few VM works on one node, they may have the common memory space or may be completely isolated.
プロトコルは仕事のメモリを制御しません。 メモリのコントロールはVMがわかるはずです。 1つのノードの上のいくつかのVM作品であるなら、それらは、一般的なメモリスペースを持っているか、または完全に隔離されるかもしれません。
UMSP uses the transport layer with reliable delivery for the data exchange. This document defines of using TCP. For the transfer of not requiring acknowledgement data may be used UDP. Thus, the connection through TCP is obligatory. Use of multiple connections TCP with multiplexing is supposed. The control of transport connections is not the part of the UMSP protocol.
UMSPはデータ交換に信頼できる配信があるトランスポート層を使用します。 このドキュメントが定義する、TCPを使用するのについて。 必要さでない転送のために、承認データは中古のUDPであるかもしれません。 したがって、TCPを通した接続は義務的です。 マルチプレクシングがある複数の接続TCPの使用は思われます。 輸送の接続のコントロールはUMSPプロトコルの部分ではありません。
The UMSP instructions do not contain network addresses of the receiver and sender. The protocol requires that one address UMSP must correspond to the one transport layer address. Accordingly, it is necessary to define unequivocal the node address on transport layer by the 128-bit address of memory.
UMSP指示は受信機と送付者のネットワーク・アドレスを含んでいません。 プロトコルは、1アドレスUMSPが1つのトランスポート層アドレスに対応しなければならないのを必要とします。 それに従って、それが定義するのに必要である、はっきりする、メモリの128ビットのアドレスによるトランスポート層に関するノードアドレス。
Except the TCP, it is possible to use other transport protocols or not network communications. The following requirements are showed to them:
TCPを除いて、ネットワークコミュニケーションではなく、他のトランスポート・プロトコルを使用するのは可能です。 以下の要件がそう、彼らに以下を目立たせました。
o Reliable delivery. The transport layer must inform about
delivery or its impossibility;
o The violation of a sequence of transmitted segments is allowed;
o The duplication of segments is not allowed;
o At emergency reload of nodes it is necessary to guarantee
identification of segments concerning session connections,
assigned up to reload;
o Use connectionless-mode is possible.
o 信頼できる配信。 トランスポート層は配送かその不可能に関して知らせなければなりません。 o 伝えられたセグメントの系列の違反は許されています。 o セグメントの複製は許容されていません。 o ノードの非常時の再ロードでは、再ロードまで選任されたセッション接続に関してセグメントの識別を保証するのが必要です。 o 使用、コネクションレスなモードは可能です。
VM is the independent program and the interaction with the protocol is necessary for it only when it executes the instructions with the 128-bit address, concerning to other node. VM can execute several
VMは独立しているプログラムです、そして、128ビットのアドレス、他のノードへの関係があることで指示を実行するときだけ、プロトコルとの相互作用がそれに必要です。 VMは数個を実行できます。
Bogdanov Experimental [Page 10] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[10ページ]RFC3018
user tasks. Each task can contain several threads of control. VM must be able to interpret the application instructions with the 128- bit address to one or several instructions of the UMSP protocol.
ユーザタスク。 各タスクはコントロールのいくつかのスレッドを含むことができます。 VMはUMSPプロトコルの1かいくつかの指示に128ビット・アドレスによるアプリケーション指示を解釈できなければなりません。
The session connection opens between nodes for the data exchange. One connection is relational only with one job. There may be several session connections for the different jobs simultaneously between two nodes. Besides, the protocol provides the connectionless data exchange.
セッション接続はデータ交換のためのノードの間で開きます。 1つの接続が単に1つの仕事で関係しています。 2つのノードの間には、異なった仕事のための接続が同時に、数個のセッションのときにあるかもしれません。 そのうえ、プロトコルはコネクションレスなデータ交換を供給します。
The exchange between UMSP nodes can include the instructions of the following type:
UMSPノードの間の交換は以下のタイプの指示を含むことができます:
o Immediate reading/write in memory;
o Requests of allocation/free memory;
o Comparison instructions;
o Call-subroutine and unconditional jump instructions;
o Synchronization instructions;
o Work with objects instructions - reading / writing in memory of
objects and execution of objects procedures.
o 即座の読書/はメモリに書きます。 o 配分/無料の記憶の要求。 o 比較命令。 o 呼び出しサブルーチンと無条件飛越し命令。 o 同期指示。 o オブジェクトで、オブジェクトに関するメモリとオブジェクトの実行に手順を読み込むか、または書いて、指示を扱ってください。
UMSP does not trace the user control threads. VM must provide itself the necessary order of performance of the instructions.
UMSPはユーザコントロールスレッドをたどりません。 VMは指示の性能の必要な注文をそれ自体に提供しなければなりません。
The length of UMSP instructions does not depend on segment length of the transport layer. The segmentation is provided for transfer of the long instructions. The packing of the short instructions in one segment with a possibility of compression of headings is used for its transfer. The minimal size of necessary for work segment is 6 octets. For realization of all functions, it is necessary 54 octets.
UMSP指示の長さはトランスポート層のセグメントの長さに依存しません。 長い指示の転送に分割を提供します。 見出しの要約の可能性がある1つのセグメントにおける、短い指示のパッキングは転送に使用されます。 仕事セグメントに必要の最小量のサイズは6つの八重奏です。 すべての機能の実現のために、それは必要な54の八重奏です。
3 Instruction Format
3命令形式
The UMSP instruction includes the basic header, extension headers and operands. All fields have variable length.
UMSP指示は基本的なヘッダー、拡張ヘッダー、およびオペランドを含んでいます。 すべての分野には、可変長があります。
+----------------+----------------------+------------------------+ | Header | Extension headers | Operands | +----------------+----------------------+------------------------+
+----------------+----------------------+------------------------+ | ヘッダー| 拡張ヘッダー| オペランド| +----------------+----------------------+------------------------+
The header contains operation code and the information necessary for the instruction interpretation.
ヘッダーは指示解釈に必要な命令コードと情報を含んでいます。
The optional extension headers contain the additional information, not defined in basic header.
任意の拡張ヘッダーは基本的なヘッダーで定義されるのではなく、追加情報を含みます。
The operands contain instructions data.
オペランドは指示データを含んでいます。
Bogdanov Experimental [Page 11] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[11ページ]RFC3018
The instruction format allows calculating common instruction length, without knowing definition of separate operation code.
命令形式で、別々の命令コードの定義を知らないで、一般的な指示の長さについて計算します。
The instructions headers provide for the short and extended format for maintenance of the effective protocol work in wide range of network speeds. Besides, there is a simple algorithm of the headers compression.
指示ヘッダーは広範囲のネットワーク速度における、有効なプロトコル仕事のメインテナンスのための短くて拡張している書式に備えます。 そのうえ、ヘッダー圧縮の簡単なアルゴリズムがあります。
The all instructions and extension headers the identifiers are given which enter the name by upper case symbols. The identifiers of the instructions begin with the letter. The identifiers of the extension headers begin with underlining symbol.
すべての指示と拡張ヘッダー、大文字シンボルで名前を入れる識別子を与えます。 指示に関する識別子は手紙で始まります。 拡張ヘッダーの識別子はシンボルにアンダーラインを引くのに始まります。
3.1 Instruction Header
3.1 指示ヘッダー
The header has the following format:
ヘッダーには、以下の形式があります:
Octets:
+0 +1
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | OPCODE |ASK| PCK |CHN|EXT| OPR_LENGTH|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | OPR_LENGTH_EXT |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
4: | CHAIN_NUMBER |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
6: | INSTR_NUMBER |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
8: | |
+ SESSION_ID +
| |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
12:| |
+ REQ_ID +
| |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
八重奏: +0 +1 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 0: | OPCODE|尋ねてください。| PCK|CHN|EXT| OPR_長さ| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2: | _OPR_長さのEXT| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 4: | チェーン_数| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 6: | INSTR_数| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 8: | | + セッション_ID+| | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 12:| | + REQ_ID+| | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
OPCODE
OPCODE
1 octet. The operation code. Value of this field is identified by
the instruction. Values of operation codes are divided into the
following intervals:
1つの八重奏。 命令コード。 この分野の値は指示で特定されます。 命令コードの値は次の間隔に分割されます:
1 - 112 management instructions
113 - 127 reserved
128 - 223 instructions of exchange between VM
0, 224, 255 reserved
112の管理指示113--127が128を予約したというVM0、224、255の間の交換の223の指示が予約した1
Bogdanov Experimental [Page 12] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[12ページ]RFC3018
ASK
尋ねてください。
1 bit. The flag of response necessity. This flag defines
presence of field REQ_ID in header. If ASK = 1, there is field
REQ_ID in the instruction. If EXT = 0, the field REQ_ID in the
instruction are absent.
1ビット。 応答の必要性の旗。 この旗はヘッダーでの分野REQ_IDの存在を定義します。 ASK=1であるなら、指示には分野REQ_IDがあります。 EXT=0、指示における分野REQ_IDが欠けるなら。
PCK
PCK
2 bits. The Header compression attribute. These bits are used
for packing instructions headers transmitted on one connection TCP
or for sending of the several instructions in one package UDP.
Use of these bits is based on the assumption that two following in
succession instructions concern to one session connection, or one
chain, with a high probability. The PCK bits have one of the
following values:
2ビット。 Header圧縮属性。 これらのビットは1接続TCPのときに伝えられたこん包指示書ヘッダーか1パッケージUDPでのいくつかの指示の送付に使用されます。 これらのビットの使用は継承指示で続く2が1つのセッションまで接続、または1つのチェーンに関係があるという前提に基づいています、高い確率で。 PCKビットには、以下の値の1つがあります:
%b00 - The instruction does not belong to the definite session.
The fields CHAIN_NUMBER, INSTR_NUMBER and SESSION_ID are
absent in header of such instruction.
%b01 - The given instruction concerns to the same session
connection, as previous. The field SESSION_ID in the
instruction header is absent.
%b10 - The given instruction belongs to the same connection and
same chain, as previous. The fields CHAIN_NUMBER,
INSTR_NUMBER and SESSION_ID in header of such instruction
are absent. The INSTR_NUMBER value of the current
instruction calculates by addition of one to INSTR_NUMBER
value of the previous instruction.
%b11 - The given instruction may does not concern to the same
session, as previous. The field SESSION_ID is present at
it. The presence of fields CHAIN_NUMBER and INSTR_NUMBER
is defined by CHN flag.
%b00--指示は明確なセッションに属しません。 分野のCHAIN_NUMBER、INSTR_NUMBER、およびSESSION_IDはそのような指示のヘッダーで欠けています。 %b01--同じセッション接続への前であるとしての与えられた指示関心。 指示ヘッダーの分野SESSION_IDは欠けています。 %b10--与えられた指示は同じ接続と同じことにチェーンで、前であることの状態で属します。 そのような指示のヘッダーの分野のCHAIN_NUMBER、INSTR_NUMBER、およびSESSION_IDは欠けています。 NUMBERが評価する現在の指示のINSTR_は前の指示のINSTR_NUMBER値への1の添加で計算されます。 %b11--前であるとしての指示が同じセッションまで関しないかもしれない付与。 分野SESSION_IDはそれに存在しています。 分野のCHAIN_NUMBERとINSTR_NUMBERの存在はCHN旗で定義されます。
CHN
CHN
1 bit. The flag of chain. Transmitted on one session connection
and concerning one job instructions, may be unified in a chain.
Chains are considered in details by section 7. If SEQ = 1, the
instruction is connected with chain and there are fields
CHAIN_NUMBER and INSTR_NUMBER (if PCK is not set to %b10) at it.
If bit CHN = 0, the instruction is not connected with chains and
there are no fields CHAIN_NUMBER and INSTR_NUMBER in it.
1ビット。 チェーンの旗。 1つのセッション接続と1つの教える技能に関して伝えられて、チェーンで統一されるかもしれません。 チェインズはセクション7によって詳細に考えられます。 SEQ=1、指示がチェーンに接続されて、分野のCHAIN_NUMBERとINSTR_NUMBER(PCKが%b10に用意ができていないなら)がそこにあれば。 ビットCHN=0、指示がチェーンに接続されないで、分野がないことのCHAIN_NUMBERとINSTR_NUMBERがそこにあれば。
Bogdanov Experimental [Page 13] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[13ページ]RFC3018
EXT
EXT
1 bit. The flag of extension headers presence in the instruction.
If EXT = 1, there is one or more extension headers in the
instruction. If EXT = 0, the extension headers in the instruction
are absent.
1ビット。 指示における拡張ヘッダー存在の旗。 EXT=1であるなら、指示には1人以上の拡張ヘッダーがいます。 EXT=0であるなら、指示における拡張ヘッダーは欠けています。
OPR_LENGTH
OPR_長さ
3 bits. The number of 32 bit words in the operands field. The
value 0 defines absence of operands field. The value %b111
specifies use of the extended header format. In the extended
format, the length of operands is defined by the field
OPR_LENGTH_EXT, and the field OPR_LENGTH is not used.
3ビット。 オペランド分野の32ビットの単語の数。 値0はオペランド分野の欠如を定義します。 値の%b111は拡張ヘッダー形式の使用を指定します。 拡張フォーマットでは、オペランドの長さは分野OPR_LENGTH_EXTによって定義されます、そして、分野OPR_LENGTHは使用されていません。
OPR_LENGTH_EXT
_OPR_長さのEXT
2 octets. The number of 32 bit words in the operands field. The
field OPR_LENGTH_EXT is present in header, only if OPR_LENGTH =
%b111. If OPR_LENGTH < > %b111, the field OPR_LENGTH_EXT is
absent. If OPR_LENGTH_EXT = 0, the field of operands is absent.
There are following reasons, on which it is necessary to use field
OPR_LENGTH_EXT instead of OPR_LENGTH:
2つの八重奏。 オペランド分野の32ビットの単語の数。 OPR_LENGTHが%b111と等しい場合にだけ、分野OPR_LENGTH_EXTはヘッダーに存在しています。 OPR_LENGTH<>%b111であるなら、分野OPR_LENGTH_EXTは欠けています。 OPR_LENGTH_EXT=0であるなら、オペランドの分野は欠けています。 次の理由があります:(そこでは、OPR_LENGTHの代わりに分野OPR_LENGTH_EXTを使用するのが必要です)。
(1) If operands length must be more than 24 octets
(2) If making the fields alignment of 4 octets is more
effective, than compression of header of 2 octets.
(1) 4つの八重奏の整列は(2) 分野を作るならオペランドの長さが24以上の八重奏であるに違いないなら2つの八重奏のヘッダーの圧縮より効果的です、。
CHAIN_NUMBER
チェーン_数
2 octets. The number of chain. This field contains number of
chain, to which the given instruction concerns. The values %x0000
and %xFFFF are reserved.
2つの八重奏。 チェーンの数。 この分野は与えられた指示が関するものにチェーンの数を含んでいます。 値の%x0000と%xFFFFは予約されています。
INSTR_NUMBER
INSTR_数
2 octets. The instruction number. This field contains the serial
number of instruction in a chain. The numbering begins with zero.
Value %xFFFF is reserved.
2つの八重奏。 指示番号。 この分野はチェーンに指示の通し番号を含んでいます。 付番はゼロで始まります。 値の%xFFFFは予約されています。
SESSION_ID
セッション_ID
4 octets. It is the identifier of the session connection assigned
by the instruction receiver. During the session connection
opening, each side sets its own identifier to connection and
informs it to other side. The zero value of this field specifies
that the instruction does not concern to the definite session.
The value %xFFFFFFFF is reserved.
4つの八重奏。 それは指示受信機によって選任されたセッション接続に関する識別子です。セッション接続始まりの間、それぞれの側は、それ自身の識別子を接続に設定して、それを反対側に知らせます。 この値がさばくゼロは、指示が明確にセッションが関係がないと指定します。 値の%xFFFFFFFFは予約されています。
Bogdanov Experimental [Page 14] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[14ページ]RFC3018
REQ_ID
REQ_ID
4 octets. The request identifier. It is uses for establishment
of correspondence between requests and responds to it.
4つの八重奏。 要求識別子。 それは、要求の間の通信の設立への用途であり、それに応じます。
Further, the identifier OPR_LENGTH is used at the description of the instructions format. It means using of OPR_LENGTH_EXT field, if OPR_LENGTH = %b111. The instruction with length of operands, which are not exceeding 24 octets, may be transmitted with header in the short format (OPR_LENGTH < > %b111) or in the extended format (OPR_LENGTH = %b111). Both forms are equivalent.
さらに、識別子OPR_LENGTHは指示形式の記述のときに使用されます。 それは、OPR_LENGTHが%b111と等しいならEXTがさばくOPR_LENGTH_が使用されることを意味します。 24の八重奏を超えていないオペランドの長さがある指示はヘッダーと共に短い形式(OPR_LENGTH<>%b111)か拡張フォーマット(OPR_LENGTH=%b111)で伝えられるかもしれません。 両方のフォームは同等です。
Minimal header length in the short format is 2 octets, in the extended format - 4 octets. Maximal header length is 16 octets.
短い形式の最小量のヘッダ長は拡張フォーマットにおいて2つの八重奏です--4つの八重奏。 最大限度のヘッダ長は16の八重奏です。
3.2 Extension Headers
3.2 拡大ヘッダー
If the EXT flag in the instruction header set to 1, the instruction contains from one up to thirty extension headers. The extension headers are used for the following purposes:
EXTが指示ヘッダーセットで1まで弛むなら、指示はある上から30まで拡張ヘッダーを含みます。 拡張ヘッダーは以下の目的に使用されます:
o For sending of the service information which were not provided in
the basic header.
o For sending of the data of length more than 262240 octets in one
instruction.
o 基本的なヘッダー. o Forに提供されなかった情報にサービスを1つの指示における長さの262240以上八重奏に関するデータを発信させるように。
The extension headers have the following common format:
拡張ヘッダーには、以下の一般的な形式があります:
Octets:
+0 +1
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: |HXT| HEAD_LENGTH | HEAD_LENGTH_EXT |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | continued HEAD_LENGTH_EXT |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
4: |HSL|HOB|HRZ| HEAD_CODE | HEAD_CODE_EXT |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
6: | RESERVED |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
8: | |
/ DATA /
/ /
| |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
八重奏: +0 +1 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 0: |HXT| ヘッド_長さ| _ヘッド_長さのEXT| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2: | 継続的な_HEAD_LENGTH EXT| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 4: |HSL|暖炉内部の横棚|HRZ| ヘッド_コード| _ヘッド_コードEXT| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 6: | 予約されます。| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 8: | | /データ///| | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Bogdanov Experimental [Page 15] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[15ページ]RFC3018
HXT
HXT
1 bit. Specify length of the field of data length. If HXT = 0,
length of the extension header is defined by a field HEAD_LENGTH.
The field HEAD_LENGTH_EXT in this case is absent. If HXT = 1,
length of header is defined by unification of fields HEAD_LENGTH
and HEAD_LENGTH_EXT.
1ビット。 データの長さの分野の長さを指定してください。 HXT=0であるなら、拡張ヘッダーの長さは分野HEAD_LENGTHによって定義されます。 この場合、分野HEAD_LENGTH_EXTは欠けています。 HXT=1であるなら、ヘッダーの長さは分野のHEAD_LENGTHとHEAD_LENGTH_EXTの統一で定義されます。
HEAD_LENGTH
ヘッド_長さ
7 bit. The number of 16 bit words in DATA field. If HXT = 0,
this is independent field. If HXT = 1, it is the senior bits of
complete length field.
7に噛み付きました。 DATAの単語がさばく16ビットの数。 HXT=0であるなら、これは独立している分野です。 HXT=1であるなら、それは完全な長さの分野の年上のビットです。
HEAD_LENGTH_EXT
_ヘッド_長さのEXT
3 octets. The number of 16 bit words in DATA field. If HXT = 0,
this field is absent. If HXT = 1, it is the younger bits of
complete length field.
3つの八重奏。 DATAの単語がさばく16ビットの数。 HXT=0であるなら、この分野は欠けています。 HXT=1であるなら、それは完全な長さの分野の、より若いビットです。
HSL
HSL
1 bit. The flag of last header. It is set to 1 for last
extension header in the instruction. In other extension headers,
this flag is set to 0.
1ビット。 最後のヘッダーの旗。 それは指示における最後の拡張ヘッダーのために1に設定されます。 他の拡張ヘッダーでは、この旗は0に設定されます。
HOB
暖炉内部の横棚
1 bit. The flag of obligatory processing. It defines the order
of the instruction processing, if the receiving node does not know
purpose of the extension header or cannot process it by any
reason. If HOB = 1, instruction must not be carried out. If HOB
= 0, it does not influence on the instruction processing. The
protocol must process all extension headers, irrespective of
errors presence.
1ビット。 義務的な処理の旗。 それは指示処理の注文を定義します、受信ノードが拡張ヘッダーの目的を知らないことができませんし、どんな理由でもそれを処理できないなら。 HOB=1であるなら、指示を行ってはいけません。 HOB=0であるなら、指示への影響が処理されて、それは=ではありません。 プロトコルは誤り存在の如何にかかわらずすべての拡張ヘッダーを処理しなければなりません。
HRZ
HRZ
1 bit. The field is reserved for the future expansions. This
field must not be analyzed by the protocol on receiving. It must
be set to 0 at sending.
1ビット。 分野は今後の拡大のために予約されます。 この分野は受信のときにプロトコルによって分析されてはいけません。 それは発信における0へのセットであるに違いありません。
HEAD_CODE
ヘッド_コード
5 bits. If HXT = 0, the field contains the extension header code.
If HXT = 1, this field joins the field HEAD_CODE_EXT. It is the
senior bits of the header code.
5ビット。 HXT=0であるなら、分野は拡張ヘッダーコードを含んでいます。 HXT=1であるなら、この分野は分野HEAD_CODE_EXTを接合します。 それはヘッダーコードの年上のビットです。
Bogdanov Experimental [Page 16] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[16ページ]RFC3018
HEAD_CODE_EXT
_ヘッド_コードEXT
1 octet. If HXT = 0, this field is absent. If HXT = 1, it is the
younger bits of the header code.
1つの八重奏。 HXT=0であるなら、この分野は欠けています。 HXT=1であるなら、それはヘッダーコードの、より若いビットです。
RESERVED
予約されます。
2 octets. If HXT = 0, this field is absent. If HXT = 1, this
field is reserved for further use. The field RESERVED must not be
analyzed by the protocol during the receiving in the current
realization of the protocol. It must be set to 0 at sending.
2つの八重奏。 HXT=0であるなら、この分野は欠けています。 HXT=1であるなら、この分野はさらなる使用のために予約されます。 分野RESERVEDはプロトコルの現在の実現における受信の間、プロトコルによって分析されてはいけません。 それは発信における0へのセットであるに違いありません。
DATA
データ
The data field of the extension header. If HXT = 0, the length of
field is 0 - 254 octets, if HXT = 1, the length is 0 - 4 * 10^9
octets. The format of this field is defined separately for each
value of the header code.
拡張ヘッダーのデータ・フィールド。 HXT=0であるなら、分野の長さは0です--254の八重奏、HXT=1であるなら、長さは0です--4*10の^9八重奏。 この分野の書式はヘッダーコードの各値のために別々に定義されます。
On the receiving side, the extension headers must be processed in that order, in what they follow in the instruction. If the instruction contains more than 30 extension headers, it is considered erroneous. It is necessary to break off the session connection, on which it was transmitted, after the reception of such instruction.
拡張ヘッダーの受信側を、その注文、彼らが指示で続くことで処理しなければなりません。 指示が30人以上の拡張ヘッダーを含むなら、それは誤ると考えられます。 セッション接続をやめるのが必要です。(その時、それはそのような指示のレセプションの後に伝えられました)。
The identifiers HEAD_LENGTH and HEAD_CODE are used further in the text at the description of the extended headers format. It assumes using of fields HEAD_LENGTH + HEAD_LENGTH_EXT and HEAD_CODE + HEAD_CODE_EXT, if HXT = 1. The headers with the code 0 - 30 can be sent in short (HXT = 0) and in extended (HXT = 1) format.
識別子のHEAD_LENGTHとHEAD_CODEは拡張ヘッダー形式の記述のときにテキストで、より遠くに使用されます。 それはHXT=1であるなら分野のHEAD_LENGTH+HEAD_LENGTH_EXTとHEAD_CODE+HEAD_CODE_EXTの使用を仮定します。 コード0--30があるヘッダーは急(HXT=0)と拡張している(HXT=1)形式を送ることができます。
3.3 Instruction Operands
3.3 指示オペランド
The operands field contains the instruction data. The length of operands field is showed in OPR_LENGTH or OPR_LENGTH_EXT and it is multiple to four octets. If necessary, 1 - 3 zero-value octets are padded in the end of a field. Maximal length of operands is 262140 octets. The extension headers are used, if the instruction must contain longer data.
オペランド分野は指示データを含んでいます。 オペランド分野の長さはそうです。OPRでは、_LENGTH_EXTとそれが4つの八重奏への倍数であることを_LENGTHかOPRに示しました。 必要なら、1--3つの無価値の八重奏が畑の端で水増しされます。 最大限度の長さのオペランドは262140の八重奏です。 指示が、より長いデータを含まなければならないなら、拡張ヘッダーは使用されています。
The format of the operands field is defined separately for each instruction.
オペランド分野の書式は各指示のために別々に定義されます。
3.4 Address Formats
3.4 アドレス形式
The following address format numbers are definite for nodes, immediately connected to the global IPv4 network:
以下のアドレス形式番号は、ノードに明確であって、すぐに、グローバルなIPv4ネットワークに関連しています:
Bogdanov Experimental [Page 17] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[17ページ]RFC3018
N 4-0-0 (4)
N 4-0-1 (4-1)
N 4-0-2 (4-2)
N4-0-0(4)N4-0-1(4-1)N4-0-2(4-2)
The appropriate formats of 128-bit addresses:
128ビットのアドレスの適切な形式:
Octets:
+0 +1 +2 +3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0: |0 1 0 0|0 0|0 0| Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4: | Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8: | Free | IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12:| IP address | Local memory address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
八重奏: +0 +1 +2 +3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0: |0 1 0 0|0 0|0 0| 自由| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4: | 自由| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8: | 自由| IPアドレス| +++++++++++++++++++++++++++++++++12: | IPアドレス| 地方のメモリアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0: |0 1 0 0|0 0|0 1| Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4: | Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8: | Free | IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12:| IP address | Local memory address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0: |0 1 0 0|0 0|0 1| 自由| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4: | 自由| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8: | 自由| IPアドレス| +++++++++++++++++++++++++++++++++12: | IPアドレス| 地方のメモリアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0: |0 1 0 0|0 0|1 0| Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4: | Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8: | IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12:| Local memory address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0: |0 1 0 0|0 0|1 0| 自由| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4: | 自由| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8: | IPアドレス| +++++++++++++++++++++++++++++++++12: | 地方のメモリアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Free
自由
It is not used by the protocol.
それはプロトコルによって使用されません。
IP address
IPアドレス
It sets the node address in the global IPv4 network.
それはグローバルなIPv4ネットワークにノードアドレスをはめ込みます。
Bogdanov Experimental [Page 18] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[18ページ]RFC3018
Local memory address
地方のメモリアドレス
It is described in section 2.1.
それはセクション2.1で説明されます。
IP-address defines the nodes of the given type unequivocally. The TCP is used for the interaction with such nodes. For sending of not requiring response instructions, using UDP is allowed. IANA has assigned ports TCP and UDP 2110. This port must be open for the listening (receiving). TCP node, initialing the connection opening, or the UDP node, carrying out the package sending, can use any port. Using several TCP connections with multiplexing is supposed.
IP-アドレスは明確に与えられたタイプのノードを定義します。 TCPはそのようなノードとの相互作用に使用されます。 応答指示を必要としないのを発信させるのにおいて、UDPを使用するのは許されています。 IANAはポートTCPとUDP2110を割り当てました。 聴取(受信)において、このポートは開いているに違いありません。 パッケージ発信を行って、接続始まり、またはUDPノードに頭文字をつけて、TCPノードはどんなポートも使用できます。 マルチプレクシングとのいくつかのTCP関係を使用するのは思われます。
4 Response of the Instructions
4 指示の応答
The protocol instructions are divided into two types:
プロトコル指示は2つのタイプに分割されます:
(1) The management instructions transmitted on UMSP layer (OPCODE
= 1 - 112).
(2) The instructions of the exchange between VM (OPCODE = 128 -
223).
(1) UMSPで伝えられた管理指示は(OPCODE=1--112)を層にします。 (2) VM(OPCODE=128--223)の間の交換の指示。
The processing of two types of the instructions differs as follows:
指示の2つのタイプの処理は以下の通り異なります:
o The field of the identifier of request REQ_ID is formed by the
protocol in the instructions of the first type, and it is formed
by VM for the instructions of the second type.
o The protocol must analyze the field REQ_ID and compare it with the
instructions, transmitted earlier, after receiving of the response
instruction of the first type.
o The protocol must not analyze the field REQ_ID after receiving of
the response instruction of the second type. This instruction is
simply sent to VM.
o 要求REQ_IDに関する識別子の分野は最初のタイプの指示におけるプロトコルによって形成されます、そして、それは2番目のタイプの指示のためにVMによって形成されます。○ 最初のタイプの応答命令を受信した後に、プロトコルは、分野REQ_IDを分析して、より早く伝えられた指示とそれを比べなければなりません。○ 2番目のタイプの応答命令を受信した後に、プロトコルは分野REQ_IDを分析してはいけません。 単にこの指示をVMに送ります。
The response instructions have the field ASK equal to 1. It means, that the header have the field REQ_ID. The value taken from the confirmed instruction is written into the field REQ_ID. The response instruction does not require response.
応答指示には、1と等しい分野ASKがあります。 意味する、ヘッダーには、分野REQ_IDがあります。 確認された指示から取られた値は分野REQ_IDに書かれています。 応答命令は応答を必要としません。
A few VM can be connected to the protocol on the node. Everyone VM can work in its own address space. The identifiers of requests for different VM can coincide. Therefore, instruction is identified by two fields:
ノードの上のプロトコルにいくつかのVMを接続できます。 VMの皆はそれ自身のアドレス空間で働くことができます。 異なったVMを求める要求に関する識別子は一致できます。 したがって、指示は2つの分野によって特定されます:
o The session identifier SESSION_ID, which is connected with
definite VM.
o The request identifier REQ_ID.
o セッション識別子SESSION_ID。(そのIDは明確なVM○ 要求識別子REQ_IDに関連づけられます)。
Bogdanov Experimental [Page 19] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[19ページ]RFC3018
4.1 RSP, RSP_P
4.1 RSP、RSP_P
"Response" (RSP) and "Response of the protocol" (RSP_P) instructions have the identical format. The difference is only in the operation code:
「応答」(RSP)と「プロトコルの応答」(RSP_P)指示には、同じ形式があります。 命令コードだけには違いがあります:
OPCODE = 129/1 ; correspondingly to RSP/RSP_P
ASK = 1
PCK = %b01/11
EXT = 0/1
CHN = 0
OPR_LENGTH = 0/1
SESSION_ID and REQ_ID - The values is taken from the confirmed
instruction.
Operands:
2 octets: The basic return code.
2 octets: The additional return code.
The optional extension header:
_MSG - contains the arbitrary error description.
OPCODEは129/1と等しいです。 RSP/RSP_P ASK=と、1PCKが%b01/11 EXT対応する、等しいです。= 0/1CHNは0OPR_LENGTH=0/1SESSION_IDとREQ_IDと等しいです--確認された指示から値を取ります。 オペランド: 2つの八重奏: 基本的な復帰コード。 2つの八重奏: 追加復帰コード。 任意の拡張ヘッダー: _MSG--任意のエラー記述を含んでいます。
The instruction without operands is used for the positive response. It is equivalent to zero values of the field of the basic and additional return codes.
オペランドのない指示は積極的な応答に使用されます。 基本的で追加している復帰コードの分野の値のゼロを合わせるのは同等です。
The zero basic return code is used for positive response. The additional return code may have non-zero value.
ゼロ基本的な復帰コードは積極的な応答に使用されます。 追加復帰コードには、非ゼロ値があるかもしれません。
The instruction with non-zero basic return code is used for negative response. The basic return code defines the error category. The additional return code identifies an error.
非ゼロの基本的な復帰コードによる指示は否定応答に使用されます。 基本的な復帰コードは誤りカテゴリを定義します。 追加復帰コードは間違いを突き止めます。
The instruction RSP is formed upon the VM request. The return codes must be received from VM. If the protocol cannot deliver the requiring response instruction to VM, it forms negative response RSP independently.
指示RSPはVM要求のときに形成されます。 VMから復帰コードを受け取らなければなりません。 プロトコルがVMへの応答命令を必要に提供できないなら、それは独自に否定応答RSPを形成します。
The instruction RSP_P is always formed at the UMSP layer. If the protocol cannot define on what instruction the RSP_P is transmitted, nothing actions is executed.
指示RSP_PはいつもUMSP層に形成されます。 プロトコルであるなら、どんな指示へのRSP_Pが伝えられて、何かも動作でないかをでも定義できません。実行されます。
4.2 SND_CANCEL
4.2SND_キャンセル
There can be a necessity to cancel sending after the part of the data have been already transmitted and have occupied the buffer on the reception side, by sending of the long fragmented instructions or transactions. The protocol provides the instruction "The sending is canceled" (SND_CANCEL) for this purpose. This instruction has the following fields value:
伝えられて、データの部分が既に発信した後に発信しながら取り消して、バッファを占領した必要がレセプション側にあることができます、長い断片化している指示か取引を発信させることによって。 プロトコルはこのために、「発信は取り消されること」を(SND_キャンセル)指示に提供します。 以下の分野はこの指示で以下を評価します。
Bogdanov Experimental [Page 20] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[20ページ]RFC3018
OPCODE = 2
ASK = 0
PCK = %b01/10/11
EXT = 0/1
CHN = 1
OPR_LENGTH = 1
SESSION_ID - The value is taken from the cancelled chain.
CHAIN_NUMBER - Number of the chain, which sending is cancelled.
INSTR_NUMBER - Always has zero-value.
Operands:
2 octets: The basic return code.
2 octets: The additional return code.
The optional extension header:
_MSG - contains the arbitrary error description.
0/1 0 2OPCODE=ASK=PCK=%b01/10/11 EXT=CHNは1 1OPR_LENGTH=SESSIONの_IDと等しいです--取り消されたチェーンから値を取ります。 CHAIN_NUMBER--チェーンの数。その発信は取り消されます。 INSTR_NUMBER--いつも無値を持っています。 オペランド: 2つの八重奏: 基本的な復帰コード。 2つの八重奏: 追加復帰コード。 任意の拡張ヘッダー: _MSG--任意のエラー記述を含んでいます。
The instruction SND_CANCEL is used for the cancel of the partially transmitted transaction or fragmented instruction. At the receiving the SND_CANCEL instruction, all the earlier received data in the chain are rejected.
指示SND_キャンセルは部分的に伝えられた取引か断片化している指示のキャンセルに使用されます。 受信のときに、SND_キャンセル命令であり、チェーンにおけるすべての以前の受信データが拒絶されます。
5 Jobs Management
5 ジョブス管理
The jobs management includes the following functions:
仕事の経営者側は以下の機能を含んでいます:
o Initiation and completion of jobs; o Initiation and completion of tasks; o Opening and closing of session connections; o Activity control of nodes.
o 仕事の開始と完了。 o タスクの開始と完了。 o セッション接続の始まりと閉鎖。 o ノードのアクティビティ管理。
The instructions with OPCODE = 1 - 112 are used for jobs management. These instructions must be sent through TCP. Use UDP is not allowed, even if the instructions do not demand response.
OPCODE=1--112がある指示は仕事の管理に使用されます。 TCPを通してこれらの指示を送らなければなりません。 指示が応答を要求しないでもUDPが許容されていない使用。
UMSP bases on model with the centralized control of the separate job. The reason is that the pointers control is not obviously possible in the decentralized system. Any task can be finished at any moment or the node can be reloaded. There is no way guaranteeing the notification about in the decentralized system all other nodes, on which the job works. As the job continues to exist - the task concerning the job can be initiated on the same node again. This task can allocate new dynamic resources. The addresses for the again allocated resources can be crossed with addresses of resources, which existed on the node before the task restart. The old pointers can be kept on other nodes. It may be the formally correct pointers, but they will actually specify other objects. The uncontrollable work of the application can be consequence of such situation.
UMSPは別々の仕事の集中制御でモデルを基礎づけます。 理由はポインタ制御装置が分散システムで明らかに可能でないということです。 どんなタスクもいつ何時、終わることができますか、またはノードは再び積むことができます。 分散システムの仕事が取り組む他のすべてのノードに関する通知を保証する道が全くありません。 仕事が存続するので--再び同じノードの上で仕事に関するタスクを開始できます。 このタスクは新しいダイナミックなリソースを割り当てることができます。 リソースのアドレスで再び割り当てられたリソースのためのアドレスに交差できます。(リソースはタスク再開の前にノードの上に存在しました)。 他のノードの上に古いポインタを保つことができます。 それは正式に正しいポインタであるかもしれませんが、それらは実際に他の物を指定するでしょう。 アプリケーションの制御不可能な仕事はそのような状況の結果であるかもしれません。
Bogdanov Experimental [Page 21] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[21ページ]RFC3018
UMSP solves this task as follows:
UMSPは以下のこのタスクを解決します:
o It allows defining the node, on which the task was completed,
precisely.
o If the task on the node is finished before end of the job, all
nodes, on which the job is executed, are notified of it.
o The repeated task initialization on the node is allowed, while all
nodes will receive the message about the first task end.
o 仕事では、それについてすべてのノード(仕事は実行される)に通知します。それでどれに関するタスクが完成して. ○ 正確にIfがタスクであるかに関してノードを定義することノードが終えている。すべてのノードがメッセージを受け取る間の最初のタスク終わり頃の○ ノードにおける繰り返されたタスク初期化が許されている終わりの
The protocol does not control the pointers. VM supervises the pointers correctness. VM must have architecture, in which 128 - bit pointers are stored in special memory areas, for this purpose. The protocol informs VM about the nodes, on which task have finished the work. VM must make all pointers concerning such tasks, invalid. It results in exclusive situations at the access under these pointers. If the application provides processing exceptions, it keeps the capacity for work, or it is finished emergency. Such decision allows excluding unguided applications working.
プロトコルはポインタを制御しません。 VMはポインタの正当性を監督します。 VMには、特別なメモリ領域に128--噛み付いているポインタがどれであるかに格納された構造がこの目的のためになければなりません。 プロトコルは、どのタスクが仕事を終えたかをノードと、オンの周りのVMに知らせます。 病人、VMはそのようなタスクに関してすべてのポインタを作らなければなりません。 それはこれらのポインタの下のアクセスのときに唯一の状況をもたらします。 アプリケーションが処理例外を提供するなら、仕事のために容量を保つか、それは終わっている非常時です。 そのような決定で、非誘導されたアプリケーション運用を除きます。
For the decision of the specified questions at UMSP level, the control job node is defined for each job. It names Job Control Point (JCP). It may be the same node, on which the job is initiated, or it can be another dedicated node. The basic JCP function is to trace the initialization and the end of the job tasks. Besides, the dedicated JCP node may be used for the centralized users identification and the attack protection.
UMSPレベルにおける指定された質問の決定において、規制仕事のノードは各仕事のために定義されます。 それは(JCP)とJob Control Pointを命名します。 それは同じノードであるかもしれませんかそれが別の専用ノードであるかもしれません。仕事はノードで開始されます。 基本的なJCP機能は仕事のタスクの初期化と終わりをたどることです。 そのうえ、専用JCPノードは集結されたユーザ識別と攻撃保護に使用されるかもしれません。
The following identifiers are definite for the jobs and tasks control:
仕事とタスクコントロールに、以下の識別子は明確です:
o Locally Task Identifier (LTID) is assigned to each active task on
the node. LTID length is equal to the length of local memory
address defined for the node. All LTID on the node must give
unique values at each moment of time. It is allowed to establish
LTID, used earlier in the already completed tasks, for the again
initiated tasks.
o JCP assigned the Control Task Identifier (CTID) to each task of
the job. Its length is equal to length of the local address
memory on the node JCP. All CTID on the JCP must give unique
values at each moment of time. As against LTID, the CTID value is
chosen with some restrictions.
o Globally Task Identifier (GTID) is assigned to each task. GTID
has the same format, as the 128 - bit address of node memory has.
The address of local memory is replaced on LTID in it.
o Globally Job Identifier (GJID) is assigned to the each job. GJID
is defined on the JCP node. It has the same format, as the 128 -
bit address of node JCP memory has. The address of local memory
o 局所的に、Task Identifier(LTID)はノードに関する各アクティブ・タスクに割り当てられます。 LTIDの長さはノードのために定義された地方のメモリアドレスの長さと等しいです。 ノードの上のすべてのLTIDが時間の各瞬間にユニークな値を与えなければなりません。 それは再び開始しているタスクのために、より早く既に完成したタスクで使用されたLTIDを設立できます。o JCPはControl Task Identifier(CTID)を仕事に関する各タスクに割り当てました。 長さはノードJCPに関するローカルアドレスメモリの長さと等しいです。 JCPの上のすべてのCTIDが時間の各瞬間にユニークな値を与えなければなりません。 LTIDに対比して、CTID値はいくつかの制限で選ばれています。o Globally Task Identifier(GTID)は各タスクに割り当てられます。 GTIDには、128と同じ形式があります--メモリが持っているノードのビット・アドレス。 それでLTIDでローカルの記憶のアドレスを取り替えます。o Globally Job Identifier(GJID)をそれぞれ賃仕事に割り当てます。 GJIDはJCPノードの上で定義されます。 それには、128と同じ形式があります--JCPメモリが持っているノードのビット・アドレス。 ローカルの記憶のアドレス
Bogdanov Experimental [Page 22] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[22ページ]RFC3018
is replaced on CTID of the first (initial) task of the job in it.
GJID is used in the procedure of session connection opening for
the definition JCP, which controls the job.
仕事の最初の(初期)のタスクのCTIDでは、それで取り替えます。 GJIDは仕事を制御する定義JCPのために開いているセッション接続の手順で使用されます。
LTID and CTID are written at the instructions in the field of length 2/4/8 octets. If the allocated for identifier field in the instruction is longer than identifier, LTID (CTID) writes in the last octets. In the initial octets, the value 0 must be written. If received LTID (CTID) is shorter than the local memory address, it is necessary to pad it with the zero octets in the beginning.
LTIDとCTIDは長さの2/4/8の八重奏の分野での指示のときに書かれます。 指示における識別子分野への割り当てが識別子より長いなら、LTID(CTID)は最後の八重奏に書きます。 初期の八重奏に、値0を書かなければなりません。 容認されたLTID(CTID)が地方のメモリアドレスより短いなら、それを水増しするのに必要である、八重奏のゼロを合わせてください、初めに。
GTID and GJID are written at the instructions in the field of length 4-16 octets. The field FREE is not present at these identifiers (see section 2.1). It is considered, that it contains the zero-value octets. Length of the identifier is defined in header of the address.
GTIDとGJIDは長さ4-16八重奏の分野での指示のときに書かれます。 分野から無料であることは、これらの識別子でプレゼント(セクション2.1を見る)ではありません。 それは考えられて、それはそれです。無価値の八重奏を含んでいます。 識別子の長さはアドレスのヘッダーで定義されます。
By sending of instructions CONTROL_REQ, TASK_REG and SESSION_OPEN, the protocol uses timeout. The value of timeout is assigned by node and must be more than three intervals of the maximal time of delivery at the transport layer. The timeout is not influenced the waiting period in queue to the transport layer.
指示CONTROL_REQの送付、TASK_REG、およびSESSION_オープンで、プロトコルはタイムアウトを使用します。 タイムアウトの値は、ノードによって割り当てられて、トランスポート層での配送の最大限度の現代の3回以上の間隔でなければなりません。 タイムアウトは影響を及ぼされないで、輸送への待ち行列における待ちの期間が層にするということです。
5.1 Job Initiate
5.1 仕事の開始
The job concerns to the user application executed on VM. The UMSP job initialization can be made simultaneously with the application user start or during its working.
VMで作成されたユーザアプリケーションへの仕事上の心配。 同時に、アプリケーションユーザ始めかその働きの間、UMSP仕事の初期化をすることができます。
The task, appropriated to its job, is initialized on the node together with the job. LTID is binding to this task.
仕事に当てられたタスクは仕事と共にノードの上で初期化されます。 LTIDはこのタスクに拘束力があります。
If the node, on which the user application was loaded, is chosen for JCP, the question of the job initialization lays beyond the scope of the network protocol.
ノード(ユーザアプリケーションはロードされた)がJCPに選ばれているなら、仕事の初期化の問題はネットワーク・プロトコルの範囲を超えて横たえられます。
Other node can be chosen as JCP for the following reasons:
以下のためのJCPが推論するように他のノードを選ぶことができます:
o The job initialization node is connected to network by slow-speed
or overloaded channel. It is undesirable to send the managing
traffic.
o The node has no computing possibilities for conducting the
managing tables.
o The authentication on the detailed node is necessary.
o 仕事の初期化ノードは遅い速度か積みすぎられたチャンネルでネットワークでつなぐのにおいて接続されています。 管理交通を送るのは望ましくありません。○ ノードには、計算していない可能性が、管理テーブルを行うためにあります。○ 詳細なノードにおける認証が必要です。
If the other node is chosen for JCP, the node, that initiates the job, must register the job at JCP.
もう片方のノードがJCP、ノードに選ばれているなら、それは、仕事を開始して、JCPに仕事を登録しなければなりません。
Bogdanov Experimental [Page 23] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[23ページ]RFC3018
5.1.1 CONTROL_REQ
5.1.1 コントロール_REQ
The instruction "To request a control" (CONTROL_REQ) is sending from the node, initial the job, to JCP of other node. The instruction has the following values of fields:
指示「コントロールを要求する」(CONTROL_REQ)はノードから発信して、他のノードのJCPに仕事に頭文字をつけてください。 指示には、分野の以下の値があります:
OPCODE = 3
PCK = %b00
CHN = 0
ASK = 1
EXT = 0/1
OPR_LENGTH = 2/3 ; Depends on LTID length.
REQ_ID - The value is assigned by the sender node protocol and
then will be sent in the response.
Operands:
4 octets: The control parameters profile. This field has the
following format:
3OPCODE=PCK=%b00 CHN=0は1EXTの==0/1OPR_長さ=の2/3を尋ねます。 LTIDの長さに依存します。 REQ_ID--値を送付者ノードプロトコルで割り当てて、次に、応答で送るでしょう。 オペランド: 4つの八重奏: 管理パラメータプロフィール。 この分野には、以下の形式があります:
bits
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
+ JOB_LIFE_TIME +
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| CMT | Reserved | VERSION |
+-----+-----+-----+-----+-----+-----+-----+-----+
| Reserved |
+-----+-----+-----+-----+-----+-----+-----+-----+
ビット0 1 2 3 4 5 6 7+-----+-----+-----+-----+-----+-----+-----+-----+ | | + _時間+仕事_人生| | +-----+-----+-----+-----+-----+-----+-----+-----+ | CMT| 予約されます。| バージョン| +-----+-----+-----+-----+-----+-----+-----+-----+ | 予約されます。| +-----+-----+-----+-----+-----+-----+-----+-----+
JOB_LIFE_TIME
_時間仕事_人生
2 octets. The job lifetime in seconds. The zero-value
signifies that the restriction of the job lifetime is
unused.
2つの八重奏。 秒の仕事の生涯。 無値は、仕事の生涯の制限が未使用であることを意味します。
CMT
CMT
1 bit. The flag of several JCP using. This field is
reserved for the future expansion of the protocol.
1ビット。 数個のJCP使用の旗。 この分野はプロトコルの今後の拡大のために予約されます。
VERSION
バージョン
1 octet. The number of the UMSP version. It must
contain the value 1.
1つの八重奏。 UMSPバージョンの数。 それは値1を含まなければなりません。
Bogdanov Experimental [Page 24] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[24ページ]RFC3018
Reserved
予約されます。
3 + 8 bits. All bits must be set to 0.
3+8ビット。 すべてのビットを0に設定しなければなりません。
4/8 octet: LTID of task of the job, assigned on the node, which
initiate the job (by the sender of this
instruction).
The optional extension headers:
_JOB_NAME - This header contains the name of the Job. Is
assigned once and must not change further.
_INACT_TIME - This header contains the inaction time (see
section 5.7).
4/8八重奏: 仕事(この指示の送付者による)を開始するノードで割り当てられた仕事に関するタスクのLTID。 任意の拡張ヘッダー: _JOB_NAME--このヘッダーはJobという名前を含んでいます。 一度割り当てられて、さらに変化してはいけません。 _INACT_タイム誌--このヘッダーは無活動時間を含んでいます(セクション5.7を見てください)。
At reception of the CONTROL_REQ instruction JCP checks the LTID value from the received instruction and makes the following:
CONTROL_REQ指示のレセプションでは、JCPは容認された指示からLTID値をチェックして、以下を作ります:
(1) If the node, which has sent CONTROL_REQ, already has registered
on JCP the active job with such LTID, the notification about
abnormality end of the registered job is sent, as is described in
section 5.5.2 (it is considered, that the node was reloaded).
After that, the sanction to an initiation of the new job is sent.
(2) If the node has no registered job with received LTID, it allows
the new job initiation at once.
(1) ノード(CONTROL_REQを送った)がJCPに既にそのようなLTIDに活発な仕事を登録したなら、そのままでセクション5.5で説明されていた状態で登録された仕事の異常終わり頃の通知を送ります。.2 (それを考える、ノードは再び積まれました) その後に、新しい仕事の開始への認可を送ります。 (2) ノードに容認されたLTIDとの登録された仕事が全くないなら、それはすぐに、新しいジョブ起動を許容します。
If JCP confirms the control, it will send the instruction CONTROL_CONFIRM, or else CONTROL_REJECT.
JCPがコントロールを確認すると、それは指示CONTROL_CONFIRM、またはCONTROL_REJECTを送るでしょう。
5.1.2 CONTROL_CONFIRM
5.1.2 _が確認するコントロール
The instruction "To confirm the control" (CONTROL_CONFIRM) is sent from JCP as the positive response to CONTROL_REQ instruction. CONTROL_CONFIRM has the following values of fields:
CONTROL_REQ指示への積極的な応答としてJCPから指示「コントロールを確認する」(CONTROL_CONFIRM)を送ります。 CONTROL_CONFIRMには、分野の以下の値があります:
OPCODE = 4
PCK = %b00
CHN = 0
ASK = 1 ; The instruction does not need to be responded. This flag
specifies presence of the REQ_ID field.
EXT = 0/1
OPR_LENGTH = 1-4 ; Depends of length of the GJID.
REQ_ID - The value is taken from the instruction CONTROL_REQ
Operands:
4-16 octets: The GJID assigned to the job on the JCP.
4OPCODE=PCK=%b00 CHN=0は=1を尋ねます。 指示は反応する必要はありません。 この旗はREQ_ID分野の存在を指定します。 EXTは= 1-4に0/1のOPR_長さと等しいです。 GJIDの長さを依存させます。 REQ_ID--指示CONTROL_REQ Operandsから値を取ります: 4-16の八重奏: JCPにおける仕事に割り当てられたGJID。
The sending of the instruction CONTROL_REQ means request of control and request of task initiation. Assigned to the task CTID is part GJID (field of the local memory address).
指示CONTROL_REQの発信はコントロールの要求とタスク開始の要求を意味します。 タスクCTIDに割り当てられているのは、パートGJID(地方のメモリアドレスの分野)です。
Bogdanov Experimental [Page 25] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[25ページ]RFC3018
5.1.3 CONTROL_REJECT
5.1.3 コントロール_廃棄物
The instruction "To reject the control" (CONTROL_REJECT) is sent from JCP as the negative response to CONTROL_REQ instruction. CONTROL_REJECT has the following values of fields:
指示「コントロールを拒絶する」(CONTROL_REJECT)を否定応答としてのJCPからCONTROL_REQ指示に送ります。 CONTROL_REJECTには、分野の以下の値があります:
OPCODE = 4
PCK = %b00
CHN = 0
ASK = 1. The instruction does not need to be responded. This flag
specifies presence of the REQ_ID field.
EXT = 0/1
OPR_LENGTH = 1/2 ; Depends on presence of the control parameters
profile field.
REQ_ID - The value is taken from the instruction CONTROL_REQ
Operands:
2 octets: The basic error code. The zero-value is not
available.
2 octets: The additional error code.
4 octets: The control parameters profile (see section 5.1.1),
that is allowed by JCP. This is optional field.
The optional extension headers:
_INACT_TIME - This header contains the inaction time (see
section 5.7).
_MSG - contains the arbitrary error description.
4OPCODE=PCK=%b00 CHN=0は=1を尋ねます。 指示は反応する必要はありません。 この旗はREQ_ID分野の存在を指定します。 EXTは0/1のOPR_長さ=1/2と等しいです。 パラメタプロフィールがさばくコントロールの存在によります。 REQ_ID--指示CONTROL_REQ Operandsから値を取ります: 2つの八重奏: 基本的なエラーコード。 無値は利用可能ではありません。 2つの八重奏: 追加エラーコード。 4つの八重奏: 管理パラメータプロフィール(セクション5.1.1を見る)であり、それはJCPによって許容されています。 これは任意の分野です。 任意の拡張ヘッダー: _INACT_タイム誌--このヘッダーは無活動時間を含んでいます(セクション5.7を見てください)。 _MSG--任意のエラー記述を含んでいます。
5.2 Task Initiate
5.2 タスク開始
The job is executed on several nodes simultaneously. The task, appropriate to it, must be initialized on each node. There is corresponding only one task to one job on the node. Each task must be connected only with one job.
仕事は同時に、いくつかのノードの上で実行されます。 各ノードの上でそれに適切なタスクを初期化しなければなりません。 1つだけがノードにおける1つの仕事まで仕事を課す対応があります。 各タスクを1つの仕事だけに関連づけなければなりません。
The task is initiated together with the job on the node, which had created the job. On the other nodes, the task is initiated during the receiving of the first request on the opening of the session connection, which is appropriate to the job. The request about openings of session connection contains GJID. GJID contains the JCP address. It is necessary to receive the sanction from JCP for the task start. If the request about the opening of session has been received from JCP node, it is not necessary to request the sanction.
タスクは仕事と共にノードの上で開始されます。ノードは雇用を創り出しました。 他のノードの上では、タスクはセッション接続の始まりの上の最初の要求の受信の間、開始されます。接続は仕事に適切です。 セッション接続の始まりに関する要求はGJIDを含んでいます。 GJIDはJCPアドレスを含んでいます。 認可をJCPからタスク開始に受けるのが必要です。 JCPノードからセッションの始まりに関する要求を受け取ったなら、認可を要求するのは必要ではありません。
5.2.1 TASK_REG
5.2.1 タスク_レッジ
The instruction "To register a task" (TASK_REG) is sent from the node, which initials the task, to JCP of the remote node. The instruction has the following values of fields:
ノードから指示「タスクを登録する」(TASK_REG)を送ります、遠隔ノードのJCPに。(ノードはタスクに頭文字をつけます)。 指示には、分野の以下の値があります:
Bogdanov Experimental [Page 26] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[26ページ]RFC3018
OPCODE = 6/7/8 ; For length CTID of 2/4/8 octets.
PCK = %b00
CHN = 0
ASK = 1
EXT = 0/1
OPR_LENGTH = 2-8 ; Depends on length of the GTID and LTID.
REQ_ID - The value is assigned by the sender node protocol and
then will be sent in the response.
Operands:
2/4/8 octets: CTID of the task initiated the job. It CTID is a
part GJID from the instruction SESSION_OPEN.
4-16 octets: GTID, assigned on the node, initialed session
connection. GTID is formed of sender addresses (at
transport layer) and field LTID of the instruction
SESSION_OPEN.
2/4/8 octets: LTID, assigned on the node, initialed the task
(by the sender of this instruction).
The optional extension headers:
_INACT_TIME - This header contains the inaction time (see
section 5.7).
6/7/8のOPCODE=。 2/4/8の八重奏の長さのCTIDのために。 b00 CHN=0が0/1のOPR_長さと等しいように=1EXTに頼むPCK=%は2-8と等しいです。 GTIDとLTIDの長さに依存します。 REQ_ID--値を送付者ノードプロトコルで割り当てて、次に、応答で送るでしょう。 オペランド: 2/4/8の八重奏: タスクのCTIDは仕事を開始しました。 それ、CTIDは指示SESSION_オープンからのパートGJIDです。 4-16の八重奏: ノードで割り当てられたGTIDはセッション接続に頭文字をつけました。 GTIDは指示SESSION_オープンの送付者アドレス(トランスポート層の)と分野LTIDについて形成されます。 2/4/8の八重奏: ノードで割り当てられたLTIDはタスク(この指示の送付者による)に頭文字をつけました。 任意の拡張ヘッダー: _INACT_タイム誌--このヘッダーは無活動時間を含んでいます(セクション5.7を見てください)。
The instruction TASK_REG must be sent only if the task with given GJID was not initiated on the node.
ノードの上で与えられたGJIDがあるタスクを開始しなかった場合にだけ、指示TASK_REGを送らなければなりません。
JCP confirms initiation of a task at observance of the following conditions:
JCPは以下の条件の遵守でタスクの開始を確認します:
(1) Task with received GTID already has registered on JCP.
(2) Task with LTID for the node requesting for initiation has not
registered.
(1) 容認されたGTIDがあるタスクはJCPに既に登録してあります。 (2) 開始のためのノード要求のためのLTIDがあるタスクは登録されていません。
In all other cases, JCP will not confirm a task.
他のすべての場合では、JCPはタスクを確認しないでしょう。
If JCP confirms the task, it will send the instruction TASK_CONFIRM, differently TASK_REJECT.
JCPがタスクを確認するなら、それはTASK_CONFIRMを指示に異なって送るでしょう。TASK_REJECT。
5.2.2 TASK_CONFIRM
5.2.2 _が確認するタスク
The instruction "To confirm the task" (TASK_CONFIRM) is sent from JCP as the positive response to TASK_REG. TASK_CONFIRM has the following values of fields:
TASK_REGへの積極的な応答としてJCPから指示「タスクを確認する」(TASK_CONFIRM)を送ります。 TASK_CONFIRMには、分野の以下の値があります:
OPCODE = 9
PCK = %b00
CHN = 0
ASK = 1. The instruction does not need to be responded. This flag
specifies the field REQ_ID presence.
EXT = 0/1
9OPCODE=PCK=%b00 CHN=0は=1を尋ねます。 指示は反応する必要はありません。 この旗は分野REQ_ID存在を指定します。 EXTは0/1と等しいです。
Bogdanov Experimental [Page 27] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[27ページ]RFC3018
OPR_LENGTH = 1/2 ; Depends on length of the CTID.
REQ_ID - The value is taken from the instruction TASK_REG.
Operands:
4/8 octets: The CTID assigned to the task on the JCP.
The optional extension headers:
_JOB_NAME - This header contains the name of the Job.
OPR_長さは1/2と等しいです。 CTIDの長さに依存します。 REQ_ID--指示TASK_REGから値を取ります。 オペランド: 4/8の八重奏: JCPに関するタスクに割り当てられたCTID。 任意の拡張ヘッダー: _JOB_NAME--このヘッダーはJobという名前を含んでいます。
5.2.3 TASK_REJECT
5.2.3 タスク_廃棄物
The instruction "To reject the task" (TASK_REJECT) is sent from JCP as the negative response to TASK_REG instruction. TASK_REJECT has the following values of fields:
指示「タスクを拒絶する」(TASK_REJECT)を否定応答としてのJCPからTASK_REG指示に送ります。 TASK_REJECTには、分野の以下の値があります:
OPCODE = 10
PCK = %b00
CHN = 0
ASK = 1. The instruction does not need to be responded. This flag
specifies presence of the REQ_ID field.
EXT = 0/1
OPR_LENGTH = 1
REQ_ID - The value is taken from the instruction CONTROL_REQ
Operands:
2 octets: The basic error code. The zero-value is not
available.
2 octets: The additional error code.
The optional extension headers:
_INACT_TIME - This header contains the inaction time (see
section 5.7).
_MSG - contains the arbitrary error description.
10OPCODE=PCK=%b00 CHN=0は=1を尋ねます。 指示は反応する必要はありません。 この旗はREQ_ID分野の存在を指定します。 EXTは1 0/1OPR_LENGTH=REQの_IDと等しいです--指示CONTROL_REQ Operandsから値を取ります: 2つの八重奏: 基本的なエラーコード。 無値は利用可能ではありません。 2つの八重奏: 追加エラーコード。 任意の拡張ヘッダー: _INACT_タイム誌--このヘッダーは無活動時間を含んでいます(セクション5.7を見てください)。 _MSG--任意のエラー記述を含んでいます。
5.2.4 TASK_CHK
5.2.4 タスク_CHK
With the purposes of a safety the node, which have received request about the opening of session connection, may check up at JCP the node, which has initialed connection, even if the task was already initiated.
安全の目的で、ノード(セッション接続の始まりに関する要求を受け取った)はJCPでノードについて調査するかもしれません、タスクが既に開始されたとしても。(ノードは接続に頭文字をつけました)。
The instruction "To check up the task" (TASK_CHK) is sent from the node, which has received the instruction of the establishment of session connection SESSION_OPEN, to JCP. The task with given GJID, must have existed on the node already. The instruction TASK_CHK format coincides with TASK_REG. OPCODE = 11. The response to the instruction TASK_CHK JCP forms instructions TASK_REG similarly.
ノードから指示「タスクについて調査する」(TASK_CHK)を送ります、JCPに。(ノードはセッション接続SESSION_オープンの確立の指示を受けました)。 与えられたGJIDがあるタスク、必須はノードの上に既に存在しました。 指示TASK_CHK形式はTASK_REGと同時に起こります。 OPCODE=11。 指示TASK_CHK JCPへの応答は同様に指示TASK_REGを形成します。
JCP confirms the instruction TASK_CHK if a task with received GTID and LTID already has registered on JCP.
容認されたGTIDとLTIDがあるタスクがJCPに既に登録してあるなら、JCPは指示TASK_CHKを確認します。
The sending of the TASK_CHK is optional.
TASK_CHKの発信は任意です。
Bogdanov Experimental [Page 28] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[28ページ]RFC3018
5.3 Establishment of session connection
5.3 セッション接続の設立
The session connection is established between two tasks of one job. The connection is established under the VM initiative and it is used for the exchange of the instructions between VM.
セッション接続は1つの仕事に関する2つのタスクの間で確立されます。 接続はVMイニシアチブで確立されます、そして、それはVMの間の指示の交換に使用されます。
One session connection must be connected only with one task on the node. The task may have several connections with different nodes. Between two nodes must be only one session connection with one GJID.
1つのセッション接続をノードに関する1つのタスクだけに接続しなければなりません。 タスクには、異なったノードとのいくつかの接続があるかもしれません。 2の間では、ノードは1GJIDとの1つのセッション関係であるにすぎないに違いありません。
The request about the establishment of session connection contains the global identifier of the job GJID. If the node receives the request about the establishment of connection with GJID, which is not presented on the given node, VM must create a new task. If the task has been already initialized, the new task is not created.
セッション接続の設立に関する要求は仕事のGJIDのグローバルな識別子を含んでいます。 ノードが与えられたノードの上に示されないGJIDとの接続の設立に関する要求を受け取るなら、VMは新たなタスクを生成しなければなりません。 タスクが既に初期化されたなら、新しいタスクは作成されません。
The session connection needs to be established over TCP. After the connection is established, the sending of the instructions, which are not require of execution response, is possible through UDP. One TCP connection may be used by several session connections. One session connection may use several TCP connections.
セッション接続は、TCPの上に設立される必要があります。 接続が確立された後に、指示の発信であり、どれがあるかは、実行応答に要求して、UDPを通して可能ではありません。 1つのTCP接続がいくつかのセッション接続によって使用されるかもしれません。 1つのセッション接続がいくつかのTCP接続を使用するかもしれません。
The protocol allows working without the establishment of session connection. The node must have VM by default, which must execute the instructions without the establishment of connection.
プロトコルは、セッション接続の設立なしで働くのを許容します。 ノードには、VMがデフォルトでなければなりません(接続の設立なしで指示を実行しなければなりません)。
At the establishment of session connection, the sides agree about the used VM type and the subset of the protocol functions. The session connection UMSP may be asymmetrical. It means, that two sides of one connection can be connected with VM of the different type and provide the different subset of the protocol functions.
セッション接続の設立のときに、側は中古のVMタイプとプロトコル機能の部分集合に関して同意します。 セッション接続UMSPは非対称的であるかもしれません。 それは、1つの接続の2つの側面が異なったタイプのVMに接続されて、プロトコルの異なった部分集合を供給できるのが機能することを意味します。
If at an establishment of session connection the zero-type VM is used, it specifies group VM (see section 9). The zero-value of realization VM is not allowed.
無タイプVMがセッション接続の設立のときに使用されているなら、それはグループVMを指定します(セクション9を見てください)。 実現VMの無値は許容されていません。
The procedure of the establishment of session connection may contain from 2-way up to 8-way handshakes.
セッション接続の設立の手順は8ウェイに上がっている2ウェイから握手を含むかもしれません。
5.3.1 SESSION_OPEN
5.3.1 セッション_戸外
The instruction "To open a session" (SESSION_OPEN) is used for the initiation of session connection and for the specification of connection parameters during handshake. It has the following values of fields:
「開会する」指示(SESSION_オープン)はセッション接続の開始と握手の間の接続パラメタの仕様に使用されます。 それには、分野の以下の値があります:
Bogdanov Experimental [Page 29] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[29ページ]RFC3018
OPCODE = 12
PCK = %b00/11. In the first instruction (initial) the value of
this field is set to %b00. In all subsequent -
%b11.
CHN = 0
ASK = 1
EXT = 0/1
OPR_LENGTH = 6 - 10 ; Depends on length GJID and LTID.
SESSION_ID - In the first instruction this field is absent. In all
subsequent, it contains the identifier of sessions,
assigned by the instruction receiver.
REQ_ID - This field contains the session connection identifier,
assigned by the instruction sender.
Operands:
2 octets: The VM type required from the addressee.
2 octets: The VM version required from the addressee.
4 octets: The profile of connection required from the
instruction addressee.
2 octets: The VM type of the sender.
2 octets: The VM version of the sender.
4 octets: The profile of connection given by the instruction
sender.
2 octets: The number of 256 octet blocks in the buffer,
allocated for session ("window"), on the side of the
sender of this instruction (see section 7.4). The
zero-value specifies absence of the buffer.
4-16 octets: GJID.
4/8 octets: LTID of the sender task, assigned on the node -
sender of the instruction. It is used in the
instruction TASK_REG (as a part of the field GTID).
12OPCODE=PCKは%b00/11と等しいです。 最初の指示(初期の)では、この分野の値は%b00に設定されます。 すべてでその後、--%b11。 CHN=0は=1EXT=0/1OPR_長さ=の6--10を尋ねます。 長さのGJIDとLTIDによります。 SESSION_ID--最初の指示では、この分野は欠けています。 すべてでは、その後です. 指示受信機REQ_IDによって割り当てられたセッションに関する識別子を含んでいます--この分野は指示送付者によって割り当てられたセッション接続識別子を含んでいます。 オペランド: 2つの八重奏: VMタイプが受け取り人から必要です。 2つの八重奏: VMバージョンが受け取り人から必要です。 4つの八重奏: 接続のプロフィールが指示受け取り人から必要です。 2つの八重奏: 送付者のVMタイプ。 2つの八重奏: 送付者のVMバージョン。 4つの八重奏: 指示送付者によって与えられた接続のプロフィール。 2つの八重奏: 256八重奏の数はこの指示の送付者の側面でセッション(「窓」)に割り当てられたバッファの輪郭を描きます(セクション7.4を見てください)。 無値はバッファの欠如を指定します。 4-16の八重奏: GJID。 4/8の八重奏: タスクであって、ノードで割り当てられた送付者のLTID--指示の送付者。 それは指示TASK_REG(分野GTIDの一部としての)に使用されます。
If the VM type and version, required from the addressee, have the value 0, the receiving node independently chooses the VM type and reports it in the response. The establishment of connection without binding to VM or VM group is not allowed.
受け取り人から必要であるVMタイプとバージョンが値0を持っているなら、受信ノードは、独自にVMタイプを選んで、応答でそれを報告します。 VMかVMグループに付くことのない接続の設立は許容されていません。
Totally, it can be transmitted up to 7 instructions SESSION_OPEN at the establishment of connection. The instruction SESSION_ACCEPT is used for the response of the establishment of connection. For the refusal of connection the instruction, SESSION_REJECT is used.
完全に、接続の設立のときにそれを7指示SESSION_オープンまで伝えることができます。 指示SESSION_ACCEPTは接続の設立の応答に使用されます。 接続の拒否において、指示であり、SESSION_REJECTは使用されています。
It is possible to refuse connection on any step. It is necessary either to confirm connections, or to refuse it on the eighth step.
どんなステップのときにも接続を拒否するのは可能です。 接続を確認するか、または第8ステップのときにそれを拒否するのが必要です。
During the establishment of connection the following parameters may be changed:
接続の設立の間、以下のパラメタを変えるかもしれません:
Bogdanov Experimental [Page 30] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[30ページ]RFC3018
o VM type and VM version; o profiles of connection.
o VMタイプとVMバージョン。 o 接続のプロフィール。
If the repeated request about opening of session connection is received from the definite node, while one connection with received GJID have been already established, the following variants are possible:
明確なノードからセッション接続の始まりに関する繰り返された要求を受け取りますが、以下の異形は可能であって、既に容認されたGJIDとの1つの接続を確立しました:
(1) If the request has arrived from the node JCP, it is necessary:
o To finish the existing task emergency and to deallocate all
dynamic resources belong to it.
o To initiates a task without request of the JCP sanction again.
o To confirm the establishment of connection.
(2) If the request arrived not from the JCP node, it is necessary to
refuse the establishment of new session connection. The existing
task does not need to be changed.
(1) 要求がノードJCPから到着したなら、必要です: o 既存のタスク非常時を終えて、すべてのダイナミックなリソースを「反-割り当て」るために、それに属してください。o Toは再びJCP認可の要求なしでタスクを開始します。o Toは接続の設立を確認します。 (2) 要求がいずれかのJCPノードから到着しなかったなら、新しいセッション接続の設立を拒否するのが必要です。 既存のタスクは変えられる必要はありません。
5.3.2 SESSION_ACCEPT
5.3.2 セッション_は受け入れます。
The instruction "To accept the session" (SESSION_ACCEPT) is used for positive response to the establishment of session connection. It has the following values of fields:
指示「セッションを受け入れる」(SESSION_ACCEPT)はセッション接続の設立への積極的な応答に使用されます。 それには、分野の以下の値があります:
OPCODE = 13
ASK = 1
PCK = %11
EXT = 0/1
CHN = 0
OPR_LENGTH = 0
SESSION_ID - This field contains the session connection identifier
of assigned by the node of the addressee of the
instruction.
REQ_ID - This field contains the session connection identifier,
assigned by the instruction sender.
0/1%11 1 13OPCODE=ASK=PCK=EXT=CHNは0OPR_LENGTH=0SESSION_IDと等しいです--この分野は指示の受け取り人のノードによる割り当てられることのセッション接続識別子を含んでいます。 REQ_ID--この分野は指示送付者によって割り当てられたセッション接続識別子を含んでいます。
5.3.3 SESSION_REJECT
5.3.3 セッション_廃棄物
The instruction "To reject the session" (SESSION_ACCEPT) is used for negative response to the establishment of session connection. It has the following values of fields:
指示「セッションを拒絶する」(SESSION_ACCEPT)は否定応答にセッション接続の設立に使用されます。 それには、分野の以下の値があります:
OPCODE = 14
ASK = 0
PCK = %b11
EXT = 0/1
CHN = 0
OPR_LENGTH = 1
0のOPR_長さ=の14が0/1CHNと等しいように=0PCK=%b11 EXTに頼むOPCODE==1
Bogdanov Experimental [Page 31] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[31ページ]RFC3018
SESSION_ID - This field contains the session connection identifier
of assigned by the node of the addressee of the
instruction.
Operands:
2 octets: The basic error code. The zero-value is not
available.
2 octets: The additional error code.
The optional extension headers:
_MSG - contains the arbitrary error description.
SESSION_ID--この分野は指示の受け取り人のノードによる割り当てられることのセッション接続識別子を含んでいます。 オペランド: 2つの八重奏: 基本的なエラーコード。 無値は利用可能ではありません。 2つの八重奏: 追加エラーコード。 任意の拡張ヘッダー: _MSG--任意のエラー記述を含んでいます。
5.3.4 Connection Profile
5.3.4 接続プロフィール
The profile of connection is defined in 4-octet field of flags. The flags have identifiers S0 - S31. The number in the identifier is defining the serial number of bit. If the flag is set to 1, the function, connected with it, is provided. If the flag is set to 0, the function, connected with it, is not provided (not required). The list of functions, determined at the establishment of session connection, are described further.
接続のプロフィールは旗の4八重奏の分野で定義されます。 旗には、識別子S0があります--S31。 識別子の数はビットの通し番号を定義しています。 1に旗を設定するなら、それに接続された機能を提供します。 旗が0に設定されるなら、それに接続された機能は提供されません(必要ではありません)。 機能のセッション接続の設立のときに決定しているリストはさらに説明されます。
Work with chains:
チェーンで、働いてください:
S0 - Use of fragmented instructions.
S1 - Use of sequences.
S2 - Use of transactions.
S0--断片化している指示の使用。 S1--系列の使用。 S2--取引の使用。
Establishment of connection:
接続の設立:
S3 - Use the exchange of the data without the establishment of
connection.
S4 - Use the exchange of the data with the establishment of
connection.
S3--接続の設立なしでデータの交換を使用してください。 S4--接続の設立によるデータの交換を使用してください。
The instructions format:
指示形式:
S5 - Reserved. Must have set to 0.
S6 - Use of 16-octet address in the exchange instructions.
S7 - Use of the compressed form of header of the instruction
(OPR_LENGTH < > %b111) is allowed
S8 - Use of the extension form of header of the instruction
(OPR_LENGTH = %b111) is allowed
S9 - Use of the extension headers with the data field up to 254
octets of length.
S10 - Use of the extension headers with the data field up to 4 *
10^9 octets of length.
S11-S15 Maximal length of the data field in operands in the 4
octet words. These bits are the common field. Maximal
length in octets is computed under the formula:
S5--予約されています。 0にセットしたに違いありません。 S6--交換指示における16八重奏のアドレスの使用。 S7--S8は指示(OPR_LENGTH<>%b111)のヘッダーの圧縮形の使用に許容されています--S9は指示(OPR_LENGTH=%b111)のヘッダーの拡大フォームの使用に許容されています--データがある拡張ヘッダーの使用は長さの最大254の八重奏をさばきます。 S10--データがある拡張ヘッダーの使用は長さの9つの八重奏を4*10^までさばきます。 4つの八重奏単語によるオペランドのデータ・フィールドのS11-S15の最大限度の長さ。 これらのビットは共同耕地です。 八重奏における最大限度の長さは公式の下で計算されます:
Bogdanov Experimental [Page 32] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[32ページ]RFC3018
<max length> = (<value of this field> + 1) * 4.
If the value is equal %b1111, maximal length of the data
is defined by the instruction format.
S16-S19 These bits are the common field. In the profile required
from the addressee of the instruction, this field
contains the version of the UMSP. It must is set to the
value %b0001. In the profile given sender of the
instruction, this field contains priority of the job. The
more is value of this field, the more priority. The
priority of the job is used:
o In queues on sending to the transport layer for the
instructions of the job.
o For set of sending priority of the transport layer.
o For set of computing priority of the task.
S20 - making the border multiple of 4 octets. If S16 = 1:
(1) OPR_LENGTH = %b111
(2) Each extension header and the field of operands begin with
the border multiple of four octets.
(3) The necessary number of zero octets is added in the end of
each header.
S21 - Use of the procedures name of objects.
S22 - Use of the objects name.
<最大の長さの>は*4と等しいです(この分野>+1の<値)。 値が等しい%b1111であるなら、データの最大限度の長さは命令形式によって定義されます。 S16-S19、これらのビットは共同耕地です。 指示の受け取り人から必要であるプロフィールでは、この分野はUMSPのバージョンを含んでいます。 それは設定しなければなりません。値の%b0001に設定されます。 指示の送付者に与えられたプロフィールでは、この分野は仕事の優先権を含んでいます。 この分野の値、より多くの優先権が、より多いです。 仕事の優先権は使用されています: o 輸送に発信するときの待ち行列では. o Forが設定する. o Forが設定するタスクの優先権を計算するトランスポート層の優先権を送る仕事の指示には、層にしてください。 S20--4つの八重奏の境界倍数を作ります。 S16=1であるなら: (1) 各拡張ヘッダーとオペランドの分野が4つの八重奏の境界倍数で始めるOPR_LENGTH=%b111(2)。 (3) 八重奏がない必要な数はそれぞれのヘッダーの端で加えられます。 S21--物の手順名の使用。 S22--物の名の使用。
The permissible instructions:
許されている指示:
S23 - The response of the execution on VM (instruction RSP) is
provided.
S24 - Use of data reading and comparison instructions.
S25 - Use of data writing instructions.
S26 - Use of control transfer instructions.
S27 - Use of synchronize instruction.
S28 - Use of instructions of work witch objects.
S29 - Use of the immediate access to memory of object. If this
flag is set to 0, the access to object is solved only
through its procedures. If S28=0, this flag must be set to
0.
S30 - Use of instruction MVRUN in zero-session.
S31 - Reserved. Must have set to 0.
S23--VM(指示RSP)における実行の応答を提供します。 S24--データ読書と比較命令の使用。 S25--指示を書くデータの使用。 S26--コントロール飛越し命令の使用。 S27--、使用、指示を同時にさせてください。 S28--仕事の指示の使用は物に魔法をかけさせます。 S29--物に関するメモリへの即座のアクセスの使用。 この旗が0に設定されるなら、反対させるアクセスは単に手順で解決されています。 S28=0であるなら、この旗を0に設定しなければなりません。 S30--無セッションにおける指示MVRUNの使用。 S31--予約されています。 0にセットしたに違いありません。
5.4 Session Closing
5.4 セッション閉鎖
Initiate closing session connection the node must only, which has initiated its establishment. It uses the SESSION_CLOSE instruction for this purpose. The procedure of break of connection is 3-way handshake. The procedure of unconditional emergency end of connection is stipulated. It can be transmitted by any node.
ノードがそうするだけでよい閉会式接続を開始してください。(それは、設立を開始しました)。 それはこのためにSESSION_CLOSE指示を使用します。 接続の中断の手順は3ウェイ握手です。 接続の無条件の非常時の終わりの手順は規定されています。 どんなノードもそれを伝えることができます。
Bogdanov Experimental [Page 33] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[33ページ]RFC3018
Let node A is the initiator of the establishment of a session, and the node B is the second side of connection. The node A must send the instruction SESSION_CLOSE for closing session. The node A may recommence sending of the instructions after sending of this instruction. It means that it has refused closing connection. The instructions of response (see section 6) does not influence on the closing of connection. The node, which has sent SESSION_CLOSE, does not use the timeout and can be waiting for the response beyond all bounds long.
貸されて、ノードAはセッションの設立の創始者です、そして、ノードBは接続の2番目の側面です。 ノードAは閉会式のために指示SESSION_CLOSEを送らなければなりません。 ノードAは、この指示を発信させた後に指示を発信させながら、再開するかもしれません。 それは、終わりの接続を拒否したことを意味します。 応答(セクション6を見る)の指示は接続の閉鎖へのどんな影響もしません。 ノード(SESSION_CLOSEを送った)は、タイムアウトを使用しないで、なかなかすべての領域を超えて応答を待つことができません。
The node B, after reception of the instruction SESSION_CLOSE, sends in the answer the instruction RSP_P. The zero basic return code responds closing session. The non-zero basic return code cancels closing session. After sending of positive response, the node must not use connection during 30-second timeout. If the instruction SESSION_ABEND or any other instruction, except response instruction, has not been received from the node A after the expiration of this time, the node send the instruction SESSION_ABEND and considers the session connection closed.
ノードBは指示SESSION_CLOSEのレセプションの後に答えで指示RSP_Pを送ります。 ゼロ基本的な復帰コードは閉会式を反応させます。 非ゼロの基本的な復帰コードは閉会式を中止します。 積極的な応答を発信させた後に、ノードは30秒のタイムアウトの間、接続を使用してはいけません。 指示であるなら、応答命令以外に、ABENDかいかなる他の指示ではもあるSESSION_は、今回の満了、ノードが指示SESSION_ABENDを送った後にノードAから受け取られて、セッション接続が閉じられると考えません。
The node A sends the instruction SESSION_ABEND after reception of positive response on the instruction SESSION_CLOSE. After that, the connection is considered closed. The node A may refuse closing of connection. For this purpose, any instruction is sent, including NOP. In this case, the procedure of end interrupts, and the session connection is translated in the working state.
ノードAは指示SESSION_CLOSEでの積極的な応答のレセプションの後に指示SESSION_ABENDを送ります。 その後に、接続は閉じられると考えられます。 ノードAは接続の閉鎖を拒否するかもしれません。 このために、NOPを含んでいて、どんな指示も送ります。 この場合、終わりの手順は中断します、そして、セッション接続は勤務状態で翻訳されます。
5.4.1 SESSION_CLOSE
5.4.1 セッション_は閉じます。
The instruction "To close the session" (SESSION_CLOSE) initiates the end of session connection. It has the following values of fields:
指示「セッションを終える」(SESSION_CLOSE)はセッション接続の終わりを開始します。 それには、分野の以下の値があります:
OPCODE = 15
PCK = %b01/11
CHN = 0
ASK = 0
EXT = 0/1
OPR_LENGTH = 0/1
SESSION_ID - Contains the session identifier assigned by the
addressee.
Operands:
2 octets: The basic termination code.
2 octets: The additional termination code.
The optional extension header:
_MSG - contains the arbitrary message.
0 0 15OPCODE=PCK=%b01/11 CHN=ASK=EXTは0/1OPR_LENGTH=0/1SESSION_IDと等しいです--受け取り人によって割り当てられたセッション識別子を含んでいます。 オペランド: 2つの八重奏: 基本的な終了コード。 2つの八重奏: 追加終了コード。 任意の拡張ヘッダー: _MSG--任意のメッセージを含んでいます。
The operands may be absent. It is equivalent to the zero exit code.
オペランドは欠けているかもしれません。 ゼロと同等物がコードを出るということです。
Bogdanov Experimental [Page 34] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[34ページ]RFC3018
5.4.2 SESSION_ABEND
5.4.2 セッション_アベンド
The instruction "Abend of session" SESSION_ABEND is applied to unconditional end of session. The node, which has sent this instruction, finishes the exchange of the data on connection at both sides, not waiting responses from other node. The instruction has the following values of fields:
指示「セッションのアベンド」SESSION_ABENDはセッションの無条件の終わりに付けられます。 ノード(この指示を送った)は両側での接続のデータの交換を終えます、他のノードから応答を待っていなくて。 指示には、分野の以下の値があります:
OPCODE = 16
PCK = %b01/11
CHN = 0
ASK = 0
EXT = 0/1
OPR_LENGTH = 0/1
SESSION_ID - Contains the session identifier assigned by the
addressee.
Operands:
2 octets: The basic termination code.
2 octets: The additional termination code.
The optional extension header:
_MSG - contains the arbitrary message.
0 0 16OPCODE=PCK=%b01/11 CHN=ASK=EXTは0/1OPR_LENGTH=0/1SESSION_IDと等しいです--受け取り人によって割り当てられたセッション識別子を含んでいます。 オペランド: 2つの八重奏: 基本的な終了コード。 2つの八重奏: 追加終了コード。 任意の拡張ヘッダー: _MSG--任意のメッセージを含んでいます。
The operands may be absent. It is equivalent to the zero termination codes.
オペランドは欠けているかもしれません。 それは終了がコード化するゼロに同等です。
5.5 Task Termination
5.5 タスクの終了
The task is finished during the process of the job finishing at the normal end of the user application working. This procedure is described in the following item. The following situations require finishing the task irrespective of the job:
タスクは仕事が、ユーザの正常な終わりでアプリケーションが働き終える過程の間、終わっています。 この手順は以下の項目で説明されます。 以下の状況は、仕事の如何にかかわらずタスクを終えるのを必要とします:
o There are not enough of computing resources for maintenance of the
task on the node;
o The node finishes the work;
o If VM has accepted such decision for the internal reasons.
o ノードにおけるタスクのメンテナンスのためのコンピューティング資源が十分ありません。 o ノードは仕事を終えます。 o VMが内部の理由のためのそのような決定を受け入れたなら。
The references to the resources allocated by the task can be on any node, on which the job is carried out. Therefore, all nodes must be notified of the end of the task.
どんなノードの上にもタスクによって割り当てられたリソースの参照があることができます。仕事がノードで行われます。 したがって、タスクの終わりについてすべてのノードに通知しなければなりません。
Node, finishing the task, must abnormally close all session connections joining the finished task (to send the instruction SESSION_ABEND).
タスクを終えて、ノードは異常に終わっているタスク(指示SESSION_ABENDを送る)に加わるすべてのセッション接続を終えなければなりません。
Bogdanov Experimental [Page 35] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[35ページ]RFC3018
5.5.1 TASK_TERMINATE
5.5.1 タスク_は終わります。
The instruction "To terminate the task" (TASK_TERMINATE) is sent from the node, on which the task is finished, to JCP. The instruction has the following values of fields:
指示「タスクを終える」(TASK_TERMINATE)をノードからJCPに送ります。(タスクはノードで終わっています)。 指示には、分野の以下の値があります:
OPCODE = 17
PCK = %b00
CHN = 0
ASK = 0
EXT = 0/1
OPR_LENGTH = 2/3 ; Depends on the length of CTID.
Operands:
2 octets: The basic termination code.
2 octets: The additional termination code.
4/8 octets: CTID.
The optional extension header:
_MSG - contains the arbitrary message.
b00 CHN=0が0/1のOPR_長さと等しいように=0EXTに頼む17OPCODE=PCK=%は2/3と等しいです。 CTIDの長さに依存します。 オペランド: 2つの八重奏: 基本的な終了コード。 2つの八重奏: 追加終了コード。 4/8の八重奏: CTID。 任意の拡張ヘッダー: _MSG--任意のメッセージを含んでいます。
After sending of the instruction TASK_TERMINATE to JCP, the node sends the instruction of unconditional end of connection ABEND_SESSION on all session connections connected with a task. After that, the task is considered completed.
指示TASK_TERMINATEをJCPに発信させた後に、ノードはタスクに接続されたすべてのセッション接続の接続ABEND_SESSIONの無条件の端の指示を送ります。 その後に、タスクは完成していると考えられます。
If the basic return code in the instruction TASK_TERMINATE is equal to 0, it is not required to notify other nodes about the end of the task. Such situation arises, if the task did not allocate dynamic resources. If the basic return code is unequal to 0, JCP must notify about the task end the other nodes, on which the job is carried out, after reception of the instruction TASK_TERMINATE. JCP responds for the notification of all nodes of the job about the task end.
指示TASK_TERMINATEにおける基本的な復帰コードが0と等しいなら、それは、タスクの終わり頃に他のノードに通知するのに必要ではありません。 タスクがダイナミックなリソースを割り当てなかったなら、そのような状況は起こります。 基本的な復帰コードが0に不平等であるなら、JCPはタスク終わり頃に他のノードに通知しなければなりません、指示TASK_TERMINATEのレセプションの後に。(仕事がノードで行われます)。 JCPはタスク終わり頃に仕事のすべてのノードの通知のために応じます。
5.5.2 TASK_TERMINATE_INFO
5.5.2 タスク_は_インフォメーションを終えます。
The instruction "The information on terminating of the task" (TASK_TERMINATE_INFO) is used for the notification about the task end. It is sent from JCP to other nodes, on which the job is carried out. The instruction has the following values of fields:
指示、「タスクを終わらせることの情報」(TASK_TERMINATE_INFO)はタスク終わり頃に通知に使用されます。 JCPから他のノードにそれを送ります。(仕事がノードで行われます)。 指示には、分野の以下の値があります:
OPCODE = 18
PCK = %b00
CHN = 0
ASK = 0
EXT = 0/1
OPR_LENGTH = 2-5 ; Depends on the length of GTID.
Operands:
2 octets: The basic termination code.
2 octets: The additional termination code.
b00 CHN=0が0/1のOPR_長さと等しいように=0EXTに頼む18OPCODE=PCK=%は2-5と等しいです。 GTIDの長さに依存します。 オペランド: 2つの八重奏: 基本的な終了コード。 2つの八重奏: 追加終了コード。
Bogdanov Experimental [Page 36] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[36ページ]RFC3018
4-16 octets: GTID of the terminated task. JCP forms GTID from
LTID (from the instruction TASK_REG) and address
of transport layer of the task.
The optional extension header:
_MSG - contains the arbitrary message.
4-16の八重奏: 終えられたタスクのGTID。 JCPはタスクのトランスポート層のLTID(指示TASK_REGからの)とアドレスからGTIDを形成します。 任意の拡張ヘッダー: _MSG--任意のメッセージを含んでいます。
The fields of termination codes are taken from the instruction TASK_TERMINATE. The job must delete (to make invalid) all references to resources concerning the node, on which the completed task worked, at reception of the instruction TASK_TERMINATE_INFO.
指示TASK_TERMINATEから終了コードのグラウンドに出ます。 仕事はノードに関してリソースのすべての参照を削除しなければなりません(無効に作る)。(完成したタスクは指示TASKのレセプションで_TERMINATE_INFOをそれを扱いました)。
5.6 Job Completion
5.6 仕事の完成
The job is finished, when the appropriated to it the user application on the node, on which it was initiated, is finished. The end of the job occurs under the initiative of VM. Besides, it can be completed under the JCP initiative at ending the lifetime of the job or at end of the JCP node working.
仕事は終わっています、いつ、それに当てられて、それがどれであったかに関して開始されたノードにおけるユーザアプリケーションが終わっているか。 仕事の終わりはVMのイニシアチブの下で現れます。 そのうえ、仕事の生涯を終わらせることにおいて、または、JCPノードの働きの終わりにおいてJCPイニシアチブで完成できます。
5.6.1 JOB_COMPLETED
5.6.1 _が完了した仕事
The instruction "The task is completed" (JOB_COMPLETED) is sent from the node, which initiated the job, in the JCP side. It has the following values of fields:
ノードから指示「タスクは完成する」(JOB_COMPLETED)を送ります。(それは、JCP側で仕事を開始しました)。 それには、分野の以下の値があります:
OPCODE = 19
PCK = %b00
CHN = 0
ASK = 0
EXT = 0/1
OPR_LENGTH = 2/3 ; Depends on the CTID length.
Operands:
2 octets: The basic completion code.
2 octets: The additional completion code.
4/8 octets: CTID of the completed task of the job. CTID is a
part GJID of the job.
The optional extension header:
_MSG - contains the arbitrary message.
b00 CHN=0が0/1のOPR_長さと等しいように=0EXTに頼む19OPCODE=PCK=%は2/3と等しいです。 CTIDの長さに依存します。 オペランド: 2つの八重奏: 基本的な完了コード。 2つの八重奏: 追加完了コード。 4/8の八重奏: 仕事の完成したタスクのCTID。 CTIDは仕事のパートGJIDです。 任意の拡張ヘッダー: _MSG--任意のメッセージを含んでいます。
After sending of the instruction JOB_COMPLETED to JCP, the node sends on all connected with the session connections of the job the instruction of unconditional end of connection ABEND_SESSION. After that, the job is considered completed.
指示JOB_COMPLETEDをJCPに発信させた後に、ノードは、すべてが接続ABEND_SESSIONの無条件の端の指示に仕事のセッション接続に接したのを転送します。 その後に、仕事は完成していると考えられます。
JCP must notify of the end of the job the nodes, on which the job is carried out, after reception of the instruction JOB_COMPLETED. JCP responds for the notification of all nodes of the job about end of the job.
JCPはノードであって、仕事がどれであるかに関して外まで運ばれた仕事の終わりについて通知しなければなりません、指示JOB_COMPLETEDの後レセプション。 JCPは仕事の終わり頃に仕事のすべてのノードの通知のために応じます。
Bogdanov Experimental [Page 37] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[37ページ]RFC3018
The instruction TASK_TERMINATE_INFO may be transferred under the initiative JCP, if node of the task has abnormal terminated work.
タスクのノードに異常な終えられた仕事があるなら、イニシアチブJCPで指示TASK_TERMINATE_INFOを移すかもしれません。
5.6.2 JOB_COMPLETED_INFO
5.6.2 仕事の_は_インフォメーションを完成しました。
The instruction "The information on completion of the job" (JOB_COMPLETED_INFO) is used for the notification about end of the job. It is sent from JCP to other nodes, on which the job is carried out. The instruction has the following values of fields:
指示、「仕事の完成の情報」(JOB_COMPLETED_INFO)は仕事の終わり頃に通知に使用されます。 JCPから他のノードにそれを送ります。(仕事がノードで行われます)。 指示には、分野の以下の値があります:
OPCODE = 20
PCK = %b00
CHN = 0
ASK = 0
EXT = 0/1 ;
OPR_LENGTH = 2-5 ; Depends on the GJID length and presence of
fields completion code.
Operands:
2 octets: The basic completion code.
2 octets: The additional completion code.
4-16 octets: GJID of the completed job.
The optional extension header:
_MSG - contains the arbitrary message.
20OPCODE=PCK=%b00 CHN=0は=0EXT=0/1を尋ねます。 OPR_長さは2-5と等しいです。 分野完了コードのGJIDの長さと存在に依存します。 オペランド: 2つの八重奏: 基本的な完了コード。 2つの八重奏: 追加完了コード。 4-16の八重奏: 完了した作業のGJID。 任意の拡張ヘッダー: _MSG--任意のメッセージを含んでいます。
The fields of completion codes are optional.
完了コードの分野は任意です。
The fields of completion codes are taken from the instruction JOB_COMPLETED. At reception of the instruction, JOB_COMPLETED_INFO the node must make the following:
指示JOB_COMPLETEDから完了コードのグラウンドに出ます。 指示のレセプション、JOB_COMPLETED_INFO、ノードは以下を作らなければなりません:
(1) To remove all session connections, connected to the task. At
that, it is not necessary to send network primitives.
(2) To abnormally finish the task of the job and to deallocate all
dynamic resources of the task.
タスクに接続されたすべてのセッション接続を外す(1)。 おまけに、ネットワーク基関数を送るのは必要ではありません。 (2) 異常に仕事に関するタスクとdeallocateへのタスクのすべてのダイナミックなリソースを終えるために。
The instruction JOB_COMPLETED_INFO is used for the end of the job under the JCP initiative at the end of lifetime or at end of the JCP node working. In these cases, the node initiated the job is the first addressee of the instruction.
指示JOB_COMPLETED_INFOは仕事の終わりに生涯の終わりかJCPノードの働きの終わりのJCPイニシアチブで使用されます。 これらのケース、開始されたノードでは、仕事は指示の最初の受け取り人です。
JCP considers the job completed after sending of all instructions JOB_COMPLETED_INFO.
JCPはすべての指示JOB_COMPLETED_INFOを発信させた後に完了した仕事を考えます。
5.7 Activity Control of Nodes
5.7 ノードのアクティビティ管理
UMSP unites nodes, which have any arrangement in the network and which are not having uniform controls. Each of nodes can be disconnected or reloaded at any moment of time. However, other nodes
UMSPはノードを結合させます。(ノードは、ネットワークでどんなアレンジメントも持っていて、一定のコントロールは持っていません)。 時間のどんな瞬間にもそれぞれのノードを外すか、または再び積むことができます。 しかしながら、他のノード
Bogdanov Experimental [Page 38] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[38ページ]RFC3018
can be not notified about it. The fact of breaking or repeated establishment of transport connection cannot be the indicator of disconnect or restart of the node. The control of transport connections is not the part of the UMSP protocol and the presence of transport connection is not obligatory.
それに関して通知できません。 輸送接続の壊しているか繰り返された設立の事実は、分離のインディケータかノードの再開であるはずがありません。 輸送の接続のコントロールはUMSPプロトコルの部分ではありません、そして、輸送接続の存在は義務的ではありません。
Besides the separate task on the node can be finished emergency. Procedure described in section 5.5.1 in this case must be executed. If this procedure cannot be executed, must is abnormally finished work of the node.
そのうえ、ノードに関する別々のタスクは終わっている非常時であるかもしれません。 この場合セクション5.5.1で説明されている手順を実行しなければなりません。 この手順を実行できないなら、必須はノードの異常に終わっている仕事です。
The JCP executes the functions of the control of nodes activity. The instruction of request of the status TASK_REQ is sent periodically between tasks on nodes and JCP for this purpose.
JCPはノード活動のコントロールの機能を実行します。 ノードとJCPで定期的にこのために状態TASK_REQの要求の指示をタスクの間に送ります。
The following actions JCP are possible at detection of deactivating of the node:
以下の動作JCPはノードを非活性化する検出で可能です:
(1) If the task initiated the job was finished, it is considered,
that the job is completed. JCP sends the instruction
JOB_COMPLETED_INFO to all other nodes, on which the job was
executed.
(2) JCP sends the instruction TASK_TERMINATE_INFO to all other nodes
of the job, if the task, which has not initiated the job, is
finished.
タスクが仕事を開始したなら、(1)は終えられて、それは考えられて、それは仕事です。完成されます。 JCPは指示JOB_COMPLETED_INFOを他のすべてのノードに送ります。仕事はノードで実行されました。 (2) JCPは指示TASK_TERMINATE_INFOを仕事の他のすべてのノードに送ります、タスク(仕事を開始していない)が終わるなら。
The deactivating of the JCP node imposes the restriction on GJID appropriated by it after reloading. The following variants are probable:
JCPノードの非活性化は再び荷を積んだ後にそれによって当てられたGJIDに制限を課します。 以下の異形はありえそうです:
(1) The disconnection of the JCP node passed normally. It
transferred to all nodes, which it has controlled, instruction
JOB_COMPLETED_INFO. In this case, it can appropriate anyone
GJID after reloading.
(2) There is the emergency disconnect of the JCP node. It has not
informed all nodes about the deactivating. In this case, it
must guarantee after reloading, that new GJID will not concur
witch the GJID, existing up to the reload, during two maximal
intervals of inactivity time (which sets this JCP).
(1) 通常、JCPノードの断線は終わりました。 _それはすべてのノードに移されて、指示JOB_COMPLETEDはINFOです。(それはノードを制御しました)。 この場合、それは再び荷を積んだ後に、GJIDのだれでも当てることができます。 (2) JCPノードの非常時の分離があります。 それは非活性化に関するすべてのノードを知らせるというわけではありませんでした。 この場合、再び荷を積んでいて、そんなに新しいGJIDが同意しなかった後にGJIDに魔法をかけさせるように保証しなければなりません、再ロードまで存在していて、不活発時間(このJCPを設定する)の2回の最大限度の間隔の間。
The reload of nodes, which are not being JCP, does not impose restrictions on LTID established on these nodes.
ノードの再ロードはこれらのノードの上に設立されたLTIDに制限を課しません。(ノードは存在JCPではありません)。
5.7.1 _INACTION_TIME
5.7.1_無活動_時間
The extension header "The time of inaction" (_INACTION_TIME) allows setting the inaction time of the node (non JCP). It has the following values of fields:
「無活動の時間」の間の拡張ヘッダー(_INACTION_タイム誌)はノード(非JCP)の無活動時間を設定させます。 それには、分野の以下の値があります:
Bogdanov Experimental [Page 39] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[39ページ]RFC3018
HEAD_CODE = 2
HEAD_LENGTH = 1;
HOB = 1
DATA contains:
2 octets: The inaction period. The number of 0,5 second
intervals, through which the activity of the node - sender of
the instruction from the side JCP - will be checked.
ヘッド_は=2ヘッド_長さ=の1をコード化します。 1HOB=DATAが以下を含んでいます。 2つの八重奏: 無活動の期間。 0、5回の2番目の間隔の数。(ノードの活動(サイドJCPからの指示の送付者)は間隔の間、チェックされるでしょう)。
The inaction period must be more than three intervals of the maximal time of delivery at the transport layer. The waiting period in queue to the transport layer does not influence on timeout.
無活動の期間はトランスポート層の最大限度の納期の3回以上の間隔であるに違いありません。 トランスポート層への待ち行列における待ちの期間はタイムアウトへのどんな影響もしません。
The header _INACTION_TIME may be attached to the following instructions:
ヘッダー_INACTION_タイム誌は以下の指示に付けられるかもしれません:
(1) To the instruction TASK_REG. In this case must be satisfied
condition - on node there must not be other active tasks, which
are controlled the JCP of addressee. The zero-value specifies
that the activity checking is unused. The absence of the header
specifies that the inaction period must be set on the JCP.
(2) To the instruction TASK_REJECT, if the time from the instruction
TASK_REG does not fit for JCP.
(3) To the instruction TASK_CONFIRM, if instruction TASK_REG had no
this header.
指示TASK_REGへの(1)。 満足している状態になってください--ノードの上に、他のアクティブ・タスクがあるはずがありません、制御もの。この場合必須である、受け取り人のJCP。 無値は、活動の照合が未使用であると指定します。 ヘッダーの不在は、JCPで無活動の期間を決めなければならないと指定します。 (2) _指示TASK_REJECTには、REGは指示TASKからの時間であるならJCPのために合いません。 (3) _指示TASK_CONFIRMには、REGが指示TASKであるならいいえ、このヘッダーがいました。
If JCP receives the instruction TASK_REG with the attached heading _INACTION_TIME, it must check up presence of active tasks with sender node (as it can mean, that the node was reloaded). If such tasks exist, for each of them it is necessary to execute procedure of end of the task described in section 5.6.2. The instruction TASK_CONFIRM must be sent only after that.
JCPが付属_見出し_INACTIONタイム誌と共に指示TASK_REGを受けるなら、送付者ノードでアクティブ・タスクの存在について調査しなければならない、(意味できて、それがノードである、再び積まれた、) そのようなタスクが存在しているなら、それぞれのそれらに、セクション5.6.2で説明されたタスクの終わりの手順を実行するのが必要です。 その後にだけ指示TASK_CONFIRMを送らなければなりません。
5.7.2 STATE_REQ
5.7.2 状態_REQ
The instruction "State Request" (STATE_REQ) is sent from JCP to the definite task of other node. The instruction has the following values of fields:
指示「州の要求」(州_REQ)をJCPから明確な他のノードのタスクに送ります。 指示には、分野の以下の値があります:
OPCODE = 21
PCK = %b00
CHN = 0
ASK = 0
EXT = 0
OPR_LENGTH = 1/2 ; Depends on the LTID length.
Operand:
4/8 octets: LTID, established on the node of the instruction
addressee.
b00 CHN=0が0のOPR_長さと等しいように=0EXTに頼む21OPCODE=PCK=%は1/2と等しいです。 LTIDの長さに依存します。 オペランド: 4/8の八重奏: 指示受け取り人のノードの上に設立されたLTID。
Bogdanov Experimental [Page 40] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[40ページ]RFC3018
The instruction STATE_REQ will be sent in the defined task but it has concern with node. It is sent, if between the node and JCP was not sending of the instruction during inactive time. The task activated after sending of last instruction STATE_REQ does not influence the control of activity.
定義されたタスクで指示州_REQを送るでしょうが、それには、関心がノードと共にあります。 ノードとJCPの間には、不活発な時間指示を発信させるのがなかったなら、それを送ります。 最後の指示州_REQを発信させた後に活性化したタスクは活動のコントロールに影響を及ぼしません。
The instruction TASK_STATE is sent in reply to STATE_REQ. At expectation of the response, the timeout equal to one inaction period is used. After the expiration of the timeout the node is considered switched - off.
州_REQに対して指示TASK_州を送ります。 応答への期待では、ある無活動の期間と等しいタイムアウトは使用されています。 タイムアウトの満了の後に、ノードは切り換えられると考えられます--オフです。
If the node not receives of any instructions from JCP during two intervals of inaction time, it is considered, that JCP has finished the work. The actions of the node in this case are described in section 5.6.2 at receiving the instruction JOB_COMPLETED_INFO. The check of this condition is optional for the node.
ノードが無活動時間の2回の間隔の間、JCPから少しの指示も受信しないなら、考えられる、そのJCPは仕事を終えました。 この場合、ノードの機能はセクション5.6.2で指示JOB_COMPLETED_INFOを受けるのに説明されます。 ノードに、この状態のチェックは任意です。
If at JCP there are no active tasks connected with the defined node, the control of activity of this node will not be carried out.
定義されたノードに接続されたアクティブ・タスクが全くJCPにないと、このノードの活動のコントロールが行われないでしょう。
5.7.3 TASK_STATE
5.7.3 タスク_状態
The instruction "Task State" (TASK_STATE) is sent from the definite task to JCP. It serves for the response of the instruction STATE_REQ. The instruction has the following values of fields:
指示「タスク状態」(TASK_州)を明確なタスクからJCPに送ります。 それは指示州_REQの応答を満たします。 指示には、分野の以下の値があります:
OPCODE = 22
PCK = %b00
CHN = 0
ASK = 0
EXT = 0
OPR_LENGTH = 1/2/3 ; Depends on the CTID length.
Operands:
1 octet: The state code of task. The following values are
defined for this field:
%x01 - The task is active and has active session
connections.
%x02 - The task is active and have no session connections.
%x03 - The task is active, have no session connections and
have no resources, allocated on the node.
%x04 - The task is completed.
1/3 octets: Reserved. If OPR_LENGTH = 1, then this field has
length 1 octet, else 3 octets. JCP must not check
the value of this field. It is established in zero
value by sending.
2/4/8 octets: CTID connected with LTID from the instruction
STATE_REQ.
0b00 CHN=0が尋ねる22OPCODE=PCK=%=EXTは= 1/2/3に0のOPR_長さと等しいです。 CTIDの長さに依存します。 オペランド: 1つの八重奏: タスクの州のコード。 以下の値はこの分野と定義されます: %x01--タスクには、アクティブであり、活発なセッション接続があります。 %x02--タスクはアクティブであり、セッション接続が全くしないでください。 %x03--タスクはアクティブであり、セッション接続が全くしないでください、そして、ノードで割り当てられなかったリソースを全く持ってください。 %x04--タスクは完成します。 1/3の八重奏: 予約にされる。 OPR_LENGTH=1であるなら、この分野には、長さ1の八重奏、3つのほかの八重奏があります。 JCPはこの分野の値をチェックしてはいけません。 それは、発信することによって、どんな値にも設立されません。 2/4/8の八重奏: CTIDは指示州_REQからLTIDに接続しました。
Bogdanov Experimental [Page 41] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[41ページ]RFC3018
If OPR_LENGTH = 1 that length of the reserved field is equal to one octet and length CTID makes two octets. In all other cases, length of the reserved field is equal 3 octets and length CTID - not less than 4 octets.
OPR_LENGTH=1であるなら、予約された分野のその長さは1つの八重奏と等しいです、そして、長さのCTIDは2つの八重奏をします。 他のすべての場合では、予約された分野の長さは、等しい3つの八重奏と長さのCTIDです--少なくとも4つの八重奏。
5.7.4 NODE_RELOAD
5.7.4 ノード_再ロード
The instruction "The node was reloaded" (NODE_RELOAD) is sent to JCP as the negative response to STATE_REQ instruction. NODE_RELOAD has the following values of fields:
州_REQ指示への否定応答として指示「ノードは再び積まれた」(NODE_RELOAD)をJCPに送ります。 NODE_RELOADには、分野の以下の値があります:
OPCODE = 23
PCK = %b00
CHN = 0
ASK = 0
EXT = 0
OPR_LENGTH = 1/2 ; Depends on the LTID length.
Operands:
4/8 octets: LTID. The value is taken from the instruction
STATE_REQ.
b00 CHN=0が0のOPR_長さと等しいように=0EXTに頼む23OPCODE=PCK=%は1/2と等しいです。 LTIDの長さに依存します。 オペランド: 4/8の八重奏: LTID。 指示州_REQから値を取ります。
The instruction RELOAD_NODE indicates, that the task with given LTID for given JCP on the node is absent. At reception of this instruction, JCP must make the following:
RELOAD_NODEが示す指示、ノードの上の与えられたJCPのための与えられたLTIDがあるタスクは欠けています。 この指示のレセプションでは、JCPは以下を作らなければなりません:
(1) To send the instruction STATE_REQ to all tasks of the node,
which were initiated before a sending of the penultimate
instruction STATE_REQ.
(2) To wait for ending of one inaction interval after sending of the
last instruction STATE_REQ (on which the negative response is
received).
(3) To send the instructions STATE_REQ to all tasks of the node,
which were initiated between last and penultimate instructions
STATE_REQ (not including instructions from item 1).
終わりから二番目の指示州_REQの送付の前に開始されたノードに関するすべてのタスクに指示州_REQを送る(1)。 (2) 最後の指示州_REQ(否定応答はそこで受け取られている)を発信させた後に1回の無活動間隔の終わりを待つために。 (3) 最後の、そして、終わりから二番目のの指示州_REQ(項目1からの指示を含んでいない)の間で開始されたノードに関するすべてのタスクに_指示州REQを送るために。
For all instructions STATE_REQ the positive response (TASK_STATE) or negative response (RELOAD_NODE) must be transmitted.
すべての指示州_REQに関しては、積極的な応答(TASK_州)か否定応答(RELOAD_NODE)を伝えなければなりません。
5.8 Work without session connection
5.8 セッション接続のない仕事
The protocol provides the data exchange between nodes without an establishment of session connection. In this case, initialization of the job and tasks is not made and JCP is not used.
プロトコルはセッション接続の設立なしでノードの間のデータ交換を供給します。 この場合、仕事とタスクの初期化をしません、そして、JCPは使用されていません。
The format of the instructions, transmitted without the establishment of connection, is completely correspond to the instructions transmitted by session connections. The difference is that the field SESSION_ID has zero value or PCK = %b00.
接続の設立なしで伝えられた指示の形式はセッション接続によって伝えられた指示に完全に対応することです。 違いは分野SESSION_IDには値でないPCKがない=%b00があるということです。
Bogdanov Experimental [Page 42] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[42ページ]RFC3018
The node, supporting work without the establishment of session connection, must have VM, which executes by default the instructions transmitted without the establishment of connection. In fact, these instructions are executed within the framework of a so-called zero- session (or zero-task) of this VM. The memory address space of this VM is accessible without a connection establishment.
セッション接続の設立なしで仕事を支持して、ノードにはVMがなければなりません。(VMはデフォルトで接続の設立なしで伝えられた指示を実行します)。 事実上、これらの指示はこのVMのいわゆる無セッション(または、無タスク)の枠組みの中で実行されます。 このVMのメモリアドレススペースはコネクション確立なしでアクセスしやすいです。
The instruction SESSION_INIT with SESSION_ID = 0 and REQ_ID = 0 allows to specify parameters of its zero-session and to request the zero-session parameters of the addressee node. If the node, which has received such instruction, provides the requiring profile, it sends the instruction SESSION_ACCEPT. If the profile is not provided, the answerback instruction SESSION_INIT will send, in which the field SESSION_ID and REQ_ID also have the value 0. Actually, such instructions of session initialization do not establish connection, but have the information meaning. The exchange of the data by zero-session can occur irrespective of its.
SESSION_IDがある指示SESSION_INITはID=0から無セッションのパラメタを指定して、受け取り人ノードの無セッションパラメタを要求する0とREQ_と等しいです。 ノード(そのような指示を受けた)が必要さプロフィールを備えるなら、それは指示SESSION_ACCEPTを送ります。 プロフィールが提供されないと、アンサーバック指示SESSION_INIT(また、分野SESSION_IDとREQ_IDは値0を持っている)は発信するでしょう。 実際に、セッション初期化のそのような指示は接続を確立しませんが、情報意味を持ってください。 の如何にかかわらず、無セッションによるデータの交換が起こることができる、それ
There are the following restrictions at working without connection:
接続なしで働いているのに以下の制限があります:
o The chain must be sent, only if it is completely located in one
segment of the transport layer.
o It is impossible to request an allocation of memory and to create
objects (except instruction MVRUN). This objects is not adhered
to the definite job and is not automatically release the resources
at the end of the job, which has created them.
o Parameters of functions and the returned values must not contain
the pointers, because the node can be reloaded at any moment. It
will result that the pointers will become invalid or will address
other objects.
o チェーンを送らなければなりません、それがトランスポート層の1つのセグメントで完全に位置している場合にだけ。o Itはメモリの配分を要求して、物(指示MVRUNを除いた)を作成するのは不可能です。 この目的は、明確な仕事を固守されていなくて、仕事の終わりに自動的にリソースを発表しないことです。機能のo Parametersと戻り値はポインタを含んではいけません、いつ何時ノードを再び積むことができるので。仕事はそれらを作成しました。 ポインタが無効になるか、または他の物を記述するのが結果として生じるでしょう。
The protocol cannot check those conditions. Their realization lays on VM wholly.
プロトコルはそれらの状態をチェックできません。 彼らの実現は完全にVMに横たえられます。
The work without establishment of session connection may be used in the following systems:
セッション接続の設立のない仕事は以下のシステムで使用されるかもしれません:
o In simple devices, which do not have the operational system;
o On servers which are executed a plenty of requests (for work
without connection of resources is used less);
o In systems requiring the fast response to rare requests (if
keeping of connection is inexpedient).
o 簡単な装置で(簡単な装置には基幹系システムがありません)。 o 要求(リソースの接続のない仕事がそれほど使用されないので)の実行されたa多数であるサーバに関して。 o まれな要求(接続のキープが不便であるなら)への速い応答を必要とするシステムで。
Bogdanov Experimental [Page 43] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[43ページ]RFC3018
6 Instructions of Exchange between VM
VMの間の交換の6つの指示
The instructions intended for an exchange between VM uses values OPCODE in range 128 - 223. Depending on length of the operands field, several formats of the instruction may be defined for one OPCODE. The complete instruction format is defined by aggregate of the values of fields OPCODE and OPR_LENGTH.
VM用途の間の交換のために意図する指示は範囲128--223でOPCODEを評価します。 オペランド分野の長さによって、指示のいくつかの書式が1OPCODEのために定義されるかもしれません。 完全な命令形式は分野のOPCODEとOPR_LENGTHの値の集合によって定義されます。
The instruction has the field REQ_ID, if in the instruction header flag ASK = 1. REQ_ID is used for the response identification. The value of this field is specifies by VM. The response is formed by VM, too. The protocol does not check the response and does not analyze the value of the field REQ_ID for the instructions of exchange between VM. One of the instructions RSP, DATA, RETURN, ADDRESS, OBJECT or PROC_NUM is used for sending of the response. The instructions of response have ASK = 1 and the value taken from the confirmed instruction is record in REQ_ID. The instructions of response do not require the response.
指示ヘッダー旗のASK=1で指示には、分野REQ_IDがあります。 REQ_IDは応答識別に使用されます。 この分野の値はそうです。VMで、指定します。 応答はVMによっても形成されます。 プロトコルは、応答をチェックしないで、またVMの間の交換の指示のために分野REQ_IDの値を分析しません。 指示のRSP、DATA、RETURN、ADDRESS、OBJECTまたはPROC_NUMの1つは、応答を発信させるのに使用されます。 応答の指示には、ASK=1があります、そして、確認された指示から取られた値はREQ_IDで記録的です。 応答の指示は応答を必要としません。
The instructions of exchange between VM may be sent through UDP at observance of the following conditions:
UDPを通して以下の条件の遵守でVMの間の交換の指示を送るかもしれません:
o ASK = 0; o The instruction is located in one segment UDP;
o =0を尋ねてください。 o 指示は1つのセグメントのUDPに位置しています。
The timeouts and the repeated sending are not used at UMSP layer for instructions of exchange between VM. It is explained to, that the time of sending instructions with low priority may be very large because of the output queues. Therefore, the VM must make a decision on timeout, as only VM has the complete information on type of the transmitted data. Besides, the transport layer protocol must use the timeouts.
タイムアウトと繰り返された発信はVMの間の交換の指示にUMSP層で使用されません。 それに説明されて、それは出力キューのために発信では、低い優先度がある指示が非常に大きいかもしれない時です。 したがって、VMはタイムアウトで決定しなければなりません、VMだけに伝えられたデータのタイプの完全な情報があるとき。 そのうえ、トランスポート層プロトコルはタイムアウトを使用しなければなりません。
A few VM may be connected to the protocol on the node. VM may simultaneously execute several jobs. Each job may work in its address space. The protocol determines VM and job, which the received instruction must transfer to, on field SESSION_ID value.
いくつかのVMがノードの上のプロトコルに接続されるかもしれません。 VMは同時に、いくつかの仕事を実行するかもしれません。 各仕事はアドレス空間で働くかもしれません。 プロトコルはVMと仕事を決定します。(容認された指示は分野SESSION_ID価値でそれに移さなければなりません)。
The local memory address is located in the instruction in field of length 2/4/8 octets. If memory address length in the instruction is not equal to memory address length defined for the node, the following variants are possible:
地方のメモリアドレスは長さの2/4/8の八重奏の分野に指示で位置しています。 指示におけるメモリアドレスの長さがノードのために定義されたメモリアドレスの長さと等しくないなら、以下の異形は可能です:
o If memory address length is set in 24 bits for the node, the
address is writes in the end of 4 - octets field. The 0 value
sets in an initial (zero) octet.
o メモリアドレスの長さがそうならノードのために24ビット始まってください、そして、アドレスはそうです。分野は結局、4--八重奏を書きます。 0値は初期(ゼロ)の八重奏でセットします。
Bogdanov Experimental [Page 44] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[44ページ]RFC3018
o If the instruction format assumes the memory address length not
less than 4 octets, 2-octet address is located in the last octets.
The first 2 octets must set to zero.
o If instruction is the member of a chain and it has the less length
of the memory address, than it is defined for the node - it is
considered, that the base-displacement addressing is used. If the
value of the memory base is not assigned for the chain -
instruction is erroneous.
o If the instruction is not the member of a chain and has the length
of memory address less, than it is defined for the node, it is
considered, that the abbreviated address is used. The complete
address length must be received by padding in front of it the
necessary number of zero-value octets.
o In all other cases, the instruction is erroneous.
o 命令形式が、メモリアドレスの長さが少なくとも4つの八重奏であると仮定するなら、2八重奏のアドレスは最後の八重奏で位置しています。 最初の2つの八重奏がゼロにセットしなければなりません。それには、メモリアドレスの、より少ない長さがあります、それがノードのために定義されるより--o If指示はチェーンのメンバーです、そして、それは考えられて、それは使用される基底変位アドレス指定です。 --メモリベースの値がチェーンのために割り当てられないなら指示が誤る、o If、指示は、aチェーンのメンバーでなく、またそれほどメモリアドレスの長さを持っていません、それがノードのために定義されるよりそれは考えられて、それは使用される短縮アドレスです。 それの正面ですべてのもう一方がケースに入れる無価値の八重奏o Inの必要な数を水増しすることによって、完全なアドレスの長さを受け取らなければならなくて、指示は誤っています。
Complete 128-bit memory address writes in operands in the 16-octets field. The reason of using of the complete address is that the additional information, using by the memory control subsystem in the node, may contain in its field FREE (see section 2.1). If the FREE of the complete address is set to zero, it is recommended to use local address in operands.
完全な128ビットのメモリアドレスは16八重奏の分野のオペランドで書きます。 完全なアドレスの使用の理由は追加情報、ノードのメモリコントロールサブシステムによる使用が分野に無料で含むかもしれないという(セクション2.1を見てください)ことです。 完全なアドレスからの無料がゼロに設定されるなら、オペランドにローカルアドレスを使用するのはお勧めです。
Operands field has a length, which is an integral number of 32 bits. The alignment is making by padding, if necessary, of the zero-value octets at the end of the field.
オペランド分野には、長さがあります。(それは、32ビットの整数です)。 必要なら、無価値の八重奏が分野の端でそっと歩くことによって、整列は作成です。
Header fields of the instructions not defined in the formats description are used according to the description from section 3.
記述によると、形式記述で定義されなかった指示のヘッダーフィールドはセクション3から使用されます。
The instruction of the transfer control JUMP, CALL, CALL_BNUM and CALL_BNAME may contain the information about VM of the sender. If VM type and VM version of the sender are contains in the instruction, the call parameters are formed in a format VM of the sender. Else, the call parameters have format defined by VM of the addressee. The code is always connected with of specific VM.
転送コントロールのJUMP、CALL、CALL_BNUM、およびCALL_BNAMEの指示は送付者のVMの情報を含むかもしれません。 VMがタイプするか、そして、送付者のVMバージョンはそうです。指示、パラメタがあるという要求では、送付者の形式VMで形成されて、含んでいます。 ほかに、呼び出しパラメタには、受け取り人のVMによって定義された書式があります。 いつも特定のVMについてコードに関連づけられます。
All instructions of the protocol work with binary data and do not provide operations of formats transformation.
プロトコルの指示が2進のデータで扱って、操作を提供しないすべてが変化をフォーマットします。
6.1 Data Reading/Writing Instructions
6.1 データ読書/書くことの指示
6.1.1 REQ_DATA
6.1.1 REQ_データ
The instruction "To request a data" (REQ_DATA) is used for the data request from the remote node. Two instructions REQ_DATA with length of the length field 2 and 4 octets are defined. These instructions have the following values of fields:
指示「データを要求する」(REQ_DATA)は遠隔ノードからのデータ要求に使用されます。 長さの分野2と4八重奏の長さがある2指示REQ_DATAは定義されます。 これらの指示には、分野の以下の値があります:
Bogdanov Experimental [Page 45] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[45ページ]RFC3018
OPCODE = 130/131 ; For length of the length field of 2/4
octets.
OPR_LENGTH = 1/2/3/5 ; Depends on address length.
Operands:
2/4 octets: The length field. The number of the required data in
octets.
2/4/8/16 octets: The memory address of the required data.
OPCODEは130/131と等しいです。 2/4の八重奏の長さの分野の長さのために。 OPR_長さ=1/2/3/5。 アドレスの長さに依存します。 オペランド: 2/4の八重奏: 長さの分野。 八重奏における、必要なデータの数。 2/4/8/16の八重奏: 必要なデータのメモリアドレス。
The instruction DATA, containing required data, is sent in reply to it. If the data cannot be sent, the instruction RSP with the non- zero basic return code, comes back.
必要なデータを含んでいて、それに対して指示DATAを送ります。 データを送ることができないで、非ゼロが基本的の指示RSPが復帰コードである、戻ります。
6.1.2 DATA
6.1.2 データ
The instruction "The data" (DATA) is sent in reply to the instruction REQ_DATA and OBJ_REQ_DATA. The instruction has the following values of fields:
指示REQ_DATAとOBJ_REQ_DATAに対して指示「データ」(DATA)を送ります。 指示には、分野の以下の値があります:
OPCODE = 132
OPR_LENGTH = 0 - 65535 ; Depends on the immediate data length of
the operand.
Operands:
0 - 262140 octets: Immediate data. If OPR_LENGTH = 0, this
field are absent.
Extension headers:
_DATA - Contains immediate data. If OPR_LENGTH <> 0, this
header are absent.
OPCODE=132OPR_長さ=の0--65535。 オペランドの即値データの長さに依存します。 オペランド: 0--262140の八重奏: 即値データ。 0、このOPR_LENGTH=分野が欠けるなら。 拡張ヘッダー: _DATA--即値データを含んでいます。 OPR_LENGTH<>0、このヘッダーが欠けるなら。
The extension header is used, if the data are more then an maximum operands field size. The data must not be sent simultaneously in operands and in the extension header. To make the length of data multiple of 4 octets, 1 - 3 zero-value octets are padded in the end of a field.
拡張ヘッダーが使用されている、データが、より多いなら、最大のオペランドはサイズをさばきます。 同時に、オペランドと拡張ヘッダーでデータを送ってはいけません。 4つの八重奏のデータ倍数の長さを作るために、1--3つの無価値の八重奏が畑の端で水増しされます。
6.1.3 WRITE
6.1.3 書いてください。
The instruction "To write the data" (WRITE) is used for data writing on the remote node. The instruction has the following values of fields:
指示「データを書く」(WRITE)は遠隔ノードを書き続けるデータに使用されます。 指示には、分野の以下の値があります:
OPCODE = 133/134/135/136 ; For memory address length of 2/4/8/16
octets.
OPR_LENGTH = 1 - 65535 ; Depends on length of the immediate
data.
Operands:
2/4/8/16 octets: The memory address for writing the data.
0 - 262136 octets: Immediate data for write.
OPCODEは133/134/135/136と等しいです。 2/4/8/16の八重奏のメモリアドレスの長さのために。 OPR_長さ=1--65535。 即値データの長さに依存します。 オペランド: 2/4/8/16の八重奏: データを書くためのメモリアドレス。 0--262136の八重奏: 即値データ、書いてください。
Bogdanov Experimental [Page 46] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[46ページ]RFC3018
Extension headers:
_DATA - Contains immediate data. This header is present only,
if the data does not contain in operands.
拡張ヘッダー: _DATA--即値データを含んでいます。 データが中に単にオペランドを含んでいないなら、このヘッダーは出席しています。
At address length of 2 octets the data length must be 2 octets. In all other cases, address length must be not less than 4 octets and data length must be multiple of 4 octets. The data must not be sent simultaneously in operands and in the extension header.
2つの八重奏のアドレスの長さでは、データの長さは2つの八重奏であるに違いありません。 他のすべての場合では、4の倍数が八重奏であったに違いないなら、アドレスの長さは、少なくとも4つの八重奏とデータの長さであるに違いありません。 同時に、オペランドと拡張ヘッダーでデータを送ってはいけません。
The instruction RSP is sent in reply to the instruction WRITE. The zero basic return code defines normal executing.
指示WRITEに対して指示RSPを送ります。 ゼロ基本的な復帰コードは正常な実行を定義します。
6.1.4 WRITE_EXT
6.1.4 _EXTに書いてください。
The instruction "The extension writing of data" (WRITE_EXT) is used for the data writing on the remote node. Length of the data may be 1 - 262132 octets with a step 1 octet. The instruction has the following values of fields:
指示「データを主題にして書く拡大」(WRITE_EXT)は遠隔ノードを書き続けるデータに使用されます。 ステップ1八重奏でデータの長さは1--262132の八重奏であるかもしれません。 指示には、分野の以下の値があります:
OPCODE = 137
OPR_LENGTH = 3 - 65535 ; Depends on length of the immediate data.
Operands:
1 octets: Always set to zero.
3 octets: The number of the write data in octets. The zero-
value is not available.
4 - 262132 octets: Immediate data for write. The data length
must be multiple of 4 octets.
4/8/16 octets: The memory address for writing the data.
OPCODE=137OPR_長さ=の3--65535。 即値データの長さに依存します。 オペランド: 1八重奏: いつもゼロにセットしてください。 3つの八重奏: 数、八重奏にデータを書いてください。 無値は利用可能ではありません。 4--262132の八重奏: 即値データ、書いてください。 データの長さは4つの八重奏の倍数であるに違いありません。 4/8/16の八重奏: データを書くためのメモリアドレス。
To make the immediate data multiple of four octets, the data is padded with 1 - 3 zero-value octets at the end of a field.
4つの八重奏の即値データ倍数を作るために、データは畑の端の1--3つの無価値の八重奏で水増しされます。
The instruction RSP is sent in reply to the instruction WRITE_EXT. The zero basic return code defines normal executing.
指示WRITE_EXTに対して指示RSPを送ります。 ゼロ基本的な復帰コードは正常な実行を定義します。
6.2 Comparison Instructions
6.2 比較指示
6.2.1 CMP
6.2.1 Cmp
The instruction "To compare" (CMP) is used for binary data comparison. It has the following values of fields:
「比較する」指示(CMP)はバイナリ・データ比較に使用されます。 それには、分野の以下の値があります:
OPCODE = 138/139/140/141 ; For the address length of 2/4/8/16
octets.
OPR_LENGTH = 1 - 65535 ; Depends on length of the immediate
data.
OPCODEは138/139/140/141と等しいです。 2/4/8/16の八重奏のアドレスの長さのために。 OPR_長さ=1--65535。 即値データの長さに依存します。
Bogdanov Experimental [Page 47] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[47ページ]RFC3018
Operands:
2/4/8/16 octets: The memory address for compared data.
2 - 262136 octets: The immediate data for the comparison.
オペランド: 2/4/8/16の八重奏: 比較されたデータのためのメモリアドレス。 2--262136の八重奏: 比較のための即値データ。
At the address length of 2 octets the data length must be 2 octets. In all other cases length of the address must not be less than 4 octets and the data length is multiple to four octets.
2つの八重奏のアドレスの長さでは、データの長さは2つの八重奏であるに違いありません。 4つ未満の八重奏と長さが複数であるデータが4つの八重奏であったならアドレスの他のすべてのケースの長さでそうしてはいけません。
6.2.2 CMP_EXT
6.2.2 Cmp_EXT
The instruction "The extension compare" (CMP_EXT) is used for binary data comparison. Length of the data may be 1 - 262132 octets with a step 1 octet. The instruction has the following values of fields:
指示「拡大は比較する」(CMP_EXT)はバイナリ・データ比較に使用されます。 ステップ1八重奏でデータの長さは1--262132の八重奏であるかもしれません。 指示には、分野の以下の値があります:
OPCODE = 142
OPR_LENGTH = 3 - 65535 ; Depends on length of the immediate data
and the address.
Operands:
1 octet: Always set to 0.
3 octets: The length of compared data in octets. The zero-value
is not available.
4 - 262132 octets: The immediate data for the comparison. The
length of field is multiple of 4 octets.
4/8/16 octets: The memory address of compared data.
OPCODE=142OPR_長さ=の3--65535。 即値データとアドレスの長さに依存します。 オペランド: 1つの八重奏: いつも0にセットしてください。 3つの八重奏: 八重奏における、比較されたデータの長さ。 無値は利用可能ではありません。 4--262132の八重奏: 比較のための即値データ。 分野の長さは4つの八重奏の倍数です。 4/8/16の八重奏: 比較されたデータのメモリアドレス。
To make the immediate data multiple of four octets, the data is padded with 1 - 3 zero-value octets at the end of a field.
4つの八重奏の即値データ倍数を作るために、データは畑の端の1--3つの無価値の八重奏で水増しされます。
6.2.3 Response to Comparison Instructions
6.2.3 比較命令への応答
The instruction RSP is sent in reply to the instruction CMP, CMP_EXT and OBJ_CMP (see below). If the comparison was executed, the basic return code is equal to zero. The additional return code is equal to -1, if the data at the address memories are less then the data from the operand; 0, if they are equal; and 1, if they are more. If the comparison cannot be executed, the basic return code of the instruction RSP must be non-zero.
指示CMP、CMP_EXT、およびOBJ_CMPに対して指示RSPを送ります(以下を見てください)。 比較が実行されたなら、基本的な復帰コードは、ゼロに合わせるために等しいです。 追加復帰コードは-1と等しいです、アドレス思い出におけるデータであるなら、次に、以下はオペランドからのデータです。 0 それらが等しいなら。 そして、1 それらが、より多いなら。 比較を実行できないなら、指示RSPの基本的な復帰コードは非ゼロであるに違いありません。
6.3 Control Transfer Instructions
6.3 コントロール飛越し命令
6.3.1 JUMP, CALL
6.3.1 ジャンプ、呼び出し
The "Unconditional jump" (JUMP) and "To Call-subroutine" (CALL)_ instructions have an equal format and differ only by OPCODE. These instructions have the following values of fields:
「無条件ジャンプ」(JUMP)と「サブルーチンを呼び出す」(CALL)_指示は、等しい形式を持って、OPCODEだけで異なります。 これらの指示には、分野の以下の値があります:
OPCODE = 143/144 ; Correspondingly for the JUMP not containing
and containing the information about VM.
OPCODEは143/144と等しいです。 対応、VMの情報は含んでいて、含まないJUMPのために。
Bogdanov Experimental [Page 48] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[48ページ]RFC3018
145/146 ; Correspondingly the CALL not containing and
containing the information about VM.
OPR_LENGTH = 2 - 65535 ; Depends on inclusion of the information
about VM, address length and parameters
length.
Operands:
2 octets: The VM type of the sender. If OPCODE=143/145 this
field is absent.
2 octets: The VM version of the sender. If OPCODE=143/145 this
field is absent.
4/8/16 octets: The address of memory, where is necessary to
transfer control.
2 octets: The number of 32 bit words in the call parameters
field.
4 - 262134 octets: The immediate data are the parameters of a
call.
145/146 ; 対応、VMの情報は含んでいて、含まないCALL。 OPR_長さ=2--65535。 VMの情報、アドレスの長さ、およびパラメタの長さの包含によります。 オペランド: 2つの八重奏: 送付者のVMタイプ。 OPCODE=143/145であるなら、この分野は欠けています。 2つの八重奏: 送付者のVMバージョン。 OPCODE=143/145であるなら、この分野は欠けています。 4/8/16の八重奏: メモリのアドレス、どこが、コントロールを移すのに必要であるか。 2つの八重奏: 呼び出しパラメタ分野の32ビットの単語の数。 4--262134の八重奏: 即座のデータは呼び出しのパラメタです。
On the reception side the processing of the instructions of a control transfer occurs as follows:
レセプション側では、コントロール転送の指示の処理が以下の通り起こります:
o The memory address is checked. If it has erroneous value, the
negative response RSP is sent. At this stage, the correctness of
parameters of a call may be also checked up.
o If the memory address and the parameters of a call have correct
value, the positive response RSP is sent for the instruction JUMP.
The transmitting side considers the instruction JUMP executed
after receiving response.
o For response of an execution of the instruction CALL the
instruction RETURN is sent. The instruction RETURN may contain
the returned values. If there is an exception condition in a
thread of control created by the CALL instruction, the instruction
RSP with a non-zero basic return code is sent instead of RETURN.
o メモリアドレスはチェックされます。 それに誤った値があるなら、否定応答RSPを送ります。 現在のところ、呼び出しのパラメタの正当性はまた. o Ifにチェックされて、呼び出しのメモリアドレスとパラメタには正しい値があって、指示JUMPのために積極的な応答RSPを送るということであるかもしれません。 伝える側は、指示が応答を受けた後に実行されたJUMPであると考えます。指示CALL指示RETURNの実行のo For応答を送ります。 指示RETURNは戻り値を含むかもしれません。 CALL指示で作成されたコントロールのスレッドに例外条件があれば、RETURNの代わりに非ゼロの基本的な復帰コードがある指示RSPを送ります。
6.3.2 RETURN
6.3.2 リターン
The instruction "Return of control" (RETURN) is used at return of control from the instructions CALL, MVRUN, CALL_BNUM and CALL_BNAME (see below). Those instructions have the following values of fields:
指示「コントロールの復帰」(RETURN)は指示のCALL、MVRUN、CALL_BNUM、およびCALL_BNAMEからコントロールの復帰に使用されます(以下を見てください)。 それらの指示には、分野の以下の値があります:
OPCODE = 147
OPR_LENGTH = 0 - 65535 ; Depends on length of the immediate data.
Operands:
0 - 262140 octets: Immediate data returned from the subroutine.
OPCODE=147OPR_長さ=の0--65535。 即値データの長さに依存します。 オペランド: 0--262140の八重奏: 即値データはサブルーチンから戻りました。
If it is not required to send returned value, the instruction RETURN does not contain operands. The data format coincides with the instruction, for which the response (format VM of the sender or addressee) will be sent.
それは戻り値を送るのに必要でないなら、指示RETURNがオペランドを含んでいません。 データの形式は指示と一致しています。(応答(送付者か受け取り人の形式VM)はそれにおいて送られるでしょう)。
Bogdanov Experimental [Page 49] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[49ページ]RFC3018
6.4 Memory Control Instructions
6.4 メモリコントロール指示
UMSP gives means for division of memory for a code and for the data. The protocol does not make checks of correctness of operations with memory. The code and the data use common address space. The control of memory is completely realized by VM.
UMSPはコードとデータのためのメモリの分割に手段を与えます。 プロトコルはメモリで操作の正当性のチェックをしません。 コードとデータは一般的なアドレス空間を使用します。 メモリのコントロールはVMによって完全に実現されます。
6.4.1 MEM_ALLOC
6.4.1 MEM_ALLOC
The instruction "To allocate a memory for the data" (MEM_ALLOC) is used for request of the allocation of memory under the data. The instruction has the following values of fields:
指示「データのためのメモリを割り当てる」(MEM_ALLOC)はメモリの配分の要求にデータの下に使用されます。 指示には、分野の以下の値があります:
OPCODE = 148
OPR_LENGTH = 1
Operands:
4 octets: The size of required memory in bytes.
OPCODEは148のOPR_長さ=の1オペランドと等しいです: 4つの八重奏: バイトで表現される必要なメモリのサイズ。
For the positive response on the instruction MEM_ALLOC, the instruction ADDRESS, for negative - RSP with the non-zero basic return code is sent. The received address can be used by the protocol in the instructions of reading/writing, comparison and synchronization.
積極的な応答にオンである、指示MEM_ALLOC、ネガのための指示ADDRESS--非ゼロの基本的な復帰コードがあるRSPを送ります。 プロトコルは読書/書くこと、比較、および同期の指示に受け取られていているアドレスを使用できます。
6.4.2 MVCODE
6.4.2 MVCODE
The instruction "To move the code" (MVCODE) is used for moving of the executable code from one node on another. The instruction has the following values of fields:
指示「コードを動かす」(MVCODE)は、別のものの1つのノードから実行コードを移行させるのに使用されます。 指示には、分野の以下の値があります:
OPCODE = 149
OPR_LENGTH = 1 - 65535 ; Depends on length of the code field.
Operands:
2 octets: The VM type of addressee.
2 octets: The VM version of addressee.
0-262136 octets: contains the executable code.
The extension headers:
_DATA - contains the executable code. This header is present
only, if the code does not contain in operands.
OPCODE=149OPR_長さ=の1--65535。 コード分野の長さに依存します。 オペランド: 2つの八重奏: 受け取り人のVMタイプ。 2つの八重奏: 受け取り人のVMバージョン。 0-262136の八重奏: 実行コードを含んでいます。 拡張ヘッダー: _DATA--実行コードを含んでいます。 コードが中に単にオペランドを含んでいないなら、このヘッダーは出席しています。
The code is always connected with VM of the definite type. The code field is always transparent for the protocol. It is formed by the VM of sender and must contain all the information necessary VM of the receiver. The code must not simultaneously be sent in operands and in the extension header.
コードはいつも明確なタイプのVMに接続されます。 プロトコルに、コード分野はいつも透明です。 それは、送付者のVMによって形成されて、受信機のすべての必要情報VMを含まなければなりません。同時に、オペランドと拡張ヘッダーでコードを送ってはいけません。
Bogdanov Experimental [Page 50] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[50ページ]RFC3018
For the positive response on the instruction MVCODE, the instruction ADDRESS, for negative - RSP with the non-zero basic return code is used. The code transferred on the instruction MVCODE, may be executed by the instruction JUMP or CALL.
積極的な応答にオンである、指示MVCODE、ネガのための指示ADDRESS--非ゼロの基本的な復帰コードがあるRSPは使用されています。 コードは指示MVCODEのときに移されて、指示のJUMPかCALLによって実行されるかもしれません。
6.4.3 ADDRESS
6.4.3 アドレス
The instruction "The memory address" (ADDRESS) is used for the positive response on the instruction MEM_ALLOC and MVCODE. ADDRESS has the following values of fields:
指示「メモリアドレス」(ADDRESS)は指示のMEM_ALLOCとMVCODEのときに積極的な応答に使用されます。 ADDRESSには、分野の以下の値があります:
OPCODE = 150
OPR_LENGTH = 1/2/4; Depends on length of the address.
Operands:
4/8/16 octets: The address of the allocated memory.
OPCODEは= 1/2/4に150のOPR_長さと等しいです。 アドレスの長さに依存します。 オペランド: 4/8/16の八重奏: 割り当てられたメモリのアドレス。
For the instruction, MEM_ALLOC the address specifies first byte of the allocated data area. For the instruction MVCODE the contents of the address is defined VM, by which the code is connected.
指示、アドレスが最初に指定するMEM_ALLOC、割り当てられたデータ領域のバイト。 指示MVCODEのために、アドレスのコンテンツは定義されたVMです。(そのVMで、コードは関連しています)。
6.4.4 FREE
6.4.4 無料です。
The memory allocated with the instructions MEM_ALLOC and MVCODE, must be explicitly release. For this purpose, the instruction "To free the memory" (FREE) is used. It has the following values of fields:
指示MEM_ALLOCとMVCODEと共に割り当てられたメモリは明らかにそうであるに違いありません。リリース。 このために、「メモリを解放する」指示(無料)は使用されています。 それには、分野の以下の値があります:
OPCODE = 151
OPR_LENGTH = 1/2/4; Depends on length of the address
Operands:
4/8/16 octets: the address of free memory.
OPCODEは= 1/2/4に151のOPR_長さと等しいです。 アドレスOperandsの長さに依存します: 4/8/16の八重奏: 無料の記憶のアドレス。
VM must free this memory automatically at end of the task on the node.
VMはノードに関するタスクの終わりで自動的にこのメモリを解放しなければなりません。
6.4.5 MVRUN
6.4.5 MVRUN
The instruction "To move and run" (MVRUN) is used for simultaneous move of a code and its execution. The instruction has the following values of fields:
「動いて、実行する」指示(MVRUN)はコードとその実行の同時の移動に使用されます。 指示には、分野の以下の値があります:
OPCODE = 152
OPR_LENGTH = 1 - 65535 ; Depends on length of the code field.
Operands:
2 octets: The addressee VM type.
2 octets: The addressee VM version.
4 - 262136 octets: Contains an executable code.
OPCODE=152OPR_長さ=の1--65535。 コード分野の長さに依存します。 オペランド: 2つの八重奏: 受け取り人VMはタイプします。 2つの八重奏: 受け取り人VMバージョン。 4--262136の八重奏: 実行コードを含んでいます。
Bogdanov Experimental [Page 51] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[51ページ]RFC3018
The extension headers:
_DATA - Contains an executable code. This header is present
only, if the code does not contain in operands.
拡張ヘッダー: _DATA--実行コードを含んでいます。 コードが中に単にオペランドを含んでいないなら、このヘッダーは出席しています。
The executable code is the transparent buffer with the binary data for the protocol. The format of this field is defined by the VM and it must contain all the information necessary for the loader VM of the addressee, including parameters of a call.
実行コードはプロトコルのためのバイナリ・データがある見え透いたバッファです。 この分野の書式はVMによって定義されます、そして、受け取り人の荷物を積む人VMに必要なすべての情報を含まなければなりません、呼び出しのパラメタを含んでいて。
The code must not simultaneously be sent in operands and in the extension header.
同時に、オペランドと拡張ヘッダーでコードを送ってはいけません。
The answer to the instruction MVRUN is formed similarly to instruction CALL. It is not necessary to release memory allocated for a code by this instruction. The memory must deallocate the VM.
指示MVRUNの答えは同様に指示CALLに形成されます。 コードのためにこの指示で割り当てられたメモリを発表するのは必要ではありません。 メモリはVMを「反-割り当て」なければなりません。
6.5 Other Instructions
6.5 他の指示
6.5.1 SYN
6.5.1 SYN
The instruction "To Synchronize" (SYN) is used for the single message about the data change. The instruction has the following values of fields:
「連動させる」指示(SYN)はデータ変化に関するただ一つのメッセージに使用されます。 指示には、分野の以下の値があります:
OPCODE = 153/154/155 ; For length of the address 4/8/16 octets.
OPR_LENGTH = 2 - 65535; Depends on length of the data
Operands:
4/8/16 octets: The memory address of the tracking data.
2 - 131068 octets: The initial data. Length of the data must be
multiple of two octets.
2 - 131068 octets: A mask for comparison. Length of this field
is equal to length of a field of the initial
data.
OPCODEは153/154/155と等しいです。 アドレス4/8/16の八重奏の長さのために。 OPR_長さ=2--65535。 データOperandsの長さに依存します: 4/8/16の八重奏: 追跡データのメモリアドレス。 2--131068の八重奏: 初期のデータ。 データの長さは2つの八重奏の倍数であるに違いありません。 2--131068の八重奏: 比較のためのマスク。 この分野の長さは初期のデータの分野の長さと等しいです。
The tracking data is set by the memory address in the first operand. These data are originally compared to the initial data value from the second operand. If the values do not coincide, it is considered, that the data have changed. The third operand allows setting a mask for comparison. Set to one bits of the mask specifies bits in the data, which change must be traced.
追跡データは最初のオペランドのメモリアドレスによって設定されます。 これらのデータは元々、2番目のオペランドから初期のデータ値にたとえられます。 値が一致しないなら、それは考えられて、それはデータです。変化しました。 3番目のオペランドで、比較のためのマスクを設定します。 マスクの1ビットへのセットはデータでビットを指定して、どれが変化するかたどらなければなりません。
The following variants of the answer are probable on the instruction:
答えの以下の異形は指示のときにありえそうです:
o If the address of local memory is incorrect, the instruction RSP
with the non-zero basic return code is sent for the response.
o If the data do not change, in the response nothing is sent.
o If the data have changed, the instruction DATA with new value of
the traced data is sent.
o データがするo Ifは変化しません、何も送られない応答で。ローカルの記憶のアドレスが不正確であるなら、応答のために非ゼロの基本的な復帰コードがある指示RSPを送ります。データが変えたo If、たどられたデータの新しい値がある指示DATAを送ります。
Bogdanov Experimental [Page 52] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[52ページ]RFC3018
6.5.2 NOP
6.5.2 NOP
The instruction "No operation" (NOP) has the following values of fields:
指示「いいえ操作」(NOP)には、分野の以下の値があります:
OPCODE = 156
OPR_LENGTH = 0 - 65535
Operands:
0 - 262140 octets: Encapsulated data.
Extension headers:
Any Extension headers.
OPCODEは156のOPR_長さ=の0--65535のオペランドと等しいです: 0--262140の八重奏: データであるとカプセル化されます。 拡張ヘッダー: どんなExtensionヘッダー。
The instruction NOP is intended for the decision of the following tasks:
指示NOPは以下のタスクの決定のために意図します:
o Send the control extension headers, when there are no other
instructions for sending in a session
o Encapsulate the fragmented instructions and transactions with the
established flag of special processing (see section 7).
o コントロール拡張ヘッダーを送ってください、セッションo Encapsulateのときに特別な処理の確立した旗で断片化している指示とトランザクションを送るための他の指示が全くないとき(セクション7を見てください)。
6.6 Work with Objects
6.6 オブジェクトとの仕事
The protocol has a set of the instructions being expansion of the protocol RPC [6]. As against RPC, UMSP allows immediately to address memory on remote nodes and to send the pointers in parameters and returned values.
プロトコルは、指示の1セットがプロトコルRPC[6]の拡張であることを持っています。 RPCに対比して、UMSPは遠隔ノードに関するメモリを扱って、すぐに、パラメタと戻り値における指針を送らせます。
The UMSP object is identified by the 4-octet number. The values are divided into the following ranges:
UMSPオブジェクトは4八重奏の数によって特定されます。 値は以下の範囲に分割されます:
I -> %x00000000 - 1FFFFFFF are assigned for standard objects
II -> %x20000000 - 3FFFFFFF are assigned for users objects
III -> %x30000000 - 4FFFFFFF free
IV -> %x50000000 - DFFFFFFF transient
V -> %xE0000000 - FFFFFFFF reserved
I->%x00000000--1FFFFFFFは3FFFFFFFがユーザオブジェクトIII->%x30000000割り当てられるという4FFFFFFF空き領域IV->%x50000000--DFFFFFFF一時的なV->%xE0000000--FFFFFFFFが予約した標準のオブジェクトII->%x20000000割り当てられます。
The objects from a range I must be definite, as standard, and the specifications of their interfaces must be published. The protocol does not suppose the private or not described interfaces of standard objects.
範囲Iからのオブジェクトは規格として明確であるに違いありません、そして、それらのインタフェースの仕様を発表しなければなりません。 プロトコルは標準のオブジェクトの個人的な説明されたインタフェースを思いません。
The objects from a range II must be registered, but the specifications of their interfaces may be optional published. These numbers are applied in cases, when it is required to exclude the probable conflict of systems of the different manufacturers.
範囲IIからのオブジェクトを登録しなければなりませんが、それらのインタフェースの仕様は発行されていた状態で任意であるかもしれません。 これらの数は場合で適用されます、それが異なったメーカーのシステムのありえそうな闘争を除くのに必要であるときに。
Bogdanov Experimental [Page 53] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[53ページ]RFC3018
The range III can be used freely. The objects accessible on these numbers may be created statically or dynamically. These objects can have any interfaces.
自由に範囲IIIを使用できます。 これらの数でアクセスしやすいオブジェクトは静的かダイナミックに作成されるかもしれません。 これらのオブジェクトはどんなインタフェースも持つことができます。
All objects, concerning ranges I, II and III, is common for all jobs on the node, including zero-session. Their interfaces are accessible to all tasks on the node, depending on parameters of authentication.
すべてが反対して、無セッションを含むノードにおけるすべての仕事に、範囲に関して、私、II、およびIIIは一般的です。 認証のパラメタによって、それらのインタフェースはノードに関するすべてのタスクにアクセスしやすいです。
The range IV is intended for objects created dynamically within the framework of one job. These objects are the isolated associative memory of the job. The access to these objects must be granted only for one job. The zero-session has no access to these objects.
範囲IVは1つの仕事のフレームワークの中でダイナミックに作成されたオブジェクトのために意図します。 これらのオブジェクトは仕事の孤立している連想記憶です。 1つの仕事のためだけにこれらのオブジェクトへのアクセスを承諾しなければなりません。 無セッションはこれらのオブジェクトに近づく手段を持っていません。
The protocol grants the access to the data of object, as to the continuous segment of memory. The memory of objects may be overlapping or no overlapping with flat local memory of the node. The offset field is used in the instructions of work with the data of object. The offset rules writing are similar to the local address rules writing.
プロトコルはメモリの連続したセグメントに関してオブジェクトのデータへのアクセスを承諾します。 重なりますが、オブジェクトに関するメモリはノードの平坦なローカルの記憶に重なることでないかもしれません。 オフセット分野はオブジェクトに関するデータで仕事の指示に使用されます。 オフセット規則書法はローカルアドレス規則書くことと同様です。
The address memory length of the node, definite for the UMSP protocol, limits the maximal data size of one object. The instructions definite in the given section, allow to work with associative memory with the theoretical limiting size on one node - 2^96 (7,9 * 10^28) Byte.
ノードのUMSPプロトコルに、明確なアドレスメモリの長さは1個のオブジェクトの最大限度のデータサイズを制限します。 指示、当然のことの部で明確です、連想記憶で理論上の制限サイズがオンのあるノードを仕事に許容してください--2^96(7、9*10^28)バイト。
In addition to the number, the object has the version, 2 octets length, and realization, 2 octets length. The protocol requires obligatory compatibility from bottom-up for all realizations of one version of object. The publication of new realization of standard object may contain only added interfaces.
数に加えて、オブジェクトには、バージョン、2八重奏の長さ、および実現、2八重奏の長さがあります。 プロトコルはオブジェクトの1つのバージョンのすべての実現のためのボトムアップから義務的な互換性を必要とします。 標準のオブジェクトの新しい実現の公表は加えられたインタフェースだけを含むかもしれません。
If for the sender of the instruction the version and/or the realization of object do not play any role or is unknown, the instruction may contain zero fields of the version and realization of object or only zero field of realization. The zero field of the version and non-zero field of realization are not allowed.
指示の送付者にとって、バージョン、そして/または、オブジェクトの実現がどんな役割も果たさないか、または未知であるなら、指示はバージョンのゼロ磁場とオブジェクトの実現か実現のゼロ磁場だけを含むかもしれません。 バージョンのゼロ磁場と実現の非ゼロ磁場は許容されていません。
6.6.1 Reading/Writing of the Objects Data
6.6.1 オブジェクトデータを読むか、または主題にして書くこと。
6.6.1.1 OBJ_REQ_DATA
6.6.1.1 OBJ_REQ_データ
The instruction "To request the data of object" (OBJ_REQ_DATA) is used for request of data of the Object from the remote node. The instruction has the following values of fields:
指示「オブジェクトに関するデータを要求する」(OBJ_REQ_DATA)はObjectに関するデータの要求に遠隔ノードから使用されます。 指示には、分野の以下の値があります:
Bogdanov Experimental [Page 54] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[54ページ]RFC3018
OPCODE = 192/193 ; For length of the field of length 2/4 octets.
OPR_LENGTH = 3/4/5 ; Depends on length of the offset field.
Operands:
4 octets: The number of object.
2 octets: The version of object.
2 octets: The realization of object.
2/4 octets: The length of the required data in octets.
2/4/8 octets: Offset required data from the beginning of object
in bytes.
OPCODEは192/193と等しいです。 長さ2/4の八重奏の分野の長さのために。 = 3/4/5のOPR_の長さ。 オフセット分野の長さに依存します。 オペランド: 4つの八重奏: オブジェクトの数。 2つの八重奏: オブジェクトのバージョン。 2つの八重奏: オブジェクトの実現。 2/4の八重奏: 八重奏における、必要なデータの長さ。 2/4/8の八重奏: バイトでオブジェクトの始まりからの必要なデータを相殺してください。
At length of the length field of 2 octets the offset length must be 2 octets. In all other cases, length of the length field and offset length must be not less than 4 octets.
十分、2つの八重奏の長さの分野では、オフセット長さが2つの八重奏であるに違いありません。 他のすべての場合では、長さの分野とオフセット長さの長さは少なくとも4つの八重奏であるに違いありません。
The instruction DATA, containing the required data, is sent for reply to instruction OBJ_REQ_DATA. If the data cannot be transmitted, the instruction RSP from the non-zero basic return code comes back.
必要なデータを含んでいて、回答のために指示OBJ_REQ_DATAに指示DATAを送ります。 データを送ることができないなら、非ゼロの基本的な復帰コードからの指示RSPは戻ります。
6.6.1.2 OBJ_WRITE
6.6.1.2 OBJ_は書きます。
The instruction "To write the data in object" (OBJ_WRITE) is used for write of the data in object. The instruction has the following values of fields:
「オブジェクトにデータを書くこと」が(OBJ_WRITE)使用される指示はオブジェクトにデータを主題にして書きます。 指示には、分野の以下の値があります:
OPCODE = 194/195/196 ; For length of the offset field of 2/4/8
octets.
OPR_LENGTH = 3 - 65535 ; Depends on the data length.
Operands:
4 octets: The number of object.
2 octets: The version of object.
2 octets: The realization of object.
2/4/8 octets: The offset in object for the data writes.
2 - 262128 octets: The immediate data for write.
The extension headers:
_DATA - Contains immediate data for write. This header is
present, only if the data is not present in operands.
OPCODEは194/195/196と等しいです。 2/4/8の八重奏のオフセット分野の長さのために。 OPR_長さ=3--65535。 データの長さに依存します。 オペランド: 4つの八重奏: オブジェクトの数。 2つの八重奏: オブジェクトのバージョン。 2つの八重奏: オブジェクトの実現。 2/4/8の八重奏: データのためのオブジェクトでのオフセットは書きます。 2--262128の八重奏: 即値データ、書いてください。 拡張ヘッダー: _DATA--、即値データを含んでいる、書いてください。 データがオペランドで存在していない場合にだけ、このヘッダーは出席しています。
At length of the field-offset of 2 octets, length of the data must be 2 octets. In all other cases, the offset length must be not less than 4 octets and the data length is multiple to four. The data must not simultaneously be sent in operands and in the extension header.
十分、2つの八重奏の分野オフセットでは、データの長さは2つの八重奏であるに違いありません。 他のすべての場合では、オフセット長さは少なくとも4つの八重奏と長さが複数であるデータが4であったならそうしなければなりません。 同時に、オペランドと拡張ヘッダーでデータを送ってはいけません。
The instruction RSP is sent in reply to the instructions OBJ_WRITE. The zero basic return code defines the normal execution.
指示OBJ_WRITEに対して指示RSPを送ります。 ゼロ基本的な復帰コードは通常の実行を定義します。
Bogdanov Experimental [Page 55] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[55ページ]RFC3018
6.6.1.3 OBJ_WRITE_EXT
6.6.1.3 OBJ_は_EXTに書きます。
The instruction "The extension writing of the data in object" (OBJ_WRITE_EXT) is used for write of the data in object. Length of the data may be 1 - 262132 octets with the step 1 octet. The instruction has the following values of fields:
「中にデータを主題にして書く拡大は反対すること」が(OBJ_WRITE_EXT)使用される指示はオブジェクトにデータを主題にして書きます。 ステップ1八重奏でデータの長さは1--262132の八重奏であるかもしれません。 指示には、分野の以下の値があります:
OPCODE = 197
OPR_LENGTH = 3 - 65535; Depends on the data length and the address
length.
Operands:
4 octets: The number of object.
2 octets: The version of object.
2 octets: The realization of object.
1 octet: Always set to 0.
3 octets: Length written down data in octets. The zero-value is
incorrect.
4 - 262124 octets: The immediate data for write. Length of the
data is multiple of 4 octets.
2/4/8 octets: Offset in object for the data write.
OPCODE=197OPR_長さ=の3--65535。 データの長さとアドレスの長さに依存します。 オペランド: 4つの八重奏: オブジェクトの数。 2つの八重奏: オブジェクトのバージョン。 2つの八重奏: オブジェクトの実現。 1つの八重奏: いつも0にセットしてください。 3つの八重奏: 八重奏でデータの下側に書かれた長さ。 無値は不正確です。 4--262124の八重奏: 即値データ、書いてください。 データの長さは4つの八重奏の倍数です。 2/4/8の八重奏: データのためにオブジェクトで相殺されて、書いてください。
If the length of the written down data is not multiple of four octets, the data is padded with 1 - 3 zero octets at the end.
--書くことのデータの下側に長さが4つの八重奏の倍数、データが1で水増しされるということでないなら3は八重奏のゼロを終わりに合わせます。
The instruction RSP is sent in reply to the instructions OBJ_WRITE_EXT. The zero basic return code defines the normal execution.
指示OBJ_WRITE_EXTに対して指示RSPを送ります。 ゼロ基本的な復帰コードは通常の実行を定義します。
6.6.2 Comparison Instructions of the Objects Data
6.6.2 オブジェクトデータの比較命令
6.6.2.1 OBJ_DATA_CMP
6.6.2.1 OBJ_データ_Cmp
The instruction "To compare the data of object" (OBJ_DATA_CMP) is used for binary comparison of data of the object by the immediate data from operands. The instruction has the following values of fields:
指示「オブジェクトに関するデータを比較する」(OBJ_DATA_CMP)はオブジェクトに関するデータの2進の比較にオペランドからの即値データによって使用されます。 指示には、分野の以下の値があります:
OPCODE = 198/199/200 ; For length of offset field of 2/4/8
octets.
OPR_LENGTH = 3 - 65535; Depends on length of the data.
Operands:
4 octets: The number of object.
2 octets: The version of object.
2 octets: The realization of object.
2/4/8 octets: Offset in object for the compared data.
2 - 262128 octets: The immediate data for comparison.
OPCODEは198/199/200と等しいです。 2/4/8の八重奏のオフセット分野の長さのために。 OPR_長さ=3--65535。 データの長さに依存します。 オペランド: 4つの八重奏: オブジェクトの数。 2つの八重奏: オブジェクトのバージョン。 2つの八重奏: オブジェクトの実現。 2/4/8の八重奏: 比較されたデータのためにオブジェクトで相殺してください。 2--262128の八重奏: 比較のための即値データ。
Bogdanov Experimental [Page 56] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[56ページ]RFC3018
At length of a field of 2 octets offset the data length must be 2 octets. In all other cases the offset length must be not less than 4 octets and the data length is multiple to 4 octets.
十分、相殺された2つの八重奏の分野では、データの長さが2つの八重奏であるに違いありません。 全部で、他のオフセット長さのケースは少なくとも4つの八重奏と長さが複数であるデータが4つの八重奏であったならそうしなければなりません。
The response to the instruction OBJ_DATA_CMP is described in section 6.2.3.
応答はセクション6.2.3で指示OBJ_DATA_CMPに説明されます。
6.6.2.2 OBJ_DATA_CMP_EXT
6.6.2.2 _OBJ_データCmp_EXT
The instruction "The extension compare of data of the object" (OBJ_DATA_CMP_EXT) is used for binary comparison of data of the object by the immediate data from operands. Length of the data may be 1 - 262132 octets with a step 1 octet. The instruction has following values of fields:
オペランドからの即値データによるオブジェクトに関するデータの「拡大はオブジェクトに関するデータを比較すること」の(OBJ_DATA_CMP_EXT)が使用される指示の2進の比較。 ステップ1八重奏でデータの長さは1--262132の八重奏であるかもしれません。 指示には、分野の次の値があります:
OPCODE = 201
OPR_LENGTH = 5 - 65535 ; Depends on length of the immediate data
and the address length.
Operands:
4 octets: The number of object.
2 octets: The version of object.
2 octets: The realization of object.
1 octet: Always set to 0.
3 octets: The length of compared data in octets. The zero-value
is incorrect.
4 - 262124 octets: The immediate data for the comparison. The
length of field is multiple of 4 octets.
4/8 octets: Offset in object for the compared data.
OPCODE=201OPR_長さ=の5--65535。 即値データの長さとアドレスの長さに依存します。 オペランド: 4つの八重奏: オブジェクトの数。 2つの八重奏: オブジェクトのバージョン。 2つの八重奏: オブジェクトの実現。 1つの八重奏: いつも0にセットしてください。 3つの八重奏: 八重奏における、比較されたデータの長さ。 無値は不正確です。 4--262124の八重奏: 比較のための即値データ。 分野の長さは4つの八重奏の倍数です。 4/8の八重奏: 比較されたデータのためにオブジェクトで相殺してください。
To make the immediate data multiple of four octets, the data is padded with 1 - 3 zero-value octets at the end.
4つの八重奏の即値データ倍数を作るために、データは終わりの1--3つの無価値の八重奏で水増しされます。
The response to the instruction OBJ_DATA_CMP_EXT is described in section 6.2.3.
応答はセクション6.2.3で指示OBJ_DATA_CMP_EXTに説明されます。
6.6.3 Execution of the Objects Procedures
6.6.3 オブジェクト手順の実行
6.6.3.1 CALL_BNUM
6.6.3.1 _をBNUMと呼んでください。
The instruction "To call the object procedure over number" (CALL_BNUM) transfers control to the object procedure over indication of the number. The instruction has following values of fields:
指示「数の上オブジェクト手順を呼ぶ」(CALL_BNUM)は数のしるしの上でオブジェクト手順にコントロールを移します。 指示には、分野の次の値があります:
OPCODE = 202/203 ; Accordingly for the instructions not containing
and containing the information about VM.
OPR_LENGTH = 4 - 65535 ; Depends on inclusion of the information
about VM and call parameters length.
OPCODEは202/203と等しいです。 指示のためにそれに従って、含まないでVMに関して情報を含んでいます。 OPR_長さ=4--65535。 VMの情報と呼び出しパラメタの長さの包含によります。
Bogdanov Experimental [Page 57] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[57ページ]RFC3018
Operands:
2 octets: The VM type of the sender. If OPCODE=202 this field
is absent.
2 octets: The VM version of the sender. If OPCODE=202 this
field is absent.
4 octets: The number of object.
2 octets: The version of object.
2 octets: The realization of object.
4 octets: The number of the called procedure.
4 - 262128 octets: Parameters of the call.
オペランド: 2つの八重奏: 送付者のVMタイプ。 OPCODE=202であるなら、この分野は欠けています。 2つの八重奏: 送付者のVMバージョン。 OPCODE=202であるなら、この分野は欠けています。 4つの八重奏: オブジェクトの数。 2つの八重奏: オブジェクトのバージョン。 2つの八重奏: オブジェクトの実現。 4つの八重奏: 呼ばれた手順の数。 4--262128の八重奏: 呼び出しのパラメタ。
The processing on the reception side is made similarly instructions CALL (see section 6.3.1).
レセプション側で同様に処理をします。指示CALL(セクション6.3.1を見ます)。
6.6.3.2 CALL_BNAME
6.6.3.2 _をBNAMEと呼んでください。
The instruction "To call the object procedure over name" (CALL_BNAME) transfers control to the object procedure over indication of the name. The instruction has following values of fields:
指示「名前の上のオブジェクト手順を呼ぶ」(CALL_BNAME)は名前のしるしの上でオブジェクト手順にコントロールを移します。 指示には、分野の次の値があります:
OPCODE = 204/205 ; Accordingly for the instructions not
containing and containing the information
about VM.
OPR_LENGTH = 3 - 65535 ; Depends on inclusion of the information
about VM and call parameters length.
Operands:
2 octets: The VM type of the sender. If OPCODE=204 this field
is absent.
2 octets: The VM version of the sender. If OPCODE=204 this
field is absent.
4 octets: The number of object.
2 octets: The version of object.
2 octets: The realization of object.
4 - 262128 octets: Parameters of the call.
The extension header:
_NAME - Contains the name of the called procedure.
OPCODEは204/205と等しいです。 指示のためにそれに従って、含まないでVMに関して情報を含んでいます。 OPR_長さ=3--65535。 VMの情報と呼び出しパラメタの長さの包含によります。 オペランド: 2つの八重奏: 送付者のVMタイプ。 OPCODE=204であるなら、この分野は欠けています。 2つの八重奏: 送付者のVMバージョン。 OPCODE=204であるなら、この分野は欠けています。 4つの八重奏: オブジェクトの数。 2つの八重奏: オブジェクトのバージョン。 2つの八重奏: オブジェクトの実現。 4--262128の八重奏: 呼び出しのパラメタ。 拡張ヘッダー: _NAME--呼ばれた手順の名前を含んでいます。
The processing on the reception side is made similarly instructions CALL (see section 6.3.1).
レセプション側で同様に処理をします。指示CALL(セクション6.3.1を見ます)。
The names may have the procedures of the objects belonging to ranges III and IV. The procedures of the objects belonging to ranges I and II must not have a name on the UMSP layer. They must have the number only.
名前には、範囲IIIとIVに属すオブジェクトの手順があるかもしれません。 私とIIが属さなければならない範囲に属すオブジェクトの手順はUMSP層に名前を持っていません。 彼らには、数しかあってはいけません。
Bogdanov Experimental [Page 58] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[58ページ]RFC3018
6.6.3.3 GET_NUM_PROC
6.6.3.3 _ヌム_PROCを手に入れてください。
The instruction "To get the name of object procedure" (GET_NUM_PROC) allows receiving number of the procedure for objects in ranges III and IV over procedure name. The instruction has following values of fields:
「オブジェクト手順の名前を得る」指示(_GET_ヌムPROC)で、範囲IIIとIVのオブジェクトのために手順の数をプロシージャ名の上に受けます。 指示には、分野の次の値があります:
OPCODE = 206
OPR_LENGTH = 2
Operands:
4 octets: The number of object.
2 octets: The version of object.
2 octets: The realization of object.
The extension header:
_NAME - Contains procedure name.
OPCODEは206のOPR_長さ=の2つのオペランドと等しいです: 4つの八重奏: オブジェクトの数。 2つの八重奏: オブジェクトのバージョン。 2つの八重奏: オブジェクトの実現。 拡張ヘッダー: _NAME--プロシージャ名を含んでいます。
For the positive response on the instruction GET_NUM_PROC, the instruction PROC_NUM, for negative - RSP with the non-zero basic return code is sent.
_指示GET_ヌムPROCの積極的な応答、ネガのための指示PROC_NUM--非ゼロの基本的な復帰コードがあるRSPを送ります。
6.6.3.4 PROC_NUM
6.6.3.4 PROC_ヌム
The instruction "The procedure number" (PROC_NUM) is sent in reply to the instruction GET_NUM_PROC. The instruction PROC_NUM has following values of fields:
_指示GET_ヌムPROCに対して指示「手順番号」(PROC_NUM)を送ります。 指示PROC_NUMには、分野の次の値があります:
OPCODE = 207
OPR_LENGTH = 3
Operands:
4 octets: The number of object.
2 octets: The version of object.
2 octets: The realization of object.
4 octets: The number of procedure.
OPCODEは207のOPR_長さ=の3つのオペランドと等しいです: 4つの八重奏: オブジェクトの数。 2つの八重奏: オブジェクトのバージョン。 2つの八重奏: オブジェクトの実現。 4つの八重奏: 手順の数。
6.6.4 The Objects Creation
6.6.4 オブジェクト作成
The objects from the ranges I and II (standard and assigned for the user) cannot be created on the remote node through the UMSP interface. These objects must be created only through API of the VM. The objects from the ranges III and IV can be created on the remote node by the protocol instructions.
オブジェクト、範囲から、UMSPインタフェースを通して遠隔ノードで(標準でユーザのために割り当てられる)の私とIIを創造できません。 VMのAPIだけを通してこれらのオブジェクトを作成しなければなりません。 遠隔ノードでプロトコル指示で範囲IIIとIVからのオブジェクトを作成できます。
The realization of objects from the ranges I - III (not connected with the certain job) is difficult enough. The reason is that the different jobs can have the different address spaces of memory. The pointers must be processed in the context of the job, from which they are received. Besides, these objects must trace the end of the jobs
I--III(ある仕事に関連づけられない)が十分難しいという範囲からのオブジェクトの認識。 理由は異なった仕事がメモリの異なったアドレス空間を持つことができるということです。 仕事の文脈で指針を処理しなければなりません。(それらは仕事によって受け取られています)。 そのうえ、これらのオブジェクトは仕事の終わりをたどらなければなりません。
Bogdanov Experimental [Page 59] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[59ページ]RFC3018
for deallocation of dynamic resources. The specified requirements impose essential restrictions on these objects. The protocol does not impose any restrictions on objects from the range IV.
ダイナミックなリソースの反配分のために。 規定要求事項は不可欠の制限をこれらのオブジェクトに課します。 プロトコルは少しの制限も範囲IVからオブジェクトに課しません。
Unique key identifying object on node, is number of object. To objects from the ranges, III and IV the name may be assigned. The objects from range I and II must not have names on the UMSP layer. Within the framework of one task must not be two objects having one number or one name.
ユニークキーがノードの上の物を特定して、物で数をできさせますか? 範囲、III、およびIVからの物に、名前は割り当てられるかもしれません。 私とIIがそうしなければならない範囲からの物はUMSP層に名前を持っていません。 中では、1つのタスクの枠組みが1つの数か1つの名前がある2個の物であるはずがありません。
6.6.4.1 NEW, SYS_NEW
6.6.4.1 新しくて、SYS_新しいです。
The format of both instructions "New object" (NEW) and "New system object" (NEW_SYS) is similar. First instruction creates object in the range IV, second - in the range III. These instructions have the following values of fields:
両方の指示「新しい物」(NEW)と「新しいシステム対象物」(NEW_SYS)の形式は同様です。 まず最初に、指示は範囲IIIで範囲IVの物、2番目を作成します。 これらの指示には、分野の以下の値があります:
OPCODE = 208/209; Accordingly for NEW/NEW_SYS.
OPR_LENGTH = 3
Operands:
2 octets: The addressee VM type.
2 octets: The addressee VM version.
2 octets: The version of object.
2 octets: The realization of object.
4 - 262136 octets: Immediate data necessary for creation of
object.
The extension headers:
_DATA - Contains immediate data, necessary for creation of
object. This header is present, only if the data is not
present in operands.
_NAME - Contains the name of object. This header is optional.
OPCODEは208/209と等しいです。 それに従って、新しいか新しい_SYSのために。 OPR_長さは3つのオペランドと等しいです: 2つの八重奏: 受け取り人VMはタイプします。 2つの八重奏: 受け取り人VMバージョン。 2つの八重奏: 物のバージョン。 2つの八重奏: 物の実現。 4--262136の八重奏: 物の創造に必要な即値データ。 拡張ヘッダー: _DATA--物の創造に必要な即値データを含んでいます。 データがオペランドで存在していない場合にだけ、このヘッダーは出席しています。 _NAME--物の名前を含んでいます。 このヘッダーは任意です。
The instruction NEW_SYS is used for the creation of object accessible from any job, NEW - for creation of object accessible only from its job. If the object is created, the instruction OBJECT is sent for the response. If the object cannot be created, the instruction RSP with the non-zero basic return code is sent.
指示NEW_SYSはどんな仕事でもアクセスしやすい物の創造に使用されます、NEW--単に仕事でアクセスしやすい物の創造のために。 物を作成するなら、応答のために指示OBJECTを送ります。 物を作成できないなら、非ゼロの基本的な復帰コードがある指示RSPを送ります。
The immediate data field is transparent for the protocol. It is formed by the sender VM and it must contain the information, which is necessary to the addressee VM for the creation of object. Data must not simultaneously be sent in operands and in the extension header.
プロトコルに、即値データ分野は透明です。 送付者VMによって形成されます、そして、それは情報を含まなければなりません。(受け取り人VMに、それが、物の創造に必要です)。 同時に、オペランドと拡張ヘッダーでデータを送ってはいけません。
The field SESSION_ID of the instruction cannot have the zero value. The dynamic object must be created only in the context of the definite job. The object is always created on VM, with which the session is connected.
指示のSESSION_IDがゼロに評価させることができない分野。 明確な仕事の文脈だけでダイナミックな物を作成しなければなりません。 物はいつもVMに作成されます。(セッションはVMに関連しています)。
Bogdanov Experimental [Page 60] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[60ページ]RFC3018
The zero values of the version and the realizations of object means, that the object have no these values.
ゼロが評価する、物にはいいえがこれらが評価するあるという物の手段のバージョンと実現について。
It is possible to register the name of object simultaneously with its creation. The name contains in the _NAME extension header.
同時に物の名前を創造に登録するのは可能です。 _NAME拡張ヘッダーの含有という名前。
All objects created upon the instructions NEW and NEW_SYS must be obviously deleted. VM must automatically delete all dynamic objects, created and not deleted by the task, at the end of the task.
明らかに指示のNEWとNEW_SYSに作成されたすべての物を削除しなければなりません。 VMは自動的にタスクの終わりでタスクによって削除されないで、作成されたすべてのダイナミックな物を削除しなければなりません。
6.6.4.2 OBJECT
6.6.4.2 物
The instruction "The Object" (OBJECT) is used for the positive response on the instruction NEW and NEW_SYS. The instruction OBJECT has following values of fields:
指示「物」(OBJECT)は指示のNEWとNEW_SYSのときに積極的な応答に使用されます。 指示OBJECTには、分野の次の値があります:
OPCODE = 210
OPR_LENGTH = 2
Operands:
4 octets: The number of object.
2 octets: The version of object.
2 octets: The realization of object.
OPCODEは210のOPR_長さ=の2つのオペランドと等しいです: 4つの八重奏: 物の数。 2つの八重奏: 物のバージョン。 2つの八重奏: 物の実現。
6.6.4.3 DELETE
6.6.4.3、削除
The instruction "To delete the object" (DELETE) is used for the deleting of object created on the instruction NEW or NEW_SYS. The instruction DELETE has the following values of fields:
指示「物を削除する」(DELETE)は指示NEWかNEW_SYSに作成された物の削除に使用されます。 指示DELETEには、分野の以下の値があります:
OPCODE = 211
OPR_LENGTH = 1
Operands:
4 octets: number of object
OPCODEは211のOPR_長さ=の1オペランドと等しいです: 4つの八重奏: 物の数
The object may be deleted only from the job, which has created it. The instruction RSP is sent in reply to this instruction.
物は単に仕事から削除されるかもしれません。(それは、それを作成しました)。 この指示に対して指示RSPを送ります。
6.6.5 The Objects Identification
6.6.5 物の識別
At registration of object on the node, it may be identify by the name, the length of 4 - 254 octets. The name contains the symbols ASCII. The following versions of the protocol may define other types of the name.
ノードにおける物の登録では、それは名前を特定することであるかもしれません、4の長さ--254の八重奏。 名前はシンボルASCIIを含んでいます。 プロトコルの以下のバージョンは名前の他のタイプを定義するかもしれません。
The name identifies with the number of object and is its synonym. The names of all active objects in one task on the node must be unique. Thus, all active objects from the range of number I - III
名前は、物の数を同一視して、その同義語です。 ノードに関する1つのタスクのすべてのアクティブオブジェクトの名前はユニークであるに違いありません。 その結果、数Iの範囲からのすべてのアクティブオブジェクト--III
Bogdanov Experimental [Page 61] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[61ページ]RFC3018
must have the unique names for all tasks on the node. The protocol allows receiving the number of object by the name and the name of object by the number.
ノードに関するすべてのタスクのためのユニークな名前を持たなければなりません。 プロトコルで、数に応じて、名前の物の数と物の名前を受け取ります。
6.6.5.1 OBJ_SEEK
6.6.5.1 OBJ_は探されます。
The instruction "To seek the object" (OBJ_SEEK) is used for seek of number of the object by the name. It has the following values of fields:
「物を探すこと」が(OBJ_SEEK)使用される指示は名前で物の数を求めます。 それには、分野の以下の値があります:
OPCODE = 212
OPR_LENGTH = 0
The extension header:
_NAME - contains the name of object for search.
OPCODEは_拡張ヘッダーの212OPR LENGTH=0と等しいです: _NAME--検索のための物の名前を含んでいます。
If the object is found - the instruction OBJECT is sent in the answer. If the object is not found - the instruction RSP with the non-zero basic return code is sent for the response.
--物が見つけられるなら答えで指示OBJECTを送ります。 --物が見つけられないなら応答のために非ゼロの基本的な復帰コードがある指示RSPを送ります。
The instruction OBJ_SEEK may be sent broadcast through UDP. In this case, it concerns to zero-session. The instruction may contain the field REQ_ID for identification of answers. The positive responses in this case must be sent only. The response may be transmitted through UDP.
UDPを通して指示OBJ_SEEKに放送を送るかもしれません。 この場合、それは無セッションまで関係があります。 指示は答えの識別のための分野REQ_IDを含むかもしれません。 この場合応答を送らなければならない積極的専用。 応答はUDPを通して伝えられるかもしれません。
6.6.5.2 OBJ_GET_NAME
6.6.5.2 OBJ_は_名前を得ます。
The instruction "To get a name of the object" (OBJ_GET_NAME) is used for get of the name of object by number. It has the following values of fields:
数に応じて、「物の名前を得ること」が(OBJ_GET_NAME)使用される指示は物の名前を得ます。 それには、分野の以下の値があります:
OPCODE = 213
OPR_LENGTH = 1
Operands:
4 octets: number of object for getting
OPCODEは213のOPR_長さ=の1オペランドと等しいです: 4つの八重奏: 得る物の数
If the object is present - the instruction OBJECT with the extension header _NAME is sent for the response. If the object is not present - the instruction RSP with the non-zero basic return code is sent for the response.
--物が存在しているなら応答のために_拡張ヘッダーNAMEと指示OBJECTを送ります。 --物が存在していないなら応答のために非ゼロの基本的な復帰コードがある指示RSPを送ります。
7 Chains
7 チェインズ
The instructions, which will be sent on one session connection, can be unified in a chain. The chain is a group of the instructions relational with each other. In one session, several chains simultaneously can be transferred. The chains can be the following types:
チェーンで指示(1つのセッション接続に送られる)を統一できます。 チェーンは互いと共に関係している指示のグループです。 1つのセッションでは、同時に、数人のチェーンを移すことができます。 チェーンは以下のタイプであるかもしれません:
Bogdanov Experimental [Page 62] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[62ページ]RFC3018
o The sequence. o The transaction o The fragmented instruction.
o . ○ 取引oを配列してください。断片化している指示。
If the instruction is included into a chain, the flag CHN should be equal 1. The field CHAIN_NUMBER of header contains number of a chain, INSTR_NUMBER - serial instruction number in a chain, since 0. The numbering of chains is conducted by the protocol. In one session simultaneously can be transferred up to 65533 chains. Values of numbers of chains %x0000 and %xFFFF reserved by the protocol. One chain can contain up to 65535 instructions.
指示がチェーンに含められているなら、旗のCHNは1と等しいことであるべきです。 ヘッダーの分野CHAIN_NUMBERはチェーン、INSTR_NUMBERの数を含んでいます--0以来のチェーンにおける連続の指示番号。 チェーンの付番がプロトコルによって行われます。 1では、同時に、セッションを65533のチェーンまで移すことができます。 %x0000と%xFFFFがプロトコルで予約したチェーンの数の値。 1つのチェーンが最大65535の指示を含むことができます。
The instruction with a zero serial number INSTR_NUMBER should contain the extension header describing a chain. Each type of a chain has own initiating extension header.
通し番号がないINSTR_NUMBERとの指示はチェーンについて説明する拡張ヘッダーを含むべきです。 チェーンの各タイプには、自身の開始している拡張ヘッダーがいます。
_END_CHAIN. The extension header "End of the chain" is transferred in last instruction of chain, irrespective of type of the chain. It has the following values of fields:
__チェーンを終わらせてください。 チェーンのタイプの如何にかかわらずチェーンの最後の指示で拡張ヘッダー「チェーンの端」を移します。 それには、分野の以下の値があります:
HEAD_CODE = 6
HEAD_LENGTH = 0
HOB = 1
6のヘッド_長さ=の0ヘッド_コード=暖炉内部の横棚=1
Number of a finished chain contains in a field CHAIN_NUMBER of the instruction header, to which the extension header is attached.
完成チェーンの数は分野に指示ヘッダーのCHAIN_NUMBERを保管しています。(ヘッダーにおいて、拡張ヘッダーは付けています)。
The instructions, included in chains, can be transferred through UDP only if all chain is located in one segment.
1つのセグメントですべてのチェーンを位置させる場合にだけ、UDPを通して手かせ足かせをはめられた状態で含まれていた指示は移すことができます。
7.1 Sequence
7.1 系列
The sequence is a type of a chain, which unites the instructions dependent from each other. The following instruction of a sequence can be executed on VM, only if have been executed previous. If the current instruction cannot be executed, all other instructions of the given sequence (already sent or expecting sending) simply cancel. Due to this, it is possible for one computing control thread not to wait for the current instruction positive end and to transfer following at once.
系列はチェーンのタイプです。(それは、互いから依存する指示を結合させます)。 VMで系列の以下の指示を実行できる、唯一、前であることの状態で、実行されてください、そうした。 現在の指示を実行できないなら、与えられた系列(既に発信を送るか、または予想する)の他のすべての指示が単に中止されます。 これのために、すぐに続いて、現在の指示上向きの終わり、移すのを待たないように個人的には制御糸を計算するのは可能です。
_BEGIN_SQ. The extension header "To begin a sequence" is transferred in the first instruction of the sequence. It has the following values of fields:
_平方で_を始めてください。 系列の最初の指示で「系列を始める」拡張ヘッダーを移します。 それには、分野の以下の値があります:
HEAD_CODE = 3
HEAD_LENGTH = 0
HOB = 1
3のヘッド_長さ=の0ヘッド_コード=暖炉内部の横棚=1
Bogdanov Experimental [Page 63] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[63ページ]RFC3018
Number of created chain is established in field CHAIN_NUMBER of the instruction header, to which the extension header is attached. The field INSTR_NUMBER must have value 0.
作成されたチェーンの数は指示ヘッダーの分野CHAIN_NUMBERに確立されます。(ヘッダーにおいて、拡張ヘッダーは付けています)。 分野INSTR_NUMBERには、値0がなければなりません。
The initiator of creation of a sequence is VM. It is not obligatory that the sequence should have known length beforehand. It can be completed in any moment. If it is necessary to finish a sequence and there are no instructions for sending, the instruction NOP can be generated.
系列の創造の創始者はVMです。 系列があらかじめ長さを知っていたのは、義務的ではありません。 それはどんな瞬間でも完成できます。 系列を終えるのが必要であり、送付のための指示が全くなければ、指示NOPは発生できます。
7.2 Transaction
7.2 取引
The transaction is a type of the chain uniting some possibly not connected with each other instructions. All transaction instructions must be executed all at once or must not be executed. It is possible to cancel or to confirm transaction execute. The transaction cancellation after execution is not stipulated. If it is necessary, such mechanism should be realized at VM level, because there can be instructions in transaction, which are impossible to cancel, for example a control transfer.
取引はいくつかを結合させるチェーンのタイプがことによると互いに伴う指示を接続しなかったということです。 すべての取引指示を一気に実行しなければならないか、または実行しなければならないというわけではありません。 取り消すか、または取引が実行すると確認するのにおいてそれは可能です。 実行の後の取引キャンセルは規定されていません。 それが必要であるなら、そのようなメカニズムはVMレベルで実現されるべきです、取引における取り消すのが不可能な指示があることができるので、例えば、コントロール転送。
The initiator of transaction creation is VM. The transaction length must be known beforehand. The length will define a way of transaction transfer. It is connected with buffering described in section 7.4.
取引創造の創始者はVMです。 あらかじめ、取引の長さを知っていなければなりません。 長さは取引転送の方法を定義するでしょう。 それはセクション7.4で説明されるバッファリングに接続されます。
7.2.1 _BEGIN_TR
7.2.1 __TRを始めてください。
The extension header "To begin a transaction" _BEGIN_TR is transferred in the first transaction instruction. It has the following values of fields:
最初の取引命令で拡張ヘッダー「取引を始め」_BEGIN_TRを移します。 それには、分野の以下の値があります:
HEAD_CODE = 4
HEAD_LENGTH = 1
HOB = 1
DATA - Has the following format:
4HEAD_LENGTH=1HEAD_CODE=HOBは1DATAと等しいです--以下の形式を持っています:
+---+---+---+---+---+---+---+---+
|TRE|TRR|TRS| Reserve |
+---+---+---+---+---+---+---+---+
| TIME_TR |
+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+ |Tre|TRR|TRS| 蓄え| +---+---+---+---+---+---+---+---+ | 時間_TR| +---+---+---+---+---+---+---+---+
TRE
Tre
1 bit. The flag of obligatory execution. This flag relates
only to completely transferred, but have not yet executed
transaction. If TRE = 1, the transaction must be executed at
1ビット。 義務的な実行の旗。 この旗は関係しますが、完全に移しますが、まだ取引を実行していません。 TRE=1であるなら、取引を実行しなければなりません。
Bogdanov Experimental [Page 64] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[64ページ]RFC3018
the expiration of existence time, established by field TIME_TR,
or at emergency session end. If TRE = 0, at end of existence
time the transaction must be cancelled and the negative
acknowledgement must be transferred, and at emergency session
end - must be simply cancelled.
分野タイム誌_TR、または緊急集会終わりに確立された存在時間の満了。 TREが取引を中止しなければならなくて、否定的承認を移さなければならない存在時の終わり、および緊急集会終わりの0--単に取り消さなければならないのと等しいなら。
TRR
TRR
1 bit. The flag of execution after sending. If TRR = 1, the
transaction must be executed after sending of all instructions,
of which it is consists, at once. Such transaction is executed
after reception of the instruction with the extension header
_END_CHAIN. If TRR = 0, it is necessary to transfer the
special instruction EXEC_TR of transaction acknowledgement for
its execution.
1ビット。 発信した後の実行の旗。 TRR=1であるなら、すべての指示を発信させた後に取引を実行しなければならなくて、どれについてそれがあるかはすぐに、成ります。 そのような取引は_拡張ヘッダーEND_CHAINとの指示のレセプションの後に実行されます。 TRR=0であるなら、実行のために取引承認の特殊命令EXEC_TRを移すのが必要です。
TRT
TRT
1 bit. The flag of special processing. It is entered for a
possibility of the further expansion of the protocol. If TRT =
1, before transaction execution it is necessary to make some
additional actions above the instructions, of which it is
consists, for example to decipher. These actions can be
definite in the additional extension headers transmitted in the
transaction instructions. The given document will not define
cases of use of this flag. The value TRT must be zero.
1ビット。 特別な処理の旗。 それはプロトコルの一層の拡大の可能性のために入られます。 取引実行の前に指示を超えていくつかの追加動作をするのがTRT=1であるなら、必要である、どれについてそれがあるかは例えば、暗号文の解読に成ります。 これらの動きは取引指示で伝えられた追加拡張ヘッダーで明確である場合があります。 与えられたドキュメントはこの旗で役に立つケースを定義しないでしょう。 値のTRTはゼロであるに違いありません。
Reserve
蓄え
Must be set to 0.
0に設定しなければなりません。
TIME_TR
時間_TR
1 octet. Time of transaction life in 2 - second intervals
(maximal lifetime - 8 minutes). The receiving side begins
readout of this time after receiving all transaction
instructions. The value %x00 sets transaction without
restriction of lifetime.
1つの八重奏。 2における取引人生の時間--2番目の間隔(最大限度の生涯--8分)。 すべての取引指示を受けた後に、受信側は今回の読み取りを始めます。 値の%x00は生涯の制限なしで取引を設定します。
In the last instruction of transaction the header, _END_CHAIN is always sent.
取引の最後の指示では、ヘッダーであり、_END_CHAINをいつも送ります。
7.2.2 EXEC_TR
7.2.2 幹部_TR
This instruction "To execute the transaction" (EXEC_TR) is transferred for execution transaction early transferred. It has the following values of fields:
実行取引のために早くわたった状態でこの指示「取引を実行する」(EXEC_TR)を移します。 それには、分野の以下の値があります:
Bogdanov Experimental [Page 65] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[65ページ]RFC3018
OPCODE = 158
ASK = 1
PCK = %b01/10/11
CHN = 1
EXT = 0/1
CHAIN_NUMBER - Contains the number of chain, which is necessary to
execute.
INSTR_NUMBER = 0
OPR_LENGTH = 0
1 1 158OPCODE=ASK=PCK=%b01/10/11 CHN=EXTが0/1CHAIN_NUMBERと等しいです--チェーンの数を含んでいます。(チェーンが、実行するのに必要です)。 0のOPR_長さ=のINSTR_数=0
7.2.3 CANCEL_TR
7.2.3 _TRを取り消してください。
The instruction "To cancel transaction" (CANCEL_TR) is transmitted for a cancellation of execution transaction transmitted before. It has the following values of fields:
指示「取引を中止する」(キャンセル_TR)は以前伝えられた実行取引のキャンセルのために伝えられます。 それには、分野の以下の値があります:
OPCODE = 159
ASK = 0
PCK = %b01/10/11
CHN = 1
EXT = 0/1
CHAIN_NUMBER - Contains the number of chain, which is necessary to
cancel.
INSTR_NUMBER = 0
OPR_LENGTH = 0
1 0 159OPCODE=ASK=PCK=%b01/10/11 CHN=EXTが0/1CHAIN_NUMBERと等しいです--チェーンの数を含んでいます。(チェーンが、取り消すのに必要です)。 0のOPR_長さ=のINSTR_数=0
The instructions, of which the cancelled transaction consists, delete without a possibility of restoration.
指示(取り消された取引は成る)はaなしで回復の可能性を削除します。
7.3 Fragmented instruction
7.3 断片化している指示
UMSP is designed for work with the transport protocol with the limited size of transmitted data segment. The fragmentation of the instructions is made in the following two cases:
UMSPは仕事のために伝えられたデータ・セグメントの限られたサイズがあるトランスポート・プロトコルで設計されています。 以下の2つの場合で指示の断片化をします:
(1) If the instruction is longer than the maximal segment size of
transport layer or,
(2) If the segment is formed of the several instructions and last
instruction is not located in it completely.
(1) 指示がトランスポート層の最大限度のセグメントサイズより長いか、またはセグメントがいくつかの指示と最後の指示について形成されるなら(2)がそれに完全に位置するというわけではないなら。
The decision on fragmentation is taken to UMSP level.
断片化の決定はUMSPレベルに上げられます。
The fragmented instruction is encapsulated in several NOP instructions. Then all instructions NOP are transmitted, as one chain of special type. The following algorithm is used during encapsulation:
断片化している指示はいくつかのNOP指示で要約されます。 そして、すべての指示NOPが特別なタイプの1つのチェーンとして伝えられます。 以下のアルゴリズムはカプセル化の間、使用されます:
Bogdanov Experimental [Page 66] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[66ページ]RFC3018
(1) The fields SESSION_ID and REQ_ID from the fragmented instruction
are written in the first NOP instruction. If field REQ_ID is
not present in the initial instruction, it must not be in the
NOP instruction. The field SESSION_ID always is present in the
fragmented instructions.
(2) Then these fields delete from the initial instruction. The
value of all other fields of the header does not change.
(3) After that, the initial instruction is divided into fragments of
necessary length. Each fragment is located in a field of
operands of the NOP instruction. Other data should not be
entered in operand field.
(1) 断片化している指示からの分野SESSION_IDとREQ_IDは最初のNOP指示に書かれています。 分野REQ_IDが初期の指示で存在していないなら、それはNOP指示中であるはずがありません。 分野SESSION_IDは断片化している指示でいつも存在しています。 (2) そして、これらの分野は初期から指示を削除します。 ヘッダーの他のすべての分野の値は変化しません。 (3) その後に、初期の指示は必要な長さの断片に分割されます。 各断片はNOP指示のオペランドの分野に位置しています。 他のデータをオペランド欄に入力するべきではありません。
_BEGIN_FRG. The extension header "The first fragment" is transmitted to the NOP instruction, which contains the first fragment. It has the following values of fields:
__FRGを始めてください。 「1番目は断片化する」拡張ヘッダーがNOP指示に伝えられます。(それは、最初の断片を含みます)。 それには、分野の以下の値があります:
HEAD_CODE = 5
HEAD_LENGTH = 0/2 ; Depends on subordination of the chain.
HOB = 1
Data:
2 octets: Number of the parental chain. Fragmented instruction
may be a part of the sequence or transaction.
2 octets: The instruction number in the parental chain.
ヘッド_コードは5のヘッド_長さ=0/2と等しいです。 チェーンの従属によります。 暖炉内部の横棚は1つのデータと等しいです: 2つの八重奏: 親のチェーンの数。 断片化している指示は系列か取引の一部であるかもしれません。 2つの八重奏: 親のチェーンにおける指示番号。
The header _END_CHAIN is transmitted in NOP instruction, which contains last fragment.
ヘッダー_END_CHAINはNOP指示で伝えられます。(それは、最後の断片を含みます)。
7.4 Buffering
7.4 バッファリング
In the given item, the buffering used by the protocol on receiving of data is described. The question of buffering on sending lies beyond the scope of the protocol.
既知項目では、データを受け取るときプロトコルによって使用されたバッファリングは説明されます。 発信するときのバッファリングの問題がプロトコルの範囲を超えてあります。
If the instruction is not include in a chain, it is transmitted to VM for execution at once and does not require buffering at the protocol level. The interface UMSP - VM must provide asynchronous instructions sending. It is recommended, that the productivity of UMSP systems, should allow to process the instructions accepted from network, with that speed, with what they were received. All instructions are designed so that carries out the known and limited computing loading. Exception is the instruction of control transfers, which must be processed in two stages. The instruction correctness is checked firstly and its scheduling is made. Then the instruction is executed. At that must be guaranteed that the protocol can receive such part of processor time, which would allow it to work in stationary mode. Therefore, the questions of node overload are deduced on VM layer and user applications layer, where they can be sensible controlled.
指示がチェーンでインクルードでないなら、それは、すぐに、実行のためにVMに伝えられて、プロトコルレベルでバッファリングするのを必要としません。 インタフェースUMSP--VMは非同期な指示発信を提供しなければなりません。 それはお勧めであり、それはUMSPシステムの生産性です、その速度でネットワークから受け入れられた指示を過程に許すべきであり、それらが何であったかで受けて。 すべての指示が設計されているので、それは知られていて限られたコンピューティングローディングを行います。 例外はコントロール転送の指示です。(2つの段階で転送を処理しなければなりません)。 指示の正当性はまず第一にチェックされます、そして、スケジューリングは作られています。 そして、指示は実行されます。 おまけに、プロトコルがそれが静止したモードで働いているだろうプロセッサ時間のそのような部分を受け取ることができるのを保証しなければなりません。 したがって、ノードオーバーロードの問題はVM層で推論されます、そして、ユーザアプリケーション(彼らは制御されていた状態で分別がある場合がある)は層にされます。
Bogdanov Experimental [Page 67] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[67ページ]RFC3018
For chains, the protocol provides two schemes of buffering during the receiving:
チェーンのために、プロトコルは受信の間、以下をバッファリングする2つの計画を提供します。
(1) At the session connection establishment, the sides agree about
the allocated buffer ("window") size. The window always is more
than the maximal segment of a transport layer. The transmitting
side can expect for this buffer without the preliminary
coordination with the receiving side. The window size is
established single for each session connection, and cannot be
changed in subsequent. UMSP is designed for using of transport
layer, which informs about the data delivery. Therefore
transmitting side traces the current free size of the window on
the reception side for each connection without assistance. If
the reception side finds out, that the data have been received,
which cannot be placed in the window, the connection is broken
off.
(1) セッションコネクション確立のときに、側は割り当てられたバッファ(「窓」)サイズに関して同意します。 いつも窓はトランスポート層の最大限度のセグメント以上です。 伝える側は、受信による予備のコーディネートのないこのバッファのために面があるように予想できます。 ウィンドウサイズは、それぞれのセッション接続のための確立したシングルであり、その後で変えることができません。 UMSPはトランスポート層の使用のために設計されています。(トランスポート層はデータ配送に関して知らせます)。 したがって、各接続のために支援なしでレセプション側の上の窓の現在の自由なサイズのサイド跡を伝えます。 レセプション側が見つけるなら、データ(窓、接続に置くことができない)を受け取ったのは壊れています。
(2) For transactions and fragmented instructions, which size exceeds
the window, it is necessary to request the reception node the
sanctions to sending. The theoretical limiting size of chain
transmitting so is 4 Gbytes.
そのサイズは窓を超えています。(2) 取引と断片化している指示に、レセプションノードを要求するのが必要です。発信への制裁。 したがって、チェーンの伝えることの理論上の制限サイズは4ギガバイトです。
REQ_BUF. The instruction "To request the buffer" requests at VM the
buffer allocation for sending of transaction or large fragmented
instruction ("Window"). It has the following values of fields:
REQ_BUF。 「バッファを要求する」指示はVMで取引か大きい断片化している指示(「窓」)を発信させるためのバッファ配分を要求します。 それには、分野の以下の値があります:
OPCODE = 24
ASK = 1
PCK = b01/11
CHN = 0
EXT = 0/1
OPR_LENGTH = 1
Operands:
4 octets: The buffer required size in octets. The value is
equal to the total size of all instructions of the
chain, including the size of the subordinated chains.
0 1 24OPCODE=ASK=PCK=b01/11 CHN=EXTは1 0/1OPR_LENGTH=Operandsと等しいです: 4つの八重奏: バッファは八重奏におけるサイズを必要としました。 値はチェーンのすべての指示の総サイズと等しいです、下位に置いているチェーンのサイズを含んでいて。
The instruction is formed under the initiative of the protocol and it uses the instruction RSP_P as acknowledgement. However, on the reception side the buffer is allocated at VM level, as VM has the most complete information about the task. The interface between UMSP and VM must give possibility of asynchronous request of such buffer.
指示はプロトコルのイニシアチブの下で形成されます、そして、それは承認として指示RSP_Pを使用します。 しかしながら、レセプション側では、VMレベルでバッファを割り当てます、VMにタスクの最も完全な情報があるとき。 UMSPとVMとのインタフェースはそのようなバッファに関する非同期要求の可能性を与えなければなりません。
The instruction REQ_BUF can be used irrespective of the possibility to place the chain in the buffer, allocated for session (window). It is necessary to take into account, that the negative acknowledgement can be transmitted on this instruction, but using of a "window" guarantees sending.
セッション(窓)のために割り当てられたバッファにチェーンを置く可能性の如何にかかわらず指示REQ_BUFを使用できます。 それが考慮に入れるのに必要である、否定的承認がこの指示のときに伝えられますが、「窓」を使用できるのが発信を保証します。
Bogdanov Experimental [Page 68] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[68ページ]RFC3018
The subordinated chain on reception uses the buffer of the parental chain.
レセプションの下位に置いているチェーンは親のチェーンに関するバッファを使用します。
The sequence sending will not require about the buffer allocation in difference of transaction or fragmented instruction. If the single connection TCP is used for sending, the sequence buffering is not necessary. If the multiple connections TCP with multiplexing are used, the sequence requires buffering for the disorder instructions. In this case, it is necessary to use the buffer, allocated for session.
発信が取引か断片化している指示の違いにおけるバッファ配分に関して必要としない系列。 単独結合TCPが送付に使用されるなら、系列バッファリングは必要ではありません。 マルチプレクシングがある複数の接続TCPが使用されているなら、系列は、混乱指示のためにバッファリングするのを必要とします。 この場合、セッションのために割り当てられたバッファを使用するのが必要です。
Transactions, at which flag TRR = 0, always must request the sanction for sending by instruction REQ_BUF, even if they can be placed in one segment of transport layer.
どの旗のTRR=0に、取引は指示REQ_BUFで発信するための認可をいつも要求しなければならないか、トランスポート層の1つのセグメントにそれらを置くことができても。
The buffering of the fragmented instructions and transactions, at which flag TRR = 1, depends on their size:
どの旗のTRR=1に、断片化している指示と取引のバッファリングをそれらのサイズに依存するか:
o If the transaction is located in one segment of transport layer,
it is transmitted without buffering.
o If length of a chain is no more then "window", it can be
transmitted without request of the buffer of window allocation.
Thus, the place in the buffer must be reserved before the sending
begins. The sending cannot be begun, if it is not enough places
in the buffer. In this case, it is possible to wait the window
deallocation or to use the request instruction of the buffer
allocation at VM REQ_BUF.
o If length exceeds the session window size it is necessary to use
the instruction REQ_BUF.
o 取引がトランスポート層の1つのセグメントで位置しているなら、それはバッファリングなしで伝えられます。チェーンのo Ifの長さは、より多くの当時の「窓」どんな、窓の配分に関するバッファの要求なしでそれを伝えることができないということです。 したがって、発信が始まる前にバッファの場所を予約しなければなりません。 それがバッファの十分な場所でないなら発信を始めることができません。 この場合、VM REQ_BUF o Ifの長さでのバッファ配分の要求命令が指示REQ_BUFを使用するのに必要な状態でセッションウィンドウサイズを超えているのは、ウィンドウ反配分か使用への待ちに可能です。
7.5 Acknowledgement of chains
7.5 チェーンの承認
The field REQ_ID in chains of any type is established only in the first instruction and concerns to all chain. The all following instructions, including last, do not contain REQ_ID.
どんなタイプでも手かせ足かせをはめられている分野REQ_IDはすべてのチェーンへの最初の指示と関心だけに確立されます。 最終を含むすべて次の指示はREQ_IDを含んでいません。
The transport protocol used for chains sending, must inform about the end of data transfer, because it is necessary for the transmitting side to know the free size of the allocated session window on the reception side.
チェーンに使用されるトランスポート・プロトコルは、発信して、データ転送終了頃に知らせなければなりません、レセプション側の上の割り当てられたセッションウィンドウの自由なサイズを知るのが伝える側に必要であるので。
If the chain uses the allocated VM buffer (the sanction to sending REQ_BUF was requested), or the chain completely locates in transport layer segment, the protocol on the transmitting side does not trace acknowledgement.
割り当てられたVMがバッファリングするか(送付REQ_BUFへの認可は要求されました)、またはチェーンが完全に輸送で場所を見つけるチェーン用途がセグメントを層にするなら、伝える側の上のプロトコルは承認をたどりません。
Bogdanov Experimental [Page 69] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[69ページ]RFC3018
If the sequence is transmitted, the transmitting side receives the information about free place of the buffer on the reception side by acknowledgement of transport layer delivery. It can be made, as the regulated sequence instructions are transmitted VM at once after receiving and release the buffer.
系列が伝えられるなら、伝える側はレセプション側でバッファの自由な場所に関してトランスポート層配送の承認で知らせを聞きます。 それは、すぐに規制された系列指示が伝えられたVMであるので受信した後に、作られて、バッファを発表できます。
The fragmented instructions and transactions are not transmitted VM until its will be completely accepted. If session window is use, the occupation of places in the buffer can be calculated upon acknowledgement of transport layer sending. To trace free of places it is necessary to check execution acknowledgement by VM. The following algorithm of sending is used for this purpose:
それが完全に受け入れられてしまうだろうまで、断片化している指示と取引は伝えられたVMではありません。 セッションウィンドウが使用であるなら、トランスポート層発信の承認のときにバッファの場所の占領について計算できます。 場所を有でない跡に、それがVMによるチェック実行承認に必要です。 発信の以下のアルゴリズムはこのために使用されます:
o The value of field REQ_ID, which has given VM for chain sending,
is kept and it is enters the value established by the protocol
instead of it
o The new value REQ_ID is transmitted in the first instruction of
chain
o The chain completely collected in the session window on the
reception side. After linking, it is transmitted for execution on
VM. At that, the chain can continue to occupy a place in the
buffer.
o After execution, VM informs about it to the reception side
protocol.
o The protocol clears place in the allocated buffer.
o Then the protocol forms and transmits on chain acknowledgement
RSP_P, instead of RSP, as in other cases.
o The transmitting side protocol corrects size of free place in the
reception side buffer after reception of acknowledgement RSP_P.
o Then the old value REQ_ID is restored and the acknowledgement is
transmitted to VM.
o 分野REQ_の値はそれの代わりにプロトコルによって確立された値に入ります。○ 新しい値のREQ_IDはレセプション側でチェーンがセッションウィンドウに完全に集めたチェーンoの最初の指示で伝えられます。 リンクした後に、それは実行のためにVMで伝えられます。 ○ プロトコルは割り当てられたバッファ. o Thenのプロトコルがチェーン承認RSP_Pのときに形成して、伝わる場所をクリアします、RSPの代わりに、他のケースのように。チェーンは、おまけに、バッファの場所を占領し続けることができます。o After実行、VMはそれに関してレセプションサイドプロトコルに知らせます; ○ 伝わっているサイドプロトコルは承認RSP_P.o Thenのレセプションの後のレセプションサイドバッファの古い値のREQ_IDが回復して、承認がVMに伝えられる自由な場所のサイズを修正します。
7.6 Base-displacement Addressing
7.6 基底変位アドレス指定
The memory base address for the relative addressing can be established for the instructions from one chain. Thus, it is possible to use the abbreviated address memory fields in the instructions of chain. The abbreviated addresses are used, as displacement from base.
指示のために1つのチェーンから相対アドレシングのためのメモリベースアドレスを確立できます。 したがって、チェーンの指示に短縮アドレスメモリ分野を使用するのは可能です。 短縮アドレスはベースからの置換えとして使用されます。
_SET_MBASE. The extension header "To set memory base" establishes the value of base address for chain. It has the following values of fields:
__MBASEを設定してください。 「メモリベースを設定する」拡張ヘッダーはチェーンのためにベースアドレスの値を確立します。 それには、分野の以下の値があります:
HEAD_CODE = 7
HEAD_LENGTH = 2/4/8 ; Depends on address length.
HOB = 1
DATA contains:
ヘッド_コードは= 2/4/8に7のヘッド_長さと等しいです。 アドレスの長さに依存します。 1HOB=DATAが以下を含んでいます。
Bogdanov Experimental [Page 70] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[70ページ]RFC3018
4/8/16 octets: The base address.
4/8/16の八重奏: ベースアドレス。
The length of address is 3 octets, enters the name in last octets of 4-octets data field. The initial octet is set to 0. The base- displacement addressing is not used for nodes with address length 2 octets.
アドレスの長さは、3つの八重奏であり、4八重奏のデータ・フィールドの最後の八重奏に名前を入れます。 初期の八重奏は0に設定されます。 ベース置換えアドレシングはノードにアドレス長さ2の八重奏で使用されません。
The value of memory base for a sequence may change. The base must be established once in any instruction for all transaction instructions. The repeated establishment of transaction base is a mistake, which results refusal of transaction execution.
系列のためのメモリベースの値は変化するかもしれません。 一度すべての取引指示のためのどんな指示にもベースを確立しなければなりません。 取引ベースの繰り返された設立は誤りであり、どの結果が取引実行の拒否であるか。
8 Extension Headers
8 拡大ヘッダー
This section contains the description of the extension headers, which are not connected with the definite instruction. The description of the specialized extension headers describes in the appropriate sections of this document.
このセクションは拡張ヘッダーの記述を含みます。(その拡張ヘッダーは、明確な指示に接続されません)。 専門化している拡張ヘッダーの記述は適切でこのドキュメントのセクションについて説明します。
8.1 _ALIGNMENT
8.1_整列
The extension header "Alignment" (_ALIGNMENT) allows to make any extension header or field of operands multiple of 4 - 16 octets with the step of two octets. The protocol does not give any rules of use given extension header. It can be used arbitrarily. The header has the following values of fields:
「整列」(_ALIGNMENT)がオペランドのどんな拡張ヘッダーか分野も複数にさせる4歳の拡張ヘッダー--2つの八重奏のステップによる16の八重奏。 拡張ヘッダーを考えて、プロトコルはどんな規則も役に立つのに与えません。 任意にそれを使用できます。 ヘッダーには、分野の以下の値があります:
HEAD_CODE = 8
HEAD_LENGTH = 1-7 ; Depends on length of the data field.
HOB = 0
DATA contains:
2 - 14 octets: All octets of the field have the zero-value.
ヘッド_コードは= 1-7に8のヘッド_長さと等しいです。 データ・フィールドの長さに依存します。 0HOB=DATAは以下を含んでいます。 2--14の八重奏: 分野のすべての八重奏には、無値があります。
The format of the protocol instructions provides the alignment of two octets field without any additional means.
プロトコル指示の形式は追加いずれのない分野が意味する2つの八重奏の整列を提供します。
8.2 _MSG
8.2_エムエスジー
The extension header "The any message" (_MSG) allows sending the textual message in symbols ASCII. The order of this header processing at receiving can be anyone. The message can be written in a log-file, be shown on the console or be ignored. The header has the following values of fields:
拡張ヘッダー、「」 どんなメッセージ(_MSG)もシンボルASCIIにおける原文のメッセージを送らせます。 受信におけるこのヘッダー処理の注文はだれであるかもしれませんも。 メッセージをログファイルに書くか、コンソールの上に示されるか、または無視できます。 ヘッダーには、分野の以下の値があります:
HEAD_CODE = 9
HEAD_LENGTH = 1 - 127 ; Depends on data length of field.
HOB = 0
DATA contains:
ヘッド_は=9ヘッド_長さ=の1--127をコード化します。 分野のデータの長さに依存します。 0HOB=DATAは以下を含んでいます。
Bogdanov Experimental [Page 71] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[71ページ]RFC3018
2 - 254 octets: The any text of the message.
2--254の八重奏: どんなメッセージの本文。
The instruction may contain several headings _MSG.
指示は数個見出し_MSGを含むかもしれません。
8.3 _NAME
8.3_名前
The extension header "The Name" (_NAME) allows specifying the job name, name of object or name of object procedure. The header has the following values of fields:
ジョブ名を指定する物の手順の物か名前の名前を拡張ヘッダー「名前」(_NAME)は許容します。 ヘッダーには、分野の以下の値があります:
HEAD_CODE = 10
HEAD_LENGTH = 1 - 127 ; Depends on length of a field of data.
HOB = 0
DATA contains:
2 - 254 octets: The text of the name in symbols ASCII.
ヘッド_は=10ヘッド_長さ=の1--127をコード化します。 データの分野の長さに依存します。 0HOB=DATAは以下を含んでいます。 2--254の八重奏: シンボルASCIIにおける名前のテキスト。
8.4 _DATA
8.4_データ
The extension header "The Data" (_DATA) is used for data transfer in the instructions of exchange between VM, if the data cannot be placed in operands. It allows transferring up to 4 Gbytes of data in one instruction. The header has the following values of fields:
拡張ヘッダー「データ」(_DATA)はVMの間の交換の指示におけるデータ転送に使用されます、データをオペランドに置くことができないなら。 それで、1つの指示における最大4ギガバイトのデータを移します。 ヘッダーには、分野の以下の値があります:
HEAD_CODE = 11
HEAD_LENGTH = 1 - 2 147 483 647 ; Depends on length of the data
field.
HOB = 1
DATA contains:
2 - 4 294 967 294 octets : Binary data in an any format.
ヘッド_は=11ヘッド_長さ=1--2 147 483 647をコード化します。 データ・フィールドの長さに依存します。 1HOB=DATAが以下を含んでいます。 2--4 294 967 294の八重奏: どんな形式の2進のデータ。
8.5 _LIFE_TIME
_時間8.5_人生
The extension header "The lifetime" (_LIFE_TIME) contains value of time. It has the following values of fields:
「生涯」(_LIFE_タイム誌)が値を含む拡張ヘッダーは調節します。 それには、分野の以下の値があります:
HEAD_CODE = 12
HEAD_LENGTH = 1/2; Depending on length of data.
HOB = 1
DATA contains:
2/4 octets: The time in 1,024 milliseconds intervals.
ヘッド_コードは12のヘッド_長さ=1/2と等しいです。 データの長さに依存します。 1HOB=DATAが以下を含んでいます。 2/4の八重奏: 1,024ミリセカンドの間隔の時間。
The header _LIFE_TIME allows to set limiting time of sending of the instruction to VM of the addressee.
タイム誌が指示を発信させる時間を受け取り人のVMに制限しながらセットするのを許容するヘッダー_LIFE_。
Bogdanov Experimental [Page 72] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[72ページ]RFC3018
The instruction lifetime is calculated as follows:
指示寿命は以下の通り計算されます:
o On the transmitting side the time of waiting in a queue to the
transport layer is taken into account. The value of the lifetime
decreases on the waiting time value now of the transport layer
package formation.
o On the reception side the lifetime is taken into account only for
the fragmented instructions. The value of the lifetime decreases
on time of the instruction assembly value. This header is ignored
at receiving for no-fragmented instructions. Its value must be
sent to VM.
o The time of sending at the transport layer is not taken into
account. For the fragmented instructions, only the time of
sending of the first fragment is not taken into account.
o 伝える側では、トランスポート層に列を作って待つ時間が考慮に入れられます。 生涯の値は待ち時間の値でトランスポート層パッケージ構成o Onでは、寿命が連れていかれるレセプション側が断片化している指示だけを説明する現在を減少させます。 生涯の値は指示アセンブリ価値の時に減少します。 このヘッダーは断片化していない指示のために受信するのに無視されます。 値をVMに送らなければなりません。○ トランスポート層で発信する時間を考慮に入れません。 断片化している指示において、最初の断片を発信させる時間だけが考慮に入れられません。
The end of lifetime at the instruction relating to sequence finishes the sequence sending. The header _LIFE_TIME must not be used at transactions sending.
系列に関連する指示における生涯の終わりは、系列が発信し終えます。 取引発信にヘッダー_LIFE_タイム誌を使用してはいけません。
If the instruction is fragmented, the header _LIFE_TIME is sent only in the instruction NOP, containing the first fragment. This header deletes from the initial fragmented instruction. If the time is over, when the fragmented instruction part has not been transmitted yet, the stayed part of the instruction is cleared.
指示を断片化するなら、最初の断片を含んでいて、指示NOPだけでヘッダー_LIFE_タイム誌を送ります。 このヘッダーは初期から断片化している指示を削除します。 断片化している指示部分がまだ伝えられていないとき、時間が終わっているなら、指示の滞在した部分は儲けられます。
The instruction lifetime is established by the sender VM and must be sent together with data to the addressee VM. If the time of life expires, the instruction is rejected and the negative response (if ASK = 1) is sent to it. If ASK = 0, the response is not sent.
指示生涯を送付者VMが確立して、データと共に受け取り人VMに送らなければなりません。 年齢が期限が切れるなら、指示を拒絶します、そして、否定応答(ASK=1であるなら)をそれに送ります。 ASK=0であるなら、応答は送られません。
The header _LIFE_TIME may be used in the multimedia systems and in the real time systems. The protocol may raise the priority of sending for data with coming to the end lifetime.
ヘッダー_LIFE_タイム誌はマルチメディア・システムとリアルタイムシステムで使用されるかもしれません。プロトコルがデータのために意識を取り戻すと共に発信する優先権を上げるかもしれない、生涯を終わらせてください。
9 Search of resources
9 リソースの検索
Virtual Machines are the identified resources of the protocol. The VM standardization is not function of UMSP. The protocol gives transparent environment for transportation of the code and data of any type.
仮想のMachinesはプロトコルの特定されたリソースです。 VM標準化はUMSPの機能ではありません。 プロトコルはコードの輸送とどんなタイプに関するデータのためにも透明性のある環境を与えます。
For VM, connected to the protocol, the following values are established:
プロトコルに接続されたVMに関しては、以下の値は確立されます:
o The VM type. The range of values 1 - 65534. o The VM version. The range of values 1 - 65534.
o VMはタイプします。 値1の範囲--65534o VMバージョン。 値1--65534の範囲。
Bogdanov Experimental [Page 73] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[73ページ]RFC3018
The protocol requires obligatory compatibility from bottom-up for VM of one type and different numbers of the versions (VM with larger number of version must be able to execute the VM code with any smaller number of version).
プロトコルは1つのタイプのVMとバージョンのボトムアップと異なった数のために義務的な互換性を必要とします(より多くのバージョンがあるVMはどんなより少ない数のバージョンでもVMコードを実行できなければなりません)。
Numbers of VM types are broken on the following ranges:
VMタイプの数は以下の範囲で壊れています:
1 - 1023 Assigned for standard VM
1024 - 49151 Assigned for registered VM of the users
49152 - 65534 Free (defined for dynamic and/or private VM)
1--1023は標準のVM1024(ユーザ49152の登録されたVMのための49151Assigned)のために65534Freeを割り当てました。(ダイナミックな、そして/または、個人的なVMのために、定義されます)
Numbers of types and versions %x0000 and %xFFFF are reserved by the protocol.
バージョンのタイプの数、%x0000、および%xFFFFはプロトコルによって予約されます。
Several VM of different types may be united in a group. All VM, included in a group, must work in the common space of local memory and have the common subsystem of the jobs control. It means, that if the same 128-bit address is met in anyone VM code for one task, it must specify one physical cell of memory. The performance of the specified conditions allows executing multivendor user code (containing procedures for different VM) on one node. All VM, included in a group, must have the different types. The group can include no more than 65534 VM. One number of group on different nodes may identify groups with different structure VM.
異なったタイプの数個VMはグループで結合するかもしれません。 グループに含まれていたすべてのVMがローカルの記憶の共用面積で働いていて、仕事のコントロールの一般的なサブシステムを持たなければなりません。 それはそれが同じ128ビット・アドレスであるならVMが1つのタスクのためにコード化するだれでも会われて、メモリの1つの物理電池を指定しなければならないことを意味します。 指定された状態の性能で、1つのノードの上で「マルチ-ベンダー」ユーザコードを実行します(異なったVMのための手順を含んでいます)。 グループに含まれていたすべてのVMが異なったタイプがいなければなりません。 グループは65534未満VMを含むことができます。 異なったノードの上の1つの数のグループは異なった構造VMとグループを同一視するかもしれません。
To each group VM on the node the code of group of 2 octets length is assigned. So long as the node has even one session connection, the codes of groups must not change. It is recommended to change the code of group only at reconfiguration of the node. The group VM is identified, as well as one VM. Thus, the type VM is set to 0, and the number of group is assigned to VM version.
ノードの上のそれぞれのグループVMに、2八重奏の長さのグループのコードは割り当てられます。 ノードに1つのセッション接続さえある限り、グループのコードは変化してはいけません。 単にノードの再構成でグループのコードを変えるのはお勧めです。 グループVMは1VMと同様に特定されます。 したがって、タイプVMは0に用意ができています、そして、グループの数はVMバージョンに割り当てられます。
The support of association VM in groups is optional requirement of the protocol. The multivendor user code can be executed, even if the association in groups is not provided. For this purpose, the procedures containing a different type of a code must be executed on different nodes.
グループにおける、協会VMのサポートはプロトコルの任意の要件です。 グループにおける協会が提供されないでも、「マルチ-ベンダー」ユーザコードを実行できます。 このために、異なったノードの上でコードの異なったタイプを含む手順を実行しなければなりません。
UMSP gives the instructions of search of the VM, which allow defining, what VM and the groups VM are connected at the given moment to the protocol on the definite node.
UMSPは与えられた瞬間に明確なノードの上のプロトコルに関連していた状態でVMとグループVMが定義、ものであることを許容するVMの検索の指示を与えます。
The instructions of search of the VM can be sent upon TCP or UDP. The broadcasting dispatch can be used. The node can independently notify about VM, available on it, for example at start, or to respond on others VM requests. The answerback instructions must be sent under the same protocol, on which the request was received.
VMの検索の指示をTCPかUDPに送ることができます。 放送発信を使用できます。 または、ノードはVMに関して独自に通知できます、それで利用可能です、例えば、始めで他のものVM要求のときに反応するために。 要求が受け取られたのと同じプロトコルの下でアンサーバック指示を送らなければなりません。
Bogdanov Experimental [Page 74] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[74ページ]RFC3018
VM from ranges of numbers 49152 - 65534 or any group VM may be identified on names. VM with numbers 1 - 49151 must not have names at a layer of the instructions UMSP.
No.49152の範囲からのVM--65534かどんなグループVMも名前で特定されるかもしれません。 1--49151が持ってはいけない数があるVMは指示の層でUMSPを命名します。
9.1 VM_REQ
9.1 VM_REQ
The instruction "To request the VM" (VM_REQ) allows finding out VM, connected on the remote node. The instruction has the following values of fields:
指示「VMを要求する」(VM_REQ)は遠隔ノードで接続されたVMを見つけさせます。 指示には、分野の以下の値があります:
OPCODE = 25
PCK = %b00
CHN = 0
ASK = 0/1
EXT = 0/1
OPR_LENGTH = 0 - 65534 ; Depending on quantity VM in operands.
Operands:
2 octets: The type required VM. The value 0 is not allowed.
2 octets: The version required VM. The value 0 is not allowed.
The value %xFFFF requests the most senior version.
.
.
.
25OPCODE=PCK=%b00 CHN=0は=0/1OPR_長さ=の0--65534を=0/1EXTに尋ねます。 オペランドで量のVMによります。 オペランド: 2つの八重奏: タイプはVMを必要としました。 値0は許容されていません。 2つの八重奏: バージョンはVMを必要としました。 値0は許容されていません。 値の%xFFFFは最も年上のバージョンを要求します。 . . .
2 octets: The type required VM.
2 octets: The version required VM.
The optional extension header:
_NAME - This header contains the name of required VM or VM
group.
2つの八重奏: タイプはVMを必要としました。 2つの八重奏: バージョンはVMを必要としました。 任意の拡張ヘッダー: _NAME--このヘッダーが必要なVMという名前を含んでいるか、またはVMは分類します。
The instruction without operands is used for request of all types VM, connected on the node. The instruction with one VM in operands requests the information on one VM. If it is contained several VM in operands, the group VM containing all specified VM is requested. The type and version in list VM must be indexed on increase.
オペランドのない指示はVMの、そして、ノードで関連しているすべてのタイプの要求に使用されます。 1VMがオペランドにある指示は1VMの情報を要求します。 それがオペランドの含まれた数個VMであるなら、すべての指定されたVMを含むグループVMが要求されます。 増加のときにリストVMのタイプとバージョンに索引をつけなければなりません。
To request VM, used at work without session connection, the VM type and VM version must have the value %xFFFF.
セッション接続なしで仕事に使用されるVMを要求するために、VMタイプとVMバージョンには値の%xFFFFがなければなりません。
The header _NAME is not connected with value of operands. For it, the separate answer must be transmitted.
ヘッダー_NAMEはオペランドの値に接続されません。 それに関しては、別々の答えを伝えなければなりません。
9.2 VM_NOTIF
9.2 VM_NOTIF
The instruction "To notify about VM" (VM_NOTIF) is used for the notification of one VM or one VM group attached on the node. The instruction has the following values of fields:
「VMに関して通知する」指示(VM_NOTIF)はノードで添付された1VMか1つのVMグループの通知に使用されます。 指示には、分野の以下の値があります:
Bogdanov Experimental [Page 75] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[75ページ]RFC3018
OPCODE = 26
PCK = %b00
CHN = 0
ASK = 0/1
EXT = 0/1
OPR_LENGTH = 1 - 65534 ; Depending on quantity VM in operands.
Operands:
2 octets: The used transport protocol. The following values of
this field are definite:
x0100 - Single TCP connection through the port 2110.
x0101 - Multiple TCP connection through the port 2110.
x0102 - Single TCP connection through ports 2110 and UDP
through ports on receiving 2110.
x0103 - Multiple TCP connection through ports 2110 and UDP
through port on receiving 2110.
The port 2110 must be opened on the one side or both side at
each TCP connection.
2 octets: Reserved. This field must not be analyzed by the
protocol during the receiving in the current
realization of the protocol. It must be set to 0 at
sending.
2 octets: The type VM.
2 octets: The version VM.
26OPCODE=PCK=%b00 CHN=0は=0/1OPR_長さ=の1--65534を=0/1EXTに尋ねます。 オペランドで量のVMによります。 オペランド: 2つの八重奏: 中古のトランスポート・プロトコル。 この分野の以下の値は明確です: x0100--ポート2110x0101を通したTCP接続を選抜してください--2110x0102--ポート2110を通した単独のTCP接続と2110x0103を受けるところのポートを通したUDP--ポートのポート2110を通した複数のTCP接続と2110を受け取るところのポートを通したUDPを通した複数のTCP接続。 ポート2110は、半面の上で開かれなければならないか、またはそれぞれのTCP接続のときにともに面がなければなりません。 2つの八重奏: 予約にされる。 この分野はプロトコルの現在の実現における受信の間、プロトコルによって分析されてはいけません。 それは発信における0へのセットであるに違いありません。 2つの八重奏: タイプVM。 2つの八重奏: バージョンVM。
.
.
.
. . .
2 octets: The type VM.
2 octets: The version VM.
2つの八重奏: タイプVM。 2つの八重奏: バージョンVM。
The optional extension header:
_NAME - This header contains the name by separate VM or group VM
from operands of the instruction.
任意の拡張ヘッダー: _NAME--このヘッダーは指示のオペランドからの別々のVMかグループVMで名前を含みます。
It is necessary to generate several instructions, if it is required to inform about several VM or groups. It is necessary to form the separate instructions for each protocol, if the node provides several transport protocols.
それがいくつかのVMかグループに関して知らせるのに必要であるなら、いくつかの指示を生成するのが必要です。 ノードがいくつかのトランスポート・プロトコルを備えるなら、各プロトコルのための別々の指示を形成するのが必要です。
If the instruction is used for the response to VM_REQ request, it can contain ASK = 1 and REQ_ID, established in value from the instruction of request. If the VM group was requested, the instruction must contain several VM. First VM must have the type set to 0 and the version must contain the number of group. Others VM must define structure of group. The type and version in VM list must be indexed on increase.
指示がREQが要求するVM_への応答に使用されるなら、ASK=1とREQ_IDを含むことができます、要求の指示によって、値では、確立しています。 VMグループが要求されたなら、指示は数個VMを含まなければなりません。 まず最初に、VMはタイプを0に用意ができさせなければなりません、そして、バージョンはグループの数を含まなければなりません。 他のものVMはグループの構造を定義しなければなりません。 増加のときにVMリストのタイプとバージョンに索引をつけなければなりません。
Bogdanov Experimental [Page 76] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[76ページ]RFC3018
The protocols, contained in the instruction VM_NOTIF, may differ from the protocol, through which this instruction is transferred.
指示VM_NOTIFに含まれたプロトコルはプロトコルと異なるかもしれません。そこでは、この指示がわたっています。
10 Security Considerations
10 セキュリティ問題
The present document contains the description of the functions, minimally necessary for the realization of the declared task - immediate access to memory of the remote node. To reduce initial complexity of the protocol, the decision of safety questions is not included in the document. All reasons of the given unit are the recommendations to the further expansion of the protocol.
現在のドキュメントは機能の記述を含んでいます、宣言しているタスクの実現に最少量で必要です--遠隔ノードに関するメモリへの即座のアクセス。 プロトコルの初期の複雑さを減少させるために、安全質問の決定はドキュメントに含まれていません。 与えられたユニットのすべての理由がプロトコルの一層の拡張への推薦です。
For the description three nodes are used - node A and node B are exchanges the data. The node G is JCP.
記述において、3つのノードが使用されています--ノードAとノードBは交換です。データ。 ノードGはJCPです。
Protection against sniffing, spoofing and hijacking:
スニフィングに対する保護、スプーフィング、およびハイジャック:
(1) The means specifies in TCP/IP can be used.
(2) There is a possibility to create chains with the special
processing. To create such chain, it is necessary to transfer
the extension header, determining the special processing, in
the first instruction of the chain. The instructions of chain
can be encapsulated in the NOP instructions. The algorithms
of the control of instructions sequence integrity or the
encryption can be realized in such a way.
手段がTCP/IPで指定する(1)は使用できます。 (2) 特別な処理でチェーンを創設する可能性があります。 そのようなチェーンを創設するのに、拡張ヘッダーを移すのが必要です、特別な処理を決定して、チェーンの最初の指示で。 NOP指示でチェーンの指示をカプセル化することができます。 そのような方法で指示系列保全のコントロールのアルゴリズムか暗号化を実現できます。
Protection against the man-in-the-middle:
中央の男性に対する保護:
The protection is based on the fact, that the routes between nodes
A - B, A - G and G - B is not crossed. Such scheme allows
organizing the additional managing dataflow, allowing revealing
such type of attack. If the specified routes pass through one
gateway, this protection is less effective.
保護はノードA--B、A--G、およびG--Bの間のルートが交差していないという事実に基づいています。 そのような体系で、そのようなタイプの攻撃を明らかにするのを許容して、追加管理データフローを組織化します。 指定されたルートが1門を通り抜けるなら、この保護はそれほど有効ではありません。
Authentication:
認証:
The protocol working is based on a principle of the centralized
control. It allows using several schemes of authentication. The
parameters of authentication are sent in the extension headers.
The establishment of session connection can contain up to eight
handshakes. It also raises flexibility at a choice of
authentication algorithm. The realization of authentication is
possible between three pairs nodes A - B, A - G and G - B. All
pairs can be used in any combination. The node G can be specially
allocated for realization of authentication.
プロトコルの働きは集中制御の原則に基づいています。 それで、認証のいくつかの体系を使用します。 拡張ヘッダーで認証のパラメタを送ります。 セッション接続の設立は最大8つの握手を含むことができます。 また、それは認証アルゴリズムの選択に柔軟性を上げます。 認証の実現は3組のノードA--A--B、G、およびGの間で可能です--どんな組み合わせにもB.All組を使用できます。 特に、認証の実現のためにノードGを割り当てることができます。
Bogdanov Experimental [Page 77] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[77ページ]RFC3018
Protection against denial-of-service:
サービスの否定に対する保護:
The instructions of the protocol have definite computing loading.
It allows projecting the node so, that it can process the
instructions with such speed, with what they are accepted from the
network. A possible reason of an overload is the instructions
JUMP and CALL. VM must solve this problem. It has the complete
information about the user task and can make a decision on the
amount of allocated resources. The decision of a problem is the
failure in service for low-priority traffic.
プロトコルの指示には、明確なコンピューティングローディングがあります。 したがって、それでノードを映し出して、それはそれです。そのような速度で指示を処理できます、それらがネットワークから受け入れられるものであることで。 オーバーロードの可能な理由は、指示のJUMPとCALLです。 VMはこの問題を解決しなければなりません。 それは、ユーザタスクに関して完全な情報を持って、割り当てられたリソースの量で決定できます。 問題の決定は低い優先度トラフィックに、使用中の失敗です。
Protection at the applications architecture level:
アプリケーションアーキテクチャレベルにおける保護:
The protocol allows creating the applications of any architecture.
It is possible due to an asymmetric structure of connection. It
is possible to allocate three basic groups:
プロトコルで、どんなアーキテクチャの応用も作成します。 それは接続の非対称の構造のために可能です。 3つの基本的なグループを割り当てるのは可能です:
(1) The client who is carrying out terminal functions and
client/server technologies. The security of such systems is
completely defined by the server. Such architecture is
represented most protected.
(2) The client, loading an active code from the server. It is the
least protected architecture, from the client point of view.
On the server side, there are no special requirements upon
protection.
(3) The client, who is executing his code on the server. This
architecture is safe for the client. It is necessary to
strengthen the protection on the server. The functionalities
of such architecture do not differ from architecture of
loading by the client of an active code. If ones take into
account, that the server is the specially allocated computer,
the given architecture is optimum.
(1) 端末の機能とクライアント/サーバ技術を行っているクライアント。 そのようなシステムのセキュリティはサーバによって完全に定義されます。そのようなアーキテクチャは最も保護されていた状態で表されます。 (2) クライアント、サーバからアクティブなコードをロードして. それは最も保護されなかったアーキテクチャです、クライアント観点から。 サーバ側には、保護に関するどんな特別な要件もありません。 (3) クライアント。(そのクライアントはサーバの彼のコードを実行して、クライアントにとって. このアーキテクチャが安全であるということです)。 サーバにおける保護を強化するのが必要です。そのようなアーキテクチャの機能性はアクティブなコードのクライアントでロードするアーキテクチャと異なっていません。 ものがアカウントを連れていくなら、サーバが特に、割り当てられたコンピュータ、与えられたアーキテクチャであることは最適です。
All given technologies may be used simultaneously in any
combination.
すべての与えられた技術が同時に、どんな組み合わせにも使用されるかもしれません。
11 Used Abbreviations
11 中古の略語
API Application Programming Interface.
APIアプリケーションプログラミングインターフェース。
CTID JCP assigned the Control Task IDentifier to each task of the
job. Its length is equal to length of the local address
memory on the node JCP.
CTID JCPは仕事に関する各タスクにControl Task IDentifierを割り当てました。 長さはノードJCPに関するローカルアドレスメモリの長さと等しいです。
Bogdanov Experimental [Page 78] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[78ページ]RFC3018
GJID Globally Job IDentifier is assigned for the each job. GJID is
defined on the JCP node. It has the same format, as the 128 -
bit address of node JCP memory has. The address of local
memory is replaced on CTID of the first (initial) task of the
job in it.
GJID Globally Job IDentifierはそれぞれ賃仕事のために割り当てられます。 GJIDはJCPノードの上で定義されます。 それには、128と同じ形式があります--JCPメモリが持っているノードのビット・アドレス。 それで仕事の最初の(初期)のタスクのCTIDでローカルの記憶のアドレスを取り替えます。
GTID Globally Task IDentifier is assigned to each task. GTID has
the same format, as the 128 - bit address of node memory has.
The address of local memory is replaced on LTID in it.
GTID Globally Task IDentifierは各タスクに割り当てられます。 GTIDには、128と同じ形式があります--メモリが持っているノードのビット・アドレス。 それでLTIDでローカルの記憶のアドレスを取り替えます。
JCP Job Control Point. This node will control the job.
JCPジョブ制御ポイント。 このノードは仕事を制御するでしょう。
LTID Locally Task IDentifier is assigned to each active task on the
node. LTID length is equal to the local memory address length
defined for the node.
LTID Locally Task IDentifierはノードに関する各アクティブ・タスクに割り当てられます。 LTIDの長さはノードのために定義された地方のメモリアドレスの長さと等しいです。
VM Virtual Machine.
VM仮想計算機。
12 References
12の参照箇所
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[1] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、RFC2119、1997年3月。
[3] Crocker, D., and P. Overell. "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[3] クロッカー、D.、およびP.Overell。 「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[4] Postel, J., "Transmission Control Protocol - DARPA Internet
Program Protocol Specification", STD 7, RFC 793, September 1981.
[4] ポステル、J.、「転送管理は議定書を作ります--DARPAインターネットはプロトコル仕様をプログラムする」STD7、RFC793、1981年9月。
[5] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
1980.
[5] ポステル、J.、「ユーザー・データグラム・プロトコル」、STD6、RFC768、1980年8月。
[6] Srinivasan, R., "RPC: Remote Procedure Call Protocol
Specification Version 2", RFC 1831, August 1995.
[6]Srinivasan、R.、「RPC:」 遠隔手続き呼び出しプロトコル仕様バージョン2インチ、RFC1831、1995年8月。
Bogdanov Experimental [Page 79] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[79ページ]RFC3018
13 Author's Address
13作者のアドレス
Alexander Y. Bogdanov
アレクサンダーY.Bogdanov
NKO "ORS" 22, Smolnaya St. Moscow, Russia 125445 RU
NKO「ORS」22、Smolnaya通りモスクワ、ロシア125445Ru
Phone: +7 901 732 9760 EMail: a_bogdanov@iname.ru
以下に電話をしてください。 +7 9760年の901 732メール: a_bogdanov@iname.ru
Bogdanov Experimental [Page 80] RFC 3018 Unified Memory Space Protocol December 2000
メモリスペースプロトコル2000年12月に統一されたBogdanovの実験的な[80ページ]RFC3018
14 Full Copyright Statement
14 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Bogdanov Experimental [Page 81]
Bogdanov実験的です。[81ページ]
一覧
スポンサーリンク
