scispace - formally typeset
Search or ask a question

Showing papers on "Protocol (object-oriented programming) published in 1988"


Journal ArticleDOI
Bjarne Stroustrup1
TL;DR: The meaning of the term 'object oriented' is examined in the context of the general-purpose programming language C++ and four paradigms are examined: procedural, data hiding, data abstraction, and object-oriented programming.
Abstract: The meaning of the term 'object oriented' is examined in the context of the general-purpose programming language C++. This choice is made partly to introduce C++ and partly because C++ is one of the few languages that supports data abstraction, object-oriented programming, and traditional programming techniques. The support of programming paradigms by languages is discussed and four paradigms are examined: procedural, data hiding, data abstraction, and object-oriented programming. The support of the latter two by C++ is discussed in some detail. >

248 citations


Journal ArticleDOI
Joseph Y. Halpern1, Ronald Fagin1
TL;DR: A formal model that captures the subtle interaction between knowledge and action in distributed systems and extends the standard notion of a protocol by defining knowledge-based protocols, ones in which a process' actions may depend explicitly on its knowledge.
Abstract: We present a formal model that captures the subtle interaction between knowledge and ac- tion in distributed systems. We view a distributed system as a set of runs, where a run is a function from time to global states and a global state is a tuple consisting of an environment state and a local state for each process in the system. This mod- el is a generalization of those used in many pre- vious papers. Actions in this model are associated with functions from global states to global states. A protocol is a function from local states to actions. We extend the standard notion of a protocol by defining knowledge-based protocols, ones in which a process' actions may depend explicitly on its knowledge. Knowledge-based protocols provide a natural way of describing how actions should take place in a distributed system. Finally, we show how the notion of one protocol implementing another can be captured in our model.

156 citations


Journal ArticleDOI
TL;DR: A formal model is presented, based on the theory of protocol projection, for reasoning about the semantics of different protocols and conversions between them, and two kinds of converters are presented: memoryless converters and finite-state converters.
Abstract: The problem of achieving communication between two processes across a network or an internetwork is considered. The notion of logical connectivity between processes in a protocol is formalized. The problem of constructing a protocol converter to achieve interoperability between processes that implement different protocols is addressed. A formal model is presented, based on the theory of protocol projection, for reasoning about the semantics of different protocols and conversions between them. Two kinds of converters are presented: memoryless converters and finite-state converters. The construction of some finite-state converters is illustrated, and examples are given. >

152 citations


Proceedings ArticleDOI
Won Kim, Nat Ballou, Jay Banerjee1, Hong-Tai Chou, Jorge G. Garza, Darrell Woelk 
01 Jan 1988
TL;DR: These issues are discussed and the solutions which have been incorporated into the ORION object-oriented database system at MCC are presented.
Abstract: There are two major issues to address to achieve integration of an object-oriented programming system with a database system. One is the language issue: an object-oriented programming language must be augmented with semantic data modeling concepts to provide a robust set of data modeling concepts to allow modeling of entities for important real-world applications. Another is the computational-model issue: application programmers should be able to access and manipulate objects as though the objects are in an infinite virtual memory; in other words, they should not have to be aware of the existence of a database system in their computations with the data structures the programming language allows. This paper discusses these issues and presents the solutions which we have incorporated into the ORION object-oriented database system at MCC.

124 citations


Patent
01 Sep 1988
TL;DR: In this paper, a distributed digital data processing system includes a plurality of nodes which communicate over a network, and each node maintains a naming service which associates each object in the system with one or more protocol towers.
Abstract: A distributed digital data processing system includes a plurality of nodes which communicate over a network. A node maintains one or more objects, each of which may be a file, that is, an addressable unit in the system, such as a program, database, text file, or the like, or a directory which may contain one or more files or other directories. One node maintains a naming service which associates each object in the system with one or more protocol towers. Each protocol tower identifies the object name and a series of entries each identifying a name for each of the protocol layers, along with the communications parameters and address information, to be used in communicating with the object. When a node requires access to an object maintained by another node, it first retrieves from the naming service the protocol towers for the object. The node also maintains a tower identifying the names of each of the protocols over which it can communicate. The node then compares the protocol names in the retrieved protocol towers with the protocol names over which it can communicate. If the protocol names in a retrieved tower match the protocol names in the node's tower, the node uses the communications parameters and address information in future communications with the object. If the node is unable to identify a retrieved protocol tower which matches its supported tower or towers, it is unable to communicate with the object.

