Algebraic Specification Of Communication Protocols S Mauw G J Veltink Editors

Algebraic Specification Of Communication
Protocols S Mauw G J Veltink Editors download
https://ebookbell.com/product/algebraic-specification-of-
communication-protocols-s-mauw-g-j-veltink-editors-2225470
Explore and download more ebooks at ebookbell.com

Here are some recommended products that we believe you will be
interested in. You can click the link to download.
Foundations Of Algebraic Specification And Formal Software Development
Donald Sannella
https://ebookbell.com/product/foundations-of-algebraic-specification-
and-formal-software-development-donald-sannella-2524176
Semantics And Algebraic Specification Essays Dedicated To Peter D
Mosses On The Occasion Of His 60th Birthday 1st Edition Jens Palsberg
Auth
https://ebookbell.com/product/semantics-and-algebraic-specification-
essays-dedicated-to-peter-d-mosses-on-the-occasion-of-his-60th-
birthday-1st-edition-jens-palsberg-auth-4143334
Casl Reference Manual The Complete Documentation Of The Common
Algebraic Specification Language 1st Edition Peter D Mosses
https://ebookbell.com/product/casl-reference-manual-the-complete-
documentation-of-the-common-algebraic-specification-language-1st-
edition-peter-d-mosses-1080814
Semantics And Algebraic Specification Essays Dedicated To Peter D
Mosses On The Occasion Of His 60th Birthday 1st Edition Jens Palsberg
Auth
https://ebookbell.com/product/semantics-and-algebraic-specification-
essays-dedicated-to-peter-d-mosses-on-the-occasion-of-his-60th-
birthday-1st-edition-jens-palsberg-auth-1295002

Algebraic Foundations Of Systems Specification Egidio Astesiano
Hansjrg Kreowski Bernd Kriegbrckner
https://ebookbell.com/product/algebraic-foundations-of-systems-
specification-egidio-astesiano-hansjrg-kreowski-bernd-
kriegbrckner-7158976
Casl User Manual Introduction To Using The Common Algebraic
Specification Language 1st Edition Michel Bidoit
https://ebookbell.com/product/casl-user-manual-introduction-to-using-
the-common-algebraic-specification-language-1st-edition-michel-
bidoit-1076722
Algebraic Specifications In Software Engineering An Introduction Ivo
Van Horebeek Johan Lewi
https://ebookbell.com/product/algebraic-specifications-in-software-
engineering-an-introduction-ivo-van-horebeek-johan-lewi-7158982
Nondeterminism In Algebraic Specifications And Algebraic Programs
Paperback H Hussmann
https://ebookbell.com/product/nondeterminism-in-algebraic-
specifications-and-algebraic-programs-paperback-h-hussmann-7158980
Specification Algebra And Software Essays Dedicated To Kokichi
Futatsugi 1st Edition Shusaku Iida
https://ebookbell.com/product/specification-algebra-and-software-
essays-dedicated-to-kokichi-futatsugi-1st-edition-shusaku-iida-4664670

ALGEBRAIC SPECIFICATION OF
COMMUNICATION PROTOCOLS

Cambridge Tracts in Theoretical
Computer Science
Managing Editor Professor CJ. van Rijsbergen,
Department of Computing Science, University of Glasgow
Editorial Board
S. Abramsky, Department of Computing Science, Imperial College of Science
and Technology
P.H. Aczel, Department of Computer Science, University of Manchester
J.W. de Bakker, Centrum voor Wiskunde en Informatica, Amsterdam
J.A. Goguen, Programming Research Group, University of Oxford
Y. Gurevich, Department of Electrical Engineering and Computer Science,
University of Michigan
J.V. Tucker, Department of Mathematics and Computer Science,
University College of Swansea
Titles in the series
1. G. Chaitin Algorithmic Information Theory
2. L.C. Paulson Logic and Computation
3. M. Spivey Understanding Z
4. G. Revesz Lambda Calculus, Combinators and Functional Programming
5. A. Ramsay Formal Methods in Artificial Intelligence
6. S. Vickers Topology via Logic
7. J-Y. Girard, Y. Lafont & P. Taylor Proofs and Types
8. J. Clifford Formal Semantics & Pragmatics for Natural Language Processing
9. M. Winslett Updating Logical Databases
10. K. McEvoy & J.V. Tucker (eds) Theoretical Foundations of VLSI Design
11. T.H. Tse A Unifying Framework for Stuctured Analysis and Design Models
12. G. Brewka Nonmonotonic Reasoning
14. S.G. Hoggar Mathematics for Computer Graphics
15. S. Dasgupta Design Theory and Computer Science
17. J.C.M. Baeten (ed) Applications of Process Algebra
18. J.C.M. Baeten & W. P. Weijland Process Algebra
21. D.A. Wolfram The Clausal Theory of Types
23. E.-R. Olderog Nets, Terms and Formulas
26. P.D. Mosses Action Semantics
27. W.H. Hesselink Programs, Recursion and Unbounded Choice
29. P. Gardenfors (ed) Belief Revision
30. M. Anthony & N. Biggs Computational Learning Theory
31. T.F. Melham Higher Order Logic and Hardware Verification
32. R.L. Carpenter The Logic of Typed Feature Structures
33. E.G. Manes Predicate Transformer Semantics
34. F. Nielson & H.R. Nielson Two Level Functional Languages
35. L. Feijs & H. Jonkers Formal Specification and Design
36. S. Mauw & GJ. Veltink (eds) Algebraic Specification of Communication Protocols
37. V. Stavridou Formal Methods in Circuit Design

ALGEBRAIC SPECIFICATION OF
COMMUNICATION PROTOCOLS
Edited by
S. Mauw
Eindhoven University of Technology
G.J. Veltink
ISYTEC, Bremen
CAMBRIDGE
UNIVERSITY PRESS

CAMBRIDGE UNIVERSITY PRESS
Cambridge, New York, Melbourne, Madrid, Cape Town, Singapore, Sao Paulo, Delhi
Cambridge University Press
The Edinburgh Building, Cambridge CB2 8RU, UK
Published in the United States of America by Cambridge University Press, New York
www.cambridge.org
Information on this title: www.cambridge.org/9780521418836
© Cambridge University Press 1993
This publication is in copyright. Subject to statutory exception
and to the provisions of relevant collective licensing agreements,
no reproduction of any part may take place without the written
permission of Cambridge University Press.
First published 1993
This digitally printed version 2008
A catalogue recordfor this publication is availablefrom the British Library
ISBN 978-0-521-41883-6 hardback
ISBN 978-0-521-08812-1 paperback

CONTENTS
Introduction 1
S. Mauw & GJ. Veltink
1.1 Aim and Scope 1
1.2 Formal Methods 2
1.3 Computer Networks 3
1.3.1 LANs & WANs 4
1.3.2 Network Structure 4
1.3.3 OSI Reference Model 4
1.3.4 Terminology 6
1.4 Overview 6
1.5 Bibliographical Notes 7
Algebraic Specifications in PSF 9
2.1 Introduction 9
2.2 ACP 9
2.3 The History of PSF 10
2.4 PSF: Syntax and Semantics 11
2.4.1 Basic Operators 11
2.4.1.1 Action Relations 11
2.4.1.2 The Example 12
2.4.1.3 Identifier Names, Lexical Conventions 12
2.4.1.4 Comments 12
2.4.1.5 Atoms & Processes 13
2.4.1.6 Deadlock 14
2.4.1.7 Sequential Composition 14
2.4.1.8 Recursion 14
2.4.1.9 Alternative Composition 15
2.4.1.10 Integrating Components 16
v

vi Contents
2.4.1.11 Sets 17
2.4.1.12 Communication 17
2.4.1.13 Parallel Composition 17
2.4.1.14 Encapsulation 18
2.4.1.15 The Internal Step 18
2.4.1.16 Abstraction 19
2.4.1.17 Summary of the Process Part of PSF 20
2.4.2 Modularization 20
2.4.2.1 Modules 21
2.4.2.2 Exports 21
2.4.2.3 Hidden Objects 22
2.4.2.4 Importing Modules & Renaming Objects 22
2.4.3 Data Modules & Parameterization 24
2.4.3.1 Sorts & Functions 24
2.4.3.2 Equations 25
2.4.3.3 Initial Algebra Semantics 25
2.4.3.4 Parameterization of Actions and Processes 26
2.4.3.5 Overloading of Identifiers 27
2.4.3.6 Variables 28
2.4.3.7 Generalized Alternative and Parallel Composition 28
2.4.3.8 Parameterization of a Module 29
2.4.3.9 Conditional Expressions 30
2.4.3.10 Binding of Parameters 31
2.5 The PSF Standard Library 33
2.5.1 Booleans 34
2.5.2 Naturals 34
2.5.3 Bits 34
2.5.4 Queues 35
2.5.5 Tables 35
2.5.6 Data 36
2.6 The PSF-Toolkit 36
2.6.1 The PSF Compiler 38
2.6.2 Term Rewriting 38
2.6.3 The Term Rewriter 39
2.6.4 The Simulator 40
2.6.5 The Proof Assistant 41
2.6.6 Calculating Initial Algebras 42
2.6.7 Generating Transition Systems 43
2.6.8 Equivalence Testing 44
2.6.9 Implementation & Acknowledgements 45
2.7 Summary 45
3 Simple Protocols 47
/./. van Wamel
3.1 Introduction 47

