Internet DRAFT - draft-bogdanov-comments-umsp
draft-bogdanov-comments-umsp
Internet-Draft Alexander Bogdanov
draft-bogdanov-comments-umsp-01.txt
Expires: October 2001 April 2001
Comments to the Unified Memory Space Protocol
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This memo contains the description of the several systems models, for
which the Unified Memory Space Protocol (UMSP, RFC3018) is intended.
The purpose of this memo is the review of problems, which were defined
during the protocol specification development.
1 Introduction
This memo is the addition to the document "Unified Memory Space
Protocol Specification" [2]. UMSP is the network protocol, which
gives a capability of immediate access to memory of the remote nodes.
It is based on the model of the 128-bit distributed address space of
memory. The models, submitted in the memo, were used at the problem
definition for the development of the UMSP and its have influenced a
choice of the engineering solutions. There are no detailed projects
for the described systems. In addition, for them is not given the
strict substantiation of a possibility of realization.
The following models are described in the document:
O the control of simple devices
O the universal high-level protocol
O the distributed application, created in single process of
compilation
O the distributed virtual memory.
Bogdanov Expires: October 2001 [Page 1]
Internet-Draft Comments to the UMSP April 2001
2 The Models Description
2.1 Control of Simple Devices
The architecture, considered in the given section, is focused on the
remote control of simple devices. The logic of the minimal UMSP
profile is relatively simple and can be realized in such devices.
The base architecture is given in the following figure:
+----------------+
| Internet Host |
| |
| +-----------+ |
| | Control | | +----------------+
| | Program | | +------| Slave Device 1 |
| +-----------+ | | +----------------+
+-----|----------+ |
| +------------+ +----------------+
| | |-----| Slave Device 2 |
Internet ----/ | Control | +----------------+
/ | | .
/--------| Computer |--+ .
| | | .
+------------+ | .
| +----------------+
+--| Slave Device N |
+----------------+
The control computer (CC) can carry out the following functions:
O to realize the protection from the unauthorized access
functions,
O to carry out the gateway functions, if the communications
between CC and slave devices (SD) are distinct from TCP/IP,
O to contain the program, which carrying out part of the SD
logic.
The slave devices (SD) can have simple logic and interact with CC
under the not-network communications.
UMSP provides the immediate interaction between the control program
(CP) and SD. The possibility of realization of the given architecture
is provided with the following functions of the protocol:
O The establishment of session connection is not obligatory.
Prior to the beginning of exchange, CP can receive the
information about SD (for example about a type of the device or
VM) immediately reading out data from the definite addresses of
device memory.
Bogdanov Expires: October 2001 [Page 2]
Internet-Draft Comments to the UMSP April 2001
O The interaction between CP and SD can be realized through three
simple instructions with fixed length of data: reading/write in
memory and synchronization (for tracking of asynchronous
events). These instructions can even be executed by devices
with no having micro code. All other instructions can be
ignored on SD.
O From the UMSP logic point of view, SD can be:
1) The addressable node to which is nominated the VM of the
definite type. Such VM has no its own instructions system
and directly executes the UMSP instructions.
2) The separate VM connected to the CC node.
3) The programmed object in the CC addresses space. In this
case, the device logic is completely defined by the CC
functionalities.
In general case, SD can have the large computing resources and
realize TCP/IP stack. Thus, the various variants of architecture are
possible, which have been not considered in the document.
2.2 Universal High-level Protocol
UMSP can be last in stack and only one high-level network protocol.
All other functions can be realized as Application Program Interface
(API) of standard virtual machines (VM). It is possible to quote the
following arguments for the benefit of told:
O It is easier to standardize VM, than the network protocol.
Thus, it is possible to realize compound API even on VM with
the elementary instructions set.
O The API standardization is more simple task, than
standardization of the network protocol with the same
functions. Moreover, API can considerably be complicated and
multifunctional in comparison with possibilities of the network
protocols.
O UMSP directly converts the logic of the application programs
instructions, working with data in memory, in the logic of
network exchange. The consumption of computing resources can be
reduced due to this, as disappears the necessity of
presentation layer functions.
O It is easier to use API, than to use the protocol, for the
programs development. It allows to lower considerably the work
content of creation of the distributed applications and to
realize inaccessible at using of the network protocols
functions.
O The unification of the high-level protocol allows to carry out
100% verification of the user traffic on gateways and to
provide effective protection of local networks from external
attacks.
Probably, even the functions of network control, routing, DNS and
other can be realized as API.
Bogdanov Expires: October 2001 [Page 3]
Internet-Draft Comments to the UMSP April 2001
2.3 Distributed Application Created in Single Process of Compilation
The basic convenience to the developer consists in essential
simplification of the distributed applications creation. The programs
examples, with nonexistent for today extensions of languages, are
given in this section to show it. These examples are only
illustration.
The examples contain a minimally necessary code. A possibility to
address memory on the remote system opens many opportunities before
the VM developers for realization of the various distributed services
and API. The decision of these questions does not concern to sphere
of the network protocol.
1) The following example is written in BASIC language by using of the
procedural approach:
' It is supposed to execute this function by the remote machine.
' Probably, the distributed function code has some restrictions,
' in comparison with usual function. So as the compiler to check
' them, the qualifier 'Relocatable' is used in definition.
' Besides, variables of access type in such function should be
' processed by the special method by the compiler.
Relocatable Function dFunc(parm1 As Integer) As String
' It is possible to write here a usual code, using local and
' global variable, or calling the user-defined functions or API
' functions, given by the VM.
DFunc = "OK"
End Function
' Example of execution of the function on other machine with using
' of preliminary establishment of connection
Sub RunD()
On Error GoTo Next
' The variable identifying a remote host
Dim OtherVM As RelocatableVM
Dim ForRet As String
' To set connection with the remote node. First parameter is
' constant of the address type (the decimal IP address in this
' case).
Set OtherVM = ConnectVM(vbTpIP, "10.15.127.15")
If Err Then
MsgBox "Error of connection establishment"
Exit Sub
End If
Bogdanov Expires: October 2001 [Page 4]
Internet-Draft Comments to the UMSP April 2001
' To call function
ForRet = OtherVM.Call dFunc(10)
If Err Then
MsgBox "Error of function execution"
Exit Sub
End If
End Sub
2) The second example is written in JAVA language with the object
approach using:
/**
* The instances of this class can be created on the remote node.
*/
relocatable class dClass
{
// There can be variable-members of the classes
/**
* This constructor will be called on the remote node after the
* memory allocation.
*/
dClass()
{
// Initialization code is located here
}
/**
* Function-member of the class
*/
String dMetod(int Parm1)
{
// The code located here, can execute usual calculations,
// call API functions, can create instances of standard or
// special classes, instances of classes definite in this
// program and having the 'relocatable' qualifier
return "OK";
}
}
/**
* Example of creation of the class instance on the remote node
*/
class dExamp
{
dFunc(int Parm1)
{
Bogdanov Expires: October 2001 [Page 5]
Internet-Draft Comments to the UMSP April 2001
try
{
// Create class on the remote IP node
dClass dc = new ("10.15.5.120", dClass);
// Call function. This function is executed on the remote
// node.
String sRet = dc.dMetod(15);
// Delete the instance
dc = null;
}
catch (Exception e)
{
// Exception handling
}
}
}
It is visible from the given examples that the obligatory processing
of errors is the basic complication in comparison with the not
distributed application for programs developer. It is explained to
that the exception condition can be caused by any operator.
2.4 Distributed Virtual Memory
The creation of virtual memory distributed between Internet nodes is
complex task with the ambiguous decision. Traditional page swapping
is probably inexpedient, as will result in the large traffic of
unnecessary data. Besides, the algorithms of pages blocking in the
network environment are not obvious. UMSP will not provide these
functions in an obvious kind for these reasons.
The single requirement to the protocol, which was generated on basis
of the analysis of similar systems, is the 128-bit address of memory
of fixed length. Probably, such address is optimum from the point of
view of hardware realization and is simultaneously convenient at
program realization. In addition, such length of the address can
ensure the decision of any task on any platforms now and in the
predictable future.
3 Used Abbreviations
API Application Programming Interface.
CC Control Computer
CP Control Program
SD Slave Device
Bogdanov Expires: October 2001 [Page 6]
Internet-Draft Comments to the UMSP April 2001
UMSP Unified Memory Space Protocol
VM Virtual Machine
4 References
[1] S. Bradner, "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[2] A. Bogdanov, "Unified Memory Space Protocol Specification",
RFC 3018, December 2000.
5 Author's Address
Alexander Bogdanov
23-126, Generala Kuznetsova St.
Moscow, Russia 109153
RU
Email: a_bogdanov@pisem.net
Phone: +7 901 732 9760
Full Copyright Statement
Copyright (C) the Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Bogdanov Expires: October 2001 [Page 7]