118 citations


01 Feb 1988
TL;DR: The full function of VMTP, including support for security, real-time, asynchronous message exchanges, streaming, multicast and idempotency, provides a rich selection to the VMTP user level.
Abstract: This RFC describes a protocol proposed as a standard for the Internet community. Comments are encouraged. Distribution of this document is unlimited. OVERVIEW This memo specifies the Versatile Message Transaction Protocol (VMTP) [Version 0.7 of 19-Feb-88], a transport protocol specifically designed to support the transaction model of communication, as exemplified by remote procedure call (RPC). The full function of VMTP, including support for security, real-time, asynchronous message exchanges, streaming, multicast and idempotency, provides a rich selection to the VMTP user level. Subsettability allows the VMTP module for particular clients and servers to be specialized and simplified to the services actually required. Examples of such simple clients and servers include PROM network bootload programs, network boot servers, data sensors and simple controllers, to mention but a few examples.

91 citations


Proceedings ArticleDOI
06 Dec 1988
TL;DR: The timing constraint mechanism in a real-time programming language called FLEX, which can use the constraint primitives to express timing and resource requirements, is described and some performance data is presented.
Abstract: The timing constraint mechanism in a real-time programming language called FLEX is described. A FLEX program can use the constraint primitives to express timing and resource requirements. If the required time or resources are not available at run-time, a FLEX program can dynamically produce monotonic imprecise results. Both time and system resources are defined as first-class objects in the language so that they can be evaluated just like any other first-class object. By unifying time, resources, and normal objects, the semantics and the executions of real-time programs are more manageable. Some implementation issues for FLEX are discussed, and some performance data are presented. >

87 citations


01 Jul 1988
TL;DR: An object-oriented user interface package, called InterViews, that supports the composition of a graphical user interface from a set of interactive objects and includes classes for structured text and graphics.
Abstract: We have implemented an object-oriented user interface package, called InterViews, that supports the composition of a graphical user interface from a set of interactive objects The base class for interactive objects, called an interactor, and base class for composite objects, called a scene, define a protocol for combining interactive behaviors Subclasses of scenes define common types of composition: a box tiles its components, a tray allows components to overlap or constrain each other''s placement, a deck stacks its components so that only one is visible, a frame adds a border, and a viewport shows part of a component Predefined components include menus, scrollers, buttons, and text editors InterViews also includes classes for structured text and graphics InterViews is written in C++ and runs on top of the X window system

65 citations


Proceedings ArticleDOI
01 Aug 1988
TL;DR: The architecture is interesting because the abstractions are both general enough to accommodate a wide range of protocols and efficient enough to provide a useful testbed in which protocol performance can be accurately measured.
Abstract: The x-kernel is a configurable operating system kernel designed to support experimentation in interprocess communication and distributed programming. The x-kernel's underlying architecture provides a rich set of abstractions that are used to construct and compose communication protocols. The architecture is interesting because the abstractions are both general enough to accommodate a wide range of protocols and efficient enough to provide a useful testbed in which protocol performance can be accurately measured.

54 citations


