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]