Contents
3.2 General Description 48
3.3 Alternating Bit Protocol 50
3.3.1 Description of the ABP 50
3.3.2 Specification of the ABP in PSF 51
3.3.2.1 Frames 51
3.3.2.2 Sender 52
3.3.2.3 Message Channel 53
3.3.2.4 Receiver 53
3.3.2.5 Acknowledgement Channel 54
3.3.2.6 ABP 55
3.3.2.7 Simulation of the ABP 56
3.3.2.8 Remark on the Specification of the Channels 56
3.4 Positive Acknowledgement with Retransmission Protocol 56
3.4.1 Description of the PAR-Protocol 57
3.4.2 Specification of the PAR-Protocol in PSF 58
3.4.2.1 Frames 58
3.4.2.2 Sender 59
3.4.2.3 Timer 60
3.4.2.5 Receiver 61
3.4.2.7 PAR 62
3.5 Concurrent Alternating Bit Protocol 63
3.5.1 Description of the CABP 63
3.5.2 Specification of the CABP in PSF 64
3.5.2.1 Frames 64
3.5.2.2 Sender 65
3.5.2.4 Receiver 66
3.5.2.5 Acknowledgement Sender 67
3.5.2.7 Acknowledgement Receiver 68
3.5.2.8 CABP 68
3.6 Summary 69
Sliding Window Protocols 71
/./. Brunekreef
4.1 Introduction 71
4.1.1 General Description of a Sliding Window Protocol 71
4.2 The 'One Bit' Protocol 73
4.2.1 General Introduction 73
4.2.2 Specification of the 'One Bit' Protocol 76
4.2.2.1 Frames 77
4.2.2.2 Sides 77
4.2.2.3 The Interface Message Processor 78

Contents
4.2.2.4 The Timer 79
4.2.2.5 The Channel 80
4.2.2.6 The 'One Bit* protocol 82
4.3 The 'Pipelining with Go Back n' Protocol 83
4.3.2 Specification of the 'Pipelining' protocol 85
4.3.2.1 Frame Numbers 85
4.3.2.2 Frames 86
4.3.2.3 Windows 87
4.3.2.4 Timers 87
4.3.2.5 Channel States 88
4.3.2.7 The Timer 90
4.3.2.9 The 'Pipelining' protocol 93
4.4 The 'Nonsequential Receive with Selective Repeat' Protocol 94
4.4.2 Specification of the 'Nonsequential Receive' Protocol 99
4.4.2.1 Maximum Buffer Size 99
4.4.2.2 Frames 99
4.4.2.3 Timers 100
4.4.2.5 The Timer 104
4.4.2.7 The 'Nonsequential Receive' Protocol 106
4.5 The External Behaviour of an SWP 108
4.5.1 The Communication between SWP and Hosts 108
4.5.2 The Performance of the three Protocols Ill
4.6 Summary Ill
5 The Amoeba Transaction Protocol 113
/./. Brunekreef
5.1 Introduction 113
5.2 A General Description of the Amoeba Transaction Protocol 114
5.2.1 The Transaction Layer 114
5.3 Specification of the Amoeba Transaction Protocol 119
5.3.1 Amoeba Data 120
5.3.2 Messages 120
5.3.3 Maximum Number of Retransmissions 121
5.3.4 Channel States 122
5.3.5 The Client 122
5.3.6 The Server 123
5.3.7 The Transaction Protocol - the Client Part 125
5.3.8 The Transaction Protocol - the Server Part 127
5.3.9 The Channels 130

Contents j x
5.3.10 The Amoeba Transaction Protocol 131
5.3.11 The Communication between Client and Server 132
5.4 Summary 133
Two Simple Protocols for Local Area Networks 135
/./. Brunekreef
6.2 The Logical Link Control Interface 137
6.2.1 General Description 137
6.2.2 A Specification of the LLC Interface 138
6.2.2.1 Network Data 139
6.2.2.2 Network Parameters 140
6.2.2.3 LLC Data 140
6.2.2.4 The Logical Link Control Interface 141
6.3 A Simple Token Ring Protocol: STR 142
6.3.2 A Specification of the STR Protocol 143
6.3.2.1 STR Data 144
6.3.2.2 Frames 145
6.3.2.3 The Simple Token Ring Protocol 145
6.3.2.4 The Simple Token Ring Network 148
6.3.2.5 A Simple Token Ring Station 149
6.4 A Simple CSMA/CD Protocol: SEN 150
6.4.2 A Specification of the SEN Protocol 151
6.4.2.1 SEN Data 152
6.4.2.2 Frames 153
6.4.2.3 The Simple Ethernet Protocol - Transmitting Part 153
6.4.2.4 The Simple Ethernet Protocol - Receiving Part 155
6.4.2.5 The Simple Ethernet Protocol 156
6.4.2.6 The Medium 156
6.4.2.7 The Simple Ethernet Network 158
6.4.2.8 A Simple Ethernet Station 159
6.5 Summary 160
The Token Ring Protocol 161
H. Jacobsson & S. Mauw
7.2 Token Ring Network, an Introduction 161
7.3 Specification of a Token Ring 164
7.4 The Specification 165
7.4.1 Data Specification 166
7.4.1.1 Bytes 166
7.4.1.2 Symbols 166

Contents
7.4.1.3 Octets 167
7.4.1.4 Fields 168
7.4.1.5 SDU 169
7.4.1.6 Port Names 169
7.4.1.7 Utilities 170
7.4.2 Process Specification 170
7.4.2.1 Ports 171
7.4.2.2 Frame Reception 172
7.4.2.3 Token Transmission 173
7.4.2.4 Frame Transmission 174
7.4.2.5 Ring Interfaces 175
7.4.2.6 Buffers 176
7.4.2.7 Token Ring 176
7.5 Summary 177
A The PSF Library 179
A.I Introduction 179
A.2 The Library 179
A.2.1 Booleans 179
A.2.2 Naturals 180
A.2.3 Bits 181
A.2.4 Data 182
A.2.5 Queues 182
A.2.6 Tables 183
B Syntax of PSF 185
B.I Context-free Syntax 185
B.2 Lexical Syntax 188
References 189
Module Index 193
Subject Index 195

PREFACE
The specifications in this book are the result of a number of case studies performed by
researchers from the Programming Research Group at the University of Amsterdam.
The primary goal was to study the use of the techniques developed by the
Programming Research Group for the specification of real-life protocols. From the
pool of available case studies we made a selection that focuses on communication
protocols, which we present in an order well suited for use in education. We hope
that this book provides a first step towards a methodology for the design of
communication protocols using PSF.
The following people have contributed to this book: Jacob Brunekreef, Henrik
Jacobsson1
, Sjouke Mauw2
, Gert Veltink3
and Jos van Wamel.
Other people have helped in initiating and creating this book. The editors
would like to express their gratitude for their help in various ways to Jan Bergstra,
Jacob Brunekreef, Bob Diertens, Casper Dik, Hans Kamps, Hans Mulder and Jos van
Wamel.
December 1992
S.M./G.J.V.
current affiliation Oracle Netherlands
current affiliation Eindhoven University of Technology,
e-mail: sjouke@win.tue.nl
current affiliation Institute for Applied System Technology Bremen,
e-mail: veltink@isytec.uucp

CHAPTER 1
INTRODUCTION
S. MAUW& GJ. VELTINK
1.1 AIM AND SCOPE
An important reason why formal description techniques are not appreciated as
widely as wished by the developers of such techniques, is that people who actually
design and implement software have relatively little knowledge of formal methods.
The acceptance of formal techniques not only depends on the existence of techniques
that are easy to understand and easy to use, but also on the training of potential
users. This implies that there is a need for text books and case-studies. We think
that a collection of formal specifications in a restricted area of application may
help to get a better understanding of the use of formal techniques. Although the
method we use is well suited for formal verification, we concentrate on the act of
specification. A first requirement for a formal correctness proof is a formal
specification.
We restrict ourselves in this book to a collection of specifications concerning one
application area, the field of communication protocols. Although this seems to be an
area with a relatively high acceptance of formal techniques, most of the protocols
that are actually in use are specified in natural language, if ever specified otherwise
than by the actual implementation. Even well-known and accepted standards, such
as the token ring protocol, do not have a rigorous formal definition. Informal
specifications in this area may lead to misinterpretations and, thus, to different
implementations that will not be able to work together. Formal techniques are
especially needed for communication protocol design, since these protocols describe
distributed systems which have a high degree of non-determinism. This implies

Introduction
that errors are not easily detected and hard to reproduce, which makes traditional
testing techniques too unreliable for validation purposes.
The protocols described in this book cover a wide range. We start with the
description of simple point-to-point protocols, such as the Alternating Bit Protocol,
which have been specified and verified many times with a variety of formal
techniques. The more complex protocols in this book are used in practice and some of
them have never been subject of formal specification and verification before.
The main aim of this book is to provide the reader with a collection of protocol
descriptions which illustrates how to use algebraic specification techniques, be it in
the field of communication protocols or in a related area. Furthermore, we wish to
give insight in the design and operation of communication protocols. The specifi-
cations in this book have a level of abstraction that is appropriate for a clear
understanding of the protocols without having to deal with implementation details.
Although based on a formal theory of concurrent processes, this book can be under-
stood without previous knowledge of process algebras. We think that beginners as
well as professionals in the field of communication protocols will benefit from
studying the protocol descriptions provided. The sections on simple protocols are
tutorial, whereas the more complex protocols are topics of current research and are
being used in modern networks.
1.2 FORMAL METHODS
In academia it is generally recognized that formal methods are a useful technique for
software design. The main advantage of the use of formal techniques is that a formal
specification is a mathematical object which has an unambiguous meaning, therefore
mathematical methods may be used to analyse these specifications, such as formal
verification of the correctness and completeness of a specification.
Formal methods play a vital role, especially in the field of protocol standard-
ization. Standards are needed for providing connectivity among systems. Adhering to
a formal specification guarantees that system components from different manufac-
turers can be interchanged easily. A formal specification can be used to derive test
cases automatically, in order to check whether a particular implementation behaves
as expected. If the implementation language is a formal language as well, it even
makes it possible to verify formally that an implementation satisfies a given
specification.
For most formal techniques, software tools have been developed that aid in
analyzing a given specification. Apart from syntax-checking and type-checking,
most software environments for formal methods also provide a means for rapid
prototyping. Even automatic generation of an implementation is sometimes possible.
Other tools can generate test sequences that can be used for conformance testing,
which is an important validation activity in the construction of software.
A great variety of formal specification techniques exist, some of which are general
purpose (such as Z, VDM or COLD), while others are generally used in a specific
domain of application (such as LOTOS, SDL and PSF). The mathematical theories