Journal ArticleDOI
TL;DR: The semiautomatic approach to protocol implementation offers several advantages over the conventional manual one, including correctness and modularity in protocol implementation code, conformance to the specification, and reduction in implementation time.
Abstract: The basic ideas underlying an Estelle-C compiler, which accepts an Estelle protocol specification and produces a protocol implementation in C, are presented. The implementation of the ISO (International Organization for Standardization) class-2 transparent protocol, using the semiautomatic approach, is discussed. A manual implementation of the protocol is performed and compared to the semiautomatic implementation. The semiautomatic approach to protocol implementation offers several advantages over the conventional manual one, including correctness and modularity in protocol implementation code, conformance to the specification, and reduction in implementation time. Finally, ongoing development of a new Estelle-C compiler is presented. >

53 citations


Journal ArticleDOI
TL;DR: The distributed computing communication needs of computer-integrated manufacturing (CIM) are discussed and the capabilities of MAP/TOP (manufacturing automation protocol/technical and office protocol) as a communications architecture are examined.
Abstract: The distributed computing communication needs of computer-integrated manufacturing (CIM) are discussed. The capabilities of MAP/TOP (manufacturing automation protocol/technical and office protocol) as a communications architecture are examined. An example of how MAP/TOP operates in a hypothetical CIM enterprise is presented. >

Book
01 Dec 1988

Journal ArticleDOI
TL;DR: The RTAG (real-time asynchronous grammars) programming language is discussed, and a Unix-based automated implementation system for RTAG is described.
Abstract: The RTAG (real-time asynchronous grammars) programming language is discussed. The language is based on an attribute grammar notation for specifying protocols. Its main design goals are: (1) to support concise and easily understood expression of complex real-world protocols; and (2) to serve as the basis of a portable software system for automated protocol implementation. The algorithms used in generating implementations from given specifications are sketched, and a Unix-based automated implementation system for RTAG is described. >

Proceedings ArticleDOI
01 Jan 1988
TL;DR: A survey is presented of techniques for verifying correctness properties of communications protocol design based on finite-state-machine (FSM) models, and one technique is proposed as the basis for further work on a protocol verifier and analyzer workstation which is being designed as a protocol development tool.
Abstract: A survey is presented of techniques for verifying correctness properties of communications protocol design based on finite-state-machine (FSM) models. The conventional reachability analysis is first described, giving advantages and limitations. One major limitation is the so-called state-space explosion problem. To approach this and other problems, a survey of different approaches is presented. The author classifies the various techniques into categories. These include closed covers, localized protocol verification, divide-and-conquer, modified reachability analysis, and partial state exploration. Each technique is described in detail, including an analysis of its strengths and weaknesses. Based on this analysis, one technique is proposed as the basis for further work on a protocol verifier and analyzer workstation which is being designed as a protocol development tool. >

Proceedings ArticleDOI
11 Apr 1988
TL;DR: An algorithm is provided that yields protocol FSMs from a given service FSM in which the service model allows only sequential execution of service primitives at various service access points (SAPs), and the algorithm is expanded to take care of the extended model.
Abstract: The authors address the problem of deriving a protocol specification from a given service specification, which are both in the finite-state-machine (FSM) model They provide an algorithm that yields protocol FSMs from a given service FSM in which the service model allows only sequential execution of service primitives at various service access points (SAPs) They then extend the service model to allow concurrent execution of service primitives at different SAPs, and the algorithm is also expanded to take care of the extended model Finally, they present a procedure to construct an error-recoverable protocol from its error-free version generated from the proposed algorithm, thus enabling the algorithm to provide the generated protocol with error-recovery capability Limitations of the model and the direction being taken in further work to relieve the limitations are stated >

Proceedings ArticleDOI
05 Oct 1988
TL;DR: The authors present an algorithm for deriving the protocol specification from a given service specification which is described by a set of directly coupled finite state machines (FSMs) which regulate the execution sequence of service primitives intended by the service specification.
Abstract: The authors propose a protocol synthesis method in which both service and protocol specifications are based on a state-transition model. In particular, they present an algorithm for deriving the protocol specification from a given service specification which is described by a set of directly coupled finite state machines (FSMs). These FSMs together regulate the execution sequence of service primitives intended by the service specification. To complement the protocol derivation algorithm for dealing with error-prone communication medium, the authors also devise a transformation procedure to construct an error-recoverable protocol from its error-free version derived from the proposed algorithm. >

