Network Working Group A. Bogdanov
Request for Comments: 3018 NKO "ORS"
Category: Experimental December 2000
Unified Memory Space Protocol Specification
Status of this 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.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
This document specifies Unified Memory Space Protocol (UMSP), which gives a capability of immediate access to memory of the remote nodes.
この文書では、リモートノードのメモリに直接アクセスする機能を提供するユニファイド・メモリ・スペースプロトコル（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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC-2119に記載されるように解釈される[2]。
The following syntax specification uses the augmented Backus-Naur Form (ABNF) as described in RFC-2234 [3].
以下の構文仕様は、RFC-2234に記載されているように拡張バッカス・ナウアフォーム（ABNF）を使用する[3]。
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
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
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
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多数のコンピュータのリソースを計算します。
2 The UMSP Model
2 UMSPモデル
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 |
+------+--------------+--------------------+----------------+
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 |
+-----+-----+-----+-----+-----+-----+-----+-----+
ADDR_LENGTH
ADDR_LENGTH
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
NET_TYPE
2 bits. The network type. This field specifies a type of network, in which the node is.
2ビット。ネットワークタイプ。このフィールドは、ノードがある中で、ネットワークの種類を指定します。
ADDR_CODE
ADDR_CODE
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のそれらに充当長さが定義されています。
%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:
見出しの三つのフィールドの値の組み合わせは、アドレス形式番号と命名されます。これらのフィールドは、明確にノードが位置するネットワークを定義します。次のようにフォーマット番号が書いています：
N <ADDR_LENGTH> - <NET_TYPE> - <ADDR_CODE>
N <ADDR_LENGTH> - <NET_TYPE> - <ADDR_CODE>
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.
例えば、N 4-0-2は、長さ32ビットのノードのネットワークアドレス4つのオクテットの長さとメモリアドレスにアドレスを定義します。そのようなアドレス形式のネットワークタイプ0を提示文書内のネットワークはIPv4のために定義されます。ネットワークタイプがゼロに等しい場合、アドレスフォーマット番号の書き込み中に見逃されてもよいです。例えば、フォーマットN 4-0-2と4-2は等価です。両方のフィールドNET_TYPEとADDR_CODEがゼロに設定されている場合は、それらを省略することができます。このように、フォーマット番号が一桁として書き込みます。
One or several address format numbers must be assigned for each global network, included in unified system.
一つまたは複数のアドレス形式番号が統一されたシステムに含まれ、各グローバルネットワークに割り当てる必要があります。
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
NODE_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アドレスをサポートのサブセットを整理する必要があります。
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ビットのアドレスは、一つのフィールドです。ユーザーコードは、アドレス指定されたメモリの物理的な配置について知ることができません。
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は、独自のアドレス空間を持っているとして、それはいくつかのグローバルなネットワークを統合することができます。ノードは、内部ローカルネットワークか、ネットワーク通信によってノードに接続された劣後のアドレス可能装置を有することができます。アドレスのフォーマット番号によって任意のノードは、このアドレスのルーティングのためのゲートウェイが応答を定義する機会を有していなければなりません。
Computing model is three-layer:
コンピューティングモデルは、三層です：
(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.
ジョブは、ユーザーのアプリケーションに対応します。ジョブが配布されると同時に、多くのノード上で実行することができます。ジョブ制御ジョブ制御ポイント（JCP）と名付けられたノードから、一元化を実施しています。一つJCPは、いくつかのジョブを制御することができます。 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.
適切なユーザーアプリケーションが終了するとジョブは、終了します。仕事の終わりには、すべてのノードでこのジョブのすべてのタスクが終了します。
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ビットのアドレス空間を持ちます。アドレス空間がセグメント化されています。セグメントは、一つのノードのローカルメモリです。また、プロトコルは、オブジェクトを操作することができます。オブジェクトは、ノードの別々の連想メモリです。
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ビットのグローバルジョブ識別子（GJID）は、プロトコルによって定義されます。それは、仕事を制御する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は、一つまたは異なるノードに配置することができます。つのジョブの状況において一つのノード上で実行することができる不均一なコードのように一つのノード上のグループ内の異なるVMタイプの関連付けのメカニズムは、規定されています。グループは、（メモリ制御の一般的なサブシステムを持っている）共通のメモリ空間で動作する必要があり、グループに組み込まれ、セクション9 VMに詳細に記載されています。
System structure, based on using Virtual Machines, is given in the following figure:
システム構成は、仮想マシンを使用することに基づいて、次の図に示されています。
Node 1 Node 2
-------- --------
+--------------------+ +--------------------+
| User Application 1 | | User Application 1 |
+-----------------------+ +-----------------------+
| User Application N | | User Application 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 |
| +-----+ |
+-------------------------+
Figure 1. Structure of the system based on use VM.
使用VMに基づいたシステムの1構成図。
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.
一つまたは複数の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を実現する必要があります。いくつかのVMは1つのノード上で動作する場合、彼らは共通のメモリ空間を有していてもよく、または完全に分離することがあります。
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命令は、受信機と送信者のネットワークアドレスが含まれていません。プロトコルは、一つのアドレスUMSPは、一つのトランスポート層アドレスに対応しなければならないことを要求します。したがって、メモリの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.
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 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は、独立したプログラムであり、プロトコルとの相互作用は、それが他のノードに関連する、128ビットのアドレスで命令を実行する場合にのみ必要です。 VMは、複数のユーザーのタスクを実行することができます。各タスクは、コントロールの複数のスレッドを含めることができます。 VMはUMSPプロトコルの一つまたは複数の命令に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つのジョブのみとの関係です。同時に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.
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命令の長さは、トランスポート層のセグメントの長さに依存しません。セグメンテーションは、長い命令の転送のために提供されます。見出しの圧縮の可能性のある一つのセグメントにおけるショート命令のパッキングは、その転送のために使用されます。ワークセグメントに必要な最小限の大きさは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.
オペランドは、命令のデータが含まれています。
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.
大文字記号で名前を入力して識別子が与えられているすべての命令と拡張ヘッダ。命令の識別子は文字で始まります。拡張ヘッダの識別子は下線記号で始まります。
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 +
| |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
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
255は予約VM 0、224、との間の交換の指示223 - 127 128予約1 - - 113 112管理命令
ASK
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ビット。ヘッダ圧縮属性。これらのビットは、一つの接続TCP上または1つのパッケージUDPでいくつかの命令を送信するための送信指示ヘッダを梱包するために使用されています。これらのビットの使用は二つが高い確率で、1つのセッションの接続、または1本の鎖に承継命令の懸念で、次のことを前提としています。 PCKビットは、次のいずれかの値を持っています：
%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は存在しません。現在の命令のINSTR_NUMBER値は、前の命令の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つのセッションの接続に送信され、一つの仕事の指示について、チェーンで統一することができます。 SEQ = 1、命令はチェーンで接続されている場合チェーン部7により詳細に考慮され、フィールドがあるCHAIN_NUMBERとINSTR_NUMBERそれを（PCKは％B10に設定されていない場合）。ビットCHN = 0の場合、命令はチェーンに接続されておらず、それにはフィールドCHAIN_NUMBERとINSTR_NUMBERはありません。
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_LENGTH
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_LENGTH_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_EXTのみならOPR_LENGTH =％のB111、ヘッダ内に存在します。 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）オペランドの長さが24個の以上のオクテットでなければならない場合（2）4つのオクテットのフィールド位置合わせを行うことは2つのオクテットのヘッダの圧縮よりも、より効果的である場合。
CHAIN_NUMBER
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_NUMBER
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が予約されています。
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_EXTフィールドの使用している場合OPR_LENGTH =％のB111を意味しています。 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.
4つのオクテット - ショート形式で最小のヘッダ長は、拡張形式の2つのオクテットです。最大ヘッダ長は16オクテットです。
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つの命令の長さ以上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 /
/ /
| |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
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
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ビット。データフィールドに16ビット・ワードの数。 HXT = 0の場合、これは独立した分野です。 HXT = 1の場合、それは完全な長さフィールドのシニアビットです。
HEAD_LENGTH_EXT
HEAD_LENGTH_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つのオクテット。データフィールドに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
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
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に参加します。これは、ヘッダコードのシニアビットです。
HEAD_CODE_EXT
HEAD_CODE_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
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.
拡張ヘッダのデータフィールド。 4 * 10 ^ 9オクテット - HXT = 1は、長さが0の場合、254オクテット - HXT = 0の場合、フィールドの長さは0です。このフィールドのフォーマットは、ヘッダコードの各値に対して個別に定義されています。
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は、拡張ヘッダフォーマットの説明でさらにテキストで使用されています。それはフィールドHEAD_LENGTH + HEAD_LENGTH_EXTとHEAD_CODE + HEAD_CODE_EXTの使用を前提とし、コード0のHXT = 1ヘッダ場合 - 30がショートに送信することができる（HXT = 0）および拡張（HXT = 1）の形式です。
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又はOPR_LENGTH_EXTに示され、それは4つのオクテットの倍数です。必要に応じて、1 - 3ゼロ値のオクテットは、フィールドの終わりにパディングされます。オペランドの最大長さは262140オクテットです。命令が長いデータが含まれている必要がある場合は拡張ヘッダは、使用されています。
The format of the operands field is defined separately for each instruction.
オペランドフィールドのフォーマットは、命令ごとに別々に定義されています。
The following address format numbers are definite for nodes, immediately connected to the global IPv4 network:
次のアドレス形式番号は直ちにグローバルIPv4ネットワークに接続され、ノードのための明確です。
N 4-0-0 (4) N 4-0-1 (4-1) N 4-0-2 (4-2)
N 4-0-0（4）N 4-0-1（4-1）N 4-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 |無料| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + 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ネットワーク内のノードアドレスを設定します。
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およびUDP 2110を割り当てています。 TCPノード、任意のポートを使用することができ、接続口、またはUDPノードを仮調印送信パッケージを行います。多重化して複数のTCPコネクションを使用すると想定しています。
4 Response of the Instructions
取扱説明書の4レスポンス
The protocol instructions are divided into two types:
プロトコル命令は二つのタイプに分けられます。
(1) The management instructions transmitted on UMSP layer (OPCODE = 1 - 112). (2) The instructions of the exchange between VM (OPCODE = 128 - 223).
（1）管理命令はUMSP層（ - 112 OPCODE = 1）に送信されます。 （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の識別子のフィールドは、第一のタイプの命令でプロトコルによって形成され、それは第二のタイプの手順については、VMによって形成されます。 Oプロトコルは、フィールドREQ_IDを分析し、第一のタイプの応答指示を受信した後、先に送信命令と比較しなければなりません。 Oプロトコルは、第二のタイプの応答指示を受信した後、フィールド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.
応答命令は、ヘッダフィールドのREQ_IDを持っていること、それが意味する1に等しいASKフィールドを有しています。確認された命令から取られた値は、フィールド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.
明確VMに接続されているセッション識別子SESSION_ID、O。要求識別子REQ_ID O。
"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 = 1分の129;対応RSP / RSP_PにASK = 1つのPCK =％B01 / 11 EXT = 0/1 CHN = 0 OPR_LENGTH = 0/1 SESSION_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が送信されたものを命令に定義することができない場合は、何もアクションが実行されます。
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_CANCEL）「送信が解除され、」命令を提供します。この命令は、次のフィールドの値があります。
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.
OPCODE = 2 = 0 PCK =％B01 / 10月11日EXT = 0/1 CHN = 1 OPR_LENGTH = 1 SESSION_IDをASK - 値はキャンセルチェーンから取られます。 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_CANCELは、部分的に送信されるトランザクションまたは断片化された命令をキャンセルするために使用されます。 SND_CANCEL命令を受けた時、チェーン内のすべての以前に受信したデータが拒否されています。
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.
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.
= 1 OPCODEと指示 - 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拠点。その理由は、ポインタ制御は、分散システムでは明らかにできないことです。任意のタスクは、いつでも終了させることができるか、ノードが再ロードすることができます。ジョブが働く上での他のすべてのノード、分散システムでの通知を保証する方法はありません。ジョブが存在し続けている - 仕事に関するタスクが再び同じノード上で開始することができます。このタスクは、新しい動的なリソースを割り当てることができます。再び割り当てられたリソースのアドレスは、タスクの再起動前に、ノードに存在していたリソースのアドレスと交配することができます。古いポインタは他のノードで保持することができます。これは、正式に正しいポインタかもしれないが、彼らは実際には他のオブジェクトを指定します。アプリケーションの制御不能な作業は、このような状況の結果であり得ます。
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それは正確には、タスクが完了したノードを、定義することができます。ノード上のタスクがジョブの終了前に終了している場合は、O、ジョブが実行されているすべてのノードは、それが通知されます。すべてのノードが最初のタスクの終了に関するメッセージを受信する一方Oノードで繰り返しタスクの初期化は、許可されています。
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）。これは、ジョブが開始されているのと同じノードであってもよく、またはそれは別の専用のノードすることができます。基本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 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.
Oローカルタスク識別子（ltidを）は、ノード上の各アクティブ・タスクに割り当てられます。 ltidを長さは、ノードに対して定義されたローカルメモリアドレスの長さに等しいです。ノード上のすべてのltidは、時間の各瞬間にユニークな値を与える必要があります。再び開始されたタスクのために、すでに完了したタスクに以前使用し、ltidを確立することを許可されています。 O JCPは、ジョブの各タスクに制御タスク識別子（CTID）を割り当てます。その長さは、ノードJCPのローカルアドレスメモリの長さに等しいです。 JCP上のすべてのCTIDは、時間の各瞬間にユニークな値を与える必要があります。 ltidを反対として、CTID値は、いくつかの制限が選択されています。 Oグローバルタスク識別子（GTID）は、各タスクに割り当てられています。ノードメモリのビットアドレスを持っています - 128としてGTIDは、同じフォーマットを有します。ローカルメモリのアドレスは、それにltidを上に置換されます。 Oグローバルジョブ識別子（GJID）はザ・各ジョブに割り当てられています。 GJIDはJCPノード上で定義されています。ノードJCPメモリのビットアドレスを持っています - 128としては、同じフォーマットを有します。ローカルメモリのアドレスは、その中のジョブの最初の（初期）タスクの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オクテットのフィールドの説明書に書かれています。 FREEフィールドは、これらの識別子に存在しない（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_OPENを送信することにより、プロトコルはタイムアウトを使用しています。タイムアウトの値は、ノードによって割り当てられ、トランスポート層での送達の最大の時間つ以上の間隔でなければなりません。タイムアウトは、トランスポート層にキューで待機している期間に影響を与えていません。
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ジョブの初期ノードが低速または過負荷チャネルによってネットワークに接続されています。管理トラフィックを送信することは望ましくありません。 Oノードは、管理テーブルを行うためのコンピューティングの可能性を持っていません。 O詳細なノードの認証が必要です。
If the other node is chosen for JCP, the node, that initiates the job, must register the job at JCP.
他のノードはJCPのために選択された場合、ジョブを開始したノードは、JCPで仕事を登録する必要があります。
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:
OPCODE = 3 PCK =％B00 CHN = 0 ASK = 1 EXT = 0/1 OPR_LENGTH = 2/3。 ltidを長に依存します。 REQ_ID - 値は、送信側ノードのプロトコルによって割り当てられ、その後、応答して送信されます。オペランド：4つのオクテット：制御パラメータプロファイル。このフィールドの形式は次のとおりです。
bits
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
+ JOB_LIFE_TIME +
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| CMT | Reserved | VERSION |
+-----+-----+-----+-----+-----+-----+-----+-----+
| Reserved |
+-----+-----+-----+-----+-----+-----+-----+-----+
JOB_LIFE_TIME
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が含まれている必要があります。
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 - このヘッダは、ジョブの名前が含まれています。一度割り当てられ、さらに変化してはなりません。 _INACT_TIME - このヘッダは休止時間が含まれている（セクション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に記載されているように（それがあると考えられる、そのノード）がリロードしました。その後、新しいジョブの開始に制裁が送信されます。ノードが受信ltidを有する登録済みのジョブがない場合（2）は、一度に新しいジョブの開始を可能にします。
If JCP confirms the control, it will send the instruction CONTROL_CONFIRM, or else CONTROL_REJECT.
JCPは、コントロールを確認すると、それは命令CONTROL_CONFIRM、または他のCONTROL_REJECTを送信します。
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_CONFIRM）はCONTROL_REQ命令に対する肯定応答としてJCPから送信されます。 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.
OPCODE = 4 PCK =％B00 CHN = 0 = 1 ASK。命令は、対応する必要はありません。このフラグは、REQ_IDフィールドの存在を指定します。 EXT = 0/1 OPR_LENGTH = 1-4。 GJIDの長さに依存。 REQ_ID - 値が命令CONTROL_REQオペランドから取得されます：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（ローカルメモリアドレスのフィールド）があります。
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）はCONTROL_REQ命令に否定応答としてJCPから送信されます。 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.
OPCODE = 4 PCK =％B00 CHN = 0の命令が応答する必要はありません= 1. ASK。このフラグは、REQ_IDフィールドの存在を指定します。 EXT = 0/1 OPR_LENGTH = 1/2。制御パラメータプロファイルフィールドの存在に依存します。 REQ_ID - 値は命令CONTROL_REQオペランドから取得され：2つのオクテット：基本的なエラーコード。ゼロ値は使用できません。 2つのオクテット：追加のエラーコード。 4つのオクテット：制御パラメータプロファイルは（セクション5.1.1を参照）、それは、JCPによって許容されます。これはオプションのフィールドです。オプション拡張ヘッダ：_INACT_TIME - このヘッダは、休止時間（セクション5.7を参照）を含みます。 _msgは - 任意のエラー記述が含まれています。
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つのジョブのみで接続する必要があります。
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ノードから受信された場合には、制裁を要求する必要はありません。
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に、タスクをイニシャルノードから送信されます。命令は、フィールドの次の値があります。
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).
OPCODE = 6/7/8; 2/4/8オクテットの長さCTIDください。 PCK =％B00 CHN = 0 ASK = 1 EXT = 0/1 OPR_LENGTH = 2-8。 GTIDとltidをの長さに依存します。 REQ_ID - 値は、送信側ノードのプロトコルによって割り当てられ、その後、応答して送信されます。オペランド：2/4/8オクテット：タスクのCTIDは、ジョブを開始しました。それCTIDは命令SESSION_OPENから一部のGJIDです。 4-16オクテット：GTID、ノードに割り当てられているが、セッション接続をイニシャル。 GTIDは、（トランスポート層で）送信元アドレスおよび命令SESSION_OPENのフィールドltidによって形成されています。 2/4/8オクテット：ltidを、ノードに割り当てられたが、（この命令の送信者によって）タスクをイニシャル。オプション拡張ヘッダ：_INACT_TIME - このヘッダは、休止時間（セクション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に登録されています。開始を要求するノードのltidを有する（2）タスクが登録されていません。
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を送信します。
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_CONFIRM）「タスクを確認するために、」命令はTASK_REGに肯定応答としてJCPから送信されます。 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
OPCODE = 9 PCK =％B00 CHN = 0の命令が応答する必要はありません= 1. ASK。このフラグは、フィールドREQ_IDの有無を指定します。 EXT = 0/1
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_LENGTH = 1/2。 CTIDの長さに依存します。 REQ_ID - 値が命令TASK_REGから取得されます。オペランド：4/8オクテット：JCPのタスクに割り当てCTID。オプションの拡張ヘッダー：_JOB_NAME - このヘッダは、ジョブの名前が含まれています。
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）「タスクを拒否する」命令はTASK_REG命令に否定応答としてJCPから送信されます。 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.
OPCODE = 10 PCK =％B00 CHN = 0の命令が応答する必要はありません= 1. ASK。このフラグは、REQ_IDフィールドの存在を指定します。 EXT = = 1 REQ_ID 0/1 OPR_LENGTH - 値は命令CONTROL_REQオペランドから取得され：2つのオクテット：基本的なエラーコード。ゼロ値は使用できません。 2つのオクテット：追加のエラーコード。オプション拡張ヘッダ：_INACT_TIME - このヘッダは、休止時間（セクション5.7を参照）を含みます。 _msgは - 任意のエラー記述が含まれています。
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_OPENの確立の指示を受信したノードから送信されます。与えられた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の送信はオプションです。
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.
セッション接続は、一つの仕事の二つのタスク間で確立されます。接続は、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つのセッションの接続はノード上の一つのタスクに接続する必要があります。タスクは異なるノードで複数の接続を有することができます。 2つのノード間の1 GJIDを持つ唯一のセッション接続でなければなりません。
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つの接続の双方が異なるタイプの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-wayから含まれていてもよいです。
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_OPEN）は、セッション接続の開始のためのハンドシェイクの間の接続パラメータの指定のために使用されます。これは、フィールドの次の値があります。
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).
OPCODE = 12 PCK =％のB00 / 11。最初の命令（初期）でこのフィールドの値は％B00に設定されています。 ％のB11 - 後続のすべてで。 CHN = 0 = 1 EXT = 0/1 OPR_LENGTH = 6 ASK - 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によって、ノードに割り当てられた - 命令の送信者。これは、（フィールドGTIDの一部としての）命令TASK_REGに使用されます。
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.
全体的に、それは、接続の確立にSESSION_OPEN 7つのまでの命令を送信することができます。命令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: o VM type and VM version; o profiles of connection.
接続の確立中に、以下のパラメータを変更することができる：VMタイプとVMバージョンOであり;接続の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) 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.
リクエストがノードJCPから到着した場合には（1）、それが必要です：oは既存のタスクの緊急を終了するには、すべての動的なリソースがそれに属して解放します。 oは再びJCPの制裁を要求せずに作業を開始します。 oは、接続の確立を確認します。 （2）要求がJCPノードからではない到着した場合は、新しいセッション接続の確立を拒否することが必要です。既存のタスクを変更する必要はありません。
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.
OPCODE = 13 = 1つのPCK =％11 EXT = 0/1 CHN = 0 OPR_LENGTH = 0 SESSION_IDをASK - このフィールドは、命令の宛先のノードによって割り当てられるのセッション接続識別子を含みます。 REQ_ID - このフィールドは、命令の送信者によって割り当てられたセッション接続識別子が含まれています。
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
OPCODE = 14 ASK = 0 PCK =％のB11 EXT = 0/1 CHN = 0 OPR_LENGTH = 1
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 - 任意のエラー記述を含みます。
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オクテットフィールドで定義されています。 S31 - フラグは、識別子S0を持っています。識別子中の数字はビットのシリアル番号を定義しています。フラグが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 - 予約済み。交換の指示で16オクテットアドレスの使用 - 0 S6に設定されている必要があります。命令のヘッダの圧縮形式の使用（OPR_LENGTH <>％のB111）がS8許可されている - - S7命令（OPR_LENGTH =％のB111）のヘッダの伸長形の使用は、S9許容される - と拡張ヘッダーの使用最大の長さの254オクテットまでのデータフィールド。 S10 - 最大長さの4つの* 10 ^ 9オクテットのデータフィールドと拡張ヘッダの使用。 4つのオクテットワードにおけるオペランドのデータフィールドのS11-S15最大長。これらのビットは、一般的なフィールドです。オクテットの最大長さは、式の下に計算されます。
<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.
<最大長> =（+ 1 <このフィールドの値>）* 4の値が等しい％のb1111の場合、データの最大の長さは、命令フォーマットによって定義されます。 S16-S19は、これらのビットは、一般的なフィールドです。命令の名宛人から必要なプロファイルでは、このフィールドはUMSPのバージョンが含まれています。これは、値％B0001に設定されている必要があります。命令のプロフィール与えられた送信者では、このフィールドは、ジョブの優先順位が含まれています。以上が、このフィールドの値は、より優先順位です。ジョブの優先順位が使用されます。oキューでジョブの手順については、トランスポート層への送信に。トランスポート層の優先順位を送信するのセットのためのO。タスクの演算優先順位のセットについて、O。 S20 - 4つのオクテットの境界倍数を作ります。 S16 = 1の場合：（1）OPR_LENGTH =％のB111（2）それぞれの拡張ヘッダとオペランドのフィールドは、4つのオクテットの境界の倍数で始まります。 （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に設定されている場合、オブジェクトへのアクセスは、その手順により解決されます。ゼロ・セッションの命令MVRUNの使用 - S28 = 0の場合、このフラグは0 S30に設定されなければなりません。 S31 - 予約済み。 0に設定されている必要があります。
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ウェイハンドシェイクです。接続の無条件の緊急終了の手順が規定されています。これは、任意のノードが送信することができます。
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は、接続の第二の側面でみましょう。ノード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秒のタイムアウトの間に接続を使用してはなりません。応答命令以外の命令SESSION_ABENDまたは任意の他の命令は、この時間の経過後、ノードAから受信していない場合、ノードは命令SESSION_ABENDを送信し、セッション接続が閉じ考えます。
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を含め、送信されます。この場合、端の手順を中断し、セッション接続が稼働状態に変換されます。
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.
OPCODE = 15 PCK =％B01 / 11 CHN = 0 = 0 EXT = 0/1 OPR_LENGTH = 0/1 SESSION_ID ASKは、 - 宛先によって割り当てられたセッション識別子を含みます。オペランド：2つの八重奏：基本的な終了コード。 2つのオクテット：追加の終了コード。オプション拡張ヘッダ：_msg - は任意のメッセージを含んでいます。
The operands may be absent. It is equivalent to the zero exit code.
オペランドは存在しなくてもよいです。これは、ゼロの終了コードと等価です。
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.
OPCODE = 16 PCK =％B01 / 11 CHN = 0 = 0 EXT = 0/1 OPR_LENGTH = 0/1 SESSION_ID ASKは、 - 宛先によって割り当てられたセッション識別子を含みます。オペランド：2つの八重奏：基本的な終了コード。 2つのオクテット：追加の終了コード。オプション拡張ヘッダ：_msg - は任意のメッセージを含んでいます。
The operands may be absent. It is equivalent to the zero termination codes.
オペランドは存在しなくてもよいです。これは、ゼロの終了コードと同等です。
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.
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を送信する）必要があります。
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.
OPCODE = 17 PCK =％B00 CHN = 0 = 0 EXT ASK = 0/1 OPR_LENGTH = 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.
JCPに命令TASK_TERMINATEの送信後、ノードは、タスクに接続されたすべてのセッション接続の接続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は、タスクの終了についてのジョブのすべてのノードの通知のために応答します。
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.
OPCODE = 18 PCK =％B00 CHN = 0 = 0 EXT ASK = 0/1 OPR_LENGTH = 2-5。 GTIDの長さに依存します。オペランド：2つの八重奏：基本的な終了コード。 2つのオクテット：追加の終了コード。
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の受信時に、働いているノードに関するリソースへの参照をすべて削除しなければなりません。
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イニシアチブの下で完了することができます。
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.
OPCODE = 19 PCK =％B00 CHN = 0 = 0 EXT ASK = 0/1 OPR_LENGTH = 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.
JCPにJOB_COMPLETED命令を送信した後、ノードは、ジョブ接続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は、ジョブの終了についての仕事のすべてのノードの通知のために応答します。
The instruction TASK_TERMINATE_INFO may be transferred under the initiative JCP, if node of the task has abnormal terminated work.
タスクのノードが異常終了作業を有する場合、命令TASK_TERMINATE_INFOは、主導JCPの下で転送することができます。
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.
OPCODE = 20 PCK =％B00 CHN = 0 = 0 EXT = 0/1 ASK。 OPR_LENGTH = 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）異常ジョブのタスクを完了するために、タスクのすべての動的リソース割り当てを解除します。
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の送信後に完了したジョブを検討します。
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 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は、ネットワーク内の任意の配列を有し、かつ均一なコントロールを有するされていないノードを結びつけます。各ノードは、時間の任意の瞬間に切断または再ロードすることができます。しかし、他のノードはそれについて通知されませんすることができます。トランスポート接続の確立を壊すか、繰り返しの事実は、ノードの切り離しまたは再起動の指標とすることはできません。交通機関の接続の制御は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は、ノードの活動の制御の機能を実行します。ステータスTASK_REQの要求の指示は、この目的のために、ノードとJCP上のタスク間で定期的に送信されます。
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は（このJCPを設定する）非アクティブ時間の2つの最大間隔の間、リロードまでの既存の、魔女にGJIDを同意しないこと、リロード後に保証しなければなりません。
The reload of nodes, which are not being JCP, does not impose restrictions on LTID established on these nodes.
JCPされていないノードのリロードは、これらのノードに設立されてltidに制限を課しません。
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_TIME）は、ノード（非JCP）の休止時間を設定することができます。これは、フィールドの次の値があります。
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.
HEAD_CODE = 2 HEAD_LENGTH = 1。 HOB = 1つのDATAが含まれています：2つのオクテット：不作為期間を。サイドJCPからの指示の送信元 - - 0.5秒間隔、ノードのスルー活性の数がチェックされます。
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_TIMEは、以下の手順に取り付けることができます。
(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.
（1）命令TASK_REGに。この場合、満足状態でなければならない - ノードで宛先のJCPを制御する他のアクティブタスクがあってはなりません。ゼロ値は、アクティビティのチェックが未使用であることを指定します。ヘッダが存在しない場合は、休止期間はJCPに設定しなければならないことを指定します。 （2）命令TASK_REJECTに、命令TASK_REGから時間がJCPのために収まらない場合。 （3）命令TASK_CONFIRMに、命令TASK_REGはないこのヘッダーを持っている場合。
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_TIMEと命令TASK_REGを受信した場合、それは（それはノードが再ロードされたことを、意味することができたように）送信ノードでアクティブなタスクの有無を確認する必要があります。そのようなタスクが存在する場合、それらのそれぞれのためには、セクション5.6.2で説明したタスクの終了の手順を実行する必要があります。命令TASK_CONFIRMはそれだけで後に送信される必要があります。
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:
命令「状態要求」（STATE_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.
OPCODE = 21 PCK =％B00 CHN = 0 ASK = 0 EXT = 0 OPR_LENGTH = 1/2。 ltidを長に依存します。オペランド：4/8オクテット：ltidを、命令の宛先のノードに設立。
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.
命令STATE_REQは、定義されたタスクに送信されますが、それはノードとの懸念を持っています。ノードとJCPの間、非アクティブ期間中に命令を送信されなかった場合には、送信されます。最後の命令STATE_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.
命令TASK_STATEはSTATE_REQへの応答で送信されます。応答の期待に、1つの休止期間に等しいタイムアウトが使用されます。オフ - タイムアウトの満了後にノードを切り替えると考えられています。
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は仕事を終えたことが、考えられています。この場合のノードの動作は、命令JOB_COMPLETED_INFOを受けるでセクション5.6.2に記載されています。この条件のチェックはノードのためのオプションです。
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で定義されたノードに接続されたアクティブなタスクがない場合、このノードの活動の制御は行われません。
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_STATE）はJCPへの明確なタスクから送信されます。これは、命令STATE_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.
OPCODE = 22 PCK =％B00 CHN = 0 ASK = 0 EXT = 0 OPR_LENGTH = 1/2/3。 CTIDの長さに依存します。オペランド：1つのオクテット：タスクの状態コード。 - タスクがアクティブで、アクティブなセッション接続を持つ％のX01：以下の値は、このフィールドのために定義されています。 ％X02 - タスクがアクティブで、何のセッション接続を持っていません。 ％X03 - タスクがアクティブであり、何のセッション接続を持たないノードに割り当てられないリソースを持っていません。 ％X04 - タスクが完了しています。 1/3オクテット：予約済み。 OPR_LENGTH = 1の場合、このフィールドは長さ1オクテット、他の3つのオクテットがあります。 JCPは、このフィールドの値をチェックしてはなりません。これは、送信することにより、ゼロ値に設定されています。 2/4/8オクテット：CTID命令STATE_REQからltidをと接続されています。
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つのオクテットを行います。以上4つのオクテット - 他のすべての場合では、予約フィールドの長さが3つのオクテット長さCTID等しいです。
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:
命令「ノードがリロードされた」（NODE_RELOAD）はSTATE_REQ命令に否定応答として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.
OPCODE = 23 PCK =％B00 CHN = 0 ASK = 0 EXT = 0 OPR_LENGTH = 1/2。 ltidを長に依存します。オペランド：4/8オクテット：ltidを。値は、命令STATE_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).
（1）最後から二番目の命令STATE_REQの送信前に開始されたノードのすべてのタスクに命令STATE_REQを送信します。 （2）（否定応答が受信された）最後の命令STATE_REQの送信後に1つの休止期間の終了を待ちます。 （3）（項目1からの指示を含まない）の最後と最後から二番目の命令STATE_REQ間で開始されたノードのすべてのタスクに命令STATE_REQを送信します。
For all instructions STATE_REQ the positive response (TASK_STATE) or negative response (RELOAD_NODE) must be transmitted.
すべての手順については、肯定応答（TASK_STATE）または否定応答（RELOAD_NODE）が送信されなければならないSTATE_REQ。
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を有することです。
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のメモリアドレス空間は、接続確立なしにアクセス可能です。
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 = 0とREQ_ID = 0の命令SESSION_INITはゼロセッションのパラメータを指定すると、宛先ノードのゼロセッションパラメータを要求することを可能にします。そのような命令を受信したノードは、必要なプロファイルを提供する場合、それは命令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をチェーンは、それが完全にトランスポート層の一つのセグメント内に配置されている場合にのみ、送信されなければなりません。 Oメモリの割り当てを要求すると（命令MVRUN除く）オブジェクトを作成することは不可能です。これは明確なジョブに接着されていないオブジェクトとそれらを自動的に作成したジョブの終了時にリソースを解放されていません。ノードは、任意の時点で再ロードすることができますので、O関数と返される値のパラメータは、ポインタを含めることはできません。これは、ポインタが無効になりますか、他のオブジェクトに取り組むこととなります。
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).
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のために定義されてもよいです。完全な命令フォーマットはフィールド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.
命令ヘッダフラグに= 1 REQ_ID応答の識別に使用される場合ASK命令は、フィールドREQ_IDを有しています。このフィールドの値は、VMによって指定されます。応答は、あまりにも、VMによって形成されます。プロトコルは、応答をチェックしないとVMとの間の交換を指示するためのフィールドREQ_IDの値を分析しません。 RSP、DATA、RETURN、ADDRESS、OBJECTまたはPROC_NUMが応答を送信するために使用される命令の1つ。応答の命令は= 1 ASKていると確認された命令から取られた値は、REQ_IDでレコードです。応答の指示は、応答を必要としません。
The instructions of exchange between VM may be sent through UDP at observance of the following conditions:
VM間の交換の指示は、以下の条件の遵守にUDPを介して送信することができます。
o ASK = 0;
o The instruction is located in one segment 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は、同時に複数のジョブを実行することができます。各ジョブには、そのアドレス空間で動作する可能性があります。プロトコルは、受信された命令は、フィールドSESSION_ID値上に転送しなければならないVMとジョブを決定します。
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.
オクテットフィールド - メモリアドレス長がノードに対して24ビットに設定されている場合、アドレスはO 4の端部に書き込みます。初期（ゼロ）オクテットの0値セット。
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.
命令フォーマットは、メモリアドレスの長さ以上4つのオクテットを想定した場合、O、2オクテットのアドレスは、最後のオクテットに位置しています。最初の2つのオクテットはゼロに設定しなければなりません。 O命令は、チェーンのメンバーであり、それはノードのために定義されているよりも、メモリアドレスの短い長さを有している場合 - それは考慮され、アドレッシングベース変位が使用されていること。メモリベースの値は、チェーンのために割り当てられていない場合 - 命令が誤っています。命令はチェーンのメンバではなく、それはノードのために定義されているよりも、より少ないメモリアドレスの長さを有する場合、O、略すアドレスが使用されることが、考えられます。完全なアドレスの長さは、その前にゼロ値オクテットの必要数をパディングすることによって受信されなければなりません。 O他のすべてのケースでは、命令が誤っています。
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を参照）に含まれていてもよいということです。完全なアドレスのFREEがゼロに設定されている場合は、オペランドにローカルアドレスを使用することをお勧めします。
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.
すべてのバイナリデータとプロトコルの作業の指示やフォーマット変換の操作を提供していません。
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。これらの命令は、フィールドの次の値があります。
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 = 131分の130; 2/4オクテットの長さフィールドの長さのために。 OPR_LENGTH = 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.
必要なデータを含む命令データは、それに応答して送信されます。データが送信できない場合は、ゼロ以外の基本的なリターンコードと命令RSPは、戻ってきます。
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:
命令「データ」（DATA）は、命令REQ_DATAとOBJ_REQ_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 = 132 OPR_LENGTH = 0から65535。オペランドの即値データの長さに依存します。オペランド：0から262140オクテット：即時データ。 OPR_LENGTH = 0の場合、このフィールドは存在しません。拡張ヘッダ：_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ゼロ値のオクテットは、フィールドの終わりにパディングされます。
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_LENGTH = 1から65535。即値データの長さに依存します。オペランド：2/4/8/16オクテット：データを書き込むためのメモリアドレス。 0から262136オクテット：書き込みのための即時のデータ。
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.
命令RSPは、命令WRITEに応答して送信されます。ゼロ基本的な戻りコードは実行正常定義します。
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オクテットと262132オクテット - データの長さは1であってもよいです。命令は、フィールドの次の値があります。
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 = 137 OPR_LENGTH = 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.
フィールドの終わりに3ゼロ値オクテット - 4つのオクテットの即値データの複数を作製するために、データは1で埋められます。
The instruction RSP is sent in reply to the instruction WRITE_EXT. The zero basic return code defines normal executing.
命令RSPは、命令WRITE_EXTへの応答で送信されます。ゼロ基本的な戻りコードは実行正常定義します。
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_LENGTH = 1から65535。即値データの長さに依存します。
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つのオクテットの倍数です。
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オクテットと262132オクテット - データの長さは1であってもよいです。命令は、フィールドの次の値があります。
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 = 142 OPR_LENGTH = 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.
フィールドの終わりに3ゼロ値オクテット - 4つのオクテットの即値データの複数を作製するために、データは1で埋められます。
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.
命令RSPは、命令CMP、CMP_EXT及びOBJ_CMP（下記参照）に応答して送信されます。比較が実行された場合、基本的な戻りコードはゼロに等しいです。アドレス・メモリのデータがオペランドからのデータ、次に小さい場合は、追加の戻りコードは、-1に等しいです。 0、それらが等しい場合。 1、彼らはより多くのであれば。比較が実行できない場合は、命令RSPの基本的なリターンコードがゼロ以外でなければなりません。
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 = 144分の143;これに対応しJUMPが含有し、VMに関する情報が含まれていないため。
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.
146分の145;それに対応してCALLは含有し、VMに関する情報が含まれていません。 OPR_LENGTH = 2から65535。 VM、アドレス長およびパラメータ長の情報を含めることに依存します。オペランド：2つのオクテット：送信者のVMタイプ。 OPCODE = 145分の143場合は、このフィールドは存在しません。 2つのオクテット：送信者のVMバージョン。 OPCODE = 145分の143場合は、このフィールドは存在しません。 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、肯定応答RSPは、命令JUMPのために送られます。送信側は応答を受信した後に実行される命令のJUMPを考慮する。命令CALL命令RETURNの実行の応答のためにOが送信されます。命令RETURNは、返された値が含まれていてもよいです。例外条件がCALL命令によって作成された制御のスレッドである場合、非ゼロの基本的な戻りコードで指示RSPは、RETURNの代わりに送信されます。
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 = 147 OPR_LENGTH = 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）が送信されるための命令と一致します。
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によって実現されます。
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_LENGTH = 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に肯定応答するために、負のための命令アドレス、 - RSP非ゼロの基本的な戻りコードとが送信されます。受信したアドレスは、読み取り/書き込み、比較および同期の指示にプロトコルによって使用することができます。
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）「コードを移動する」命令は、別の上の一つのノードから実行可能コードの移動のために使用されます。命令は、フィールドの次の値があります。
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 = 149 OPR_LENGTH = 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が含まれている必要があります。コードは、同時にオペランドおよび拡張ヘッダで送信されてはなりません。
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に肯定応答するために、負のための命令アドレス、 - RSP非ゼロの基本的な戻りコードでは、使用されます。命令MVCODEに転送コードは、命令JUMPまたはCALLによって実行されてもよいです。
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 = 150 OPR_LENGTH = 1/2/4。アドレスの長さに依存します。オペランド：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を、定義されています。
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に割り当てられたメモリは、明示的に解放しなければなりません。この目的のために、（FREE）「メモリを解放する」命令が使用されています。これは、フィールドの次の値があります。
OPCODE = 151 OPR_LENGTH = 1/2/4; Depends on length of the address Operands: 4/8/16 octets: the address of free memory.
OPCODE = 151 OPR_LENGTH = 1/2/4。 4/8/16オクテット：空きメモリのアドレスアドレスオペランドの長さに依存します。
VM must free this memory automatically at end of the task on the node.
VMは、ノード上のタスクの終了時に自動的にこのメモリを解放しなければなりません。
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 = 152 OPR_LENGTH = 1から65535。コードフィールドの長さに依存します。オペランド：2つの八重奏：宛先VMタイプ。 2つのオクテット：宛先VMバージョン。 4から262136個のオクテットは：実行可能コードが含まれています。
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の割り当てを解除する必要があります。
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_LENGTH = 2から65535。データオペランドの長さに依存します：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.
追跡データは、最初のオペランドのメモリアドレスが設定されています。これらのデータは、もともと第二オペランドからの初期データ値と比較されます。値が一致しない場合は、データが変更されたこと、考えられています。第三のオペランドは、比較のためにマスクを設定することができます。マスクの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、ゼロ以外の基本的なリターンコードと命令RSPは、応答のために送られます。データは変更しない場合は、O、応答は何もして送信されます。データが変更されている場合は、O、トレースしたデータの新しい値で命令データが送信されます。
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_LENGTH = 0から65535個のオペランド：0から262140オクテット：カプセル化されたデータを。拡張ヘッダ：任意の拡張ヘッダー。
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をセッションに断片化された命令およびトランザクションを送信するための他の指示がない場合（セクション7参照）、制御拡張ヘッダを送信します。
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.
プロトコルは、プロトコル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
私は - >％x00000000 - >％x20000000 - - 1FFFFFFFは、標準オブジェクトII用に割り当てられているユーザのために割り当てられている〜3FFFFFFFオブジェクトIIIは - >％x30000000 - 4FFFFFFF無料IV - >％x50000000 - DFFFFFFF過渡V - >％xE0000000 - FFFFFFFFを保有します
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.
範囲からのオブジェクトは、私は標準として、明確でなければならず、そのインターフェイスの仕様が公開されなければなりません。プロトコルは、標準オブジェクトのプライベートか説明するインタフェースを想定しません。
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からオブジェクトを登録する必要があり、それらのインターフェースの仕様が公開され、オプションであってもよいです。異なるメーカーのシステムの可能性の競合を排除するために必要とされている場合、これらの数字は、場合に適用されます。
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.
すべてのオブジェクトは、範囲I、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つのジョブのみのために付与する必要があります。ゼロ・セッションでは、これらのオブジェクトにアクセスできません。
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.
命令の送信元のバージョンおよび/またはオブジェクトの実現のための任意の役割を果たしているかは不明であるしない場合は、命令は、オブジェクトのバージョンと実現のゼロフィールドや実現の唯一のゼロフィールドが含まれていてもよいです。バージョンと実現の非ゼロ磁場のゼロフィールドが許可されていません。
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）は、リモート・ノードからのオブジェクトのデータの要求のために使用されます。命令は、フィールドの次の値があります。
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 = 193分の192;長さが2/4オクテットのフィールドの長さのために。 OPR_LENGTH = 3/4/5;オフセットフィールドの長さに依存します。オペランド：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への応答のために送られます。データを送信することができない場合は、ゼロ以外の基本的な復帰コードからの指示RSPは戻ってきます。
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_LENGTH = 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.
命令RSPは、命令OBJ_WRITEへの応答で送信されます。ゼロ基本的な戻りコードは、通常の実行を定義します。
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オクテットと262132オクテット - データの長さは1であってもよいです。命令は、フィールドの次の値があります。
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 = 197 OPR_LENGTH = 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.
終わりに3ゼロオクテット - ダウン書き込まれたデータの長さが4つのオクテットの倍数でない場合、データは1で埋められます。
The instruction RSP is sent in reply to the instructions OBJ_WRITE_EXT. The zero basic return code defines the normal execution.
命令RSPは、命令OBJ_WRITE_EXTへの応答で送信されます。ゼロ基本的な戻りコードは、通常の実行を定義します。
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）は、オペランドから即値データによるオブジェクトのデータのバイナリ比較のために使用されます。命令は、フィールドの次の値があります。
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_LENGTH = 3から65535。データの長さに依存します。オペランド：4つのオクテット：オブジェクトの数。 2つのオクテット：オブジェクトのバージョン。 2つのオクテット：オブジェクトの実現。 2/4/8オクテット：比較されたデータのためのオブジェクトのオフセット。 2から262128オクテット：比較のための即時のデータ。
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.
命令OBJ_DATA_CMPに対する応答は、セクション6.2.3に記載されています。
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）「オブジェクトのデータを比較する拡張子は」オペランドから即値データによるオブジェクトのデータのバイナリ比較のために使用されます。ステップ1オクテットと262132オクテット - データの長さは1であってもよいです。命令は、フィールドの値以下があります。
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 = 201 OPR_LENGTH = 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.
終わりに3ゼロ値オクテット - 4つのオクテットの即値データの複数を作製するために、データは1で埋められます。
The response to the instruction OBJ_DATA_CMP_EXT is described in section 6.2.3.
命令OBJ_DATA_CMP_EXTに対する応答は、セクション6.2.3に記載されています。
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_LENGTH = 4から65535。 VMとコール・パラメータの長さについての情報を含めることに依存します。
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を参照）が行われます。
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 = 205分の204;したがって手順については、含有し、VMに関する情報が含まれていません。 OPR_LENGTH = 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に属するオブジェクトの手順を有することができます。範囲に属するオブジェクトの手順はIとIIはUMSP層に名前を持っていてはいけません。彼らは唯一の番号を持っている必要があります。
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_NUM_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_LENGTH = 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_NUM_PROCに肯定応答するために、負のための命令PROC_NUM、 - RSP非ゼロの基本的な戻りコードとが送信されます。
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:
命令「手順番号」（PROC_NUM）は命令GET_NUM_PROCへの応答で送信されます。命令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_LENGTH = 3つのオペランド：4つのオクテット：オブジェクトの数。 2つのオクテット：オブジェクトのバージョン。 2つのオクテット：オブジェクトの実現。 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.
IおよびII（標準及びユーザに割り当てられた）はUMSPインタフェースを介してリモート・ノード上に作成することができない範囲のオブジェクト。これらのオブジェクトは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 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.
I範囲からオブジェクトの実現 - III（特定のジョブに接続されていない）が十分に困難です。その理由は、異なるジョブがメモリの異なるアドレス空間を持つことができるということです。ポインタは、それらが受信されているから、仕事のコンテキストで処理されなければなりません。また、これらのオブジェクトは、動的なリソースの割り当て解除のためのジョブの終了をトレースする必要があります。指定された要件は、これらのオブジェクトの基本的な制限を課します。プロトコルは、範囲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名が割り当てられてもよいです。範囲からのオブジェクトは、IとIIはUMSP層上の名前を持つことはできません。一つのタスクの枠組みの中つの番号または1つの名前を持つ二つのオブジェクトであってはなりません。
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にオブジェクトを作成します。これらの命令は、フィールドの次の値があります。
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 = 209分の208;したがってNEW / NEW_SYSため。 OPR_LENGTH = 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 - のみ、その仕事からアクセス可能なオブジェクトを作成するため。オブジェクトが作成されている場合は、指示対象は、応答のために送られます。オブジェクトを作成することができない場合は、ゼロ以外の基本的なリターンコードと命令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上で作成されます。
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は、自動的にすべての動的オブジェクト、作成したタスクの終了時に、タスクによって削除されませんを削除する必要があります。
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:
命令「オブジェクト」（オブジェクト）命令NEWとNEW_SYSに肯定応答するために使用されます。命令オブジェクトは、フィールドの値以下があります。
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_LENGTH = 2つのオペランド：4つのオクテット：オブジェクトの数。 2つのオクテット：オブジェクトのバージョン。 2つのオクテット：オブジェクトの実現。
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_LENGTH = 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は、この指示に応答して送信されます。
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.
254オクテット - ノード上のオブジェクトの登録時に、それは、名前によって4の長さを識別することができます。名前は、シンボルの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 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.
名前は、オブジェクトの数を識別し、その同義語です。ノード上の一つのタスク内のすべてのアクティブなオブジェクトの名前は一意でなければなりません。このように、数Iの範囲からすべてのアクティブオブジェクト - IIIは、ノード上のすべてのタスクのためのユニークな名前を持っている必要があります。プロトコルは、名前と数値によるオブジェクトの名前でオブジェクトの数を受信することができます。
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 = 212 OPR_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.
オブジェクトが見つかった場合 - 命令オブジェクトが答えに送信されます。オブジェクトが見つからない場合 - 非ゼロ基本的な復帰コードと命令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.
命令OBJ_SEEKはUDPを通じてブロードキャストを送信することもできます。この場合、それはゼロのセッションに関係します。命令は、回答の識別のためのフィールドREQ_IDが含まれていてもよいです。この場合、陽性反応がのみ送信する必要があります。応答は、UDPを介して送信することができます。
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_LENGTH = 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と指示対象は、応答のために送られます。オブジェクトが存在しない場合 - 非ゼロの基本的な戻りコードで指示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: o The sequence. o The transaction o The fragmented instruction.
1つのセッションの接続に送信されます命令は、チェーンで統一することができます。鎖は、互いに命令リレーショナルの基です。 1つのセッションでは、いくつかのチェーンを同時に転送することができます。チェーンは、次のタイプがあります。シーケンスoを。断片化された命令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.
鎖の番号付けは、プロトコルによって行われる0ので、チェーンにシリアル命令数 - 命令がチェーンに含まれている場合、フラグCHNは、ヘッダのフィールドCHAIN_NUMBERチェーン、INSTR_NUMBERの数が含ま1等しくなければなりません。 1つのセッションで同時に65533のチェーンまで転送することができます。プロトコルによって予約チェーン％のX0000と％xFFFFより数の値。一つのチェーンには、最大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:
_END_CHAIN。拡張ヘッダ「鎖末端」にかかわらずチェーンのタイプの、チェーンの最後の命令で転送されます。これは、フィールドの次の値があります。
HEAD_CODE = 6 HEAD_LENGTH = 0 HOB = 1
HEAD_CODE = 6 HEAD_LENGTH = 0 HOB = 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を介して転送することができます。
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上で実行することができます。現在の命令が実行できない場合は、所定の配列の他のすべての命令は（すでに送信または送信期待）単純にキャンセル。これにより、現在の命令ではない正の終了を待つことと、一度に以下の転送に1つのコンピューティング制御スレッドのため可能です。
_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:
_BEGIN_SQ。 「シーケンスを開始する」拡張ヘッダは、シーケンスの最初の命令で転送されます。これは、フィールドの次の値があります。
HEAD_CODE = 3 HEAD_LENGTH = 0 HOB = 1
HEAD_CODE = 3 HEAD_LENGTH = 0 HOB = 1
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を生成することができます。
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で説明したバッファリングに接続されています。
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:
HEAD_CODE = 4 HEAD_LENGTH = 1 HOB = 1、DATA - の形式は次のとおりです。
+---+---+---+---+---+---+---+---+
|TRE|TRR|TRS| Reserve |
+---+---+---+---+---+---+---+---+
| TIME_TR |
+---+---+---+---+---+---+---+---+
TRE
THREE
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 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.
1ビット。義務の実行のフラグ。このフラグは完全に転送、まだ実行されていないトランザクションに関するものです。 TRE = 1の場合、トランザクションは、フィールドTIME_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
TIME_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での取引の生活の時間 - 秒間隔（最大寿命 - 8分）。受信側では、すべてのトランザクションの指示を受けた後、今回の読み出しを開始します。値％X00は、寿命の制約を受けることなく、トランザクションを設定します。
In the last instruction of transaction the header, _END_CHAIN is always sent.
トランザクションヘッダの最後の命令では、_END_CHAINは常に送信されます。
This instruction "To execute the transaction" (EXEC_TR) is transferred for execution transaction early transferred. It has the following values of fields:
この命令「トランザクションを実行するには」（EXEC_TR）が早期に転送され、実行トランザクションのために転送されます。これは、フィールドの次の値があります。
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
OPCODE = 158 = 1つのPCK =％B01 / 10月11日CHN = 1 EXT = 0/1 CHAIN_NUMBER ASK - 実行する必要があるチェーンの数を、含ま。 INSTR_NUMBER = 0 OPR_LENGTH = 0
The instruction "To cancel transaction" (CANCEL_TR) is transmitted for a cancellation of execution transaction transmitted before. It has the following values of fields:
「トランザクションを取り消すには、」命令（CANCEL_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
OPCODE = 159 = 0 PCK =％B01 / 10月11日CHN = 1 EXT = 0/1 CHAIN_NUMBER ASK - キャンセルする必要があるチェーンの数を、含ま。 INSTR_NUMBER = 0 OPR_LENGTH = 0
The instructions, of which the cancelled transaction consists, delete without a possibility of restoration.
キャンセルトランザクションが構成されているの命令は、回復の可能性なしに削除します。
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: (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.
断片化された命令は、いくつかのNOP指示にカプセル化されます。そして、すべての命令NOPは、特殊なタイプの一つの鎖として、送信されています。以下のアルゴリズムは、カプセル化の間に使用される：（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:
_BEGIN_FRG。拡張ヘッダ「最初のフラグメント」は、最初のフラグメントを含む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.
HEAD_CODE = 5 HEAD_LENGTH = 0/2。チェーンの従属によって異なります。 HOB = 1つのデータ：2つのオクテット：親のチェーンの数。断片化された命令は、シーケンスまたはトランザクションの一部であってもよいです。 2つのオクテット：親のチェーン内の命令数。
The header _END_CHAIN is transmitted in NOP instruction, which contains last fragment.
ヘッダ_END_CHAINは、最後のフラグメントを含むNOP命令で送信されます。
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システムの生産性は、彼らが受け取ったものと、その速度で、ネットワークから受け入れられた命令を処理できるようにする必要があることを、お勧めします。それは、既知および限られたコンピューティング・ロードを実行するように、すべての命令は設計されています。例外は、二段階で処理しなければならないコントロール転送の命令です。命令の正しさは、まずチェックされ、そのスケジューリングが行われます。その後、命令が実行されます。その時のプロトコルは、それが静止モードで動作することを可能にするプロセッサ時間のような部分を、受信することができることが保証されなければなりません。したがって、ノードの過負荷の問題は、それらを制御することができ賢明なVM層と、ユーザーのアプリケーション層、上推定されます。
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）トランザクション及びサイズがウィンドウを超える断片化手順については、送信する受信ノードに制裁を要求する必要があります。チェーン伝達の理論上の制限サイズは、SO 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.
OPCODE = 24は、ASK = 1つのPCK = B01 / 11 CHN = 0 EXT = 0/1 OPR_LENGTH = 1つのオペランド：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セッション（ウィンドウ）のために割り当てられたバッファにチェーンを配置する可能性に関係なく使用することができます。否定応答は、この命令に送信することができることを、考慮する必要があるが、送信「窓」の保証の使用します。
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によって送信するための制裁を要求しなければなりません。
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、それはバッファリングせずに送信されます。鎖の長さは、「ウィンドウ」、次いでそれ以上ない場合、O、それは、ウィンドウ割り当てのバッファの要求なしに送信することができます。送信を開始する前にこのように、バッファ内の場所を確保する必要があります。それはバッファに十分な場所でない場合は、開始することはできません送信します。この場合、ウィンドウの解放を待機するか、VM REQ_BUFのバッファ割り当ての要求命令を使用することが可能です。長さは、セッション・ウィンドウのサイズを超える場合、Oは命令REQ_BUFを使用する必要があります。
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が要求された送信に制裁）を使用して、または鎖が完全にトランスポート層セグメントに位置している場合、送信側のプロトコルは、肯定応答を追跡しません。
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.
送信チェーンのためのVMを与えているフィールドREQ_IDの値O、完全に収集チェーンOチェーンの最初の命令で送信されて保持され、それが新たな値REQ_ID O代わりのプロトコルによって確立された値を入力されています受信側のセッションウィンドウ。リンクした後、それがVM上で実行するために送信されます。その時、チェーンは、バッファ内の場所を占有し続けることができます。 Oの実行後、VMは、受信側プロトコルにそれについて通知します。 Oプロトコルは、割り当てられたバッファ内の場所をクリアします。 O、プロトコル形式および他の場合のように、代わりRSPの、チェーン確認RSP_Pに送信します。 O送信側プロトコルは、肯定応答RSP_Pの受信後に受信側のバッファの空き場所の大きさを補正します。 Oそして、古い値REQ_IDが復元され、確認がVMに送信されます。
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.
相対アドレッシングのためのメモリベースアドレスは、一つの鎖からの指示のために確立することができます。これにより、チェーンの指示に略記アドレスメモリフィールドを使用することが可能です。略記アドレスは、ベースからの変位として、使用されています。
_SET_MBASE. The extension header "To set memory base" establishes the value of base address for chain. It has the following values of fields:
_SET_MBASE。 「メモリーベースを」拡張ヘッダは、チェーンのベースアドレスの値を確立します。これは、フィールドの次の値があります。
HEAD_CODE = 7 HEAD_LENGTH = 2/4/8 ; Depends on address length. HOB = 1 DATA contains:
HEAD_CODE = 7 HEAD_LENGTH = 2/4/8。アドレスの長さに依存します。 HOB = 1つのDATAが含まれています。
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.
このセクションでは、明確な命令と接続されていない拡張ヘッダの記述を含みます。専門的な拡張ヘッダの記述は、この文書の適切なセクションで説明します。
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:
2つのオクテットのステップで16オクテット - 拡張ヘッダ「アラインメント」（_ALIGNMENT）が4のオペランドの複数の任意の拡張ヘッダまたはフィールドを作成することを可能にします。プロトコルが使用所与の拡張ヘッダの任意のルールを与えません。これは、任意に使用することができます。ヘッダフィールドの次の値を有します。
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.
HEAD_CODE = 8 HEAD_LENGTH = 1-7。データフィールドの長さに依存します。 HOB = 0 DATAは含まれています：2から14オクテット：フィールドのすべてのオクテットは、ゼロの値を持ちます。
The format of the protocol instructions provides the alignment of two octets field without any additional means.
プロトコル命令のフォーマットは、任意の付加的な手段なしに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:
HEAD_CODE = 9 HEAD_LENGTH = 1から127。フィールドのデータ長に依存します。 HOB = 0 DATAが含まれています。
2 - 254 octets: The any text of the message.
2から254オクテット：メッセージの任意のテキスト。
The instruction may contain several headings _MSG.
命令は_msgいくつかの見出しが含まれていてもよいです。
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.
HEAD_CODE = 10 HEAD_LENGTH = 1から127。データのフィールドの長さに依存します。 HOB = 0 DATAは含まれています：2から254オクテット：シンボルのASCIIで名前のテキストを。
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つの命令でデータの4Gバイトまで転送することができます。ヘッダフィールドの次の値を有します。
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.
HEAD_CODE = 11 HEAD_LENGTH = 1 - 2 147 483 647。データフィールドの長さに依存します。 HOB = 1つのDATAが含ま： - ：任意の形式のバイナリデータ2つの4 294 967 294オクテット。
The extension header "The lifetime" (_LIFE_TIME) contains value of time. It has the following values of fields:
拡張ヘッダ「寿命」（_LIFE_TIME）は、時間の値を含みます。これは、フィールドの次の値があります。
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.
HEAD_CODE = 12 HEAD_LENGTH = 1/2。データの長さに応じて。 HOB = 1つのDATAが含まれています：2/4オクテット：1024ミリ秒間隔で時間を。
The header _LIFE_TIME allows to set limiting time of sending of the instruction to VM of the addressee.
ヘッダ_LIFE_TIMEは、宛先のVMへの命令の送信の制限時間を設定することを可能にします。
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受信側寿命しか断片化された手順については、考慮されます。寿命の値は、命令アセンブリ値の時間に減少します。このヘッダは、非断片化手順については、受信時には無視されます。その値はVMに送信する必要があります。 Oトランスポート層での送信の際には考慮されません。断片化された手順については、最初の断片を送信するだけの時間は考慮されません。
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_TIMEは、送信トランザクションで使用されてはなりません。
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.
命令が断片化された場合、ヘッダ_LIFE_TIMEは最初のフラグメントを含む、命令NOPにのみ送信されます。このヘッダは、最初の断片化された命令から削除します。時間が経過する場合は断片化された命令の一部がまだ送信されていないとき、命令の滞在部分がクリアされます。
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_TIMEは、マルチメディアシステムでは、リアルタイムシステムで使用されてもよいです。プロトコルは、エンド寿命に来るとデータのための送信の優先度を上げることができます。
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.
仮想マシンは、プロトコルの識別された資源です。 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.
VMタイプO。 VMバージョンO 65534 - 値1の範囲。 65534 - 値1の範囲。
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).
プロトコルは、一つのタイプの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)
65534フリー（動的および/またはプライベートVM用に定義された） - ユーザー49152の登録VMに割り当てられた49151から1 - 標準VM 1024に割り当てられた1023年
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ビットのアドレスを1つのタスクのために誰VMコードで満たされている場合、それはメモリの1つの物理セルを指定しなければならないことを、意味しています。指定された条件の性能は、一つのノードに（異なるVMのための手順を含む）マルチベンダユーザ・コードを実行可能にします。グループに含まれるすべてのVMは、さまざまな種類を持っている必要があります。グループは65534 VMよりも多くを含めることはできません。異なるノード上のグループの一つ数が異なる構造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オクテットの長さのグループのコードが割り当てられます。だから、長いノードが一つでもセッション接続を持っているとして、グループのコードは変更してはなりません。唯一のノードの再構成で、グループのコードを変更することをお勧めします。グループVMは、識別され、ならびに1つのVMです。したがって、タイプ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の要求に応答します。アンサーバック命令は、要求を受信した同じプロトコルの下で送信されなければなりません。
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.
番号49152の範囲からVM - 65534又はいずれかの基VMは、名前で識別することができます。数字1とVM - 49151は、命令のUMSPの層で名前を持つことはできません。
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_REQ）「VMを要求するためには、」リモート・ノードに接続された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. . . .
OPCODE = 25 PCK =％B00 CHN = 0 ASK = 0/1 EXT = 0/1 OPR_LENGTH = 0から65534。オペランドに数量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の要求のために使用されます。オペランド内の1つのVMとの命令が1 VMに関する情報を要求します。それは、オペランドに複数の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は、オペランドの値と接続されていません。そのために、別々の答えが送信されなければなりません。
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_NOTIF）「VMについて通知する」命令は、一つ又はVMノードに取り付けられた1つのVMグループの通知のために使用されます。命令は、フィールドの次の値があります。
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.
OPCODE = 26 PCK =％B00 CHN = 0 ASK = 0/1 EXT = 0/1 OPR_LENGTH = 1から65534。オペランドに数量VMによって。オペランド：2つの八重奏：使用されるトランスポートプロトコル。このフィールドの次の値は明確です：x0100 - ポートを介して単一のTCPコネクション2110 x0101 - ポート2110 x0102を介して複数のTCPコネクション - 2110 x0103を受信するポートを介してポート2110とUDPによる単一のTCP接続 - 複数のTCPコネクションポート2110、ポート2110を受信するスルーポート2110およびUDPを介して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.
命令はVM_REQ要求に応答するために使用される場合、それはリクエストの命令から値を確立= 1とREQ_IDをASK含むことができます。 VMグループが要求された場合は、命令は、いくつかのVMが含まれている必要があります。まずVMはタイプが0に設定されたバージョンは、グループの数が含まれている必要があります持っている必要があります。その他VMは、グループの構造を定義する必要があります。 VMリスト内のタイプとバージョンが増加してインデックスを作成する必要があります。
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.
（1）の手段を使用することができるTCP / IPで指定します。 （2）特別な処理でチェーンを作成する可能性があります。このようなチェーンを作成するには、チェーンの最初の命令では、特別な処理を決定し、拡張ヘッダを転送する必要があります。チェーンの命令はNOP命令にカプセル化することができます。命令の制御のアルゴリズムは、整合性をシーケンスまたは暗号化は、このような方法で実現することができます。
Protection against the man-in-the-middle:
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.
B、A - - GとG - Bが交差していない保護は、ノードAとの間のルートはという事実に基づいています。このような方式は、攻撃のようなタイプを明らかにできるように、追加の管理データフローを整理することができます。指定されたルートはつのゲートウェイを通過する場合、この保護はあまり効果的です。
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回の握手を含めることができます。また、認証アルゴリズムの選択の柔軟性を上げます。 B、A - - GとG - B.すべてのペアは、任意の組み合わせで使用することができる3つのペアは、ノード間の認証の実現が可能です。ノードGは、特別認証の実現のために割り当てることができます。
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は、ジョブの各タスクに制御タスク識別子を割り当て。その長さは、ノードJCPのローカルアドレスメモリの長さに等しいです。
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グローバルジョブ識別子は、ジョブごとに割り当てられます。 GJIDはJCPノード上で定義されています。ノードJCPメモリのビットアドレスを持っています - 128としては、同じフォーマットを有します。ローカルメモリのアドレスは、その中のジョブの最初の（初期）タスクの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グローバルタスク識別子は、各タスクに割り当てられています。ノードメモリのビットアドレスを持っています - 128としてGTIDは、同じフォーマットを有します。ローカルメモリのアドレスは、それに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を局所的にタスク識別子は、ノード上の各アクティブ・タスクに割り当てられます。 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"、BCP 9、RFC 2026、1996年10月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[2]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、RFC 2119、1997年3月を。
[3] Crocker, D., and P. Overell. "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[3]クロッカー、D.、およびP. Overell。 "構文仕様のための増大しているBNF：ABNF"、RFC 2234、1997年11月。
[4] Postel, J., "Transmission Control Protocol - DARPA Internet Program Protocol Specification", STD 7, RFC 793, September 1981.
[4]ポステル、J.、 "伝送制御プロトコル - DARPAインターネットプログラムプロトコル仕様"、STD 7、RFC 793、1981年9月。
[5] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[5]ポステル、J.、 "ユーザ・データグラム・プロトコル"、STD 6、RFC 768、1980年8月。
[6] Srinivasan, R., "RPC: Remote Procedure Call Protocol Specification Version 2", RFC 1831, August 1995.
[6]スリニバサン、R.、 "RPC：リモートプロシージャコールプロトコル仕様バージョン2"、RFC 1831、1995年8月。
13 Author's Address
13著者のアドレス
Alexander Y. Bogdanov
アレクサンダーボグダノフ
NKO "ORS" 22, Smolnaya St. Moscow, Russia 125445 RU
NKO "ORS" 22、Smolnaya聖モスクワ、ロシア125445 RU
Phone: +7 901 732 9760 EMail: a_bogdanov@iname.ru
電話番号：+7 901 732 9760 Eメール：a_bogdanov@iname.ru
14 Full Copyright Statement
14完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
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.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
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機能のための基金は現在、インターネット協会によって提供されます。