Formal Methods
on which these languages are based range from set theory and temporal logic to
lambda-calculus and process algebra.
Formal methods have been applied in the design of a great number of systems.
Many protocols have been specified and verified formally. Some protocol standards
are even defined by means of a formal method.
The specifications in this book are written in the language PSF (Process Specification
Formalism). This is a formal specification language based on the Algebra of
Communicating Processes (ACP). PSF can be seen as a concrete representation for the
process theory ACP. Furthermore, PSF supports the use of abstract data types and
has special features for modularization and parameterization of specifications.
ACP is a theory for the specification and verification of concurrent systems. It can
be viewed as a generalization of other theories for concurrency such as CCS and CSP.
An ACP specification consists of a collection of algebraic process definitions and
verification is done by algebraic manipulation of these processes. Its semantics are
relatively simple and it can be extended easily with special features such as real
time and interrupts. ACP has been applied in the specification and verification of
many concurrent systems.
In this book we advocate the use of algebraic techniques for protocol specifi-
cation. However, we regard the PSF language as one of the many ways to obtain
formal protocol specifications and do not claim that it is the specification language
best suited for communication protocols in general.
1.3 COMPUTER NETWORKS
The way in which people interact with computers has changed significantly since
their introduction. In the early days only one user could be working with a computer
at a time. The introduction of so-called time-sharing systems made it possible for
computers to be used by a number of users at the same time. Nowadays, with
decreasing prices of computer hardware, mainframes are being more and more
replaced by clusters of smaller machines connected by a network. An important reason
for this is that the price/performance ratio of a personal computer is much better
than that of a mainframe.
A second reason for using networks, is that they allow one to construct systems
that share resources like file servers and printers. Such systems can also achieve an
increased reliability by offering duplicated services. If one computer or peripheral
device is out of order, other machines can take over its tasks.
The final reason for using computer networks, is that they make it possible to
connect computer systems that are spread out geographically. A company with
branches all over the world that each have their local computer systems can access
information about all different branches through a network that connects the local
systems.

Introduction
1.3.1 LANS & WANS
There are two important classes of networks. A Local Area Network (LAN) is used
when the distances between the computers are not too large. A typical example is a
network that connects the computers in one building. Each user has his own computer
and all users share output devices and storage devices using the LAN.
A Wide Area Network (WAN) is used when the distance between two computers
is larger, for example to establish a connection between different cities. An example
of a world-wide WAN is USENET. One of the services offered by this network is
electronic mail, which enables people all around the world to exchange messages.
1.3.2 NETWORK STRUCTURE
A network consists of a collection of computers, called hosts, and a subnet that
connects the hosts. The subnet consists of transmission lines, the medium through
which the data is transported, and special dedicated processors IMPs (Interface
Message Processor) which connect two or more communication channels.
There are two important designs for the subnet. The first design uses a so-called
point-to-point subnet. All IMPs are connected by wires or telephone lines. IMPs that
are directly connected can communicate with each other. However, two IMPs that
are not directly connected must use one or more intermediate IMPs to communicate.
Messages are sent to an intermediate IMP that stores them and waits until the
channel to the next IMP is free and sends the message further. Most WANs are
implemented using point-to-point subnets.
The second communication architecture, which is mainly used in LANs, uses a
mechanism called broadcasting. Whenever a message is sent by one machine, all
other machines connected to the subnet receive this message. The message contains an
address, which indicates for which machine the message was intended. The
receiving stations that do not have a matching address, simply discard the message.
1.3.3 OSI REFERENCE MODEL
In the previous section we discussed how computers can be connected on the physical
level. Having such a connection does not automatically imply that two computers can
understand each other. It might well be the case that both computers use a different
way of representing information. To make sure that they can communicate they have
to adhere to certain agreements of how to exchange data. Such an agreement is called
a protocol.
In the early days of networks, each manufacturer used his own protocols. Such an
approach makes it difficult to connect systems of different manufacturers. To
overcome such problems the ISO (International Standards Organization) has made a
proposal for an international standard for networking. This standard is called the
ISO OSI (Open Systems Interconnection) Reference Model.
The OSI model is divided into seven layers, as shown in Figure 1.1. One
important reason for dividing the network into layers is to reduce the design
complexity of a network system. Each layer has its own specific task and offers
services to a higher layer, based on the services offered by a lower layer. In this way
a layer is shielded from the implementation details of lower layers.

Computer Networks
application protocol
7 | application layer ftj —
I
pr e s c n t a t l o n
TZ
presentation protocol
session protocol
- >| application layer j
- > presentation layer j*
| session layer m ->| session layer fe
, | i—= L transport protocol , i—=
4 | transport layer p >| transport layer
3 | network la
yc r
1 "
2 I data link layer
network protocol r
_£. w
linkprotocol
network layer
physical protocol
>| data link layer
physical layer
HostA
Figure 1.1 The ISO OSI Reference Model
A layer on level n on one computer communicates with the layer on level n on
another computer. The set of rules for communication that they adhere to is called
the protocol of layer n. The processes in the same layer, in two different computers
that communicate with each other, are called peer processes.
There is no direct transmission of data from layer n on one machine to layer n on
the other machine. Instead, data is sent to the layer immediately below, until the
physical layer is reached. The physical layer forms the only actual connection
between two computers. All other layers are in fact different levels of abstraction of
communication.
The seven layers are roughly divided into two groups, levels 1 to 4 are called the
communication layers and we refer to the levels 5 to 7 as application layers. The
lower layers take care of the exchange of information between two computers. The
upper layers contain, among others, encryption and decryption techniques, trans-
formations between different methods of character representation such as ASCII and
EBCDIC, and routines for transferring a file from one file system to another. Only the
communication layers of the OSI model will be of interest for the topics treated in
this book, so we will briefly describe their functions.
The physical layer is dedicated to the transmission of bits over a physical
communication channel. In this layer there are standards that describe how the
different bit values 0 and 1 must be represented.
The transmission of data on the physical level can be distorted in many ways,
because data often has to travel a long way through physically unreliable channels,
such as the atmosphere and telephone wires. It is the responsibility of the data link
layer to transform this unreliable connection into an error-free communication
channel for the higher layers.
The main task of the network layer is to determine the route by which data has
to travel through the network. If data has to travel from one network to another, it

Introduction
is also the responsibility of the network layer to offer services that enable this
coupling of networks.
It is the responsibility of the transport layer to decide how a transport
connection, needed by the higher layers, is mapped onto the available network
connections. If two hosts are connected by more than one network connection, the
transport layer can decide to split the data and send it along the different network
connections to achieve better performance. This technique is called downward
multiplexing. On the other hand it is possible that the upper layers need more
transport connections than available network connections. In this case the transport
layer can decide to merge the data of several transport connections, so that they can
be transported over fewer network connections. This technique is called upward
multiplexing.
1.3.4 TERMINOLOGY
The protocols that are described in this book, are mainly situated in the data link
layer. We recall that the main task of this layer is to offer the network layer an
error-free communication channel. In this section we will introduce the terminology
used in the specifications of the protocols from the data link layer.
The specifications deal with the transmission of data from a sender to a receiver, via
a channel. There are three possibilities of data transfer along a channel with respect
to the direction of the data.
• simplex', data can be transported in only one direction
• half-duplex: data can be transported in both directions but only in one direction at
a time
• full-duplex: data can be transported in both directions at the same time
To be able to detect transmission errors that may occur in the physical layer, the
data stream is augmented with extra information also called a checksum. The
method normally used to calculate this checksum is the Cyclic Redundancy Code
(CRC). The receiver verifies the checksum of the incoming data and if this
verification fails it raises a checksum error to indicate that something went wrong.
One possible action then is to ask the sender to retransmit the garbled data.
In the PSF specifications it is required that a communication channel is fair. This
means that a channel does not produce an infinite stream of garbled data, but that it
will sooner or later transmit a datum correctly.
1.4 OVERVIEW
This book contains seven chapters, most of which can be read and understood
independently. A prerequisite for understanding Chapters 3 to 7 is knowledge of the
PSF language, which is explained in Chapter 2. All specifications in this book are
analyzed with the checking and simulation tools from the PSF-Toolkit. Knowledge