Patent
26 Jan 1988
TL;DR: In this article, the authors present a system that enables a plurality of nodes in a network to communicate with each other through a communication protocol that will be understood by any node that is a party to the present conversation.
Abstract: The system and method of this invention enables a plurality of nodes (A,...., E) in a network to communicate with each other through a communication protocol that will be understood by any node that is a party to the present conversation. Each node may utilize a different version level of a distributed services program that allows nodes to communicate in a distributed environment. At the time a connection is initiated with another node in the network, the highest version level that both nodes have in common is determined. This common version level is then used as the protocol for any further communication.

Proceedings ArticleDOI
01 Jan 1988
TL;DR: The CST language, which supports concurrency using locks, asynchronous messages, and distributed objects, is described, examples of its use, and an initial implementation are discussed.
Abstract: CST is a programming language based on Smalltalk-80 that supports concurrency using locks, asynchronous messages, and distributed objects. Distributed objects have their state distributed across many nodes of a machine, but are referred to by a single name. Distributed objects are capable of processing many messages simultaneously and can be used to efficiently connect together large collections of objects. They can be used to construct a number of useful abstractions for concurrency. This paper describes the CST language, gives examples of its use, and discusses an initial implementation.

Proceedings ArticleDOI
26 Sep 1988
TL;DR: An implementation of actors in Smalltalk-80, named Actalk, is described and how to extend the Actalk kernel into various extensions to define the basic Actor model of computation, higher level programming constructs such as the 3 types of message passing (asynchronous, synchronous, and eager) proposed in the ABCL/1 programming language, and distributed architectures.
Abstract: In this paper we describe an implementation of actors in Smalltalk-80, named Actalk. This attempt is designed as a minimal extension preserving the Smalltalk-80 language.Actors are active and autonomous objects, as opposed to standard passive Smalltalk-80 objects. An actor is built from a standard Smalltalk-80 object by associating a process with it and by serializing the messages it could receive into a queue.We will study the cohabitation and synergy between the two models of computation: transfer of active messages (message and thread of activity) between passive objects, and exchange of passive messages between active objects. We propose a sketch of methodology in order to have a safe combination between these two programming paradigms.We show how to extend the Actalk kernel into various extensions to define the basic Actor model of computation, higher level programming constructs such as the 3 types of message passing (asynchronous, synchronous, and eager) proposed in the ABCL/1 programming language, and distributed architectures. All these examples are constructed as simple extensions (by using inheritance) of our kernel model.

Book ChapterDOI
Andreas Paepcke1
15 Aug 1988
TL;DR: This work describes the design of a prototype which makes objects persistent in the CommonLisp Object System, and outlines the advantages of the CLOS Metaclass Protocol for implementing object persistence or other low-level modifications to the ClOS implementation.
Abstract: We describe the design of a prototype which makes objects persistent. Our target language is the CommonLisp Object System (CLOS), although we pay attention to the eventual sharing of data with other languages. Our design is very flexible, in that it allows the simultaneous use of multiple, different databases. This is accomplished by defining a virtual database layer which consists of a core protocol that is expected to be implemented on all databases, and of protocol adapters which accommodate features offered by some databases, but not by others. This virtual database has been implemented for a simple, single-user, in-core data store, and for Iris, a multi-user, object-oriented database management system. We outline the advantages of the CLOS Metaclass Protocol for implementing object persistence or other low-level modifications to the CLOS implementation.

Journal ArticleDOI
P. Hudak1
TL;DR: A method is presented that takes functional programming one step further by letting the programmer change operational details without restructuring or rewriting the program.
Abstract: A method is presented that takes functional programming one step further by letting the programmer change operational (parafunctional) details without restructuring or rewriting the program. Parafunctional programming is based on the premise that the what (specification) and the how (implementation) are separately identifiable and maintainable system components. Unlike conventional programming methods, parafunctional programming maintains this separation by metalinguistic constructs in the source language and a programming environment that supports structured editing and high-level debugging. >

