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:
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
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.
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:
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:
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
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:
<max length> = (<value of this field> + 1) * 4.
If the value is equal %b1111, maximal length of the data
is defined by the instruction format.
S16-S19 These bits are the common field. In the profile required
from the addressee of the instruction, this field
contains the version of the UMSP. It must is set to the
value %b0001. In the profile given sender of the
instruction, this field contains priority of the job. The
more is value of this field, the more priority. The
priority of the job is used:
o In queues on sending to the transport layer for the
instructions of the job.
o For set of sending priority of the transport layer.
o For set of computing priority of the task.
S20 - making the border multiple of 4 octets. If S16 = 1:
(1) OPR_LENGTH = %b111
(2) Each extension header and the field of operands begin with
the border multiple of four octets.
(3) The necessary number of zero octets is added in the end of
each header.
S21 - Use of the procedures name of objects.
S22 - Use of the objects name.
The permissible instructions:
S23 - The response of the execution on VM (instruction RSP) is
provided.
S24 - Use of data reading and comparison instructions.
S25 - Use of data writing instructions.
S26 - Use of control transfer instructions.
S27 - Use of synchronize instruction.
S28 - Use of instructions of work witch objects.
S29 - Use of the immediate access to memory of object. If this
flag is set to 0, the access to object is solved only
through its procedures. If S28=0, this flag must be set to
0.
S30 - Use of instruction MVRUN in zero-session.
S31 - Reserved. Must have set to 0.
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.
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.
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).
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.
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.
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
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:
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.
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.
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.
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).
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.
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:
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.
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.
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.
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.
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.
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.