Overview
of the PSF-Toolkit, which is also described in Chapter 2, is not necessary for
understanding the specifications.
Chapters 3 and 4 are concerned with point-to-point protocols, that is, protocols
which communicate information from one fixed location to another (and possibly
back) using an unreliable channel. It is advisable to read Chapter 3 before Chap-
ter 4. Chapter 3 contains a specification of three simple protocols for simplex com-
munication. These are the alternating bit protocol (ABP), a protocol with positive
acknowledgement and retransmissions (PAR), and the concurrent alternating bit
protocol (CABP). They differ in the sense that PAR and CABP can handle "lossy"
channels, while ABP can only correct mutilated messages. In the PAR protocol a
timer is used to overcome lost messages, while in the CABP this is solved by sending
a continuous stream of messages.
Chapter 4 contains three more-evolved point-to-point protocols from the class of
sliding window protocols. These protocols are full-duplex. The simplest is the one-
bit protocol, which has a sending window and a receiving window of size 1. Such a
window is a buffer which contains messages that are not yet acknowledged. A more
efficient protocol is the "pipelining with go back N" protocol, which has a sending
window size greater than 1. A still more efficient protocol is the "nonsequential
receive with selective repeat" protocol which also has a receiving window greater
than 1.
Chapter 5 contains a protocol for communication in a distributed operating
system; the Amoeba Transaction protocol. It is used in the Amoeba distributed
operating system for information exchange between two processes.
Chapters 6 and 7 contain protocols for Local Area Networks. A simple token ring
protocol and a simple ethernet protocol are specified in Chapter 6. The simple token
ring protocol can be used in a network with a ring architecture. The simple ethernet
protocol is a CSMA/CD (Carrier Sense Multiple Access with Collision Detection)
protocol, which is used on a bus architecture.
A specification of a token ring protocol based on the formal IEEE standard (IEEE
8802/4) is given in Chapter 7.
1.5 BIBLIOGRAPHICAL NOTES
There are two books that are strongly related to this book: Process Algebra ([BW90])
and Applications of Process Algebra ([Bae90]). We consider [BW90] as a basic text on
process algebra theory and [Bae90] as an example of the application of this theory,
especially in the sense of correctness verification. In our view, this collection of
protocol specifications demonstrating the practical use of process algebra will link
up nicely with the two aforementioned books.
This book is completely self-contained, in the sense that it can be read without
previous knowledge of the process theory explained in [BW90]. Nevertheless we
expect that this book will stimulate readers to take an interest in the theoretical
backgrounds of concurrency theory. One can take full advantage of the formal method
used in this book by studying both the mathematical background from [BW90] and
the verification examples of [Bae90].

Introduction
The PSF language is defined in [MV90]. Other formal methods are described in
[FJ92], [VDM88], [SDL84] and [ISO89]. The theory ACP was developed by Bergstra
and Klop [BK84]. CCS and CSP are other theories for the specification of concurrent
systems. They are described in [Mil89] and [Hoa85].
There are a number of other examples of the use of PSF and ACP concerning the
specification of communication protocols. These are, amongst others [MW89],
[Mau90], [MM90] and [VW92].
A comprehensive introduction to the OSI model is [HS88]. More general books on
computer networks are [Tan89] and [Sch87].

CHAPTER 2
ALGEBRAIC SPECIFICATIONS IN PSF
GJ. VELTINK
2.1 INTRODUCTION
In this chapter we will focus on the specification language used throughout this
book: PSF (Process Specification Formalism). We will discuss the mathematical
origins of PSF as well as its syntax and semantics. The language itself will be
clarified by using a running example, which gets more complicated as new language
features are introduced. Apart from giving specifications in PSF we will also describe
the implementations that make up the so-called PSF-Toolkit, such as the term
rewriting system and the simulator.
The PSF-Toolkit also embodies a collection of frequently used specifications in
the form of the PSF standard library. In this chapter we will explain which modules
are part of the library and how they can be used. A full listing of the relevant
modules from the PSF standard library can be found in Appendix A.
2.2 ACP
Before we turn our attention to PSF, we will give some information on ACP (Algebra
of Communicating Processes). ACP is the theoretical foundation for the process part
of PSF, and deserves some explanation as such.
The development of ACP was started in 1982 by J.A. Bergstra and J.W. Klop, at
the Centre for Mathematics and Computer Science in Amsterdam. Compared with
other concurrency theories like CCS, CSP and Petri Nets, ACP is most closely allied

10 Algebraic Specifications in PSF
to CCS. The main difference between ACP and the other approaches is the way in
which the semantics is treated.
Most formalisms, like CCS, CSP and Petri Nets are based on one specific model of
concurrency. ACP, however, is a theory based on algebraic methods*. The theory is
defined by a set of axioms. The collection of possible models of this set of axioms
contains most of the models for concurrency that have been proposed. By extending or
restricting this set of axioms and by adding new operators, one can change the
collection of possible models. This is a more general approach than the one which
focuses on a single model. In many cases an algebraic approach towards verification
has advantages over the model based approach.
2.3 THE HISTORY OF PSF
Several small tools for ACP were constructed between 1982 and 1986, but the lack of a
unifying framework led to many inconsistencies between these tools. In the Autumn of
1987 the PAT (Process Algebra Tools) project was started. This project aimed at
constructing an integrated environment of computer tools for studying concurrent
systems, especially in the setting of ACP.
The first step towards this goal was the definition of PSF, a computer readable
language to specify ACP processes. Although ACP uses data types in an informal
way, it was felt that PSF should incorporate data types on a more formal basis. The
language definition of PSF was completed in the Spring of 1988.
The definition of data types and modularization concepts in PSF is based on the
algebraic specification language ASF (Algebraic Specification Language). The
language ASF was developed at the Centre for Mathematics and Computer Science in
Amsterdam.
The relation between ACP, ASF and PSF is given by Figure 2.1. The three blocks
represent the building blocks from which PSF has been constructed.
ASF
Figure 2.1 The constituent parts of PSF
We notice that in this text book series two volumes on process algebra in the style of ACP
have already appeared. One book describing the mathematical foundations of ACP and
one collected volume describing different applications of ACP.

PSF: Syntax and Semantics
After the PSF language had been defined, work on the tools started. This resulted in
a compiler for PSF and several tools such as a simulator and a term rewriter. A
detailed description of this still expanding set of tools is contained in this chapter.
2.4 PSF: SYNTAX AND SEMANTICS
In this section we will focus on the syntax and semantics of PSF. We will explain the
elements of the language by specifying a simple protocol that gradually becomes
more complicated as new language constructs are used. After a language construct has
been introduced in an example, we will discuss its usage, general appearance and
semantics. The full grammar of PSF can be found in Appendix B.
2.4.1 BASIC OPERATORS
PSF specifications deal with the description of the activity of processes, and the
interaction between different processes. The term process in this context must be
interpreted in a broad sense. It can range from the behaviour of a drinks dispenser
and production processes in a factory to the behaviour of human beings.
The basic manifestation of activity in PSF is represented by an atomic action. In
this book the terms atomic action, as well as atom and action will be used. Each
atomic action has a name or label and whenever an atomic action with name a is
active, we say that a happens.
Processes in PSF are defined in terms of process expressions. The atomic action is
the basic process expression. Complex process behaviour in PSF is expressed by
combining process expressions in different ways using additional operators. In PSF
there are for instance operators that tell whether two process expressions are to be
executed in succession, simultaneously or that a choice has to be made between either
one of them.
2.4.1.1 Action Relations
To attach semantics or meaning to the operators, we describe their behaviour by
means of a mathematical notation called action relations. For each atomic action a
we define a binary relation and a unary relation on process expressions. The notation
of the two relations is given below. The dots represent process expressions.
a a /
Table 2.1 Action relations
When x and y are variables for process expressions, the notation x -£> y expresses the
fact that x can evolve into y by executing the atomic action a. The notation for the
unary relation, x -^ V, is used to express that x, after having executed atomic action a,
can reach a state in which it has terminated successfully. The V symbol (tick)
indicates successful termination of a process.

