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

An efficient, fault-tolerant protocol for replicated data management

Abstract: A data management protocol for executing transactions on a replicated database is presented. The protocol ensures one-copy serializability. i.e., the concurrent execution of transactions on a replicated database is equivalent to some serial execution of the same transactions on a non-replicated database. The protocol tolerates a large class of failures, including: processor and communication link crashes, partitioning of the communication network, lost messages, and slow responses of processors and communication links. Processor and link recoveries are also handled. The protocol implements the reading of a replicated object efficiently by reading the nearest available copy of the object. When reads outnumber writes, the protocol performs better than other known protocols.

If Prolog is the Answer, What is the Question? or What it Takes to Support AI Programming Paradigms

Abstract: Knowledge programming, which makes use of the explicit representation and interpretation of knowledge to create intelligent programs, requires specialized languages and tools to help programmers. Prolog, an implementation of a logic programing language, provides some of these tools; it and other languages have been argued to be the "best" way to do such knowledge programming. This paper raises questions which suggest that any single paradigm of programming (e.g., logic programming or object-oriented programming) benefits by being integrated in a single environment with other paradigms of programming. Integration of these paradigms with each other, and within a flexible, user-friendly computing environment is also necessary. Such an environment must provide source level debugging and monitoring facilities, analysis and performance tuning tools, and an extended set of user communication programs.

Time-Dependent Distributed Systems: Proving Safety, Liveness and Real-TimeProperties

Abstract: Most communication protocol systems utilize timers to implement real-time constraints between event occurrences. Such systems are said to betime-dependent if the real-time constraints are crucial to their correct operation. We present a model for specifying and verifying time-dependent distributed systems. We consider networks of processes that communicate with one another by message-passing. Each process has a set of state variables and a set of events. An event is described by a predicate that relates the values of the network's state variables immediately before to their values immediately after the event occurrence. The predicate embodies specifications of both the event's enabling condition and action. Inference rules for both safety and liveness properties are presented. Real-time progress properties can be verified as safety properties. We illustrate with three sliding window data transfer protocols that use modulo-2 sequence numbers. The first protocol operates over channels that only lose messages. It is a time-independent protocol. The second and third protocols operate over channels that lose, reorder, and duplicate messages. For their correct operation, it is necessary that messages in the channels have bounded lifetimes. They are time-dependent protocols.

A distributed alternative to finite-state-machine specifications

Abstract: A specification technique, formally equivalent to finite-state machines, is offered as an alternative because it is inherently distributed and more comprehensible. When applied to modules whose complexity is dominated by control, the technique guides the analyst to an effective decomposition of complexity, encourages well-structured error handling, and offers an opportunity for parallel computation. When applied to distributed protocols, the technique provides a unique perspective and facilitates automatic detection of some classes of error. These applications are illustrated by a controller for a distributed telephone system and the full-duplex alternating-bit protocol for data communication. Several schemes are presented for executing the resulting specifications.

Interface comprising message and protocol processors for interfacing digital data with a bus network

Abstract: A network interface equipment for a bus network employs separate processors and random-access memories for handling bus-protocol and data portions of a data packet. Each processor has access to a separate random-access memory to and from which it moves data. The random-access memories are multiple-ported to permit access by more than one requester with a logic arbitrator to resolve conflicts. A status random-access memory provides communication between the two processors.

Think Pad: A Graphical system for Program-ming bY Demonstration

Abstract: Specifying complex programs may become easier if the programming system allows the programmer to manipulate data structures graphically.

Decentralized object finding using forwarding addresses (object, network, distribution)

Abstract: A problem that must be solved in designing a large distributed computing system is ensuring that processors can "find" all of the "objects" that they have the right to access. To avoid the potential reliability problems and bottlenecks that can be introduced by centralized services it is desirable that object finding be decentralized and allow any group of processors to proceed independently and autonomously. Given a model of a decentralized system in which objects are analogous to moveable physical objects and in which access rights are carried only by proper names, we examine in detail the implications of using forwarding addresses for finding objects. Special emphasis is placed on the issues of performance, active resource management, and high availability through distribution. We analyze the cost of using each of several object finding protocols based on forwarding addresses, deriving ammortized worst case upper and lower bounds as well as estimates for the average case. The average case costs of two simple protocols are analyzed using Markov chains, revealing that the mean cost per access is order of the square root of N, where N is the number of distinct processors that an object visits. The worst case costs of a path compressing protocol are determined to be order of log N. If the object is accessed a times and moves m times, then all cost estimates are decreasing functions of a/m. We provide a detailed specification of a possible implementation of the PCacc protocol. One extension of the basic implementation involves the addition of a mechanism called an inexact reference set. This extension enables a processor to actively manage its resources, both enabling it to reclaim the storage occupied by forwarding addresses and to control the use of storage occupied by objects. Another extension that we describe is that of allowing forwarding addresses to point to the multiple processors that host distributed objects. We show that this extension ensures enhanced accessibility in the presence of processor faults.

