rfc3018.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,557 行 · 第 1/5 页

   operands field is showed in OPR_LENGTH or OPR_LENGTH_EXT and it is
   multiple to four octets.  If necessary, 1 - 3 zero-value octets are
   padded in the end of a field.  Maximal length of operands is 262140
   octets.  The extension headers are used, if the instruction must
   contain longer data.

   The format of the operands field is defined separately for each
   instruction.

3.4  Address Formats

   The following address format numbers are definite for nodes,
   immediately connected to the global IPv4 network:




Bogdanov                      Experimental                     [Page 17]

RFC 3018             Unified Memory Space Protocol         December 2000


      N 4-0-0 (4)
      N 4-0-1 (4-1)
      N 4-0-2 (4-2)

   The appropriate formats of 128-bit addresses:

   Octets:
      +0              +1              +2              +3
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   0: |0 1 0 0|0 0|0 0|                   Free                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   4: |                              Free                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   8: |            Free               |           IP address          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   12:|           IP address          |      Local memory address     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   0: |0 1 0 0|0 0|0 1|                   Free                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   4: |                              Free                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   8: |     Free      |                  IP address                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   12:|   IP address  |             Local memory address              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   0: |0 1 0 0|0 0|1 0|                   Free                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   4: |                            Free                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   8: |                         IP address                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   12:|                     Local memory address                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Free

      It is not used by the protocol.

   IP address

      It sets the node address in the global IPv4 network.




Bogdanov                      Experimental                     [Page 18]

RFC 3018             Unified Memory Space Protocol         December 2000


   Local memory address

      It is described in section 2.1.

   IP-address defines the nodes of the given type unequivocally.  The
   TCP is used for the interaction with such nodes.  For sending of not
   requiring response instructions, using UDP is allowed.  IANA has
   assigned ports TCP and UDP 2110.  This port must be open for the
   listening (receiving).  TCP node, initialing the connection opening,
   or the UDP node, carrying out the package sending, can use any port.
   Using several TCP connections with multiplexing is supposed.

4  Response of the Instructions

   The protocol instructions are divided into two types:

      (1)  The management instructions transmitted on UMSP layer (OPCODE
           = 1 - 112).
      (2)  The instructions of the exchange between VM (OPCODE = 128 -
           223).

   The processing of two types of the instructions differs as follows:

   o  The field of the identifier of request REQ_ID is formed by the
      protocol in the instructions of the first type, and it is formed
      by VM for the instructions of the second type.
   o  The protocol must analyze the field REQ_ID and compare it with the
      instructions, transmitted earlier, after receiving of the response
      instruction of the first type.
   o  The protocol must not analyze the field REQ_ID after receiving of
      the response instruction of the second type.  This instruction is
      simply sent to VM.

   The response instructions have the field ASK equal to 1.  It means,
   that the header have the field REQ_ID.  The value taken from the
   confirmed instruction is written into the field REQ_ID.  The response
   instruction does not require response.

   A few VM can be connected to the protocol on the node.  Everyone VM
   can work in its own address space.  The identifiers of requests for
   different VM can coincide.  Therefore, instruction is identified by
   two fields:

   o  The session identifier SESSION_ID, which is connected with
      definite VM.
   o  The request identifier REQ_ID.





Bogdanov                      Experimental                     [Page 19]

RFC 3018             Unified Memory Space Protocol         December 2000


4.1  RSP, RSP_P

   "Response" (RSP) and "Response of the protocol" (RSP_P) instructions
   have the identical format.  The difference is only in the operation
   code:

      OPCODE = 129/1  ; correspondingly to RSP/RSP_P
      ASK = 1
      PCK = %b01/11
      EXT = 0/1
      CHN = 0
      OPR_LENGTH = 0/1
      SESSION_ID and REQ_ID - The values is taken from the confirmed
                              instruction.
      Operands:
         2 octets: The basic return code.
         2 octets: The additional return code.
      The optional extension header:
         _MSG - contains the arbitrary error description.

   The instruction without operands is used for the positive response.
   It is equivalent to zero values of the field of the basic and
   additional return codes.

   The zero basic return code is used for positive response.  The
   additional return code may have non-zero value.

   The instruction with non-zero basic return code is used for negative
   response.  The basic return code defines the error category.  The
   additional return code identifies an error.

   The instruction RSP is formed upon the VM request.  The return codes
   must be received from VM.  If the protocol cannot deliver the
   requiring response instruction to VM, it forms negative response RSP
   independently.

   The instruction RSP_P is always formed at the UMSP layer.  If the
   protocol cannot define on what instruction the RSP_P is transmitted,
   nothing actions is executed.

4.2  SND_CANCEL

   There can be a necessity to cancel sending after the part of the data
   have been already transmitted and have occupied the buffer on the
   reception side, by sending of the long fragmented instructions or
   transactions.  The protocol provides the instruction "The sending is
   canceled" (SND_CANCEL) for this purpose.  This instruction has the
   following fields value:



Bogdanov                      Experimental                     [Page 20]

RFC 3018             Unified Memory Space Protocol         December 2000


      OPCODE = 2
      ASK = 0
      PCK = %b01/10/11
      EXT = 0/1
      CHN = 1
      OPR_LENGTH = 1
      SESSION_ID - The value is taken from the cancelled chain.
      CHAIN_NUMBER - Number of the chain, which sending is cancelled.
      INSTR_NUMBER - Always has zero-value.
      Operands:
         2 octets: The basic return code.
         2 octets: The additional return code.
      The optional extension header:
         _MSG - contains the arbitrary error description.

   The instruction SND_CANCEL is used for the cancel of the partially
   transmitted transaction or fragmented instruction.  At the receiving
   the SND_CANCEL instruction, all the earlier received data in the
   chain are rejected.

5  Jobs Management

   The jobs management includes the following functions:

   o  Initiation and completion of jobs;
   o  Initiation and completion of tasks;
   o  Opening and closing of session connections;
   o  Activity control of nodes.

   The instructions with OPCODE = 1 - 112 are used for jobs management.
   These instructions must be sent through TCP.  Use UDP is not allowed,
   even if the instructions do not demand response.

   UMSP bases on model with the centralized control of the separate job.
   The reason is that the pointers control is not obviously possible in
   the decentralized system.  Any task can be finished at any moment or
   the node can be reloaded.  There is no way guaranteeing the
   notification about in the decentralized system all other nodes, on
   which the job works.  As the job continues to exist - the task
   concerning the job can be initiated on the same node again.  This
   task can allocate new dynamic resources.  The addresses for the again
   allocated resources can be crossed with addresses of resources, which
   existed on the node before the task restart.  The old pointers can be
   kept on other nodes.  It may be the formally correct pointers, but
   they will actually specify other objects.  The uncontrollable work of
   the application can be consequence of such situation.





Bogdanov                      Experimental                     [Page 21]

RFC 3018             Unified Memory Space Protocol         December 2000


   UMSP solves this task as follows:

   o  It allows defining the node, on which the task was completed,
      precisely.
   o  If the task on the node is finished before end of the job, all
      nodes, on which the job is executed, are notified of it.
   o  The repeated task initialization on the node is allowed, while all
      nodes will receive the message about the first task end.

   The protocol does not control the pointers.  VM supervises the
   pointers correctness.  VM must have architecture, in which 128 - bit
   pointers are stored in special memory areas, for this purpose.  The
   protocol informs VM about the nodes, on which task have finished the
   work.  VM must make all pointers concerning such tasks, invalid.  It
   results in exclusive situations at the access under these pointers.
   If the application provides processing exceptions, it keeps the
   capacity for work, or it is finished emergency.  Such decision allows
   excluding unguided applications working.

   For the decision of the specified questions at UMSP level, the
   control job node is defined for each job.  It names Job Control Point
   (JCP).  It may be the same node, on which the job is initiated, or it
   can be another dedicated node.  The basic JCP function is to trace
   the initialization and the end of the job tasks.  Besides, the
   dedicated JCP node may be used for the centralized users
   identification and the attack protection.

   The following identifiers are definite for the jobs and tasks
   control:

   o  Locally Task Identifier (LTID) is assigned to each active task on
      the node.  LTID length is equal to the length of local memory
      address defined for the node.  All LTID on the node must give
      unique values at each moment of time.  It is allowed to establish
      LTID, used earlier in the already completed tasks, for the again
      initiated tasks.
   o  JCP assigned the Control Task Identifier (CTID) to each task of
      the job.  Its length is equal to length of the local address
      memory on the node JCP.  All CTID on the JCP must give unique
      values at each moment of time.  As against LTID, the CTID value is
      chosen with some restrictions.
   o  Globally Task Identifier (GTID) is assigned to each task.  GTID
      has the same format, as the 128 - bit address of node memory has.
      The address of local memory is replaced on LTID in it.
   o  Globally Job Identifier (GJID) is assigned to the each job.  GJID
      is defined on the JCP node.  It has the same format, as the 128 -
      bit address of node JCP memory has.  The address of local memory




Bogdanov                      Experimental                     [Page 22]

RFC 3018             Unified Memory Space Protocol         December 2000


      is replaced on CTID of the first (initial) task of the job in it.
      GJID is used in the procedure of session connection opening for
      the definition JCP, which controls the job.

   LTID and CTID are written at the instructions in the field of length
   2/4/8 octets.  If the allocated for identifier field in the
   instruction is longer than identifier, LTID (CTID) writes in the last
   octets.  In the initial octets, the value 0 must be written.  If
   received LTID (CTID) is shorter than the local memory address, it is
   necessary to pad it with the zero octets in the beginning.