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.
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. section 7.4.
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.
OPCODE = 158 ASK = 1 PCK = %b01/10/11 CHN = 1 EXT = 0/1 CHAIN_NUMBER - Contains the number of chain, which is necessary to execute. INSTR_NUMBER = 0 OPR_LENGTH = 0
(1) 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.
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.
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.
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.
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.
2 - 254 octets: The any text of the message. The instruction may contain several headings _MSG.
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.
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.
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.
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.
The protocols, contained in the instruction VM_NOTIF, may differ from the protocol, through which this instruction is transferred.
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.
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.  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.  Crocker, D., and P. Overell. "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.  Postel, J., "Transmission Control Protocol - DARPA Internet Program Protocol Specification", STD 7, RFC 793, September 1981.  Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.  Srinivasan, R., "RPC: Remote Procedure Call Protocol Specification Version 2", RFC 1831, August 1995.
Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.