rfc3018.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,557 行 · 第 1/5 页
TXT
1,557 行
0 - 12 octets. This field is unused by the protocol. It may
contain any additional information, which is necessary for the
control system of the node memory. If this field is not used, the
zero value must be set in all octets. Using of this field results
that the network instructions must contain only complete 16 -
octet address and the short address of local memory cannot be
used.
NODE_ADDR
1 - 13 octets. The node address. The format of this field is
defined separately for each address format number. The field of
the node address should not necessary precisely correspond to the
real network address. If the real network address is longer than
this field, it is necessary to organize in the network a subset of
supporting the protocol UMSP addresses.
Bogdanov Experimental [Page 6]
RFC 3018 Unified Memory Space Protocol December 2000
MEM_ADDR
16/24/32/64 bits. The address of local memory. This field is the
memory address in system, which is set by a field NODE_ADDR. The
node completely responds for its memory control. The protocol
does not define the order of using and format of this field.
128-bit address for the user applications is one field. The user
code cannot know about a physical arrangement of addressed memory.
The 128-bit memory address may be transmits between nodes, as the
data, for example, in the buffer of function parameters, or in the
instruction of copying the data. Therefore, it must identify the
given node from any other nodes unequivocal.
Any certain algorithm, connecting real network and 128-bit address,
does not exist. All used address formats must be known beforehand.
As UMSP has its own address space, it can unite several global
networks. The nodes can have internal local networks or subordinated
addressable devices connected with the node by the not-network
communications. Any node by address format number must have an
opportunity to define the gateway respond for routing of this
address.
2.2 Computing Model
Computing model is three-layer:
(1) Job
(2) Task
(3) Thread of control
The job corresponds to the user application. The job is distributed
and can simultaneously be executed on many nodes. The job control is
carried out centralize, from the node named as Job Control Point
(JCP). One JCP can control the some jobs. JCP can be located on the
same node, on which the job is created, or on any other addressed net
point.
The task is the job presentation on the separate node. The task
includes one or several computing threads of control. The job has
only one task on each node.
The job is finished, when the appropriate user application is
finished. At the end of the job all tasks of this job on all nodes
are finished.
Bogdanov Experimental [Page 7]
RFC 3018 Unified Memory Space Protocol December 2000
The job has its isolated 128-bit address space. The address space is
segmented. A segment is the local memory of one node. Besides, the
protocol allows working with objects. The objects are separate
associative memory of the node.
The task thread represents the concrete control thread, which are
executed by VM in the certain node. The thread can read and write to
any address of 128-bit address space of the job. The control
transfer to the address from other (remote) node, results to the
creation of the new thread on the remote node. The continuous code
segment cannot be distributed on several nodes. In addition, it is
impossible to receive continuous memory area distributed on several
nodes.
The protocol does not demand to support the different tasks of not-
crossed memory space from the separate VM node. The supporting of
multi-thread is not also the obligatory requirement.
The 128-bit Global Job Identifier (GJID) is defined by protocol. It
is assigned on JCP, which will control the job. All active GJID have
the unique values in the unified system at each moment of time.
The job can contain VM code of different types. Different types VM
can be situated on one or different nodes. The mechanism of
association of different VM types in groups on one node is
stipulated, so to the non-uniform code can be executed on one node in
a context of one job. The groups are described in details in section
9. VM, incorporated in groups, must work in common memory space (to
have a common subsystem of memory control).
Bogdanov Experimental [Page 8]
RFC 3018 Unified Memory Space Protocol December 2000
2.3 System Architecture
System structure, based on using Virtual Machines, is given in the
following figure:
Node 1 Node 2
-------- --------
+--------------------+ +--------------------+
| User Application 1 | | User Application 1 |
+-----------------------+ +-----------------------+
| User Application N | | User Application N |
+--------------------+ +--------------------+
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| VM1 | | VM2 | . . . | VMn | | VM1 | | VM2 | . . . | VMn |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+
| | | | | |
+--------------------------+ +--------------------------+
| | | |
| +-----+ U M S P | | U M S P |
| | JCP | | | |
| +-----+ | +-------------+------------+
+-------------+------------+ |
| +-----+-----+
+-----+-----+ | TCP |
| TCP | +-----+-----+
+-----+-----+ |
| |
+-----------------/ |
/------------------+
/
|
+-----+-----+
Node N | TCP |
-------- +-----+-----+
|
+------------+------------+
| +-----+ |
| | JCP | U M S P |
| +-----+ |
+-------------------------+
Figure 1. Structure of the system based on use VM.
Bogdanov Experimental [Page 9]
RFC 3018 Unified Memory Space Protocol December 2000
One or several VM are working on upper level for UMSP. The VM layer
is not network level. Last network level is UMSP. Therefore, VM
layer has no its own network primitives and uses together with UMSP
the same field of operation code.
The end services user of the protocol is the user code, which is
executed by the virtual machine. It has the instructions with the
128-bit address. VM translates these instructions to network
commands, which are transmitted through the UMSP protocol for the
executing by the remote machine. Internal organization VM, command
system and API can be anyone. The protocol defines only format of
primitives, which the virtual machines exchange through a network.
The protocol does not control the jobs memory. Control of memory
should realize VM. If a few VM works on one node, they may have the
common memory space or may be completely isolated.
UMSP uses the transport layer with reliable delivery for the data
exchange. This document defines of using TCP. For the transfer of
not requiring acknowledgement data may be used UDP. Thus, the
connection through TCP is obligatory. Use of multiple connections
TCP with multiplexing is supposed. The control of transport
connections is not the part of the UMSP protocol.
The UMSP instructions do not contain network addresses of the
receiver and sender. The protocol requires that one address UMSP
must correspond to the one transport layer address. Accordingly, it
is necessary to define unequivocal the node address on transport
layer by the 128-bit address of memory.
Except the TCP, it is possible to use other transport protocols or
not network communications. The following requirements are showed to
them:
o Reliable delivery. The transport layer must inform about
delivery or its impossibility;
o The violation of a sequence of transmitted segments is allowed;
o The duplication of segments is not allowed;
o At emergency reload of nodes it is necessary to guarantee
identification of segments concerning session connections,
assigned up to reload;
o Use connectionless-mode is possible.
VM is the independent program and the interaction with the protocol
is necessary for it only when it executes the instructions with the
128-bit address, concerning to other node. VM can execute several
Bogdanov Experimental [Page 10]
RFC 3018 Unified Memory Space Protocol December 2000
user tasks. Each task can contain several threads of control. VM
must be able to interpret the application instructions with the 128-
bit address to one or several instructions of the UMSP protocol.
The session connection opens between nodes for the data exchange.
One connection is relational only with one job. There may be several
session connections for the different jobs simultaneously between two
nodes. Besides, the protocol provides the connectionless data
exchange.
The exchange between UMSP nodes can include the instructions of the
following type:
o Immediate reading/write in memory;
o Requests of allocation/free memory;
o Comparison instructions;
o Call-subroutine and unconditional jump instructions;
o Synchronization instructions;
o Work with objects instructions - reading / writing in memory of
objects and execution of objects procedures.
UMSP does not trace the user control threads. VM must provide itself
the necessary order of performance of the instructions.
The length of UMSP instructions does not depend on segment length of
the transport layer. The segmentation is provided for transfer of
the long instructions. The packing of the short instructions in one
segment with a possibility of compression of headings is used for its
transfer. The minimal size of necessary for work segment is 6
octets. For realization of all functions, it is necessary 54 octets.
3 Instruction Format
The UMSP instruction includes the basic header, extension headers and
operands. All fields have variable length.
+----------------+----------------------+------------------------+
| Header | Extension headers | Operands |
+----------------+----------------------+------------------------+
The header contains operation code and the information necessary for
the instruction interpretation.
The optional extension headers contain the additional information,
not defined in basic header.
The operands contain instructions data.
Bogdanov Experimental [Page 11]
RFC 3018 Unified Memory Space Protocol December 2000
The instruction format allows calculating common instruction length,
without knowing definition of separate operation code.
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?