A Fair Protocol for Signing Contracts (Extended Abstract)

Abstract: Assume that two parties, A and B, want to sign a contract over a communication network, i.e. they want to exchange their “commitments“ to the contract. We consider a contract signing protocol to be fair if, at any stage in its execution, the following hold: the conditional probability that party A obtains B's signature to the contract given that B has obtained A's signature to the contract, is close to 1. (Symmetrically, when switching the roles of A and B).

Protocol analysis using numerical Petri nets

Abstract: This paper presents a method for specifying and analysing communication protocols using Numerical Petri Nets (NPNs). These nets are analysed using PROTEAN — a PROTocol Emulation and ANalysis computer aid which incorporates graphics. NPNs and PROTEAN are described and illustrated by the analysis of an Integrated Services Digital Network access protocol. Results of the application of the method to a number of "real world" protocols are reported.

Dialogues: A basis for constructing programming environments

Abstract: The components of a programming environment must communicate with the user while maintaining a state that is constantly evolving We introduce the “dialogue”, an abstraction of such components, and we implement a dialogue function in a purely applicative language The dialogue function exploits the properties of lasy evaluation and recursion to implement communication and state through recursively defined streams We show how to define programming environment components using dialogues The components of the resulting programming environment are consistent in their treatment of communication and state

The trace specification of communications protocols

Abstract: A methodology for the formal specification of communications protocols is described. Communications protocol software offers special specification problems, because typically such software connects computers which are widely distributed geographically and differ in model, manufacturer and operating system. The specification method discussed is a modified version of traces, which were originally developed as a general technique for software specification. The author first describes the trace language and presents several examples. He then describes the trace methodology, illustrated with a specification of Stenning's protocol. He summarizes his experience of using the methodology to write specifications of major portions of two commercial standards: the Advanced Data Communications Control Protocol (ADCCP) and the Internet Protocol (IP). It is concluded that traces are a feasible technique for formal specification of communications protocols.

Towards a transport service for transaction processing applications

Abstract: The DoD Internet protocol suite includes two alternative transport service protocols, TCP and UDP, which provide virtual circuit and datagram service, respectively. These two protocols represent points in the space of possible transport service attributes which are quite "far apart". We want to examine an important class of applications, those which perform what is often called "transaction processing". We will see that the communication needs for these applications fall into the gap "between" TCP and UDP -- neither protocol is very appropriate. This RFC is concerned with the possible design of one or more new protocols for the ARPA-Internet, to support kinds of applications which are not well supported at present. The RFC is intended to spur discussion in the Internet research community towards the development of new protocols and/or concepts, in order to meet these unmet application requirements. It does not represent a standard, nor even a concrete protocol proposal.

On "A Simple Protocol Whose Proof Isńt": The State Machine Approach

Abstract: We discuss how to model a synchronous protocol (due to Aho, Ullman, and Yannakakis) using communicating finite state machines, and present a proof for its safety and liveness properties. Our proof is based on constructing a labeled finite reachability graph for the protocol. This reachability graph can be viewed as a sequential program whose safety and liveness properties can be stated and verified in a straightforward fashion.

A Multiaccess Protocol for Multihop Radio Networks

Abstract: We describe an adaptive multiaccess channel protocol for use in radio networks with an arbitrary distribution of stationary hidden nodes, which provides the nodes with controlled, collision-free access to the channel. The protocol can be considered to belong to the BRAM [5] protocol family, but differs in significant ways from BRAM. In this paper we describe the tenets of the protocol, then develop the protocol, and finally develop analytic expressions for its expected throughput and delay performance. Given these delay-throughput expressions, we show how protocol "delay" optimization can be achieved by dynamic adjustment of a protocol parameter as the network traffic load changes.

An Object-Oriented Protocol for Managing Data.

