From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3018.txt | 4539 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 4539 insertions(+) create mode 100644 doc/rfc/rfc3018.txt (limited to 'doc/rfc/rfc3018.txt') diff --git a/doc/rfc/rfc3018.txt b/doc/rfc/rfc3018.txt new file mode 100644 index 0000000..9e3beeb --- /dev/null +++ b/doc/rfc/rfc3018.txt @@ -0,0 +1,4539 @@ + + + + + + +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. + +Abstract + + This document specifies Unified Memory Space Protocol (UMSP), which + gives a capability of immediate access to memory of the remote nodes. + +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]. + + The following syntax specification uses the augmented Backus-Naur + Form (ABNF) as described in RFC-2234 [3]. + +Table of Contents + + 1. Introduction...................................................4 + 2. The UMSP Model.................................................5 + 2.1 128-bit Address Space.......................................5 + 2.2 Computing Model.............................................7 + 2.3 System Architecture.........................................9 + 3. Instruction Format............................................11 + 3.1 Instruction Header.........................................12 + 3.2 Extension Headers..........................................15 + 3.3 Instruction Operands.......................................17 + 3.4 Address Formats............................................17 + 4. Response of the Instructions..................................19 + 4.1 RSP, RSP_P.................................................20 + 4.2 SND_CANCEL.................................................20 + 5. Jobs Management...............................................21 + + + +Bogdanov Experimental [Page 1] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + 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 + + + +Bogdanov Experimental [Page 2] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + 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 + + + + +Bogdanov Experimental [Page 3] + +RFC 3018 Unified Memory Space Protocol December 2000 + + +1 Introduction + + 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. + + 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. + + 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. + + 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. + + 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. + + 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. + + + + + + + +Bogdanov Experimental [Page 4] + +RFC 3018 Unified Memory Space Protocol December 2000 + + +2 The UMSP Model + +2.1 128-bit Address Space + + 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: + + Octets + 0 1 16 + +------+--------------+--------------------+----------------+ + |Header| FREE | NODE_ADDR | MEM_ADDR | + +------+--------------+--------------------+----------------+ + + Complete address length is fixed and is equal to 16 octets. + + Header + + 1 octet. Address header field completely defines the address + format. The header has the following format: + + Bits + 0 1 2 3 4 5 6 7 + +-----+-----+-----+-----+-----+-----+-----+-----+ + | ADDR_LENGTH | NET_TYPE | ADDR_CODE | + +-----+-----+-----+-----+-----+-----+-----+-----+ + + 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. + + NET_TYPE + + 2 bits. The network type. This field specifies a type of + network, in which the node is. + + 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: + + + + + + +Bogdanov Experimental [Page 5] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + %b00 - 16 bit + %b01 - 24 bit + %b10 - 32 bit + %b11 - 64 bit + + The values combination of the three fields of heading is named + address format number. These fields unequivocally define a + network, in which the node is located. Format number writes as + follows: + + N - - + + 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. + + One or several address format numbers must be assigned for each + global network, included in unified system. + + FREE + + 0 - 12 octets. This field is unused by the protocol. It may + contain any additional information, which is necessary for the + control system of the node memory. If this field is not used, the + zero value must be set in all octets. Using of this field results + that the network instructions must contain only complete 16 - + octet address and the short address of local memory cannot be + used. + + 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. + + + + + + + + +Bogdanov Experimental [Page 6] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + 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. + + 128-bit address for the user applications is one field. The user + code cannot know about a physical arrangement of addressed memory. + + 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. + + Any certain algorithm, connecting real network and 128-bit address, + does not exist. All used address formats must be known beforehand. + + 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. + +2.2 Computing Model + + Computing model is three-layer: + + (1) Job + (2) Task + (3) Thread of control + + 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. + + 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. + + The job is finished, when the appropriate user application is + finished. At the end of the job all tasks of this job on all nodes + are finished. + + + + +Bogdanov Experimental [Page 7] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + 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. + + 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. + + 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. + + 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. + + 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). + + + + + + + + + + + + + + + + + + + + + + +Bogdanov Experimental [Page 8] + +RFC 3018 Unified Memory Space Protocol December 2000 + + +2.3 System Architecture + + 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. + + + + + + + +Bogdanov Experimental [Page 9] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + 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. + + 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. + + 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. + + 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. + + 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. + + Except the TCP, it is possible to use other transport protocols or + not network communications. The following requirements are showed to + them: + + o Reliable delivery. The transport layer must inform about + delivery or its impossibility; + o The violation of a sequence of transmitted segments is allowed; + o The duplication of segments is not allowed; + o At emergency reload of nodes it is necessary to guarantee + identification of segments concerning session connections, + assigned up to reload; + o Use connectionless-mode is possible. + + VM is the independent program and the interaction with the protocol + is necessary for it only when it executes the instructions with the + 128-bit address, concerning to other node. VM can execute several + + + + + +Bogdanov Experimental [Page 10] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + 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. + + 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. + + The exchange between UMSP nodes can include the instructions of the + following type: + + o Immediate reading/write in memory; + o Requests of allocation/free memory; + o Comparison instructions; + o Call-subroutine and unconditional jump instructions; + o Synchronization instructions; + o Work with objects instructions - reading / writing in memory of + objects and execution of objects procedures. + + UMSP does not trace the user control threads. VM must provide itself + the necessary order of performance of the instructions. + + 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. + +3 Instruction Format + + The UMSP instruction includes the basic header, extension headers and + operands. All fields have variable length. + + +----------------+----------------------+------------------------+ + | Header | Extension headers | Operands | + +----------------+----------------------+------------------------+ + + The header contains operation code and the information necessary for + the instruction interpretation. + + The optional extension headers contain the additional information, + not defined in basic header. + + The operands contain instructions data. + + + + +Bogdanov Experimental [Page 11] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + The instruction format allows calculating common instruction length, + without knowing definition of separate operation code. + + The instructions headers provide for the short and extended format + for maintenance of the effective protocol work in wide range of + network speeds. Besides, there is a simple algorithm of the headers + compression. + + The all instructions and extension headers the identifiers are given + which enter the name by upper case symbols. The identifiers of the + instructions begin with the letter. The identifiers of the extension + headers begin with underlining symbol. + +3.1 Instruction Header + + 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 + + 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 - 112 management instructions + 113 - 127 reserved + 128 - 223 instructions of exchange between VM + 0, 224, 255 reserved + + + + +Bogdanov Experimental [Page 12] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + 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. + + 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: + + %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. + + 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. + + + + + + + + +Bogdanov Experimental [Page 13] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + 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. + + 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. + + 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: + + (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. + + 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. + + 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. + + SESSION_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. + + + +Bogdanov Experimental [Page 14] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + REQ_ID + + 4 octets. The request identifier. It is uses for establishment + of correspondence between requests and responds to it. + + 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. + +3.2 Extension Headers + + 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: + + 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. + + 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 / + / / + | | + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + + + + + + + +Bogdanov Experimental [Page 15] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + 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. + + 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. + + 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. + + 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. + + 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. + + 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. + + 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. + + + + +Bogdanov Experimental [Page 16] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + HEAD_CODE_EXT + + 1 octet. If HXT = 0, this field is absent. If HXT = 1, it is the + younger bits of the header code. + + 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. + + 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. + + 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. + + 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. + +3.3 Instruction Operands + + 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. + + The format of the operands field is defined separately for each + instruction. + +3.4 Address Formats + + The following address format numbers are definite for nodes, + immediately connected to the global IPv4 network: + + + + +Bogdanov Experimental [Page 17] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + N 4-0-0 (4) + N 4-0-1 (4-1) + N 4-0-2 (4-2) + + The appropriate formats of 128-bit addresses: + + 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 + + It sets the node address in the global IPv4 network. + + + + +Bogdanov Experimental [Page 18] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + Local memory address + + It is described in section 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. + +4 Response of the Instructions + + The protocol instructions are divided into two types: + + (1) The management instructions transmitted on UMSP layer (OPCODE + = 1 - 112). + (2) The instructions of the exchange between VM (OPCODE = 128 - + 223). + + The processing of two types of the instructions differs as follows: + + 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. + + 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. + + 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: + + o The session identifier SESSION_ID, which is connected with + definite VM. + o The request identifier REQ_ID. + + + + + +Bogdanov Experimental [Page 19] + +RFC 3018 Unified Memory Space Protocol December 2000 + + +4.1 RSP, RSP_P + + "Response" (RSP) and "Response of the protocol" (RSP_P) instructions + have the identical format. The difference is only in the operation + code: + + 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. + + 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. + +4.2 SND_CANCEL + + 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: + + + +Bogdanov Experimental [Page 20] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + 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. + +5 Jobs Management + + The jobs management includes the following functions: + + o Initiation and completion of jobs; + o Initiation and completion of tasks; + o Opening and closing of session connections; + o Activity control of nodes. + + The instructions with OPCODE = 1 - 112 are used for jobs management. + These instructions must be sent through TCP. Use UDP is not allowed, + even if the instructions do not demand response. + + 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. + + + + + +Bogdanov Experimental [Page 21] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + UMSP solves this task as follows: + + 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. + + 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. + + 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. + + 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 + + + + +Bogdanov Experimental [Page 22] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + 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. + + 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. + + 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. + + 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. + +5.1 Job Initiate + + 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. + + The task, appropriated to its job, is initialized on the node + together with the job. LTID is binding to this task. + + 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. + + Other node can be chosen as JCP for the following reasons: + + 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. + + If the other node is chosen for JCP, the node, that initiates the + job, must register the job at JCP. + + + + +Bogdanov Experimental [Page 23] + +RFC 3018 Unified Memory Space Protocol December 2000 + + +5.1.1 CONTROL_REQ + + The instruction "To request a control" (CONTROL_REQ) is sending from + the node, initial the job, to JCP of other node. The instruction has + the following values of fields: + + 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 + + 2 octets. The job lifetime in seconds. The zero-value + signifies that the restriction of the job lifetime is + unused. + + CMT + + 1 bit. The flag of several JCP using. This field is + reserved for the future expansion of the protocol. + + VERSION + + 1 octet. The number of the UMSP version. It must + contain the value 1. + + + + + +Bogdanov Experimental [Page 24] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + Reserved + + 3 + 8 bits. All bits must be set to 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). + + At reception of the CONTROL_REQ instruction JCP checks the LTID value + from the received instruction and makes the following: + + (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. + + If JCP confirms the control, it will send the instruction + CONTROL_CONFIRM, or else CONTROL_REJECT. + +5.1.2 CONTROL_CONFIRM + + 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: + + 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). + + + + +Bogdanov Experimental [Page 25] + +RFC 3018 Unified Memory Space Protocol December 2000 + + +5.1.3 CONTROL_REJECT + + 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: + + 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. + +5.2 Task Initiate + + 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. + + 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. + +5.2.1 TASK_REG + + 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: + + + + +Bogdanov Experimental [Page 26] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + 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. + + JCP confirms initiation of a task at observance of the following + conditions: + + (1) Task with received GTID already has registered on JCP. + (2) Task with LTID for the node requesting for initiation has not + registered. + + In all other cases, JCP will not confirm a task. + + If JCP confirms the task, it will send the instruction TASK_CONFIRM, + differently TASK_REJECT. + +5.2.2 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: + + 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 + + + +Bogdanov Experimental [Page 27] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + 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. + +5.2.3 TASK_REJECT + + 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: + + 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. + +5.2.4 TASK_CHK + + With the purposes of a safety the node, which have received request + about the opening of session connection, may check up at JCP the + node, which has initialed connection, even if the task was already + initiated. + + 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. + + JCP confirms the instruction TASK_CHK if a task with received GTID + and LTID already has registered on JCP. + + The sending of the TASK_CHK is optional. + + + +Bogdanov Experimental [Page 28] + +RFC 3018 Unified Memory Space Protocol December 2000 + + +5.3 Establishment of session connection + + 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. + + 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. + + 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. + + 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. + + 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. + + 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. + + 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. + + The procedure of the establishment of session connection may contain + from 2-way up to 8-way handshakes. + +5.3.1 SESSION_OPEN + + 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: + + + + + + +Bogdanov Experimental [Page 29] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + 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. + + 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. + + It is possible to refuse connection on any step. It is necessary + either to confirm connections, or to refuse it on the eighth step. + + During the establishment of connection the following parameters may + be changed: + + + + + +Bogdanov Experimental [Page 30] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + o VM type and VM version; + o profiles of connection. + + 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: + + (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. + +5.3.2 SESSION_ACCEPT + + 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: + + 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. + +5.3.3 SESSION_REJECT + + 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: + + OPCODE = 14 + ASK = 0 + PCK = %b11 + EXT = 0/1 + CHN = 0 + OPR_LENGTH = 1 + + + + +Bogdanov Experimental [Page 31] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + 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. + +5.3.4 Connection Profile + + 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. + + Work with chains: + + S0 - Use of fragmented instructions. + S1 - Use of sequences. + S2 - Use of transactions. + + 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. + + 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: + + + +Bogdanov Experimental [Page 32] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + = ( + 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. + +5.4 Session Closing + + 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. + + + + + +Bogdanov Experimental [Page 33] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + 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. + + 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. + + 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. + +5.4.1 SESSION_CLOSE + + The instruction "To close the session" (SESSION_CLOSE) initiates the + end of session connection. It has the following values of fields: + + 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. + + + + +Bogdanov Experimental [Page 34] + +RFC 3018 Unified Memory Space Protocol December 2000 + + +5.4.2 SESSION_ABEND + + 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: + + 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. + +5.5 Task Termination + + The task is finished during the process of the job finishing at the + normal end of the user application working. This procedure is + described in the following item. The following situations require + finishing the task irrespective of the job: + + o There are not enough of computing resources for maintenance of the + task on the node; + o The node finishes the work; + o If VM has accepted such decision for the internal reasons. + + The references to the resources allocated by the task can be on any + node, on which the job is carried out. Therefore, all nodes must be + notified of the end of the task. + + Node, finishing the task, must abnormally close all session + connections joining the finished task (to send the instruction + SESSION_ABEND). + + + + + + + +Bogdanov Experimental [Page 35] + +RFC 3018 Unified Memory Space Protocol December 2000 + + +5.5.1 TASK_TERMINATE + + 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: + + 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. + + 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. + +5.5.2 TASK_TERMINATE_INFO + + 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: + + 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. + + + +Bogdanov Experimental [Page 36] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + 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. + + 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. + +5.6 Job Completion + + 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. + +5.6.1 JOB_COMPLETED + + 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: + + 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 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. + + + +Bogdanov Experimental [Page 37] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + The instruction TASK_TERMINATE_INFO may be transferred under the + initiative JCP, if node of the task has abnormal terminated work. + +5.6.2 JOB_COMPLETED_INFO + + 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: + + 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: + + (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. + + 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. + + JCP considers the job completed after sending of all instructions + JOB_COMPLETED_INFO. + +5.7 Activity Control of Nodes + + 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 + + + +Bogdanov Experimental [Page 38] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + 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. + + 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. + + 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. + + The following actions JCP are possible at detection of deactivating + of the node: + + (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. + + The deactivating of the JCP node imposes the restriction on GJID + appropriated by it after reloading. The following variants are + probable: + + (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). + + The reload of nodes, which are not being JCP, does not impose + restrictions on LTID established on these nodes. + +5.7.1 _INACTION_TIME + + 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: + + + +Bogdanov Experimental [Page 39] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + 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. + + 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. + + The header _INACTION_TIME may be attached to the following + instructions: + + (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. + + 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. + +5.7.2 STATE_REQ + + The instruction "State Request" (STATE_REQ) is sent from JCP to the + definite task of other node. The instruction has the following + values of fields: + + 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. + + + + +Bogdanov Experimental [Page 40] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + 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. + + 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. + + 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. + + 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. + +5.7.3 TASK_STATE + + 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: + + 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. + + + + +Bogdanov Experimental [Page 41] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + 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. + +5.7.4 NODE_RELOAD + + 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: + + 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: + + (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). + + For all instructions STATE_REQ the positive response (TASK_STATE) or + negative response (RELOAD_NODE) must be transmitted. + +5.8 Work without session connection + + 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. + + 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. + + + +Bogdanov Experimental [Page 42] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + 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. + + 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. + + 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. + + The protocol cannot check those conditions. Their realization lays + on VM wholly. + + 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). + + + + + + + + + +Bogdanov Experimental [Page 43] + +RFC 3018 Unified Memory Space Protocol December 2000 + + +6 Instructions of Exchange between 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. + + 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. + + The instructions of exchange between VM may be sent through UDP at + observance of the following conditions: + + o ASK = 0; + o The instruction is located in one segment UDP; + + The timeouts and the repeated sending are not used at UMSP layer for + instructions of exchange between VM. It is explained to, that the + time of sending instructions with low priority may be very large + because of the output queues. Therefore, the VM must make a decision + on timeout, as only VM has the complete information on type of the + transmitted data. Besides, the transport layer protocol must use the + timeouts. + + 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. + + 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: + + 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. + + + + + +Bogdanov Experimental [Page 44] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + 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. + + 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. + + 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. + + Header fields of the instructions not defined in the formats + description are used according to the description from section 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. + + All instructions of the protocol work with binary data and do not + provide operations of formats transformation. + +6.1 Data Reading/Writing Instructions + +6.1.1 REQ_DATA + + 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: + + + + +Bogdanov Experimental [Page 45] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + 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. + + 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. + +6.1.2 DATA + + 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: + + 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. + + 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. + +6.1.3 WRITE + + 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. + + + + +Bogdanov Experimental [Page 46] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + Extension headers: + _DATA - Contains immediate data. This header is present only, + if the data does not contain in operands. + + 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. + + The instruction RSP is sent in reply to the instruction WRITE. The + zero basic return code defines normal executing. + +6.1.4 WRITE_EXT + + The instruction "The extension writing of data" (WRITE_EXT) is used + for the data writing on the remote node. Length of the data may be 1 + - 262132 octets with a step 1 octet. The instruction has the + following values of fields: + + 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. + + 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. + + The instruction RSP is sent in reply to the instruction WRITE_EXT. + The zero basic return code defines normal executing. + +6.2 Comparison Instructions + +6.2.1 CMP + + The instruction "To compare" (CMP) is used for binary data + comparison. It has the following values of fields: + + 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. + + + + + +Bogdanov Experimental [Page 47] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + Operands: + 2/4/8/16 octets: The memory address for compared data. + 2 - 262136 octets: The immediate data for the comparison. + + 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. + +6.2.2 CMP_EXT + + The instruction "The extension compare" (CMP_EXT) is used for binary + data comparison. Length of the data may be 1 - 262132 octets with a + step 1 octet. The instruction has the following values of fields: + + 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. + + 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. + +6.2.3 Response to Comparison Instructions + + 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. + +6.3 Control Transfer Instructions + +6.3.1 JUMP, CALL + + 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 = 143/144 ; Correspondingly for the JUMP not containing + and containing the information about VM. + + + +Bogdanov Experimental [Page 48] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + 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. + + 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. + +6.3.2 RETURN + + The instruction "Return of control" (RETURN) is used at return of + control from the instructions CALL, MVRUN, CALL_BNUM and CALL_BNAME + (see below). Those instructions have the following values of fields: + + OPCODE = 147 + OPR_LENGTH = 0 - 65535 ; Depends on length of the immediate data. + Operands: + 0 - 262140 octets: Immediate data returned from the subroutine. + + 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. + + + +Bogdanov Experimental [Page 49] + +RFC 3018 Unified Memory Space Protocol December 2000 + + +6.4 Memory Control Instructions + + 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. + +6.4.1 MEM_ALLOC + + The instruction "To allocate a memory for the data" (MEM_ALLOC) is + used for request of the allocation of memory under the data. The + instruction has the following values of fields: + + OPCODE = 148 + OPR_LENGTH = 1 + Operands: + 4 octets: The size of required memory in bytes. + + 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. + +6.4.2 MVCODE + + The instruction "To move the code" (MVCODE) is used for moving of the + executable code from one node on another. The instruction has the + following values of fields: + + 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. + + 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. + + + + + + +Bogdanov Experimental [Page 50] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + 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. + +6.4.3 ADDRESS + + 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: + + OPCODE = 150 + OPR_LENGTH = 1/2/4; Depends on length of the address. + Operands: + 4/8/16 octets: The address of the allocated memory. + + 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. + +6.4.4 FREE + + 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: + + OPCODE = 151 + OPR_LENGTH = 1/2/4; Depends on length of the address + Operands: + 4/8/16 octets: the address of free memory. + + VM must free this memory automatically at end of the task on the + node. + +6.4.5 MVRUN + + The instruction "To move and run" (MVRUN) is used for simultaneous + move of a code and its execution. The instruction has the following + values of fields: + + 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. + + + + + +Bogdanov Experimental [Page 51] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + The extension headers: + _DATA - Contains an executable code. This header is present + only, if the code does not contain in operands. + + 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. + + 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. + +6.5 Other Instructions + +6.5.1 SYN + + The instruction "To Synchronize" (SYN) is used for the single message + about the data change. The instruction has the following values of + fields: + + 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. + + 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. + + 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. + + + +Bogdanov Experimental [Page 52] + +RFC 3018 Unified Memory Space Protocol December 2000 + + +6.5.2 NOP + + The instruction "No operation" (NOP) has the following values of + fields: + + OPCODE = 156 + OPR_LENGTH = 0 - 65535 + Operands: + 0 - 262140 octets: Encapsulated data. + Extension headers: + Any Extension headers. + + The instruction NOP is intended for the decision of the following + tasks: + + 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). + +6.6 Work with Objects + + 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. + + The UMSP object is identified by the 4-octet number. The values are + divided into the following ranges: + + 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. + + + + + + +Bogdanov Experimental [Page 53] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + 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. + + 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. + + 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. + + 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. + + 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. + + If for the sender of the instruction the version and/or the + realization of object do not play any role or is unknown, the + instruction may contain zero fields of the version and realization of + object or only zero field of realization. The zero field of the + version and non-zero field of realization are not allowed. + +6.6.1 Reading/Writing of the Objects Data + +6.6.1.1 OBJ_REQ_DATA + + 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: + + + + + + +Bogdanov Experimental [Page 54] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + 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. + + 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. + + 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. + +6.6.1.2 OBJ_WRITE + + 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: + + 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. + + 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. + + The instruction RSP is sent in reply to the instructions OBJ_WRITE. + The zero basic return code defines the normal execution. + + + + + + + +Bogdanov Experimental [Page 55] + +RFC 3018 Unified Memory Space Protocol December 2000 + + +6.6.1.3 OBJ_WRITE_EXT + + The instruction "The extension writing of the data in object" + (OBJ_WRITE_EXT) is used for write of the data in object. Length of + the data may be 1 - 262132 octets with the step 1 octet. The + instruction has the following values of fields: + + 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. + + 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. + + The instruction RSP is sent in reply to the instructions + OBJ_WRITE_EXT. The zero basic return code defines the normal + execution. + +6.6.2 Comparison Instructions of the Objects Data + +6.6.2.1 OBJ_DATA_CMP + + The instruction "To compare the data of object" (OBJ_DATA_CMP) is + used for binary comparison of data of the object by the immediate + data from operands. The instruction has the following values of + fields: + + 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. + + + + + +Bogdanov Experimental [Page 56] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + 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. + + The response to the instruction OBJ_DATA_CMP is described in section + 6.2.3. + +6.6.2.2 OBJ_DATA_CMP_EXT + + The instruction "The extension compare of data of the object" + (OBJ_DATA_CMP_EXT) is used for binary comparison of data of the + object by the immediate data from operands. Length of the data may + be 1 - 262132 octets with a step 1 octet. The instruction has + following values of fields: + + 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. + + To make the immediate data multiple of four octets, the data is + padded with 1 - 3 zero-value octets at the end. + + The response to the instruction OBJ_DATA_CMP_EXT is described in + section 6.2.3. + +6.6.3 Execution of the Objects Procedures + +6.6.3.1 CALL_BNUM + + The instruction "To call the object procedure over number" + (CALL_BNUM) transfers control to the object procedure over indication + of the number. The instruction has following values of fields: + + 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. + + + + +Bogdanov Experimental [Page 57] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + 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. + + The processing on the reception side is made similarly instructions + CALL (see section 6.3.1). + +6.6.3.2 CALL_BNAME + + The instruction "To call the object procedure over name" (CALL_BNAME) + transfers control to the object procedure over indication of the + name. The instruction has following values of fields: + + 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. + + The processing on the reception side is made similarly instructions + CALL (see section 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. + + + + + + + +Bogdanov Experimental [Page 58] + +RFC 3018 Unified Memory Space Protocol December 2000 + + +6.6.3.3 GET_NUM_PROC + + The instruction "To get the name of object procedure" (GET_NUM_PROC) + allows receiving number of the procedure for objects in ranges III + and IV over procedure name. The instruction has following values of + fields: + + 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. + + 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. + +6.6.3.4 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: + + 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. + +6.6.4 The Objects Creation + + 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. + + 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 + + + + +Bogdanov Experimental [Page 59] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + 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. + + 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. + +6.6.4.1 NEW, SYS_NEW + + 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: + + 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. + + 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. + + 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. + + 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. + + + + +Bogdanov Experimental [Page 60] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + 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. + + 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. + +6.6.4.2 OBJECT + + 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: + + OPCODE = 210 + OPR_LENGTH = 2 + Operands: + 4 octets: The number of object. + 2 octets: The version of object. + 2 octets: The realization of object. + +6.6.4.3 DELETE + + 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: + + OPCODE = 211 + OPR_LENGTH = 1 + Operands: + 4 octets: number of object + + The object may be deleted only from the job, which has created it. + The instruction RSP is sent in reply to this instruction. + +6.6.5 The Objects Identification + + 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. + + 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 + + + + +Bogdanov Experimental [Page 61] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + must have the unique names for all tasks on the node. The protocol + allows receiving the number of object by the name and the name of + object by the number. + +6.6.5.1 OBJ_SEEK + + 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: + + OPCODE = 212 + OPR_LENGTH = 0 + The extension header: + _NAME - contains the name of object for search. + + 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. + + 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. + +6.6.5.2 OBJ_GET_NAME + + 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: + + OPCODE = 213 + OPR_LENGTH = 1 + Operands: + 4 octets: number of object for getting + + 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. + +7 Chains + + 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: + + + +Bogdanov Experimental [Page 62] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + o The sequence. + o The transaction + o The fragmented instruction. + + 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. + + 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. + + _END_CHAIN. The extension header "End of the chain" is transferred + in last instruction of chain, irrespective of type of the chain. It + has the following values of fields: + + HEAD_CODE = 6 + HEAD_LENGTH = 0 + HOB = 1 + + Number of a finished chain contains in a field CHAIN_NUMBER of the + instruction header, to which the extension header is attached. + + The instructions, included in chains, can be transferred through UDP + only if all chain is located in one segment. + +7.1 Sequence + + 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. + + _BEGIN_SQ. The extension header "To begin a sequence" is transferred + in the first instruction of the sequence. It has the following + values of fields: + + HEAD_CODE = 3 + HEAD_LENGTH = 0 + HOB = 1 + + + +Bogdanov Experimental [Page 63] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + 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. + + 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. + +7.2 Transaction + + 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. + + 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. + +7.2.1 _BEGIN_TR + + The extension header "To begin a transaction" _BEGIN_TR is + transferred in the first transaction instruction. It has the + following values of fields: + + HEAD_CODE = 4 + HEAD_LENGTH = 1 + HOB = 1 + DATA - Has the following format: + + +---+---+---+---+---+---+---+---+ + |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 + + + +Bogdanov Experimental [Page 64] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + 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. + + 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. + + 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. + + Reserve + + Must be set to 0. + + 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. + + In the last instruction of transaction the header, _END_CHAIN is + always sent. + +7.2.2 EXEC_TR + + This instruction "To execute the transaction" (EXEC_TR) is + transferred for execution transaction early transferred. It has the + following values of fields: + + + + +Bogdanov Experimental [Page 65] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + 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 + +7.2.3 CANCEL_TR + + The instruction "To cancel transaction" (CANCEL_TR) is transmitted + for a cancellation of execution transaction transmitted before. It + has the following values of fields: + + 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. + +7.3 Fragmented instruction + + 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: + + (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. + + The decision on fragmentation is taken to UMSP level. + + 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: + + + + + +Bogdanov Experimental [Page 66] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + (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. + + _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: + + 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. + + The header _END_CHAIN is transmitted in NOP instruction, which + contains last fragment. + +7.4 Buffering + + 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. + + + +Bogdanov Experimental [Page 67] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + For chains, the protocol provides two schemes of buffering during the + receiving: + + (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. + + (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. + + 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: + + 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. + + 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. + + 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. + + + +Bogdanov Experimental [Page 68] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + 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. + + 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. + + The buffering of the fragmented instructions and transactions, at + which flag TRR = 1, depends on their size: + + 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. + +7.5 Acknowledgement of chains + + 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. + + 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. + + + + + + +Bogdanov Experimental [Page 69] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + 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. + + 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: + + 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. + +7.6 Base-displacement Addressing + + The memory base address for the relative addressing can be + established for the instructions from one chain. Thus, it is + possible to use the abbreviated address memory fields in the + instructions of chain. The abbreviated addresses are used, as + displacement from base. + + _SET_MBASE. The extension header "To set memory base" establishes + the value of base address for chain. It has the following values of + fields: + + HEAD_CODE = 7 + HEAD_LENGTH = 2/4/8 ; Depends on address length. + HOB = 1 + DATA contains: + + + +Bogdanov Experimental [Page 70] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + 4/8/16 octets: The base address. + + 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. + + 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 + + This section contains the description of the extension headers, which + are not connected with the definite instruction. The description of + the specialized extension headers describes in the appropriate + sections of this document. + +8.1 _ALIGNMENT + + 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: + + 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. + + The format of the protocol instructions provides the alignment of two + octets field without any additional means. + +8.2 _MSG + + 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: + + HEAD_CODE = 9 + HEAD_LENGTH = 1 - 127 ; Depends on data length of field. + HOB = 0 + DATA contains: + + + +Bogdanov Experimental [Page 71] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + 2 - 254 octets: The any text of the message. + + The instruction may contain several headings _MSG. + +8.3 _NAME + + 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: + + 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. + +8.4 _DATA + + 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: + + 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. + +8.5 _LIFE_TIME + + The extension header "The lifetime" (_LIFE_TIME) contains value of + time. It has the following values of fields: + + 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. + + The header _LIFE_TIME allows to set limiting time of sending of the + instruction to VM of the addressee. + + + + + + + + +Bogdanov Experimental [Page 72] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + 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. + + 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. + + 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. + + 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. + + 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. + +9 Search of resources + + 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. + + For VM, connected to the protocol, the following values are + established: + + o The VM type. The range of values 1 - 65534. + o The VM version. The range of values 1 - 65534. + + + + + +Bogdanov Experimental [Page 73] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + 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). + + Numbers of VM types are broken on the following ranges: + + 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) + + Numbers of types and versions %x0000 and %xFFFF are reserved by the + protocol. + + 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. + + 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. + + 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. + + 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. + + 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. + + + + +Bogdanov Experimental [Page 74] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + 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. + +9.1 VM_REQ + + The instruction "To request the VM" (VM_REQ) allows finding out VM, + connected on the remote node. The instruction has the following + values of fields: + + 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. + + 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. + + To request VM, used at work without session connection, the VM type + and VM version must have the value %xFFFF. + + The header _NAME is not connected with value of operands. For it, + the separate answer must be transmitted. + +9.2 VM_NOTIF + + The instruction "To notify about VM" (VM_NOTIF) is used for the + notification of one VM or one VM group attached on the node. The + instruction has the following values of fields: + + + + +Bogdanov Experimental [Page 75] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + 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. + + The optional extension header: + _NAME - This header contains the name by separate VM or group VM + from operands of the instruction. + + 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. + + 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. + + + + +Bogdanov Experimental [Page 76] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + The protocols, contained in the instruction VM_NOTIF, may differ from + the protocol, through which this instruction is transferred. + +10 Security Considerations + + 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. + + 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. + + 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. + + 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. + + + + + + +Bogdanov Experimental [Page 77] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + 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. + + 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: + + (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. + + All given technologies may be used simultaneously in any + combination. + +11 Used Abbreviations + + API Application Programming Interface. + + 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. + + + + + + + + +Bogdanov Experimental [Page 78] + +RFC 3018 Unified Memory Space Protocol December 2000 + + + 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. + + 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. + + JCP Job Control Point. This node will control the job. + + 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. + + VM Virtual Machine. + +12 References + + [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP + 9, RFC 2026, October 1996. + + [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", RFC 2119, March 1997. + + [3] Crocker, D., and P. Overell. "Augmented BNF for Syntax + Specifications: ABNF", RFC 2234, November 1997. + + [4] Postel, J., "Transmission Control Protocol - DARPA Internet + Program Protocol Specification", STD 7, RFC 793, September 1981. + + [5] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August + 1980. + + [6] Srinivasan, R., "RPC: Remote Procedure Call Protocol + Specification Version 2", RFC 1831, August 1995. + + + + + + + + + + + + + + +Bogdanov Experimental [Page 79] + +RFC 3018 Unified Memory Space Protocol December 2000 + + +13 Author's Address + + Alexander Y. Bogdanov + + NKO "ORS" + 22, Smolnaya St. + Moscow, Russia 125445 + RU + + Phone: +7 901 732 9760 + EMail: a_bogdanov@iname.ru + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bogdanov Experimental [Page 80] + +RFC 3018 Unified Memory Space Protocol December 2000 + + +14 Full Copyright Statement + + Copyright (C) The Internet Society (2000). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + 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. + + + + + + + + + + + + + + + + + + + +Bogdanov Experimental [Page 81] + -- cgit v1.2.3