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.
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.
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:
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.
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.
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.
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.
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
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.
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
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:
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
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
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:
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:
(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.
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.
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.
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:
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:
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.
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.
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.
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:
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.
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