UMSP solves this task as follows: o It allows defining the node, on which the task was completed, precisely. o If the task on the node is finished before end of the job, all nodes, on which the job is executed, are notified of it. o The repeated task initialization on the node is allowed, while all nodes will receive the message about the first task end. The protocol does not control the pointers. VM supervises the pointers correctness. VM must have architecture, in which 128 - bit pointers are stored in special memory areas, for this purpose. The protocol informs VM about the nodes, on which task have finished the work. VM must make all pointers concerning such tasks, invalid. It results in exclusive situations at the access under these pointers. If the application provides processing exceptions, it keeps the capacity for work, or it is finished emergency. Such decision allows excluding unguided applications working. For the decision of the specified questions at UMSP level, the control job node is defined for each job. It names Job Control Point (JCP). It may be the same node, on which the job is initiated, or it can be another dedicated node. The basic JCP function is to trace the initialization and the end of the job tasks. Besides, the dedicated JCP node may be used for the centralized users identification and the attack protection. The following identifiers are definite for the jobs and tasks control: o Locally Task Identifier (LTID) is assigned to each active task on the node. LTID length is equal to the length of local memory address defined for the node. All LTID on the node must give unique values at each moment of time. It is allowed to establish LTID, used earlier in the already completed tasks, for the again initiated tasks. o JCP assigned the Control Task Identifier (CTID) to each task of the job. Its length is equal to length of the local address memory on the node JCP. All CTID on the JCP must give unique values at each moment of time. As against LTID, the CTID value is chosen with some restrictions. o Globally Task Identifier (GTID) is assigned to each task. GTID has the same format, as the 128 - bit address of node memory has. The address of local memory is replaced on LTID in it. o Globally Job Identifier (GJID) is assigned to the each job. GJID is defined on the JCP node. It has the same format, as the 128 - bit address of node JCP memory has. The address of local memory
is replaced on CTID of the first (initial) task of the job in it. GJID is used in the procedure of session connection opening for the definition JCP, which controls the job. LTID and CTID are written at the instructions in the field of length 2/4/8 octets. If the allocated for identifier field in the instruction is longer than identifier, LTID (CTID) writes in the last octets. In the initial octets, the value 0 must be written. If received LTID (CTID) is shorter than the local memory address, it is necessary to pad it with the zero octets in the beginning. GTID and GJID are written at the instructions in the field of length 4-16 octets. The field FREE is not present at these identifiers (see section 2.1). It is considered, that it contains the zero-value octets. Length of the identifier is defined in header of the address. By sending of instructions CONTROL_REQ, TASK_REG and SESSION_OPEN, the protocol uses timeout. The value of timeout is assigned by node and must be more than three intervals of the maximal time of delivery at the transport layer. The timeout is not influenced the waiting period in queue to the transport layer.
Reserved 3 + 8 bits. All bits must be set to 0. 4/8 octet: LTID of task of the job, assigned on the node, which initiate the job (by the sender of this instruction). The optional extension headers: _JOB_NAME - This header contains the name of the Job. Is assigned once and must not change further. _INACT_TIME - This header contains the inaction time (see section 5.7). At reception of the CONTROL_REQ instruction JCP checks the LTID value from the received instruction and makes the following: (1) If the node, which has sent CONTROL_REQ, already has registered on JCP the active job with such LTID, the notification about abnormality end of the registered job is sent, as is described in section 5.5.2 (it is considered, that the node was reloaded). After that, the sanction to an initiation of the new job is sent. (2) If the node has no registered job with received LTID, it allows the new job initiation at once. If JCP confirms the control, it will send the instruction CONTROL_CONFIRM, or else CONTROL_REJECT.
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.
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.
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. section 5.7). _MSG - contains the arbitrary error description.
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.
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.
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.
<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.
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.
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.
The instruction TASK_TERMINATE_INFO may be transferred under the initiative JCP, if node of the task has abnormal terminated work.
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.
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.
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.
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.
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).