[要約] RFC 3018は、統一メモリスペースプロトコルの仕様を定めたものであり、主な目的は異なるアーキテクチャ間でのメモリアクセスの統一化と効率化です。
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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC-2119 [2]に記載されているように解釈される。
The following syntax specification uses the augmented Backus-Naur Form (ABNF) as described in RFC-2234 [3].
次の構文仕様では、RFC-2234 [3]に記載されているように、拡張されたバックスノーフォーム（ABNF）を使用しています。
Table of Contents
目次
1. Introduction...................................................4
2. The UMSP Model.................................................5
2.1 128-bit Address Space.......................................5
2.2 Computing Model.............................................7
2.3 System Architecture.........................................9
3. Instruction Format............................................11
3.1 Instruction Header.........................................12
3.2 Extension Headers..........................................15
3.3 Instruction Operands.......................................17
3.4 Address Formats............................................17
4. Response of the Instructions..................................19
4.1 RSP, RSP_P.................................................20
4.2 SND_CANCEL.................................................20
5. Jobs Management...............................................21
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は、分散システム開発プロセスを本質的に簡素化できます。情報だけでなく、プログラムの標準化と開発にかなりの費用なしで多数のポリティピックコンピューターのリソースを計算する機会も与えます。
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:
見出しの3つのフィールドの値の組み合わせは、アドレス形式番号と呼ばれます。これらのフィールドは、ノードが配置されているネットワークを明確に定義します。フォーマット番号は次のように書き込みます。
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は、ノードネットワークアドレス4オクテットと長さ32ビットのメモリアドレスの長さのアドレスを定義します。このようなアドレス形式のネットワークタイプ0は、提示されたドキュメントのネットワークIPv4に対して定義されています。ネットワークタイプがゼロに等しい場合、アドレス形式番号の書き込み中に見逃される可能性があります。たとえば、フォーマットn 4-0-2と4-2は同等です。両方のフィールドnet_typeとaddr_codeがゼロに設定されている場合、それらは省略される場合があります。したがって、フォーマット番号は1つの図として書き込みます。
One or several address format numbers must be assigned for each global network, included in unified system.
統合システムに含まれるグローバルネットワークごとに、1つまたは複数のアドレス形式番号を割り当てる必要があります。
FREE
無料
0 - 12 octets. This field is unused by the protocol. It may contain any additional information, which is necessary for the control system of the node memory. If this field is not used, the zero value must be set in all octets. Using of this field results that the network instructions must contain only complete 16 - octet address and the short address of local memory cannot be used.
0-12オクテット。このフィールドはプロトコルによって使用されていません。ノードメモリの制御システムに必要な追加情報が含まれる場合があります。このフィールドを使用していない場合、すべてのオクテットでゼロ値を設定する必要があります。このフィールドを使用すると、ネットワーク命令には完全な16 -Octetアドレスのみが含まれている必要があり、ローカルメモリの短いアドレスを使用できません。
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ビットアドレスは、1つのフィールドです。ユーザーコードは、アドレス指定されたメモリの物理的な配置について知ることができません。
The 128-bit memory address may be transmits between nodes, as the data, for example, in the buffer of function parameters, or in the instruction of copying the data. Therefore, it must identify the given node from any other nodes unequivocal.
128ビットメモリアドレスは、たとえば、関数パラメーターのバッファー、またはデータのコピーの指示において、データとしてノード間で送信される場合があります。したがって、他のノードから特定のノードを不平等に識別する必要があります。
Any certain algorithm, connecting real network and 128-bit address, does not exist. All used address formats must be known beforehand.
実際のネットワークと128ビットアドレスを接続する特定のアルゴリズムは存在しません。使用されているすべてのアドレス形式は、事前に既知のものでなければなりません。
As UMSP has its own address space, it can unite several global networks. The nodes can have internal local networks or subordinated addressable devices connected with the node by the not-network communications. Any node by address format number must have an opportunity to define the gateway respond for routing of this address.
UMSPには独自のアドレススペースがあるため、いくつかのグローバルネットワークを統合できます。ノードには、非ネットワーク通信によってノードに接続されている内部ローカルネットワークまたは下位アドレス指定可能なデバイスを持つことができます。アドレスフォーマット番号によるノードは、このアドレスのルーティングのためにゲートウェイ応答を定義する機会が必要です。
Computing model is three-layer:
コンピューティングモデルは3層です：
(1) Job (2) Task (3) Thread of control
(1) ジョブ（2）タスク（3）制御のスレッド
The job corresponds to the user application. The job is distributed and can simultaneously be executed on many nodes. The job control is carried out centralize, from the node named as Job Control Point (JCP). One JCP can control the some jobs. JCP can be located on the same node, on which the job is created, or on any other addressed net point.
ジョブはユーザーアプリケーションに対応します。ジョブは分散されており、多くのノードで同時に実行できます。ジョブコントロールは、ジョブコントロールポイント（JCP）と呼ばれるノードから集中化されます。1つの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ビットのアドレススペースが分離されています。アドレス空間はセグメント化されています。セグメントは、1つのノードのローカルメモリです。その上、プロトコルはオブジェクトの操作を許可します。オブジェクトは、ノードの個別の連想メモリです。
The task thread represents the concrete control thread, which are executed by VM in the certain node. The thread can read and write to any address of 128-bit address space of the job. The control transfer to the address from other (remote) node, results to the creation of the new thread on the remote node. The continuous code segment cannot be distributed on several nodes. In addition, it is impossible to receive continuous memory area distributed on several nodes.
タスクスレッドは、特定のノードのVMによって実行されるコンクリート制御スレッドを表します。スレッドは、ジョブの128ビットアドレススペースの任意のアドレスに読み書きできます。コントロールは、他の（リモート）ノードからアドレスに転送され、リモートノード上の新しいスレッドが作成されます。連続コードセグメントは、いくつかのノードに分散することはできません。さらに、いくつかのノードに分布した連続メモリ領域を受信することは不可能です。
The protocol does not demand to support the different tasks of not-crossed memory space from the separate VM node. The supporting of multi-thread is not also the obligatory requirement.
プロトコルは、別のVMノードから交差していないメモリ空間のさまざまなタスクをサポートすることを要求しません。マルチスレッドのサポートも義務的な要件ではありません。
The 128-bit Global Job Identifier (GJID) is defined by protocol. It is assigned on JCP, which will control the job. All active GJID have the unique values in the unified system at each moment of time.
128ビットのグローバルジョブ識別子（GJID）は、プロトコルで定義されています。ジョブを制御するJCPに割り当てられます。すべてのActive GJIDは、各瞬間に統一されたシステムに一意の値を持っています。
The job can contain VM code of different types. Different types VM can be situated on one or different nodes. The mechanism of association of different VM types in groups on one node is stipulated, so to the non-uniform code can be executed on one node in a context of one job. The groups are described in details in section 9. VM, incorporated in groups, must work in common memory space (to have a common subsystem of memory control).
ジョブには、さまざまなタイプのVMコードを含めることができます。異なるタイプVMは、1つまたは異なるノードに配置できます。1つのノード上のグループ内の異なるVMタイプの関連付けのメカニズムが規定されているため、1つのジョブのコンテキストで不均一なコードを1つのノードで実行できます。グループは、セクション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.
図1. VMの使用に基づくシステムの構造。
One or several VM are working on upper level for UMSP. The VM layer is not network level. Last network level is UMSP. Therefore, VM layer has no its own network primitives and uses together with UMSP the same field of operation code.
1つまたは複数のVMがUMSPの上位レベルで作業しています。VMレイヤーはネットワークレベルではありません。最後のネットワークレベルはUMSPです。したがって、VMレイヤーには独自のネットワークプリミティブがなく、UMSPと同じ操作コードを使用します。
The end services user of the protocol is the user code, which is executed by the virtual machine. It has the instructions with the 128-bit address. VM translates these instructions to network commands, which are transmitted through the UMSP protocol for the executing by the remote machine. Internal organization VM, command system and API can be anyone. The protocol defines only format of primitives, which the virtual machines exchange through a network.
プロトコルの最終サービスユーザーは、仮想マシンによって実行されるユーザーコードです。128ビットアドレスの指示があります。VMは、これらの命令をネットワークコマンドに変換します。ネットワークコマンドは、リモートマシンによる実行のためにUMSPプロトコルを介して送信されます。内部組織VM、コマンドシステム、APIは誰でもできます。プロトコルは、仮想マシンがネットワークを介して交換するプリミティブの形式のみを定義します。
The protocol does not control the jobs memory. Control of memory should realize VM. If a few VM works on one node, they may have the common memory space or may be completely isolated.
プロトコルはジョブメモリを制御しません。メモリの制御はVMを実現する必要があります。いくつかの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の使用を定義しています。承認データを要求しない場合、データを使用する場合があります。したがって、TCPを介した接続は必須です。複数の接続を使用してマルチプレックスを使用して使用することが想定されています。輸送接続の制御は、UMSPプロトコルの一部ではありません。
The UMSP instructions do not contain network addresses of the receiver and sender. The protocol requires that one address UMSP must correspond to the one transport layer address. Accordingly, it is necessary to define unequivocal the node address on transport layer by the 128-bit address of memory.
UMSP命令には、受信者と送信者のネットワークアドレスは含まれていません。プロトコルでは、1つのアドレスUMSPが1つの輸送層アドレスに対応する必要があります。したがって、128ビットのメモリアドレスによって、輸送層のノードアドレスを明確に定義する必要があります。
Except the TCP, it is possible to use other transport protocols or not network communications. The following requirements are showed to them:
TCPを除き、他の輸送プロトコルを使用するか、ネットワーク通信ではないことがあります。次の要件が彼らに示されています：
o Reliable delivery. The transport layer must inform about delivery or its impossibility; o The violation of a sequence of transmitted segments is allowed; o The duplication of segments is not allowed; o At emergency reload of nodes it is necessary to guarantee identification of segments concerning session connections, assigned up to reload; o Use connectionless-mode is possible.
o 信頼できる配達。輸送層は、配信またはその不可能性について通知する必要があります。o送信されたセグメントのシーケンスの違反が許可されています。oセグメントの重複は許可されていません。oノードの緊急リロードでは、リロードに割り当てられたセッション接続に関するセグメントの識別を保証する必要があります。o ConnectionLess-Modeの使用が可能です。
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は、128ビットアドレスでアプリケーションの指示を、UMSPプロトコルの1つまたは複数の命令に解釈できる必要があります。
The session connection opens between nodes for the data exchange. One connection is relational only with one job. There may be several session connections for the different jobs simultaneously between two nodes. Besides, the protocol provides the connectionless data exchange.
セッション接続は、データ交換のノード間で開きます。1つの接続は、1つのジョブとの関係です。2つのノード間で異なるジョブのセッション接続がいくつかあります。また、プロトコルは、Connectionless Data Exchangeを提供します。
The exchange between UMSP nodes can include the instructions of the following type:
UMSPノード間の交換には、次のタイプの指示を含めることができます。
o Immediate reading/write in memory; o Requests of allocation/free memory; o Comparison instructions; o Call-subroutine and unconditional jump instructions; o Synchronization instructions; o Work with objects instructions - reading / writing in memory of objects and execution of objects procedures.
o メモリの即時読み取り/書き込み。o割り当て/フリーメモリの要求。o比較手順。oコールサブルーチンおよび無条件のジャンプ命令。o同期命令。oオブジェクトの命令を使用します - オブジェクトの記憶とオブジェクト手順の実行を記憶して読み取り /書き込みます。
UMSP does not trace the user control threads. VM must provide itself the necessary order of performance of the instructions.
UMSPは、ユーザー制御スレッドをトレースしません。VMは、指示の必要なパフォーマンスを提供する必要があります。
The length of UMSP instructions does not depend on segment length of the transport layer. The segmentation is provided for transfer of the long instructions. The packing of the short instructions in one segment with a possibility of compression of headings is used for its transfer. The minimal size of necessary for work segment is 6 octets. For realization of all functions, it is necessary 54 octets.
UMSP命令の長さは、輸送層のセグメントの長さに依存しません。セグメンテーションは、長い指示の転送のために提供されます。見出しの圧縮の可能性を伴う1つのセグメントでの短い指示の梱包は、その伝達に使用されます。作業セグメントに必要な最小サイズは6オクテットです。すべての機能を実現するためには、54オクテットが必要です。
3 Instruction Format
3命令形式
The UMSP instruction includes the basic header, extension headers and operands. All fields have variable length.
UMSP命令には、基本的なヘッダー、拡張ヘッダー、オペランドが含まれます。すべてのフィールドの長さは変動します。
+----------------+----------------------+------------------------+
| Header | Extension headers | Operands |
+----------------+----------------------+------------------------+
The header contains operation code and the information necessary for the instruction interpretation.
ヘッダーには、操作コードと命令解釈に必要な情報が含まれています。
The optional extension headers contain the additional information, not defined in basic header.
オプションの拡張ヘッダーには、基本ヘッダーで定義されていない追加情報が含まれています。
The operands contain instructions data.
オペランドには命令データが含まれています。
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
1-112管理手順113-127予約済み128-223 VM 0、224、255の間の交換の指示
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ビット。ヘッダー圧縮属性。これらのビットは、1つの接続TCPに送信された梱包命令ヘッダー、または1つのパッケージUDPでいくつかの命令を送信するために使用されます。これらのBITの使用は、2つのフォローに続いて、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-命令は明確なセッションに属していません。Fields Chain_Number、instr_number、およびsession_idは、そのような命令のヘッダーにはありません。％B01-前のように、同じセッション接続に対する指定された命令に関する懸念。命令ヘッダーのフィールドセッション_IDはありません。％B10-指定された命令は、以前と同じ接続と同じチェーンに属します。そのような命令のヘッダーにあるfields chain_number、instr_number、session_idは存在しません。現在の命令のinstr_number値は、以前の命令のinstr_number値を追加することにより計算されます。％B11-指定された命令は、以前と同じセッションに関係しない場合があります。フィールドセッション_IDはそれに存在します。Fields Chain_Numberとinstr_Numberの存在は、CHNフラグで定義されます。
CHN
Chn
1 bit. The flag of chain. Transmitted on one session connection and concerning one job instructions, may be unified in a chain. Chains are considered in details by section 7. If SEQ = 1, the instruction is connected with chain and there are fields CHAIN_NUMBER and INSTR_NUMBER (if PCK is not set to %b10) at it. If bit CHN = 0, the instruction is not connected with chains and there are no fields CHAIN_NUMBER and INSTR_NUMBER in it.
1ビット。チェーンの旗。1つのセッション接続で送信され、1つのジョブの指示に関して、チェーンで統一される場合があります。チェーンはセクション7で詳細に考慮されます。SEQ= 1の場合、命令はチェーンに接続されており、chain_numberとinstr_number（pckが％b10に設定されていない場合）があります。BIT Chn = 0の場合、命令はチェーンに接続されておらず、その中にchain_numberとinstr_numberがありません。
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) オペランドの長さは、2オクテットのヘッダーの圧縮よりも、4オクテットのフィールドアライメントを行う場合は24オクテット（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.
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 1つの命令で262240を超えるオクテットの長さのデータを送信します。
The extension headers have the following common format:
拡張ヘッダーには、次の共通形式があります。
Octets:
+0 +1
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: |HXT| HEAD_LENGTH | HEAD_LENGTH_EXT |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | continued HEAD_LENGTH_EXT |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
4: |HSL|HOB|HRZ| HEAD_CODE | HEAD_CODE_EXT |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
6: | RESERVED |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
8: | |
/ DATA /
/ /
| |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
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
ホブ
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
予約済み
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の場合、このフィールドはさらに使用するために予約されています。予約されたフィールドは、プロトコルの現在の実現での受信中にプロトコルによって分析されてはなりません。送信時に0に設定する必要があります。
DATA
データ
The data field of the extension header. If HXT = 0, the length of field is 0 - 254 octets, if HXT = 1, the length is 0 - 4 * 10^9 octets. The format of this field is defined separately for each value of the header code.
拡張ヘッダーのデータフィールド。 HXT = 0の場合、フィールドの長さは0〜254オクテットです。HXT= 1の場合、長さは0-4 * 10^9オクテットです。 このフィールドの形式は、ヘッダーコードの各値に対して個別に定義されます。
On the receiving side, the extension headers must be processed in that order, in what they follow in the instruction. If the instruction contains more than 30 extension headers, it is considered erroneous. It is necessary to break off the session connection, on which it was transmitted, after the reception of such instruction.
受信側では、拡張ヘッダーをその順序で、指示に従うもので処理する必要があります。命令に30を超える拡張ヘッダーが含まれている場合、それは誤っていると見なされます。そのような指示を受け取った後、それが送信されたセッション接続を壊す必要があります。
The identifiers HEAD_LENGTH and HEAD_CODE are used further in the text at the description of the extended headers format. It assumes using of fields HEAD_LENGTH + HEAD_LENGTH_EXT and HEAD_CODE + HEAD_CODE_EXT, if HXT = 1. The headers with the code 0 - 30 can be sent in short (HXT = 0) and in extended (HXT = 1) format.
識別子head_lengthとhead_codeは、拡張ヘッダー形式の説明でテキストでさらに使用されます。Fields head_length head_length_extとhead_code head_code_extの使用を想定します。hxt= 1の場合、コード0〜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.
Operandsフィールドには命令データが含まれています。オペランドフィールドの長さは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: |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|1 0| Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4: | Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8: | IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12:| Local memory address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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-Addressは、指定されたタイプのノードを明確に定義します。TCPは、そのようなノードとの相互作用に使用されます。応答手順を必要としないために、UDPを使用することが許可されます。IANAはポートTCPとUDP 2110を割り当てました。このポートは、リスニング（受信）のために開いている必要があります。TCPノード、接続の開口部の初期化、またはUDPノードがパッケージ送信を実行すると、任意のポートを使用できます。多重化といくつかのTCP接続を使用することが想定されています。
4 Response of the Instructions
4指示の応答
The protocol instructions are divided into two types:
プロトコル命令は、2つのタイプに分割されます。
(1) The management instructions transmitted on UMSP layer (OPCODE = 1 - 112). (2) The instructions of the exchange between VM (OPCODE = 128 - 223).
(1) UMSPレイヤー（opcode = 1-112）に送信される管理手順。（2）VM間の交換の指示（OpCode = 128-223）。
The processing of two types of the instructions differs as follows:
2種類の命令の処理は、次のように異なります。
o The field of the identifier of request REQ_ID is formed by the protocol in the instructions of the first type, and it is formed by VM for the instructions of the second type. o The protocol must analyze the field REQ_ID and compare it with the instructions, transmitted earlier, after receiving of the response instruction of the first type. o The protocol must not analyze the field REQ_ID after receiving of the response instruction of the second type. This instruction is simply sent to VM.
o Request REQ_IDの識別子のフィールドは、最初のタイプの命令でプロトコルによって形成され、2番目のタイプの命令のためにVMによって形成されます。 oプロトコルは、最初のタイプの応答命令を受け取った後、先に送信された指示と比較して、フィールドReq_IDを分析し、それを比較する必要があります。 oプロトコルは、2番目のタイプの応答命令を受信した後、フィールドReq_IDを分析してはなりません。 この命令は、単にVMに送信されます。
The response instructions have the field ASK equal to 1. It means, that the header have the field REQ_ID. The value taken from the confirmed instruction is written into the field REQ_ID. The response instruction does not require response.
応答命令には、フィールドに1に等しい質問があります。つまり、ヘッダーにはフィールドがreq_idを持っていることを意味します。確認された命令から取得した値は、フィールドreq_idに書き込まれます。応答命令は応答を必要としません。
A few VM can be connected to the protocol on the node. Everyone VM can work in its own address space. The identifiers of requests for different VM can coincide. Therefore, instruction is identified by two fields:
いくつかのVMをノード上のプロトコルに接続できます。誰もが独自のアドレス空間で動作することができます。異なるVMのリクエストの識別子が一致する可能性があります。したがって、命令は2つのフィールドによって識別されます。
o The session identifier SESSION_ID, which is connected with definite VM. o The request identifier REQ_ID.
o 明確なVMに接続されているセッション識別子セッション_ID。o要求識別子req_id。
"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.
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.
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.
o ジョブの開始と完了。oタスクの開始と完了。oセッション接続の開閉。oノードのアクティビティ制御。
The instructions with OPCODE = 1 - 112 are used for jobs management. These instructions must be sent through TCP. Use UDP is not allowed, even if the instructions do not demand response.
OpCode = 1-112の指示は、ジョブ管理に使用されます。これらの指示はTCPを介して送信する必要があります。指示が応答を要求しない場合でも、UDPを使用することは許可されていません。
UMSP bases on model with the centralized control of the separate job. The reason is that the pointers control is not obviously possible in the decentralized system. Any task can be finished at any moment or the node can be reloaded. There is no way guaranteeing the notification about in the decentralized system all other nodes, on which the job works. As the job continues to exist - the task concerning the job can be initiated on the same node again. This task can allocate new dynamic resources. The addresses for the again allocated resources can be crossed with addresses of resources, which existed on the node before the task restart. The old pointers can be kept on other nodes. It may be the formally correct pointers, but they will actually specify other objects. The uncontrollable work of the application can be consequence of such situation.
UMSPは、個別のジョブの集中制御を備えたモデルに基づいています。その理由は、分散型システムではポインター制御が明らかに不可能であるためです。任意のタスクをいつでも終了するか、ノードをリロードできます。ジョブが機能する他のすべてのノードの分散型システムの通知を保証する方法はありません。ジョブが存在し続けるにつれて、ジョブに関するタスクは同じノードで再び開始できます。このタスクは、新しい動的リソースを割り当てることができます。再び割り当てられたリソースのアドレスは、タスクの再起動前にノードに存在するリソースのアドレスと交差することができます。古いポインターは、他のノードに保持できます。それは正式に正しいポインターかもしれませんが、実際に他のオブジェクトを指定します。アプリケーションの制御不能な作業は、そのような状況の結果である可能性があります。
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）が各タスクに割り当てられます。GTIDには、ノードメモリの128ビットアドレスがあるのと同じ形式があります。ローカルメモリのアドレスは、LTIDに置き換えられます。oグローバルなジョブ識別子（GJID）が各ジョブに割り当てられます。GJIDはJCPノードで定義されています。ノードJCPメモリの128 -BITアドレスが持っているのと同じ形式があります。ローカルメモリのアドレスは、ジョブの最初の（初期）タスクのCTIDに置き換えられます。GJIDは、ジョブを制御する定義JCPのセッション接続開口の手順で使用されます。
LTID and CTID are written at the instructions in the field of length 2/4/8 octets. If the allocated for identifier field in the instruction is longer than identifier, LTID (CTID) writes in the last octets. In the initial octets, the value 0 must be written. If received LTID (CTID) is shorter than the local memory address, it is necessary to pad it with the zero octets in the beginning.
LTIDとCTIDは、長さ2/4/8オクテットのフィールドの指示で書かれています。命令の識別子フィールドに割り当てられた割り当てが識別子よりも長い場合、LTID（CTID）は最後のオクテットに書き込みます。最初のオクテットでは、値0を記述する必要があります。受信したLTID（CTID）がローカルメモリアドレスよりも短い場合、最初はゼロオクテットでパッドする必要があります。
GTID and GJID are written at the instructions in the field of length 4-16 octets. The field FREE is not present at these identifiers (see section 2.1). It is considered, that it contains the zero-value octets. Length of the identifier is defined in header of the address.
GTIDとGJIDは、長さ4〜16個のオクテットのフィールドの指示で書かれています。フィールドフリーは、これらの識別子には存在しません（セクション2.1を参照）。ゼロ値のオクテットが含まれていると考えられています。識別子の長さは、アドレスのヘッダーで定義されます。
By sending of instructions CONTROL_REQ, TASK_REG and SESSION_OPEN, the protocol uses timeout. The value of timeout is assigned by node and must be more than three intervals of the maximal time of delivery at the transport layer. The timeout is not influenced the waiting period in queue to the transport layer.
control_req、task_reg、およびsession_openを送信することにより、プロトコルはタイムアウトを使用します。タイムアウトの値はノードによって割り当てられ、輸送層での最大配信時間の3つ以上の間隔を上げる必要があります。タイムアウトは、輸送層のキューの待機期間に影響を与えません。
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:
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で説明されているように、登録されたジョブの異常の終わりに関する通知が送信されます（ノードは考慮されています。リロード）。その後、新しいジョブの開始に対する制裁が送信されます。（2）ノードが受信LTIDに登録されたジョブがない場合、新しいジョブの開始を一度に許可します。
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.
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に割り当てられているのは、PART 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_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.
The job is executed on several nodes simultaneously. The task, appropriate to it, must be initialized on each node. There is corresponding only one task to one job on the node. Each task must be connected only with one job.
ジョブは、いくつかのノードで同時に実行されます。適切なタスクは、各ノードで初期化する必要があります。ノード上の1つのジョブに対応するタスクは1つだけです。各タスクは、1つのジョブでのみ接続する必要があります。
The task is initiated together with the job on the node, which had created the job. On the other nodes, the task is initiated during the receiving of the first request on the opening of the session connection, which is appropriate to the job. The request about openings of session connection contains GJID. GJID contains the JCP address. It is necessary to receive the sanction from JCP for the task start. If the request about the opening of session has been received from JCP node, it is not necessary to request the sanction.
タスクは、ジョブを作成したノード上のジョブとともに開始されます。他のノードでは、タスクは、ジョブに適したセッション接続の開設に関する最初のリクエストの受信中に開始されます。セッション接続の開設に関する要求には、GJIDが含まれています。GJIDにはJCPアドレスが含まれています。タスク開始のためにJCPから制裁を受ける必要があります。JCPノードからセッションの開設に関するリクエストを受け取った場合、制裁を要求する必要はありません。
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）（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).
The instruction TASK_REG must be sent only if the task with given GJID was not initiated on the node.
指示task_regは、指定されたGJIDを使用したタスクがノードで開始されなかった場合にのみ送信する必要があります。
JCP confirms initiation of a task at observance of the following conditions:
JCPは、次の条件を遵守してタスクの開始を確認します。
(1) Task with received GTID already has registered on JCP. (2) Task with LTID for the node requesting for initiation has not registered.
(1) 受信したGTIDのタスクは、すでにJCPに登録されています。 （2）開始を要求するノードのLTIDを使用したタスクは登録されていません。
In all other cases, JCP will not confirm a task.
他のすべての場合、JCPはタスクを確認しません。
If JCP confirms the task, it will send the instruction TASK_CONFIRM, differently TASK_REJECT.
JCPがタスクを確認した場合、命令task_confirmを送信します。
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
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.
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_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.
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 Nodeでチェックアップする場合があります。
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）（task_chk）の命令はノードから送信されます。ノードは、JCPにセッション接続セッション_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.
JCPは、GTIDおよびLTIDを受信したタスクが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.
セッション接続は、1つのジョブの2つのタスク間に確立されます。この接続はVMイニシアチブの下で確立され、VM間の指示の交換に使用されます。
One session connection must be connected only with one task on the node. The task may have several connections with different nodes. Between two nodes must be only one session connection with one GJID.
1つのセッション接続は、ノード上の1つのタスクでのみ接続する必要があります。タスクには、異なるノードといくつかの接続がある場合があります。2つのノード間は、1つのGJIDとの1つのセッション接続のみである必要があります。
The request about the establishment of session connection contains the global identifier of the job GJID. If the node receives the request about the establishment of connection with GJID, which is not presented on the given node, VM must create a new task. If the task has been already initialized, the new task is not created.
セッション接続の確立に関する要求には、ジョブGJIDのグローバル識別子が含まれています。NODEがGJIDとの接続の確立に関する要求を受信した場合、指定されたノードに表示されない場合、VMは新しいタスクを作成する必要があります。タスクがすでに初期化されている場合、新しいタスクは作成されません。
The session connection needs to be established over TCP. After the connection is established, the sending of the instructions, which are not require of execution response, is possible through UDP. One TCP connection may be used by several session connections. One session connection may use several TCP connections.
セッション接続は、TCPを介して確立する必要があります。接続が確立された後、実行応答を必要としない命令の送信は、UDPを通じて可能です。1つのTCP接続は、いくつかのセッション接続で使用できます。1つのセッション接続では、複数のTCP接続を使用できます。
The protocol allows working without the establishment of session connection. The node must have VM by default, which must execute the instructions without the establishment of connection.
このプロトコルは、セッション接続を確立せずに動作することができます。ノードにはデフォルトでVMが必要である必要があります。これにより、接続の確立なしに命令を実行する必要があります。
At the establishment of session connection, the sides agree about the used VM type and the subset of the protocol functions. The session connection UMSP may be asymmetrical. It means, that two sides of one connection can be connected with VM of the different type and provide the different subset of the protocol functions.
セッション接続の確立で、側面は使用済みのVMタイプとプロトコル関数のサブセットについて同意します。セッション接続UMSPは非対称である可能性があります。つまり、1つの接続の2つの側面を異なるタイプのVMに接続し、プロトコル関数の異なるサブセットを提供できることを意味します。
If at an establishment of session connection the zero-type VM is used, it specifies group VM (see section 9). The zero-value of realization VM is not allowed.
セッション接続の確立でゼロタイプVMが使用される場合、グループVMを指定します（セクション9を参照）。実現VMのゼロ値は許可されていません。
The procedure of the establishment of session connection may contain from 2-way up to 8-way handshakes.
セッション接続の確立の手順には、2方向から8方向の握手まで含まれる場合があります。
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).
If the VM type and version, required from the addressee, have the value 0, the receiving node independently chooses the VM type and reports it in the response. The establishment of connection without binding to VM or VM group is not allowed.
宛先から必要なVMタイプとバージョンの値0がある場合、受信ノードは個別にVMタイプを選択し、応答でそれを報告します。VMまたはVMグループへの拘束なしの接続の確立は許可されていません。
Totally, it can be transmitted up to 7 instructions SESSION_OPEN at the establishment of connection. The instruction SESSION_ACCEPT is used for the response of the establishment of connection. For the refusal of connection the instruction, SESSION_REJECT is used.
完全に、接続の確立時に最大7つの命令session_openに送信できます。命令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.
接続の確立中に、次のパラメーターを変更できます。OVMタイプとVMバージョン。o接続のプロファイル。
If the repeated request about opening of session connection is received from the definite node, while one connection with received GJID have been already established, the following variants are possible:
セッション接続の開くことに関する繰り返しの要求が明確なノードから受信されている場合、受信したGJIDとの1つの接続がすでに確立されている場合、次のバリアントが可能です。
(1) If the request has arrived from the node JCP, it is necessary: o To finish the existing task emergency and to deallocate all dynamic resources belong to it. o To initiates a task without request of the JCP sanction again. o To confirm the establishment of connection. (2) If the request arrived not from the JCP node, it is necessary to refuse the establishment of new session connection. The existing task does not need to be changed.
(1) リクエストがノードJCPから届いた場合、既存のタスクの緊急事態を完了し、すべての動的リソースに属するすべてのダイナミックリソースを扱う必要があります。o 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.
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
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.
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-OCTETフィールドで定義されています。フラグには識別子S0 -S31があります。識別子の数字は、ビットのシリアル数を定義しています。フラグが1に設定されている場合、それに接続された関数が提供されます。フラグが0に設定されている場合、それに接続された関数は提供されません（不要）。セッション接続の確立で決定される関数のリストについては、さらに説明します。
Work with chains:
チェーンを使用して作業：
S0 - Use of fragmented instructions. S1 - Use of sequences. S2 - Use of transactions.
S0-断片化された命令の使用。S1-シーケンスの使用。S2-トランザクションの使用。
Establishment of connection:
接続の確立：
S3 - Use the exchange of the data without the establishment of connection. S4 - Use the exchange of the data with the establishment of connection.
S3-接続の確立なしにデータの交換を使用します。S4-接続の確立とデータの交換を使用します。
The instructions format:
指示形式：
S5 - Reserved. Must have set to 0.
S6 - Use of 16-octet address in the exchange instructions.
S7 - Use of the compressed form of header of the instruction
(OPR_LENGTH < > %b111) is allowed
S8 - Use of the extension form of header of the instruction
(OPR_LENGTH = %b111) is allowed
S9 - Use of the extension headers with the data field up to 254
octets of length.
S10 - Use of the extension headers with the data field up to 4 *
10^9 octets of length.
S11-S15 Maximal length of the data field in operands in the 4
octet words. These bits are the common field. Maximal
length in octets is computed under the formula:
<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.
The permissible instructions:
許容される指示：
S23 - The response of the execution on VM (instruction RSP) is provided. S24 - Use of data reading and comparison instructions. S25 - Use of data writing instructions. S26 - Use of control transfer instructions. S27 - Use of synchronize instruction. S28 - Use of instructions of work witch objects. S29 - Use of the immediate access to memory of object. If this flag is set to 0, the access to object is solved only through its procedures. If S28=0, this flag must be set to 0. S30 - Use of instruction MVRUN in zero-session. S31 - Reserved. Must have set to 0.
S23 -VM（命令RSP）での実行の応答が提供されます。S24-データの読み取りと比較手順の使用。S25-データ作成手順の使用。S26-制御転送命令の使用。S27-同期命令の使用。S28-作業魔女のオブジェクトの指示の使用。S29-オブジェクトのメモリへの即時アクセスの使用。このフラグが0に設定されている場合、オブジェクトへのアクセスはその手順によってのみ解決されます。S28 = 0の場合、このフラグは0に設定する必要があります。S30-ゼロセッションでの命令MVRUNの使用。S31-予約。0に設定する必要があります。
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.
Node Aはセッションの確立の開始者であり、ノードBは接続の2番目の側面です。ノードaは、閉じるセッションのために命令セッション_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から受信されていない場合、ノードは命令セッション_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.
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:
命令「セッションの別れ」セッション_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.
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.
o ノード上のタスクをメンテナンスするためのコンピューティングリソースは十分ではありません。oノードが作業を終了します。o VMが内部的な理由でそのような決定を受け入れた場合。
The references to the resources allocated by the task can be on any node, on which the job is carried out. Therefore, all nodes must be notified of the end of the task.
タスクによって割り当てられたリソースへの参照は、ジョブが実行される任意のノードにあります。したがって、すべてのノードにタスクの終了を通知する必要があります。
Node, finishing the task, must abnormally close all session connections joining the finished task (to send the instruction SESSION_ABEND).
タスクを終了するノードは、完成タスクに参加するすべてのセッション接続を異常に閉じる必要があります（命令セッション_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）の命令は、ノードから送信され、その上でタスクが終了します。命令には、フィールドの次の値があります。
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.
After sending of the instruction TASK_TERMINATE to JCP, the node sends the instruction of unconditional end of connection ABEND_SESSION on all session connections connected with a task. After that, the task is considered completed.
命令task_terminateをJCPに送信した後、ノードは、タスクに接続されたすべてのセッション接続の接続abend_sessionの無条件の終了の命令を送信します。その後、タスクは完了したと見なされます。
If the basic return code in the instruction TASK_TERMINATE is equal to 0, it is not required to notify other nodes about the end of the task. Such situation arises, if the task did not allocate dynamic resources. If the basic return code is unequal to 0, JCP must notify about the task end the other nodes, on which the job is carried out, after reception of the instruction TASK_TERMINATE. JCP responds for the notification of all nodes of the job about the task end.
命令task_terminateの基本的な返品コードが0に等しい場合、タスクの最後について他のノードに通知する必要はありません。タスクが動的リソースを割り当てなかった場合、そのような状況が発生します。基本的な返品コードが0に不平等である場合、jcpはタスクの終了について通知する必要があります。他のノードは、命令task_terminateを受信した後、ジョブが実行される他のノードを実行します。JCPは、タスクの終了に関するジョブのすべてのノードの通知に対して応答します。
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.
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.
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を送信した後、ノードは、ジョブのセッション接続に接続されているすべてのものを送信します。その後、ジョブは完了したと見なされます。
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はジョブの終了を通知しなければなりません。ノードは、職務を受信した後、ジョブが実行されたノードを実行します。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.
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は、lifetimeの終わりまたは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命令。この場合、リロード後に誰でも適切な人を適切にすることができます。（2）JCPノードの緊急切断があります。非アクティブ化についてすべてのノードに通知していません。この場合、リロード後に、新しいGJIDは、不活性時間の2つの最大間隔（このJCPを設定）の間に、リロードまで存在する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:
拡張ヘッダー「The Time of Inaction」（_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データが含まれています：2オクテット：不作為期間。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_regからの時間がJCPに適合しない場合、命令task_rejectに。（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 Request」（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.
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.
If OPR_LENGTH = 1 that length of the reserved field is equal to one octet and length CTID makes two octets. In all other cases, length of the reserved field is equal 3 octets and length CTID - not less than 4 octets.
opr_length = 1の場合、予約済みフィールドのその長さは1オクテットに等しく、長さCTIDは2オクテットを作成します。他のすべての場合、予約済みフィールドの長さは等しい3オクテットと長さのCTID（4オクテット以上）です。
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:
state_req命令に対する否定的な応答として、「ノードがリロードされた」（node_reload）（node_reload）の命令はJCPに送信されます。 node_reloadには、フィールドの次の値があります。
OPCODE = 23
PCK = %b00
CHN = 0
ASK = 0
EXT = 0
OPR_LENGTH = 1/2 ; Depends on the LTID length.
Operands:
4/8 octets: LTID. The value is taken from the instruction
STATE_REQ.
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をノードのすべてのタスクに送信します。これは、最後から2番目の命令state_reqを送信する前に開始されました。（2）最後の命令State_Req（否定的な応答が受信される）を送信した後、1つの不作為間隔が終了するのを待つ。（3）state_reqをノードのすべてのタスクに送信する。最後の命令と最後から2番目の命令State_Req（項目1からの指示を含めない）の間で開始された。
For all instructions STATE_REQ the positive response (TASK_STATE) or negative response (RELOAD_NODE) must be transmitted.
すべての命令state_req正の応答（task_state）または否定的な応答（reload_node）を送信する必要があります。
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.
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にはフィールドセッション_IDとreq_idにも値があります。ゼロセッションによるデータの交換は、それに関係なく発生する可能性があります。
There are the following restrictions at working without connection:
接続なしで作業することには次の制限があります。
o The chain must be sent, only if it is completely located in one segment of the transport layer. o It is impossible to request an allocation of memory and to create objects (except instruction MVRUN). This objects is not adhered to the definite job and is not automatically release the resources at the end of the job, which has created them. o Parameters of functions and the returned values must not contain the pointers, because the node can be reloaded at any moment. It will result that the pointers will become invalid or will address other objects.
o チェーンは、輸送層の1つのセグメントに完全に配置されている場合にのみ送信する必要があります。oメモリの割り当てを要求し、オブジェクトを作成することは不可能です（命令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).
o 運用システムを持たない単純なデバイスで。o多くのリクエストが実行されるサーバーで（リソースを接続することなく作業のために使用されます）。oまれな要求への迅速な応答を必要とするシステムで（接続の維持が不安になる場合）。
6 Instructions of Exchange between VM
6 VM間の交換の指示
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の値オペコードを使用します。オペランドフィールドの長さに応じて、1つのオペコードに対していくつかの形式の命令を定義できます。完全な命令形式は、フィールド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.
命令には、命令ヘッダーフラグが尋ねられた場合、フィールドReq_IDがあります。このフィールドの値はVMによって指定されます。応答もVMによって形成されます。プロトコルは応答をチェックせず、VM間の交換の指示についてフィールドREQ_IDの値を分析しません。指示RSP、データ、返信、アドレス、オブジェクト、またはPROC_NUMの1つは、応答の送信に使用されます。応答の命令にはask = 1があり、確認された命令から取得した値は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;
o ask = 0;o命令は1つのセグメントUDPにあります。
The timeouts and the repeated sending are not used at UMSP layer for instructions of exchange between VM. It is explained to, that the time of sending instructions with low priority may be very large because of the output queues. Therefore, the VM must make a decision on timeout, as only VM has the complete information on type of the transmitted data. Besides, the transport layer protocol must use the timeouts.
タイムアウトと繰り返しの送信は、VM間の交換の指示のためにUMSP層では使用されません。出力キューのために、優先度の低い指示を送信する時間は非常に大きい場合があることが説明されています。したがって、VMのみが送信されたデータのタイプに関する完全な情報を持っているため、VMはタイムアウトで決定を下す必要があります。また、トランスポート層プロトコルはタイムアウトを使用する必要があります。
A few VM may be connected to the protocol on the node. VM may simultaneously execute several jobs. Each job may work in its address space. The protocol determines VM and job, which the received instruction must transfer to, on field SESSION_ID value.
いくつかのVMがノード上のプロトコルに接続される場合があります。VMは、複数のジョブを同時に実行する場合があります。各ジョブは、アドレス空間で機能する場合があります。プロトコルはVMとジョブを決定し、受信した命令はフィールドセッション_ID値で転送する必要があります。
The local memory address is located in the instruction in field of length 2/4/8 octets. If memory address length in the instruction is not equal to memory address length defined for the node, the following variants are possible:
ローカルメモリアドレスは、長さ2/4/8オクテットのフィールドの命令にあります。命令のメモリアドレスの長さがノードで定義されたメモリアドレスの長さに等しくない場合、次のバリアントが可能です。
o If memory address length is set in 24 bits for the node, the address is writes in the end of 4 - octets field. The 0 value sets in an initial (zero) octet.
o ノードのメモリアドレスの長さが24ビットで設定されている場合、アドレスは4 -Octetsフィールドの最後に書き込みます。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.
o 命令形式でメモリアドレスの長さが4オクテット以上を想定している場合、最後のオクテットには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を参照）。完全なアドレスがゼロに設定されている場合、オペランドでローカルアドレスを使用することをお勧めします。
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.
トランスファーコントロールジャンプ、コール、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 = 130/131;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:
命令「データ」（データ）は、命令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:
「データを書き込む」（書き込み）の命令は、リモートノードでのデータ作成に使用されます。命令には、フィールドの次の値があります。
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は、命令書に返信して送信されます。ゼロの基本返品コードは、通常の実行を定義します。
The instruction "The extension writing of data" (WRITE_EXT) is used for the data writing on the remote node. Length of the data may be 1 - 262132 octets with a step 1 octet. The instruction has the following values of fields:
命令「データの拡張書の書き込み」（write_ext）は、リモートノード上のデータ作成に使用されます。 データの長さは、ステップ1オクテットで1〜262132オクテットになる場合があります。 命令には、フィールドの次の値があります。
OPCODE = 137 OPR_LENGTH = 3 - 65535 ; Depends on length of the immediate data. Operands: 1 octets: Always set to zero. 3 octets: The number of the write data in octets. The zero-value is not available. 4 - 262132 octets: Immediate data for write. The data length must be multiple of 4 octets. 4/8/16 octets: The memory address for writing the data.
opcode = 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.
即時データを4オクテットの倍数にするために、データは、フィールドの端に1〜3ゼロの価値のオクテットでパッドで埋められます。
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オクテットで1〜262132オクテットになる場合があります。命令には、フィールドの次の値があります。
OPCODE = 142 OPR_LENGTH = 3 - 65535 ; Depends on length of the immediate data and the address. Operands: 1 octet: Always set to 0. 3 octets: The length of compared data in octets. The zero-value is not available. 4 - 262132 octets: The immediate data for the comparison. The length of field is multiple of 4 octets. 4/8/16 octets: The memory address of compared data.
opcode = 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.
即時データを4オクテットの倍数にするために、データは、フィールドの端に1〜3ゼロの価値のオクテットでパッドで埋められます。
The instruction RSP is sent in reply to the instruction CMP, CMP_EXT and OBJ_CMP (see below). If the comparison was executed, the basic return code is equal to zero. The additional return code is equal to -1, if the data at the address memories are less then the data from the operand; 0, if they are equal; and 1, if they are more. If the comparison cannot be executed, the basic return code of the instruction RSP must be non-zero.
命令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:
「無条件のジャンプ」（ジャンプ）と「コールスブルーティンへ」（コール）_命令は等しい形式を持ち、OpCodeによってのみ異なります。これらの指示には、フィールドの次の値があります。
OPCODE = 143/144 ; Correspondingly for the JUMP not containing and containing the information about VM.
opcode = 143/144;それに対応して、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.
145/146;それに対応して、VMに関する情報を含めていないと含む呼び出し。opr_length = 2-65535;VM、アドレスの長さ、パラメーターの長さに関する情報の含有に依存します。オペランド：2オクテット：送信者のVMタイプ。opcode = 143/145の場合、このフィールドは存在しません。2オクテット：送信者のVMバージョン。opcode = 143/145の場合、このフィールドは存在しません。4/8/16オクテット：コントロールを転送するために必要なメモリのアドレス。2オクテット：コールパラメーターフィールドの32ビットワードの数。4-262134オクテット：直接のデータは、呼び出しのパラメーターです。
On the reception side the processing of the instructions of a control transfer occurs as follows:
受信側では、制御転送の指示の処理が次のように発生します。
o The memory address is checked. If it has erroneous value, the negative response RSP is sent. At this stage, the correctness of parameters of a call may be also checked up. o If the memory address and the parameters of a call have correct value, the positive response RSP is sent for the instruction JUMP. The transmitting side considers the instruction JUMP executed after receiving response. o For response of an execution of the instruction CALL the instruction RETURN is sent. The instruction RETURN may contain the returned values. If there is an exception condition in a thread of control created by the CALL instruction, the instruction RSP with a non-zero basic return code is sent instead of RETURN.
o メモリアドレスがチェックされます。誤った値がある場合、否定的な応答RSPが送信されます。この段階では、呼び出しのパラメーターの正確性もチェックアップできます。oメモリアドレスと呼び出しのパラメーターが正しい値を持っている場合、instruction命令ジャンプのために肯定的な応答RSPが送信されます。送信側は、応答を受け取った後に実行された命令ジャンプを考慮します。o命令の実行の応答については、命令返品が送信されます。命令返品には、返された値が含まれている場合があります。コール命令によって作成されたコントロールのスレッドに例外条件がある場合、ゼロ以外の基本返品コードを備えた命令RSPが返される代わりに送信されます。
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 of Control」（RETURN）は、指示コール、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.
返品値を送信する必要がない場合、命令返品にはオペランドが含まれていません。データ形式は命令と一致し、そのための応答（送信者または宛先のフォーマット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によって形成され、受信者の必要なすべての情報を含める必要があります。コードを同時にオペランドとエクステンションヘッダーに送信してはなりません。
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で転送されるコードは、命令ジャンプまたは呼び出しによって実行される場合があります。
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:
命令「メモリアドレス」（アドレス）は、命令MEM_ALLOCおよびMVCODEの肯定的な応答に使用されます。アドレスには、フィールドの次の値があります。
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で割り当てられたメモリは、明示的にリリースする必要があります。この目的のために、「メモリを解放するための」（無料）の指示が使用されます。フィールドの値は次のとおりです。
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の命令に対する答えは、命令呼び出しと同様に形成されます。この命令によってコードに割り当てられたメモリをリリースする必要はありません。メモリは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）（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.
追跡データは、最初のオペランドのメモリアドレスによって設定されます。これらのデータは、もともと2番目のオペランドの初期データ値と比較されます。値が一致しない場合、データが変更されたことが考慮されます。3番目のオペランドでは、比較のためにマスクを設定できます。マスクの1ビットに設定されているのは、データのビットを指定します。これは、変更する必要があります。
The following variants of the answer are probable on the instruction:
答えの次のバリアントは、命令で可能性があります。
o If the address of local memory is incorrect, the instruction RSP with the non-zero basic return code is sent for the response. o If the data do not change, in the response nothing is sent. o If the data have changed, the instruction DATA with new value of the traced data is sent.
o ローカルメモリのアドレスが正しくない場合、ゼロ以外の基本返品コードを使用した命令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 セッションを送信するための他の指示がない場合は、断片化された命令とトランザクションを確立された特別な処理フラグでカプセル化します（セクション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
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.
Range 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つのジョブのフレームワーク内で動的に作成されたオブジェクトを対象としています。これらのオブジェクトは、ジョブの孤立した連想記憶です。これらのオブジェクトへのアクセスは、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つのオブジェクトの最大データサイズを制限します。指定されたセクションで明確な命令は、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 = 192/193;長さ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オクテットで1〜262132オクテットになる場合があります。命令には、フィールドの次の値があります。
OPCODE = 197 OPR_LENGTH = 3 - 65535; Depends on the data length and the address length. Operands: 4 octets: The number of object. 2 octets: The version of object. 2 octets: The realization of object. 1 octet: Always set to 0. 3 octets: Length written down data in octets. The zero-value is incorrect. 4 - 262124 octets: The immediate data for write. Length of the data is multiple of 4 octets. 2/4/8 octets: Offset in object for the data write.
opcode = 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.
書かれたデータの長さが4オクターの倍数でない場合、データは最後に1〜3ゼロオクテットでパディングされます。
The instruction RSP is sent in reply to the instructions OBJ_WRITE_EXT. The zero basic return code defines the normal execution.
命令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オクテットで1〜262132オクテットになる場合があります。 命令には、フィールドの次の値があります。
OPCODE = 201 OPR_LENGTH = 5 - 65535 ; Depends on length of the immediate data and the address length. Operands: 4 octets: The number of object. 2 octets: The version of object. 2 octets: The realization of object. 1 octet: Always set to 0. 3 octets: The length of compared data in octets. The zero-value is incorrect. 4 - 262124 octets: The immediate data for the comparison. The length of field is multiple of 4 octets. 4/8 octets: Offset in object for the compared data.
opcode = 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.
即時のデータを4オクテットの倍数にするために、データは最後に1〜3のゼロ値のオクテットでパディングされます。
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).
受信側の処理も同様に指示通話を行います（セクション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 = 204/205;したがって、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).
受信側の処理も同様に指示通話を行います（セクション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の肯定的な応答については、nestor -ゼロの基本返品コードを備えたrspの命令proc_numが送信されます。
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つのタスクのフレームワーク内では、1つの番号または1つの名前を持つ2つのオブジェクトであってはなりません。
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）の両方の命令の形式は似ています。最初の命令は、範囲IV、2番目 - 範囲IIIにオブジェクトを作成します。これらの指示には、フィールドの次の値があります。
OPCODE = 208/209; Accordingly for NEW/NEW_SYS. OPR_LENGTH = 3 Operands: 2 octets: The addressee VM type. 2 octets: The addressee VM version. 2 octets: The version of object. 2 octets: The realization of object. 4 - 262136 octets: Immediate data necessary for creation of object. The extension headers: _DATA - Contains immediate data, necessary for creation of object. This header is present, only if the data is not present in operands. _NAME - Contains the name of object. This header is optional.
opcode = 208/209;したがって、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は、あらゆるジョブ、新しいものからアクセス可能なオブジェクトの作成に使用されます - ジョブからのみアクセスできるオブジェクトの作成に使用されます。オブジェクトが作成された場合、命令オブジェクトが応答のために送信されます。オブジェクトを作成できない場合、ゼロ以外の基本返品コードを備えた命令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.
直接のデータフィールドは、プロトコルの透明です。Sender 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.
命令のフィールドセッション_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:
「オブジェクトを削除する」（削除）命令は、newまたはnew_Sysで作成されたオブジェクトの削除に使用されます。命令削除には、フィールドの次の値があります。
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.
ノード上のオブジェクトの登録時に、名前で4〜254オクテットの長さで識別される場合があります。名前にはシンボルASCIIが含まれています。次のバージョンのプロトコルは、他のタイプの名前を定義できます。
The name identifies with the number of object and is its synonym. The names of all active objects in one task on the node must be unique. Thus, all active objects from the range of number I - III 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.
名前はオブジェクトの数と識別し、その同義語です。ノード上の1つのタスクにあるすべてのアクティブオブジェクトの名前は一意でなければなりません。したがって、番号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つのセッション接続で送信される指示は、チェーンで統合できます。チェーンは、互いに関係する指示のグループです。あるセッションでは、複数のチェーンを同時に転送できます。チェーンは次のタイプにすることができます：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.
命令がチェーンに含まれている場合、フラグCHNは等しい必要があります。フィールドチェーン_Numberヘッダーには、チェーンのチェーンの数字、instr_numberの数が含まれています。1回のセッションでは、最大65533チェーンまで転送できます。チェーンの数の値％x0000および％xffffは、プロトコルによって予約されています。1つのチェーンには、最大65535命令を含めることができます。
The instruction with a zero serial number INSTR_NUMBER should contain the extension header describing a chain. Each type of a chain has own initiating extension header.
ゼロシリアル番号instr_numberを使用した命令には、チェーンを説明する拡張ヘッダーを含める必要があります。チェーンの各タイプには、独自の開始拡張ヘッダーがあります。
_END_CHAIN. The extension header "End of the chain" is transferred in last instruction of chain, irrespective of type of the chain. It has the following values of fields:
_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.
完成したチェーンの数には、拡張ヘッダーが添付されている命令ヘッダーのフィールドチェーン_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.
作成されたチェーンの数は、拡張ヘッダーが添付されている命令ヘッダーのフィールドチェーン_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データ - 次の形式があります。
+---+---+---+---+---+---+---+---+
|TRE|TRR|TRS| Reserve |
+---+---+---+---+---+---+---+---+
| TIME_TR |
+---+---+---+---+---+---+---+---+
TRE
トレ
1 bit. The flag of obligatory execution. This flag relates only to completely transferred, but have not yet executed transaction. If TRE = 1, the transaction must be executed at 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の場合、トランザクションは、存在時間の有効期限時に、フィールドタイム_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〜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
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
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つのチェーンとして送信されます。次のアルゴリズムは、カプセル化中に使用されます。（1）断片化された命令からのフィールドセッション_IDおよびREQ_IDは、最初のNOP命令で記述されます。Field Req_IDが最初の指示に存在しない場合、NOP命令に存在してはなりません。フィールドセッション_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システムの生産性は、その速度で、受け取ったものを使用して、ネットワークから受け入れられた命令を処理できるようにすることをお勧めします。すべての命令は、既知の限られたコンピューティングロードを実行するように設計されています。例外は、2つの段階で処理する必要がある制御転送の指示です。命令の正確性が最初にチェックされ、そのスケジューリングが行われます。その後、命令が実行されます。その時点で、プロトコルがプロセッサ時間のそのような部分を受信できることを保証する必要があります。これにより、固定モードで動作することができます。したがって、ノードオーバーロードの質問は、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) トランザクションと断片化された命令（どのサイズがウィンドウを超えている場合）は、受信ノードに制裁を送信することを要求する必要があります。チェーン送信の理論的制限サイズは4 gbytesです。
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のトランザクションは、輸送層の1つのセグメントに配置できる場合でも、命令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 トランザクションが輸送層の1つのセグメントにある場合、バッファリングなしで送信されます。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は、すべてのチェーンの最初の指示と懸念でのみ確立されます。Lastを含むすべての次の指示には、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.
o チェーン送信にVMが与えられたフィールドReq_IDの値は保持され、プロトコルの代わりにプロトコルによって確立された値に入ります。レセプション側の窓。リンク後、VMで実行するために送信されます。その時、チェーンはバッファ内の場所を占領し続けることができます。o実行後、VMはそれについてレセプションサイドプロトコルに通知します。oプロトコルは、割り当てられたバッファーの場所をクリアします。o他の場合と同様に、プロトコルがRSPではなくRSP_Pのチェーン確認RSP_Pを形成および送信します。o送信サイドプロトコルは、確認RSP_Pを受信した後、受信側バッファーの自由な場所のサイズを修正します。o old 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.
相対アドレス指定のメモリベースアドレスは、1つのチェーンからの指示のために確立できます。したがって、チェーンの命令で省略されたアドレスメモリフィールドを使用することができます。省略されたアドレスは、ベースからの変位として使用されます。
_SET_MBASE. The extension header "To set memory base" establishes the value of base address for chain. It has the following values of fields:
_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データが含まれています：
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:
拡張ヘッダー「アライメント」（_alignment）を使用すると、2オクテットのステップで、オペランドの拡張ヘッダーまたはオペランドの倍数を倍にすることができます。プロトコルは、拡張ヘッダーを与えられた使用規則を提供しません。任意に使用できます。ヘッダーには、フィールドの次の値があります。
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データが含まれます：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:
エクステンションヘッダー「The Any Message」（_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データが含まれています：
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データが含まれています：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つの命令で最大4個のデータを転送できます。ヘッダーには、フィールドの次の値があります。
HEAD_CODE = 11 HEAD_LENGTH = 1 - 2 147 483 647 ; Depends on length of the data field. HOB = 1 DATA contains: 2 - 4 294 967 294 octets : Binary data in an any format.
head_code = 11 head_length = 1-2 147 483 647;データフィールドの長さに依存します。HOB = 1データが含まれます：2-4 294 967 294オクテット：あらゆる形式のバイナリデータ。
The extension header "The lifetime" (_LIFE_TIME) contains value of time. It has the following values of fields:
エクステンションヘッダー「The Lifetime」（_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データが含まれます：2/4オクテット：1,024ミリ秒間隔での時間。
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.
o VMタイプ。値の範囲1-65534。OVMバージョン。値の範囲1-65534。
The protocol requires obligatory compatibility from bottom-up for VM of one type and different numbers of the versions (VM with larger number of version must be able to execute the VM code with any smaller number of version).
プロトコルでは、1つのタイプのVMのボトムアップからの義務的な互換性と、バージョンの数が多いVMは、より少ないバージョンでVMコードを実行できる必要があります）。
Numbers of VM types are broken on the following ranges:
VMタイプの数は、次の範囲で壊れています。
1 - 1023 Assigned for standard VM 1024 - 49151 Assigned for registered VM of the users 49152 - 65534 Free (defined for dynamic and/or private VM)
1-1023標準のVM 1024-49151に割り当てられたユーザーの登録VMに割り当てられた49152-65534無料（ダイナミックおよび/またはプライベートVM用に定義）
Numbers of types and versions %x0000 and %xFFFF are reserved by the protocol.
タイプとバージョンの数％X0000および％XFFFFは、プロトコルによって予約されています。
Several VM of different types may be united in a group. All VM, included in a group, must work in the common space of local memory and have the common subsystem of the jobs control. It means, that if the same 128-bit address is met in anyone VM code for one task, it must specify one physical cell of memory. The performance of the specified conditions allows executing multivendor user code (containing procedures for different VM) on one node. All VM, included in a group, must have the different types. The group can include no more than 65534 VM. One number of group on different nodes may identify groups with different structure VM.
さまざまなタイプのいくつかのVMは、グループで統合される場合があります。グループに含まれるすべてのVMは、ローカルメモリの共通の空間で作業し、ジョブコントロールの共通のサブシステムを持っている必要があります。つまり、同じ128ビットアドレスが1つのタスクに対して誰でもVMコードで満たされている場合、メモリの物理セルを1つ指定する必要があることを意味します。指定された条件のパフォーマンスにより、1つのノードでマルチベンダーユーザーコード（異なるVMの手順を含む）を実行できます。グループに含まれるすべてのVMには、異なるタイプが必要です。グループには、65534 VM以下を含めることができます。異なるノード上の1つのグループの数は、異なる構造VMのグループを識別する場合があります。
To each group VM on the node the code of group of 2 octets length is assigned. So long as the node has even one session connection, the codes of groups must not change. It is recommended to change the code of group only at reconfiguration of the node. The group VM is identified, as well as one VM. Thus, the type VM is set to 0, and the number of group is assigned to VM version.
ノード上の各グループVMに、2オクテットの長さのグループコードが割り当てられます。ノードに1つのセッション接続さえある限り、グループのコードが変更されてはなりません。ノードの再構成時にのみグループのコードを変更することをお勧めします。グループVMは、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.
グループでのAssociation 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とGroupは、指定された瞬間に明確なノードのプロトコルに接続されています。
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-65534または任意のグループVMの範囲からのVMは、名前で識別される場合があります。番号1-49151のVMは、命令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を要求する」（VM_REQ）命令により、リモートノードで接続されたVMを見つけることができます。命令には、フィールドの次の値があります。
OPCODE = 25
PCK = %b00
CHN = 0
ASK = 0/1
EXT = 0/1
OPR_LENGTH = 0 - 65534 ; Depending on quantity VM in operands.
Operands:
2 octets: The type required VM. The value 0 is not allowed.
2 octets: The version required VM. The value 0 is not allowed.
The value %xFFFF requests the most senior version.
.
.
.
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について通知するための」（VM_NOTIF）の命令は、1つの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.
. . .
。。。
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要求への応答に使用される場合、要求の命令から価値が確立されたAsk = 1およびReq_IDを含めることができます。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:
中間者に対する保護：
The protection is based on the fact, that the routes between nodes A - B, A - G and G - B is not crossed. Such scheme allows organizing the additional managing dataflow, allowing revealing such type of attack. If the specified routes pass through one gateway, this protection is less effective.
保護は、ノードA -b、a -g、およびg -b間のルートが交差していないという事実に基づいています。このようなスキームにより、追加の管理データフローを整理することができ、このようなタイプの攻撃を明らかにすることができます。指定されたルートが1つのゲートウェイを通過する場合、この保護はあまり効果的ではありません。
Authentication:
認証：
The protocol working is based on a principle of the centralized control. It allows using several schemes of authentication. The parameters of authentication are sent in the extension headers. The establishment of session connection can contain up to eight handshakes. It also raises flexibility at a choice of authentication algorithm. The realization of authentication is possible between three pairs nodes A - B, A - G and G - B. All pairs can be used in any combination. The node G can be specially allocated for realization of authentication.
プロトコルの動作は、集中制御の原則に基づいています。認証のいくつかのスキームを使用することができます。認証のパラメーターは、拡張ヘッダーで送信されます。セッション接続の確立には、最大8つの握手を含めることができます。また、認証アルゴリズムの選択で柔軟性を高めます。認証の実現は、3つのペアノードA -B、A -G、およびG -Bの間で可能です。すべてのペアは、任意の組み合わせで使用できます。ノード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.
プロトコルの命令には、明確なコンピューティングの負荷があります。ノードを投影できるようにするため、ネットワークから受け入れられているもので、そのような速度で命令を処理できます。過負荷の可能性のある理由は、命令ジャンプと呼び出しです。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 -BITアドレスが持っているのと同じ形式があります。ローカルメモリのアドレスは、ジョブの最初の（初期）タスクの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グローバルなタスク識別子は、各タスクに割り当てられます。GTIDには、ノードメモリの128ビットアドレスがあるのと同じ形式があります。ローカルメモリのアドレスは、LTIDに置き換えられます。
JCP Job Control Point. This node will control the job.
JCPジョブコントロールポイント。このノードはジョブを制御します。
LTID Locally Task IDentifier is assigned to each active task on the node. LTID length is equal to the local memory address length defined for the node.
LTIDローカルタスク識別子は、ノード上の各アクティブタスクに割り当てられます。LTIDの長さは、ノードで定義されたローカルメモリアドレスの長さに等しくなります。
VM Virtual Machine.
VM仮想マシン。
12 References
12の参照
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[1] Bradner、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] Bradner、S。、「要件レベルを示すためのRFCで使用するためのキーワード」、RFC 2119、1997年3月。
[3] Crocker, D., and P. Overell. "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[3] Crocker、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] Postel、J。、「トランスミッションコントロールプロトコル-DARPAインターネットプログラムプロトコル仕様」、STD 7、RFC 793、1981年9月。
[5] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[5] Postel、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、1980年8月。
[6] Srinivasan, R., "RPC: Remote Procedure Call Protocol Specification Version 2", RFC 1831, August 1995.
[6] Srinivasan、R。、「RPC：リモート手順コールプロトコル仕様バージョン2」、RFC 1831、1995年8月。
13 Author's Address
13著者の住所
Alexander Y. Bogdanov
アレクサンダーY.ボグダノフ
NKO "ORS" 22, Smolnaya St. Moscow, Russia 125445 RU
NKO "ORS" 22、スモルナヤセントモスクワ、ロシア125445 ru
Phone: +7 901 732 9760
EMail: a_bogdanov@iname.ru
14 Full Copyright Statement
14完全な著作権ステートメント
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。