Abstract: Many researchers believe that object-oriented languages are well suited for some of the programming tasks associated with the building of an office information system (OIS). To lend support to this thesis, we shall concentrate our attention on an object-oriented programming environment, named Oz, which has been effectively employed to capture certain aspects of OISs more simply and naturally than with conventional languages. After pointing out some of the limitations of Oz, we introduce additional facilities into it which further enhance its capabilities, especially with respect to the management of office data. 1 . I N T R O D U C T I O N One of the means of evaluating the utility of a programming language is to measure the effort associated with the programming of particular applications. It has been argued that by this standard, object-oriented languages are appropriate for the implementation of OISs (NIER85). A straightforward way to defend such a proposition is to demonstrate that essential characteristics of OISs can be captured more readily by the object protocol of a given object-oriented language than by the constructs associated with conventional programming languages. This was the impetus for developing Oz, a prototype object-oriented programming environment implemented at the University of Toronto (NIER83, MOON84, TWAI84]. While Oz bears comparison to general purpose systems such as Smalltalk, it is distinguished by features which reflect its intended use as a tool for building OISs. These features in turn reflect the designers view of what an OIS is. This requires some elaboration. In the office place of today, an OIS has come to refer to an aggregation of software often including word processing, graphics, electronic mail, database management and spreadsheets. In the more sophisticated of these systems, such as Lotus 1-2-3 and Symphony, a certain level of integration is achieved by allowing data flow among the constituent programs. Research in OIS is directed towards more than just the development of integrated software tools with increased functionality and ease of use. These tools assist the office worker in performing his tasks. However, they are passive in that they do not initiate or control the processing of office tasks [LOCH83, This research was supported in part by the Natural Sciences and Engineering Research Council of Canada under grants G1359 and G1360. Author's address: Computer Systems Research Institute, University of Toronto, Toronto, Ontario, Canada, M5S 1A4 (416/9786610). CSNET: weiser.toronto®csnet-relay.

Toward the Next Generation of Data Modeling Tools

Abstract: This paper describes the Update Protocol Model (UPM), a formal language for the expression of database update semantics. UPM has been used primarily to capture and communicate in a precise and uniform notation the plethora of database semantics described by a variety of "fourth generation" models, many of which are imprecise when it comes to update semantics. Several computing trends–knowledge-based expert systems, distributed database management systems, and new applications based on higher order semantic models–point to the need for modeling techniques beyond that which current data models such as the relational and entity-relationship models provide.

Time in Formal Protocol Specifications

Abstract: The need for formal, machine-readable specification of the protocols used in distributed computer systems is widely accepted. In these formal protocol specifications relatively little attention has been paid to the problem of including time — the time it takes to execute various portions of the protocol as well as explicit values for timeouts. In this tutorial, models for including time are reviewed. Techniques for analyzing these models are then discussed. A comprehensive bibliography is included.

SW 2 - An object-based programming environment

Abstract: Programming systems traditionally deal with only a few different types of data objects. Operating-system command languages, for example, are concerned with files and programs. Typical programming languages deal with computer-related objects such as integers, strings, arrays, and records. This is in sharp contrast to the variety of real-world objects that people reason about. Smallworld is a programming environment in which the real world is represented by objects that have properties. A property represents a fact about the corresponding real-world entity. Thus Smallworld actions (programs), which operate on objects specified in this simple but general way, are “smart”: they consider all of the relevant facts concerning (that is, all of the properties of) the objects they manipulate. Smallworld was strongly influenced by the design of Smalltalk, especially in the organization of objects into classes and superclasses. The two languages differ (1) in their treatment of the difference between classes and objects that are not classes and (2) in their definition of methods that act on classes. Smallworld minimizes the differences between classes and non-class objects, resulting in a simpler and more consistent system. Where Smalltalk is a programming language using a pure object-oriented paradigm and dependent on a powerful graphical interface, Smallworld is a shell language that runs on conventional terminals and allows multiple program paradigms where appropriate.

Some problems with the specification of the Military Standard Internet Protocol

Abstract: The purpose of this RFC is to provide helpful information on the Military Standard Internet Protocol (MIL-STD-1777) so that one can obtain a reliable implementation of this protocol. This paper points out several problems in this specification. This note also proposes solutions to these problems.

Modeling physical layer protocols using communicating finite state machines

Abstract: We illustrate the usefulness of communicating finite state machines in modeling a number of physical layer protocols that include (i) an asynchronous start-stop protocol and (ii) a protocol for synchronous transmission with modems. Each protocol is modeled as a network of four finite state machines that communicate by exchanging messages over unbounded, FIFO channels. (Two machines are used to model the protocol itself, while the other two are used to model its interface to the upper data link protocol in the protocol hierarchy.) We outline a methodology to verify communication boundedness and progress for each protocol model. The methodology is based on three techniques that were proposed earlier to verify networks of communicating finite state machines; they are network decomposition, machine equivalence, and closed covers.

A simple software environment based on objects and relations

Abstract: This paper presents a simple programming system based on a clear separation of value-oriented programming and object-oriented programming [MacLennan82, MacLennan83a]. The value-oriented component is a conventional functional programming language. The object-oriented component is based on a model of objects and values connected by relations, and on production system-like rules that determine the alteration of these relations through time. It is shown that these few basic ideas permit simple prototyping of a software development environment.

A Study of An Internet Protocol Implementation

Abstract: This report presents a detailed timing analysis of the dynamic behavior of TCP/IP and UDP/IP as they are implemented in the released 42BSD version of the Berkeley UNIX operating system The analysis is based on a series of performance measurements in the kernel, directed by a specific task The organization of the code and the algorithms used in the implementation of each routine are discussed The effects of this organization and these algorithm on the performance of each protocol are discussed A model is proposed to estimate the minimum cost of a protocol implementation, and a comparison is made with the measured results The results of this paper suggest that the implementation is responsible for a good deal of the overhead in the measured performance In addition, the overheads of both light and medium weight protocol do not appreciably differ from each other, and are overshadowed by the performance penalties due to interface to the user and to the hardware