Patent
25 Apr 1988
TL;DR: In this article, a protocol engine with a core central processor that implements a plurality of programmable finite state machines that perform context-dependent operations and programmable satellite processing units that operate context-free operations is presented.
Abstract: A programmable protocol engine having a core central processor that implements a plurality of programmable finite state machines that perform context-dependent operations, and programmable satellite processing units that perform context-free operations. To assist in buffering the two way communications of the protocol engine, a memory is included which interacts with the central processor and the satellite units. The programmability of the protocol engine is achieved by realizing the satellite units with combinations of a processing unit and a memory unit which stores the instructions to be performed by the corresponding processing unit. The sequence of instructions to be performed is drawn from a small unique set of instructions which are adapted particularly to the tasks associated with protocol implementations. Instruction ports are provided for loading the necessary instructions to the satellite units and the central processor, thereby implementing a chosen protocol. To permit use of the protocol engine in environments where a plurality of users are multiplexed onto a single physical link, additional means are provided for storing the state of the finite state machines within the central processor, and for restoring the finite state machines to a previously stored set of states.

Journal ArticleDOI
Lingzi Jin1, Hong Zhu1
TL;DR: This paper describes a preliminary experiment with systems programming in Backus’ FP systems that consists of a self-compiler of FP, and an interpreter of the semantics of FFP, implemented on an FP machine—FPM2.
Abstract: The development of systems software in functional programming language is still an open problem. This paper describes a preliminary experiment with systems programming in Backus’ FP systems[1]. It consists of two systems programs. One is a self-compiler of FP, the other an interpreter of the semantics of FFP (Formal Functional Programming). Both were implemented on an FP machine—FPM2. Some discussions are made finally.

Proceedings ArticleDOI
26 Sep 1988
TL;DR: This summary presents a general model supporting object-oriented programming in concurrent as well as distributed environments that combines the advantages of remote procedure calls with those of message passing.
Abstract: This summary presents a general model supporting object-oriented programming in concurrent as well as distributed environments.The model combines the advantages of remote procedure calls with those of message passing.It relies on the following concepts:• All objects are not active but the active entities are objects.• Asynchronous Message Passing with Data-driven synchronization.• Service mechanism allowing an explicit thread of control.

Journal ArticleDOI
TL;DR: This paper explores program designs for layered systems such as communication protocols and server/client systems that do not exhibit a strict hierarchy in their control flow, and concludes that the vertically layered protocol design is to be preferred unless there are many shared variables between the send-side and receive-side.
Abstract: This paper explores program designs for layered systems such as communication protocols and server/client systems that do not exhibit a strict hierarchy in their control flow. Clark has proposed structuring such systems, where both upward and downward control flow are required, to use efficient synchronous procedure calls between the layers whenever possible. The term upcall is used by Clark to describe this synchronous upward communication from server to client.Several techniques are possible for structuring such programs using upcalls. Comparisons are made by implementing a communication protocol described by Clark in three different ways. The first method implements all the protocol routines in a single large module. The second method structures the routines into modules occupying vertical slices of the protocol layers, and the third method structures the routines into modules corresponding to the protocol layers.Comparisons are made on two fronts: Preservation of modularity, in order to determine which method shows fault-tolerance and ease of programming, and program performance, which is a key motivation for the upcalls programming style. We conclude that the vertically layered protocol design is to be preferred unless there are many shared variables between the send-side and receive-side, as it is very efficient and provides the best protection of clients from each other. The horizontally layered design is the least efficient, but it is the easiest to program.