The simplest action relation states that a process expression consisting of a single
atomic action a, can terminate successfully by executing this atomic action 0. This
action rule is given by:
Table 2.2 Action relation for atomic action
2.4.1.2 The Example
The running example that we will use is an abstraction of the protocol specifications
to follow. Only the basic elements of a specification of a protocol are kept. The
example describes, like most protocol specifications, a sender and receiver pair that
are connected to each other by a channel. The goal is to transmit data from the sender
to the receiver via the channel.
The graphical representation of the example is given below. The three different
processes are represented by boxes. The dots in the boxes represent the atomic actions
that a process is able to perform. The interaction between the different components is
not modelled.
input{
Sender
^output input{ output input{
error error,
Receiver
Figure 2.2 Graphical representation of the components of the running example
2.4.1.3 Identifier Names, Lexical Conventions
Entities in a PSF specification are referred to by a name. These names or identifiers
must meet some lexical requirements. The identifier character set of PSF consists of
all lower case characters {a, h, ..., z), all upper case characters (A, B, ..., Z), all
digits (0, 1, ..., 9) and the special symbols single quote (') and hyphen (-). A valid
identifier in PSF is a string starting with a lower case or upper case character,
followed by zero or more characters from the identifier character set.
In this book we will print all keywords in PSF specifications in bold face. This is
not part of the lexical conventions of PSF, but only serves to increase the legibility of
the specifications.
2.4.1.4 Comments
Comments in PSF are introduced by two consecutive hyphens (—). Comments are
closed by another pair of hyphens or by the newline character, whichever one comes
first. Within the text of the comment, characters from the complete character set of

PSF: Syntax and Semantics 13
the host computer can be used, with the exception of the above-mentioned newline
and pair of hyphens.
2.4.1.5 Atoms & Processes
The first PSF specification, representing the sender from Figure 2.2, is given below:
process module Sender
begin
atoms
inputr output
processes
Sender
definitions
Sender = input . output . Sender
end Sender
The specification is given in the form of a module. The use of modules will be
explained in more detail in the section on modularization. The module construct in
this example serves three purposes:
• it groups a set of related entities, using a begin-end pair;
• it gives the type of the module: process (as opposed to a data module);
• it attaches a name to the module: Sender.
Within the module we see different sections. The atoms section defines a set of
atomic actions by declaring their names. The processes section declares a set of
process names. Finally, the processes are defined in the definitions section by
relating a process name to a process expression using the '=' construct. In the example
the behaviour of Sender is defined in terms of the two actions input and output and
the process Sender itself. We should mention two technical points here:
• if there is more than one definition for a process in the definitions section, the
different process expressions will be interpreted as alternatives. The concept of
alternatives in PSF will be explained later.
• if a process name is declared but has not been defined, it is defined implicitly to
be deadlock. The constant process expression deadlock will be described in the
following section.
Although the language permits the usage of any valid identifier name for the
different entities, we will adhere to some standard naming convention. This will
help to distinguish between the different identifiers in a specification.
• a module name starts with an upper case character,
example: Sender.
• an action name consists of lower case characters only,
example: input.
• a process name starts with an upper case character,
example: Sender.

2.4.1.6 Deadlock
Although deadlock will never literally appear in a PSF specification, we have to
explain its behaviour. We can think of deadlock as a process expression describing a
state, from which no progression can be made. In other words: deadlock is an
unsuccessful termination. Because there are no actions that can evolve from a
deadlock, we will not associate any action relation with it.
2.4.1.7 Sequential Composition
The process expression defining the behaviour of the process Sender, consists of
atomic actions: input and output, the process Sender itself and the '-'-operator. This
operator is called the sequential composition, and expresses the order in which
events have to occur. The semantics for the sequential composition is given by the
following action relations. The expressions above the line are conditions that must be
met to conclude the expressions below the line.
a , a i
x —» x x —> V
x-y ^ x'-y x
-y ^ y
Table 2.3 Action relations for sequential composition
The first rule says that whenever x can execute an a thereby evolving into xr
, x-y can
perform this same a, and evolve into x'-y. The second rule states that whenever x can
terminate after having executed an a, the process x-y can evolve into y after an a.
In the example of the sender, the process expression input • output • Sender
executes the action input, followed by output. The remaining part of the process
expression, after these actions have been executed, is Sender.
2.4.1.8 Recursion
Process expressions can contain process names, as was shown in the previous section.
The occurrence of such a process name is in fact an abbreviation for the process
expression related to the process name as defined in the definitions section.
If the name of a process appears in its own definition, directly or indirectly
through a chain of expansions of other process names, we call this phenomenon
recursion. By using recursion it is possible to specify processes with an infinite
behaviour by means of a finite set of finite definitions. The action relations
describing recursion are given below. The X denotes the process name and x the
process expression it represents. The symbol A represents logical conjunction.
X = x A x^x' X = x A x% V
Xa
->x> X ^ W
Table 2.4 Action relations for recursion
In the example the sender, which is an infinite process, is defined by means of
recursion.

2.4.1.9 Alternative Composition
In the next specification we describe the channel from Figure 2.2. The channel we are
going to specify allows for data to travel in one direction and has the possibility of
losing the data it is transporting. The behaviour is described as follows: first the
channel reads a datum at its input port, then it decides whether to pass it on to its
output port correctly or incorrectly. Finally it returns to its initial state, waiting for
the next datum to arrive at the input port.
process module Channel
begin
atoms
input, output, error
processes
Channel, Choice
definitions
Channel = input . Choice . Channel
Choice = output + error
end Channel
The choice determining whether or not a datum is transported correctly is modelled
by the process Choice through the use of the V-operator, the alternative
composition. The process expression x + y expresses a process that first chooses non-
deterministically between x and y, and then continues with the execution of the
chosen process. The semantics for the alternative composition are given by the
following action rules:
a , a I a , a i
x-^x x —> V V ^ V y - > v
x+y ^> xy
x+y —> V x+y —> y ' x+y —> A
Table 2.5 Action relations for alternative composition
To complete the specification of the example we give the specification of the
receiver. Its behaviour is described as follows. It has to anticipate the incorrect
transmission of the datum through the channel. Therefore it can either perform an
input or an error action in its initial state. If the input action occurs, a corresponding
output action is performed and the process returns to its initial state. However, if the
error action occurs the process returns to the initial state immediately, without
performing any actions.
process module Receiver
begin
atoms
processes
Receiver

definitions
Receiver = ((input . output) + error) . Receiver
end Receiver
The example shows that parentheses can be used in the process definition, to group
expressions. The sequential composition binds stronger than the alternative
composition, so in the example the inner pair of parentheses could have been left out.
2.4.1.10 Integrating Components
Now that we have given specifications for the different components of the system we
need to integrate them. In this section we will combine them into one module. In the
section on modularization we will discuss a different approach to integration.
The first problem that we encounter when we try to put the components in one
module, is a naming problem. Each component in the original specification contained
an input and an output action. If we simply took the union of the different sections,
the name input would become ambiguous, because it would refer to three different
atomic actions. This phenomenon is called a name clash. To overcome this problem
we have to assign new names to the different atomic actions.
The specification of the complete system is given below. It contains some new
language constructs, which will be explained in detail in the sections to come.
process module System
begin
atoms
sender-input, channel-input, receiver-input,
sender-output, channel-output, receiver-output,
channel-error, receiver-error,
sender-to-channel, channel-to-receiver, error-transmission
processes
System, System', Sender, Channel, Receiver
sets
of atoms
H = { sender-output, channel-input, channel-output,
receiver-input, channel-error, receiver-error }
I = { sender-to-channel, channel-to-receiver, error-transmission }
communications
sender-output | channel-input = sender-to-channel
channel-output | receiver-input = channel-to-receiver
channel-error | receiver-error = error-transmission
definitions
Sender = sender-input . sender-output . Sender
Channel = channel-input .
(skip . channel-output + skip . channel-error) .
Channel
Receiver = ( (receiver-input . receiver-output) + receiver-error) .
Receiver

System = encaps(H, Sender || Channel || Receiver)
System1
= hide(I, System)
end System
2.4.1.11 Sets
The first new section that appears in the specification of the complete system is the
sets section. In this case two sets of atoms are defined. Sets are merely a notational
convenience and are used as parameters in certain process operators.
We can assign a name to a set, so that we do not have to repeat the contents of the
set every time we want to refer to it. In the example, H and I are defined by an
enumeration of the atomic actions that are part of the set. Moreover, there are three
set operators: union, intersection and difference. The syntax for these operators is:
• enumeration : { si, si, ...,sn) S{ is a set element
• union: S + T S and T are sets
• intersection : S .T
• difference : ST
The naming convention for sets is as follows:
• a set name starts with an upper case character,
example: H.
It is also possible to define sets of things other than atoms. We will see examples of
this at a later stage.
2.4.1.12 Communication
The other new section that appears in the example is the communications section. In
this section the possibilities of communication between the different atomic actions
are described.
In PSF communication is defined as the simultaneous occurrence of two atomic
actions. As a result of the communication these two atomic actions are transformed
into one new atomic action. The communication function, that shows which actions
are allowed to communicate and what their result will be, is defined in the
communications section. The communication definition ab = c, states that the atomic
actions a and b can communicate and that the resulting action will be c. We should
make two technical remarks with respect to the definition of the communication
function:
• for any pair of actions at most one resulting action can be defined.
• there are no communications possible, other than the ones that are explicitly
defined.
2.4.1.1 3 Parallel Composition
The definitions section of the example introduces a new operator: the parallel
composition. The expression x I
I y states that the processes x and y are executed in
parallel. PSF is based on a so-called interleaving semantics for parallel composition.
This means that either the left operand or the right operand performs an atomic

action or that the initial actions from both operands communicate with each other.
The action rules for parallel composition are:
x -> V x - ^ x A y - ^ y A a b - c x - * y A y - * y A a l b = c
X
xy
y
a
->
a
->
X
v
xy~>y
a i a , fr / i * a i 1) i h
y -> V * - > * A y - > V A a I & = c x - > V A y -> V A a I b = c
xya
-^xy' ^ C
^
Table 2.6 Action relations for parallel composition
The parallel composition binds stronger than the alternative composition, but less
strong than the sequential composition.
2.4.1.14 Encapsulation
The encapsulation operator, in the PSF specification written for example as:
encaps(H,x), is a specific instance of the general class of renaming operators.
Renaming operators rename atomic actions into process expressions. The encap-
sulation operator takes as arguments a set of atoms H, and a process expression x. All
atomic actions from H that appear in the process expression are renamed into
deadlock. This is also true for actions that are the result of some communication that
appears inside the process expression. The action relations are as follows:
a
x —
> x A
encaps(H,;t) -> encaps(H,;t') encaps(H,;t) —
> V
Table 2.7 Action relations for the encapsulation operator
There are no action relations for the case aeH. The complete encapsulation
expression has the same behaviour as deadlock, from which it is not possible to do
any steps.
The main usage of the encapsulation operator is to guide the process of
communication between two processes. In the previous section we have seen that the
parallel composition of x and y is defined as the alternative composition of three
other process expressions. Most of the time we want just one of the three alternatives
to appear, namely the one in which an atomic action from x and an atomic action
from y communicate. By adding the atomic actions that appear in x and y to the
encapsulation set, we obstruct them from being performed as such, leaving only the
possibility in which x and y have to communicate.
2.4.1.15 The Internal Step
The specification of the channel uses a new constant process expression: skip. This
skip is an internal action of the system. We will encounter its main usage in the
following section. The action rule for skip is:

T . skip 1
skip *--» V
Table 2.8 Action relation for the internal step
In the running example skip is used to make sure that the choice between successful
and unsuccessful transmission of the data is made non-deterministically. In other
words, the choice can not be influenced by the outside world.
If we leave out the skip expressions, the receiver could influence the choice by
offering only one of the possible partners in communication, thereby forcing a choice.
Now the choice is made between two indistinguishable skips.
We should mention a technical point here. The expression (skip • input) + (skip •
error) is not equivalent to skip - (input + error). In other words: the left-
distributivity does not hold, although the right-distributivity does. The difference
stems from the fact that the moment of choice in both expressions is not the same.
In the first expression it is possible to choose between the expression skip • input
or skip • error. However, the second expression offers the possibility of performing a
skip first, and only then choosing between the expressions input or error. In the second
case, the outside world would be able to influence the choice, in the way described
above.
2.4.1.16 Abstraction
The abstraction operator, in the PSF specification written as lnide(l,x), is closely
related to the encapsulation operator. The abstraction operator renames atomic
actions, contained in its set argument I, into skip. The action rules are as follows:
a , a 1 T
x-> x Aael x —> V A ael
hided,*) -i^_> hided/*') hided,*) sktp
a , T a 1
hided,*) ^ hided,*') hided,*) ^ V
Table 2.9 Action relations for the abstraction operator
The main usage of the abstraction operator is connected with the process of
communication. In a large number of specifications we are not interested in the result
of all the communication actions. A lot of communication actions are just used
internally to synchronize two or more processes. When investigating the behaviour
of a process, we are mostly interested in the external behaviour. This means that we
want to abstract from all internal activity. We can achieve this effect by renaming
all atomic actions, representing details we are not interested in, into skip.
As suggested before, the abstraction operator and encapsulation operator are
mostly used in cooperation. A typical example of such a cooperation is:
hided, encaps(H, ... ))

In the running example we have also used this construct to specify the process
System'. We abstract from all internal communications between the sender, the
channel and the receiver (sender-to-channel, channel-to-receiver, error-transmis-
sion). These actions form the set I. The set H consists of all atomic actions that take
part in the communications that result in the actions from set I. By encapsulating the
actions from H we force communication between them. The result is that in System'
the only observable behaviour consists of the actions sender-input and receiver-
output and of the constant process expression skip.
2.4.1.17 Summary of the Process Part of PSF
In this section we will give a graphical representation of the relation between the
concepts we have introduced so far. The ellipses represent the different domains we
have explained. The arrows suggest the different functions that take elements from a
domain (the dots), and produce an entity in another domain (the arrow head).
Identifiers
sequential composition
alternative composition
parallel composition
deadlock skip
Figure 2.3 Graphical representation of relations between PSF concepts
The function i represents the injection function. The injection function is an implicit,
invisible, function application. To clarify this notion we will give an example.
The string a is an identifier. Moreover it can be the name of a process, a set or an
atomic action. Whenever it is a name for a process or atomic action, it is also a
process expression representing the corresponding process or atomic action. Its type is
derived from the context in which it is used.
2.4.2 MODULARIZATION
In the previous section we have integrated different components by combining them
into one module. This method is rather cumbersome and becomes more and more

complicated as the size of the specification grows. PSF supports the use of several
modularization techniques, which will be discussed in the sequel.
2.4.2.1 Modules
In the previous specifications we have already used the module concept. Each
specification consisted of exactly one module. A PSF specification in general consists
of a series of modules. Modules can depend on objects defined in other modules, so
there exists a certain relation between them.
2.4.2.2 Exports
The first step towards modular design is to divide all the entities in a module into
two categories. One category for the objects that are visible to the world outside a
module, the exported objects, and one for those objects that are used only locally, the
hidden objects.
In PSF the exported objects are surrounded by a begin-end pair that follows the
exports keyword. All other objects that are defined are hidden. In the two examples
below all objects are exported. The two examples redefine the Sender and Receiver
processes we have defined earlier.
begin
exports
begin
atoms
input, output
processes
Sender
end
definitions
Sender = input . output . Sender
end Sender
begin
exports
begin
atoms
processes
Receiver
end
definitions
Receiver = ( (input . output) + error) . Receiver
end Receiver

2.4.2.3 Hidden Objects
To show the use of hidden objects we give the specification of a module in which the
exported process is defined in terms of an auxiliary process. Because of its very
specific nature, this auxiliary process is intended to be local to the module. This
feature of shielding functions and data from the outside world is also known as
.i.information hiding ;or .{.data encapsulation). The term hidden in the context of
modularization should not be confused with hide, the representation of the
abstraction operator in PSF. The following example redefines the Channel process.
begin
exports
begin
atoms
processes
Channel
end
processes
Choice
definitions
Channel = input . Choice . Channel
Choice = (skip . output) + (skip . error)
end Channel
The process Choice is the local process, used in the definition of Channel. It is not
meant to be known to the outside world and therefore declared to be hidden. We
recall that all entities that are not explicitly named in the exports section are
hidden.
2.4.2.4 Importing Modules & Renaming Objects
Now we will show how the three modules we have defined in the previous sections
can be combined by means of imports, into one module called System.
begin
exports
begin
atoms
sender-to-channel, channel-to-receiver, error-transmission
processes
System, System1
end
imports
Sender {
renamed by [
input -> sender-input,

output -> sender-output
Channel {
renamed by [
input -> channel-input,
output -> channel-output,
error -> channel-error
Receiver {
renamed by [
input -> receiver-input,
output -> receiver-output,
error -> receiver-error
sets
of atoms
H = { sender-output, channel-input, channel-output,
receiver-input, channel-error, receiver-error }
I = { sender-to-channel, channel-to-receiver, error-transmission }
communications
sender-output | channel-input = sender-to-channel
channel-output | receiver-input = channel-to-receiver
channel-error | receiver-error = error-transmission
definitions
System = encaps(H, Sender || Channel || Receiver)
System1
= hide(I, System)
end System
In the example above, the exported objects from the module Sender are made
available to System by importing Sender. The imported modules are given as a list of
modules preceded by the imports keyword.
In the example we see that every module name is followed by a list of renamings.
The renamings first specify the name of the object in the module of origin, and then
the name in the current module. If an object is not renamed in the renaming list, it
keeps its old name.
Although renaming is optional, in the example we have to rename the atomic
actions coming from the imported modules, because otherwise we would run into a
name clash, as was explained above.
All objects that are imported into a module, are implicitly imported into its
export section. This means for example, that any module that imports module System
will automatically be able to use the action sender-input from module Sender.

2.4.3 DATA MODULES & PARAMETERIZATION
Until now we have given examples in which we have been abstracting from what
was sent from the sender to the receiver. We have been describing the behaviour of
the system for an abstract message. If we want to model our example on a higher
level of detail, we have to be able to add data parameters to the atomic actions and
processes. In the following sections we will show how data is modelled in PSF, and
how it is incorporated into the processes. Moreover, we will show how a module can
be parameterized with elements from the data domain.
2.4.3.1 Sorts & Functions
Data in PSF is specified using a so-called equational specification. The entities that
are used in such specifications are sorts and functions. In the example below we give
the specification of the booleans.
data module Booleans
begin
exports
begin
sorts
BOOLEAN
functions
t r u e : -> BOOLEAN
false : -> BOOLEAN
end
end Booleans
As opposed to the process modules, a data module is preceded by the keyword: data.
In the example we see that there are two new sections. The sorts section introduces
sorts or data domains, and the functions section declares functions that operate on
elements from these data domains.
The example defines one sort: BOOLEAN, and two functions true and false. The
naming convention follows from the example:
• a sort name consists of upper case characters only,
example: BOOLEAN.
• a function name consists of lower case characters only,
example: true.
A function declaration has the following general appearance:
function-name : input type -> output type
The clause input type is a list of sorts separated by f
#'-symbols and output type is a
sort. The input type specifies the types of the arguments of the function, and the
output specifies the type of the result. The two functions in the example have no
input type and are so-called constant functions.

2.4.3.2 Equations
The behaviour of functions is given by means of equations. In an equation we actually
specify that two terms are equivalent. In the implementation however, an equation
is interpreted as a rule from a term rewriting system, in which the left-hand side is
rewritten to the right-hand side. In the example below we will give a specification
of a module containing some messages.
data module Messages
begin
exports
begin
sorts
MESSAGE
functions
message-error : -> MESSAGE
message-1 : -> MESSAGE
v a l i d : MESSAGE -> BOOLEAN
end
i m p o r t s
Booleans
equations
[01] valid(message-error) = false
[02] valid(message-1) = true
end Messages
We have introduced the sort MESSAGE, that contains four messages. One of these
items represents a message that has been garbled: message-error. To be able to
distinguish between valid and invalid messages we have defined a function valid,
which accepts a message as input and which yields the boolean value true for an
ordinary message, and false for a garbled message. The usage of the function valid
will be illustrated in one of the following sections.
2.4.3.3 Initial Algebra Semantics
In the previous sections we have been assigning semantics to all language constructs
we have introduced using action relations. The data type specifications in PSF are
interpreted using initial algebra semantics. We will only sketch the principles of
the initial algebra of a specification here, for a more detailed explanation we refer
to the literature.
Using the functions introduced in a data type specification it is possible to
construct terms. Two examples of simple terms of type BOOLEAN, from module
Booleans, are true and false.
Module Messages introduces four constant functions of type MESSAGE and a
function valid with MESSAGE as input type and BOOLEAN as output type. Using

valid it is possible to create four new terms of type BOOLEAN: valid(tnessage-
error), valid(message-l), valid(message-2) and valid(message-3). This implies that
there are six different terms of type BOOLEAN in module Messages, the four created
using valid, plus the two already introduced in Booleans.
Not all these terms refer to different entities. One of the equations in Messages
states that valid(message-l) is equal to true. We say that valid(message-l) and true
refer to the same element in the initial algebra of BOOLEAN.
We conclude with an informal method to determine the initial algebra of a sort.
The first step is to generate all possible terms of a given sort. The result is a possibly
infinite set of data terms. In the second step all terms that are equal, according to the
given equations, are grouped together. The result is that the set of terms is divided in
so-called equivalence classes. Each equivalence class is exactly one element of the
initial algebra. One of the terms in the equivalence class is chosen to be the
representant of the given equivalence class. The following figure shows the
abovementioned procedure for the sort BOOLEAN.
a. allpossible terms b. equivalence classes
Figure 2.4 Determining the initial algebra
2.4.3.4 Parameterization of Actions and Processes
The data introduced in the previous section, is integrated into the process domain, by
allowing processes and actions to be parameterized with tuples of data elements. Or
to put it in a different way, processes and actions can have data items as arguments.
To show the use of these data parameters, and not have to introduce too many
new concepts at once, we briefly leave our running example and turn to a specification
of a memory cell that can contain one boolean value. First we will give a graphical
representation of this memory cell.

read(b) t % < [ ivrite(b)
Boolean Memory Cell
Figure 2.5 Boolean Memory Cell
The behaviour of the memory cell is as follows. In the initial state it is only capable
of reading a boolean value performing the action read. After having read a value it
can either input a new value or it can show the value it contains by performing the
action write. The actions will be parameterized by a boolean value.
Keep in mind that this is a specification of a memory cell from the point of
perspective of the cell itself. So read does not mean reading the memory cell but
assigning a value to the memory cell.
process module Boolean-Cell
begin
imports
Booleans
atoms
read, write : BOOLEAN
processes
C e l l
C e l l : BOOLEAN
variables
b : - > BOOLEAN
definitions
Cell = sum(v in BOOLEAN, read(v) . Cell (v))
Cell(b) = write(b) . Cell(b) + Cell
end Boolean-Cell
Arguments of an action or process are written between parentheses, as shown in the
example. The actions read and write are declared to have a boolean argument. There
are two instances of the process Cell, one with a boolean parameter, and one with no
parameters. This is an example of a phenomenon called overloading.
2.4.3.5 Overloading of Identifiers
The name Cell is overloaded, because it can refer to two different processes. PSF
allows overloading of the names of entities as long as the entities can be distin-
guished by the types of their parameters. Entities that cannot contain parameters,
like sorts for instance, cannot be overloaded.

2.4.3.6 Variables
The example introduces one new section: the variables section. In this section we
define the type of the variables that are used in the process definitions. In this
example the process Cell(b) uses its parameter b, a boolean variable, to remember its
current value. Variables cannot be exported and are therefore always local to the
module in which they are defined.
2.4.3.7 Generalized Alternative and Parallel Composition
The final point of interest in the example of the memory cell, is the usage of the
generalized alternative composition: sum(v in BOOLEAN, ... ). The general
appearance of the generalized alternative composition is: sum(x in S, P). The S can be
a sort or a data set. The x is called a placeholder and represents an element from the
data domain of S. The expression sum(x in S, P) is an abbreviation of an alternative
composition containing, for every possible valuation of x, a copy of P in which x is
replaced by the valuation of x:
As an example of this substitution we give the evaluation of the definition of Cell
from the example:
read(true) . Cell(true) + read(false) . Cell(false)
In the same way we define the generalized parallel composition, which is denoted
by merge(x in S, P).
The specification of the memory cell represents a system that can be in any of three
states: Cell, Cell(false) and Cell(true). Below we will give a picture of the states
and the possible transitions between them.
• /r i read(false)
wnte(false) u
^
read(true) . / *
. v
' wnte(true)
Figure 2.6 States and transitions of the memory cell

2.4.3.8 Parameterization of a Module
In the previous sections we have shown how a data element can be a parameter of a
process or an atomic action. In this section we will focus on parameterization on a
different level, namely on the level of modules.
In the approach we took for the specification of the memory cell, we specified a
cell that explicitly deals with booleans. If we would like a specification of a cell
that remembers natural numbers, we would have to give a complete new specifica-
tion. This is of course inconvenient, and therefore PSF incorporates a mechanism that
enables us to give a specification of a process that operates on a certain data type,
although that type itself is not yet fully specified.
The Sender process is a good candidate for parameterization, because in essence it is
capable of sending all kinds of objects. Therefore, we can make the data type a
parameter of the module.
begin
parameters
Sender-Parameter
begin
sorts
DATA
end Sender-Parameter
exports
begin
atoms
input : DATA
output : DATA
processes
Sender
end
definitions
Sender = sum(d in DATA, input(d) . output(d)) . Sender
end Sender
In the example above we can see that parameters are introduced in the parameters
section. The entries in the parameters section are named parameter blocks. The name
of the parameter block in the example is Sender-Parameter. Each block can contain
sorts, functions, sets, atoms and processes. The entities that are introduced in the
parameters section, are treated in the rest of the module as if they were normal
entities.
Not all processes can be parameterized in such a simple way as described above.
The Sender does not depend on the data it is transporting. On the contrary, a process
that would sort items does depend on the data it is sorting, because it has to know the
order of two data items. In such cases, the module that defines the sorting process

still can be parameterized, but the ordering function must also be part of the
parameter.
The following specification of the Channel also shows such a dependency. The
channel can transport a datum correctly or the datum can get garbled. In the latter
case the channel has to output a special error element of type DATA, This error
element is therefore part of the parameter of Channel,
begin
parameters
Channel-Parameter
begin
sorts
DATA
functions
error : -> D
A
T
A
end Channel-Parameter
exports
begin
atoms
input : DATA
output : DATA
processes
Channel
end
processes
Choice : DATA
variables
d : - > DATA
definitions
Channel = sum(d in DATA, input(d) . Choice(d)) . Channel
Choice(d) = (skip . output(d)) + (skip . output(error))
end Channel
2.4.3.9 Conditional Expressions
The specification of the receiver with data parameters, requires a new language
construct, the conditional expression. This construct is used to make choices, based on
the data terms, which influence the behaviour of the process. In the example below
the conditional expression is used to check the validity of the incoming data, and to
respond to it in different ways.
begin
parameters
Receiver-Parameter

begin
sorts
DATA
functions
valid-data : D
A
T
A -> B
O
O
L
E
A
N
end Receiver-Parameter
exports
begin
atoms
input : DATA
output : DATA
processes
Receiver
end
imports
Booleans
processes
Validate : DATA
variables
d : - > DATA
definitions
Receiver = sum(d in D
A
T
A
, input(d) . Validate(d))
Validate(d) = [valid-data(d) = true] -> output(d) . Receiver +
[valid-data(d) = false] -> Receiver
end Receiver
Each process expression can be prefixed by a conditional expression [s = t] —
> P. The
expression [s = t] is also called a guard. If s and t are equal, according to the initial
algebra, we say that the guard is true, if they are not equal the guard is false. If the
guard of [s = t] -> P is true, the conditional expression evaluates to process P. If the
guard is false, the conditional expression evaluates to deadlock. The semantics is
given below.
X-^X'A S = t X - > V A S = t
([s = t] -> x ) U x' ( [s = t] - > x ) £> V
Table 2.10 Action relations for the conditional expression
2.4.3.10 Binding of Parameters
After having carried out such a conscientious preparation, we are finally able to
create a completed specification of the interaction between the sender, the channel
and the receiver. We achieve our final specification of the example by binding all
the parameters, the formal entities, in the specification to actual entities. In the
following example the sort DATA, which was the parameter representing the type

of the objects that are handled by the protocol, is bound to the sort MESSAGE of the
module Messages.
begin
exports
begin
atoms
sender-to-channel : M
E
S
S
A
G
E
channel-to-receiver : M
E
S
S
A
G
E
processes
System, System1
end
imports
Sender {
Sender-Parameter bound by [
DATA -> MESSAGE
] t o Messages
renamed by [
input -> sender-input,
output -> sender-output
Channel {
Channel-Parameter bound by [
DATA -> MESSAGE,
error -> message-error
] to Messages
renamed by [
input -> channel-input,
output -> channel-output
Receiver {
Receiver-Parameter bound by [
DATA -> MESSAGE,
valid-data -> valid
] to Messages
renamed by [
input -> receiver-input,
output -> receiver-output
sets
of atoms
H = { sender-output(m), channel-input(m), channel-output(m),
receiver-input(m) | m in MESSAGE }
I = { sender-to-channel(m), channel-to-receiver(m) |
m in MESSAGE }
communications
sender-output(m) | channel-input(m) = sender-to-channel (m)
for m in M
E
S
S
A
G
E

channel-output(m) | receiver-input(m) = channel-to-receiver(m)
for m in M
E
S
S
A
G
E
definitions
System = encaps(H, Sender | | Channel | | Receiver)
System1
= hide(I, System)
end System
In the example we can see that the binding of a parameter is achieved by importing
a module A, that contains a parameter and binding it to a module B. The formal
objects from module A are bound to the actual objects of module B by means of a
syntactical construct that resembles the renaming construct. Any parameter blocks of
an imported module that are not bound, are inherited by the importing module. This
means that the unbound parameter blocks are added to the set of parameter blocks of
the latter module.
Furthermore, this example shows that the definition of a set and the definition
of a communication can be parameterized with a variable. Below we give an
example of the syntax:
• set definition: S = { a(x) I xinT]
• communication definition: a(x) I b(x) = c(x) for x in T
We should make one final remark about this specification. In the example we bind
message-error, an element from MESSAGE, to the error parameter of Channel. This
means that if the message gets garbled within the channel, Channel will use
message-error to indicate this fact. However, this is not the only situation in which
Receiver can receive a message-error. Because message-error is an element of
MESSAGE, it can be sent directly by the sender as well.
2.5 THE PSF STANDARD LIBRARY
In the previous sections we have been referring to the PSF Standard Library. This
library contains some frequently used data types. Using this library has two great
advantages. The first being the fact that a specification can be built upon already
existing reusable modules, in other words a specification does not have to be given
from scratch. The other advantage is a certain uniformity in the specifications given,
because they are based on the same set of basic modules.
In this section we will give a short description of the data types in this library
that are used throughout this book. Each entry will only show the exported sorts and
functions, which is also called the export signature. After the signature we will list
the initial algebra of the data type being defined, one example term from this
module and its normal form. The complete listings of the relevant part of the PSF
Standard Library can be found in Appendix A.

2.5.1 BOOLEANS
One of the simpler data types is the boolean. The standard library defines the sort
BOOLEAN.
sorts
BOOLEAN
functions
true
false
eq
not
and
or
xor
BOOLEAN
BOOLEAN
BOOLEAN
BOOLEAN
BOOLEAN
#
#
#
#
Initial Algebra: false,
->
->
BOOLEAN ->
->
BOOLEAN ->
BOOLEAN ->
BOOLEAN ->
true.
Example Term: and (true, or (false
2.5.2 NATURALS
BOOLEAN
BOOLEAN
BOOLEAN
BOOLEAN
BOOLEAN
BOOLEAN
BOOLEAN
,true))
— equality
— exclusive or
true
The simplest way to represent the natural numbers is by so-called successor naturals.
There is one constant function zero, and all other natural numbers are constructed by
applying the successor function s one or more times to zero.
There are three infix operators in this signature: _+_ , _-_ and _*_. They
represent addition, subtraction and multiplication. The two underscores '__' indicate
the place of their arguments.
sorts
NATURAL
functions
zero
s
eq
gte
gt
lte
It
inc
dec
mod
div
NATURAL
NATURAL
NATURAL
NATURAL
NATURAL
NATURAL
NATURAL
NATURAL
NATURAL
NATURAL
NATURAL
NATURAL
NATURAL
# NATURAL
# NATURAL
# NATURAL
# NATURAL
# NATURAL
# NATURAL
# NATURAL
# NATURAL
# NATURAL
# NATURAL
-> NATURAL
-> NATURAL
-> BOOLEAN
-> BOOLEAN
-> BOOLEAN
-> BOOLEAN
-> BOOLEAN
-> NATURAL
-> NATURAL
-> NATURAL
-> NATURAL
-> NATURAL
-> NATURAL
-> NATURAL
Initial Algebra:
Example Term:
zero, s(zero), s(s(zero)), s (s (s (zero) )) , ...
s(s(zero)) + s(s(s(zero))) -> s(s(s(s(s(zero)))))
2.5.3 BITS
Computers use bits as the basic entity to represent information. The standard library
defines two bits: bitO, bitl. Because of the fact that constants cannot be overloaded

The PSF Standard Library 35
and that the identifier names 0 and 1 are used in the library to represent the digits,
we have to introduce a different name for the bits.
sorts
BIT
functions
bitO :
bitl :
invert :
unary :
eq :
-
-
BIT
BIT
BIT # BIT -
> BIT
> BIT
> BIT
> NATURAL
> BOOLEAN
Initial Algebra: bito, biti.
Example Terms: invert (bito) —
> biti
unary(bitl) —
> s(zero)
2.5.4 QUEUES
Queues are a well-known data structure. They are used to store data in a certain
order. The standard library defines functions to put an item into a queue, to retrieve
the front element from the queue, to delete the front element from the queue and to
determine the number of items in a queue.
All functions are defined relative to the parameters of the module: Q-ELEMENT
and default-element.
parameters
sorts
Q-ELEMENT
functions
default-q-element : -> Q-ELEMENT
sorts
QUEUE
functions
empty-queue
enqueue
serve
dequeue
length
•
-> QUEUE
Q-ELEMENT # QUEUE -> QUEUE
QUEUE -> Q-ELEMENT
QUEUE -> QUEUE
QUEUE -> NATURAL
Q-ELEMENT # QUEUE -> QUEUE
Initial Algebra: empty-queue, dl * empty-queue, d2 * dl * empty-queue, ...
Example Terms: dequeue (d2 * dl * empty-queue) —
> d2 * empty-queue
serve(d2 * dl * empty-queue) —
> dl
2.5.5 TABLES
Tables are a way to represent dynamic arrays in PSF. In fact the table data structure
is moreflexible,because the index can be of any type. When an item is stored into a
table it is stored together with its key. The item itself can later be retrieved by
supplying the key to the appropriate function. The standard library defines

functions to put an item and its key into a table, to retrieve an item from a table, to
delete an item from a table, to test whether or not a certain key is an element of a
table, and to determine the number of items in a table.
All functions are defined relative to the parameters of the module, the sorts KEY
and ITEM and the functions eq and default-item.
parameters
sort 8
KEY
ITEM
functions
eq : KEY # KEY - > BOOLEAN
default-item : -> ITEM
sort 8
TABLE
functions
empty-table
insert
retrieve
delete
in-table
length
entry
-> TABLE
TABLE # ITEM # KEY -> TABLE
TABLE # KEY -> ITEM
TABLE # KEY -> TABLE
TABLE # KEY -> BOOLEAN
TABLE -> NATURAL
KEY # ITEM -> ENTRY
ENTRY # TABLE -> TABLE
Initial Algebra: empty-table, entry (kl,±l) * empty-table,
entry (k2, ±2) * entry (kl,il) * empty-table, .
.
.
Example Term: delete (entry (k2, ±2) * entry {kl, il) * empty-table, kl)
—
> entry{k2,±2) * empty-table
2.5.6 DATA
The protocol specifications in this book make no assumptions about the kind of data
they are transporting. By importing the module Data from the PSF Standard Library
any module inherits a sort parameter DATA and a constant function default-data.
This way modules can define parameters in a uniform way.
parameters
sorts
DATA
functions
default-data : -> D
A
T
A
2.6 THE PSF-TOOLKIT
The PSF-Toolkit consists of a number of programs that form a programming
environment for the language PSF. The graphical representation of the system is
given in Figure 2.7.
Situated at the centre of the PSF-Toolkit is the Tool Interface Language (TIL)
through which all tools can communicate. This means that the tools in the PSF-

The PSF-Toolkit 37
Toolkit do not directly operate on PSF but on a language on a lower level, which is
represented by TIL. This language can be seen as an assembler language for an
abstract process algebra machine. Because TIL is optimized for use by computers, its
readability for humans is of secondary importance.
From the picture we see that the PSF specification at the top is translated into
TIL by the PSF compiler. At the bottom of the picture we see the different tools. At
present a simulator, a term rewriter, a proof assistant, an equivalence tester, an
initial algebra generator and a transition system generator are implemented.
The approach of implementing an environment, by using clearly defined
intermediate languages, serves several purposes. The main reason is that it results in
a layered design, in which human users can inspect specifications on a high level
through PSF and in which the tools have access to the specifications through a low
level representation tailored to their needs. This means in particular that the
process of parsing and type checking of PSF is of no concern to the tools which will use
a very simple parser to read the intermediate language.
The second reason for using TIL and its derivatives is that software can be
developed in parallel and independently, because there is an exact definition of the
intermediate language. In the case of the PSF-Toolkit the construction of the
simulator did not have to wait for the implementation of the parser and normalizer
to be completed.
PSF
compiler
simulator
term rewriter
TIL
transition system
generator
initial algebra
generator
proof assistant
Figure 2.7 The PSF-Toolkit
The final reason for using TIL is that the PSF-Toolkit can be easily adapted for new
versions of PSF, or formalisms with comparable functionality. Writing a parser that
translates a formalism into M-TIL is sufficient to make all tools in the PSF-Toolkit

Exploring the Variety of Random
Documents with Different Content

Project Gutenberg™ eBooks are often created from several printed
editions, all of which are confirmed as not protected by copyright in
the U.S. unless a copyright notice is included. Thus, we do not
necessarily keep eBooks in compliance with any particular paper
edition.
Most people start at our website which has the main PG search
facility: www.gutenberg.org.
This website includes information about Project Gutenberg™,
including how to make donations to the Project Gutenberg Literary
Archive Foundation, how to help produce our new eBooks, and how
to subscribe to our email newsletter to hear about new eBooks.

Welcome to our website – the perfect destination for book lovers and
knowledge seekers. We believe that every book holds a new world,
offering opportunities for learning, discovery, and personal growth.
That’s why we are dedicated to bringing you a diverse collection of
books, ranging from classic literature and specialized publications to
self-development guides and children's books.
More than just a book-buying platform, we strive to be a bridge
connecting you with timeless cultural and intellectual values. With an
elegant, user-friendly interface and a smart search system, you can
quickly find the books that best suit your interests. Additionally,
our special promotions and home delivery services help you save time
and fully enjoy the joy of reading.
Join us on a journey of knowledge exploration, passion nurturing, and
personal growth every day!
ebookbell.com

Algebraic Specification Of Communication Protocols S Mauw G J Veltink Editors

More Related Content

Similar to Algebraic Specification Of Communication Protocols S Mauw G J Veltink Editors (20)

Recently uploaded (20)

Algebraic Specification Of Communication Protocols S Mauw G J Veltink Editors