Journal ArticleDOI
TL;DR: A general, formal modeling technique for protocol service interfaces using a logic-programming-based language, Prolog, is discussed and results indicate that Prolog is a very useful formal language for specifying protocol interfaces.
Abstract: A general, formal modeling technique for protocol service interfaces is discussed. An executable description of the model using a logic-programming-based language, Prolog, is presented. The specification of protocol layers consists of two parts, the specification of the protocol interfaces and the specification of entities within the protocol layer. The specification of protocol interfaces forms the standard against which protocols are verified. When a protocol has been implemented, the correctness of its implementation can be tested using the sequences of events generated at the service interface. If the behavior of the protocol implementation is consistent with the behavior at the service interface, the implementation conforms to its standard. To illustrate how it works, the model is applied to the service interfaces of protocol standards developed for the transport layer of the ISO/OSI architecture. The results indicate that Prolog is a very useful formal language for specifying protocol interfaces. >

Proceedings ArticleDOI
01 Aug 1988
TL;DR: This paper shows how the RPC approach can be used for lower layer protocols so that the resulting “layer violations” generate a simple recursive structure, thereby reducing the cost of implementation and verification.
Abstract: Current communication architectures suffer from a growing collection of protocols in the host operating systems, gateways and applications, resulting in increasing implementation and maintenance cost, unreliability and difficulties with interoperability. The remote procedure call (RPC) approach has been used in some distributed systems to contain the diversity of application layer protocols within the procedure call abstraction. However, the same technique cannot be applied to lower layer protocols without violating the strict notion of layers.In this paper, we show how the RPC approach can be used for lower layer protocols so that the resulting “layer violations” generate a simple recursive structure. The benefits of exploiting recursion in a communication architecture are similar to those realized from its use as a programming technique; the resulting protocol architecture minimizes the complexity and duplication of protocols and mechanism, thereby reducing the cost of implementation and verification. We also sketch a redesigned DoD Internet architecture that illustrates the potential benefits of this approach. This work was sponsored in part by the Defense Advanced Research Projects Agency under contract N00039-84-C-0211, by Digital Equipment Corporation, by the National Science Foundation Grant DCR-83-52048 and by ATT Information Systems.

Proceedings ArticleDOI
01 Jan 1988
TL;DR: The authors describe a programming paradigm they call attribute-grammar-based programming, its realization language AG, and the programming environment for AG, called SAGE (Support for AG Environment).
Abstract: The authors describe a programming paradigm they call attribute-grammar-based programming, its realization language AG, and the programming environment for AG, called SAGE (Support for AG Environment). AG is designed so that it can be used as a general-purpose programming language, as well as for the kernel language of various software production systems based on attribute grammars. AG is strongly typed; programs in AG are composed from data types and module definitions. The subsystems of SAGE, namely, the editor, the interpreter, the debugger, the compiler, the verifier, system browser, and other miscellaneous support modules are described, and the interactions among them are examined. >

Journal ArticleDOI
01 Jun 1988
TL;DR: This paper describes the approach taken by VISION in addressing the need to handle time, versions, and concurrency control in a manner that does not produce combinatoric complexity in object protocol.
Abstract: VISION is an object-oriented database system currently used commercially to develop investment analysis and other large statistical applications. Characteristic of these applications, beside the standard issues of structural and computational richness, is the need to handle time, versions, and concurrency control in a manner that does not produce combinatoric complexity in object protocol. This paper describes the approach taken by VISION in addressing these issues.

Proceedings ArticleDOI
G. Karjoth1
08 Mar 1988
TL;DR: The author introduces a simple language, a subset of the formal language LOTOS, expressive enough to describe a wide range of communication behavior, and shows the applicability of this specification language to a sliding-window protocol taken from the literature.
Abstract: The author introduces a simple language, a subset of the formal language LOTOS, expressive enough to describe a wide range of communication behavior. He shows the applicability of this specification language to a sliding-window protocol taken from the literature. The specifications start with the definition of the service of the protocol. The underlying service is precisely defined, giving the frame into which the protocol has to fit. The first specification defines the protocol entity as a single process. Then this sequential process is decomposed into four parallel processes, taking the replication of data objects into account. In this way, the author obtains a specification that contains adequate detail for use as an implementation specification. >