Content uploaded by Stefan Fischer
Author content
All content in this area was uploaded by Stefan Fischer on Sep 04, 2014
Content may be subject to copyright.
A New Approach for Distributing Estelle Specications
Eric Lallet, Stefan Fischer
y
and Jean-Francois Verdier
Institut National des Telecommunications
9, rue Charles Fourier, 91011 Evry Cedex, France
Phone: +33 1 60 76 44 71 Fax: +33 1 60 78 39 27
Email: epsi@hugo.int-evry.fr, stes@pi4.informatik.uni-mannheim.de
October 23, 1995
Abstract
Deriving distributed prototypes and implementations from formal specications is one
of the most important aspects of an implementation-oriented language like Estelle. Some
tools already exist allowing the generation of distributed programs to be executed on a
computer network. All these tools follow the same approach: co de in a programming
language is directly generated from the specication, compiled and linked with some
communication libraries. In this paper, we prop ose a dierent approach consisting of
rst splitting up the specication into as many specications as there were subsystems
in the initial specication. The programming language code will then be generated from
all these generated specications. We show the advantages of this approach. The new
method is being integrated into the Estelle DevelopmentToolset. Runtime measurements
and comparisons with another Estelle code generator, Pet/Dingo, show its usefulness.
Keywords:
Estelle, Tools, Distribution Method, Implementation
1 Introduction
The use of formal description techniques in system development is becoming increasingly pop-
ular, especially for distributed systems and proto col engineering. One of the reasons for this
popularity is that, in the meantime, many tools have become available which supp ort formal
specications throughout the whole lifecycle of a system. At the beginning, basic system re-
quirements may be formulated and automatically checked for consistency. Later, prototypes
This work was partially supported by CNET #93PE7404.
y
On leave from the University of Mannheim, Praktische Informatik IV, D-68131 Mannheim, Germany.
1
may be automatically derived to allow for interactive testing and debugging. At the end, com-
plete implementations with high p erformance characteristics may be generated, minimizing
the task of the implementor.
The formal language Estelle [ISO89, BD87] is usually considered to be an implementation-
oriented language. This is due to the fact that the Pascal language is used to dene data
types and to describe data processing. Consequently, Estelle, with respect to the other known
languages (SDL, LOTOS), is especially well adapted for use in the later stages of the system
development pro cess, especially for prototype and implementation development.
In the early years of protocol development with Estelle, work concentrated on the automatic
development of simple prototypes to execute protocol sp ecications on one machine [VLC88,
SSC89, FHSW89, RC89, SB90]. Recent developments oer a powerful debugging tool, Edb
[Bud92], distributed prototyping in environments very close to reality [KG93, SS93], parallel
prototyping [JJ89] and high-speed implementations on multiprocessor platforms [FH94, HK94].
Distributed implementation of Estelle specications is one of the most important issues of
automatic derivation of implementations. Implementations of a distributed system running
on one process within one computer can be considered as nothing other than a prototype for
testing.
There exists a kind of classic way to derive distributed implementations: the programming
language code for the whole distributed system is generated on one computer. Then, parts of
this code are distributed and lo cally compiled, linked and executed. Some disadvantages of
this approach will be discussed below.
We propose a new metho d which is { at least at rst glance { more complex, but which
provides solutions without the mentioned disadvantages. The heart of this new metho d is not
to distribute programming language code but parts of the initial Estelle specication.
The paper is organized as follows: In Section 2, we briey describe the classic distributed
implementation method pointing out its disadvantages and introducing, as a consequence,
our new approach. The architecture is described and compared to other p ossible solutions.
Finally, some correctness issues are discussed. Section 3 describes some implementation details
concerning the generation of the new specications and the communication structure. In
Section 4, we present performance numbers and runtime measurements to prove the usefulness
of our method. Section 5 concludes the paper.
2 Distributing Estelle Sp ecications
To provide a better understanding of our new approach, we will rst outline the classic method
of implementing specications in a distributed way. As an example, we shall take a closer look
at the Pet/Dingo system [SS93].
Starting with an Estelle specication, Pet/Dingo generates C++ source code and some utilities,
e.g. a Makele. The user may use special comments in the specication to indicate the name of
2
the host on which a given subtree of modules has to run. These comments will be conserved in
the generated C++ code. In general, it is possible to distribute subsystems (subtrees ro oted in a
module attributed
systemprocess
or
systemactivity
), but also single mo dules. Afterwards,
the user has to manually distribute the sources (in the case of separated le systems) to the
dierent host computers and start compilation and linking. To initialize the whole system, the
code implementing the root module has to be started at one site. This program automatically
starts all other processes in the system. It also sets up the connections between pro cesses
according to the
connect
statements in the initial transition. In Pet/Dingo, these connections
may be realized by TCP so ckets or Remote Procedures. To allow for a synchronized start
of the whole system after initialization, the root module sends a signal to start the Estelle
execution to all distributed parts as soon as it has received a ready signal from all parts which
have processed their initialization phase and once all connections have been set up.
Now let us consider a general case. The global aim of the distribution pro cess will always
resemble the following: create on each participating node of the system a part of the speci-
cation's implementation and execute it properly. However, the way to achieve this goal may
be dierent from the one described above. Acharacteristic of the classic way described ab ove
is that the pro cessing at the Estelle specication level is left behind very early. Once the
specication process is nished, the specication will be immediately translated into another
language. This has, in our eyes, the following disadvantages:
During the co de generation pro cess, only
one
Estelle compiler can be used. That means
that at every site the same type of programming language code is available, e.g. C or
C++. This is usually not a problem, as on most systems compilers exist for all common
programming languages. However, some code types may be not suitable for certain
machines. Some experiences show that it is for example quite dicult to port Pet/Dingo-
generated C++ code to transputers, due to the very huge executables produced from it.
Thus, it would be desirable to be able to use dierent compilers at each site.
An important issue of system specication is hardware and software
co-design
. In the
earlier stages of system development, when general b ehaviour is specied, the designer is
not concerned by the possibility that some parts mayberealized in hardware and some
others in software. Estelle is a specication language and does not determine the type
of implementation. The monolytic \classic" approach makes it dicult, in the further
step of design, to implement some parts in hardware, as translation from C or C++ to
hardware seems dicult. The translation from Estelle to a hardware description language
seems to be more feasible. Recent exp eriments [WB94] in translation of Estelle to VHDL
conrm it.
For these reasons, it seems b etter to remain within the connes of formal specications as
long as possible. Thus, instead of generating programming language code at one site and
afterwards distributing it over the network, our new metho d proposes splitting up the initial
Estelle specication into several parts, distributing these parts over the network and generating
the code separately at each of the sites. The main dierences between the classical and the
proposed approach are visualized in Figure 1.
3
Formal Specification
Generation
Code
C-Code
Compiling Linking
time
Compiling Compiling
Linking Linking
Specification
Generation
Application Range
Application Range
C Code Distribution
Estelle Distribution
(a) The classic approach (b) The new approach
Part 1 Part 2 Part 3
Formal Specification
Code
Generation Code
Generation Code
Generation
Figure 1: Comparison of the classical (a) and the prop osed (b) approaches
In developing the concrete architecture of the new method, certain requirements have to be
fullled:
1. We need, on each node, a
compilable
Estelle specication. This means that the splitting
is more a constructive process rather than a simple extraction of a given subsystem
denition; some denitions of data types, channels etc. dened globally elsewhere should
be included in the generated parts.
2. Each specication part must oer an
additional interface
to provide means of com-
munication between these parts. To ensure better performance, the trac through these
interfaces should be minimized.
3. The derived implementations have to be
executable
within the existing environments
(compilers/runtime systems). This means that within the generated sp ecication parts,
any handling of the additional interface has to be specied explicitly within transitions. It
cannot be done implicitly. An example of implicit handling would be a dierent treatment
of interaction points (IPs) marked with a special comment in the initial specication.
Specially designed compilers, recognizing this type of comment, could react on that by
generating dierent co de for these IPs, providing e.g. a TCP socket interface instead of
the usual implementation. This last requirement is included since it enlarges the use of
this method.
4
To provide a clear understanding of the new metho d's architecture, we will, in the following,
refer to the sample specication given in the appendix (page 1). The specication describes a
system consisting of one server and three client
systemactivity
instances. Please note that
the client mo dule has two dierent b o dies associated with it. Thus, when initializing, the
rst and third client instances have the behavior described by the body
client b1
and the
second client instance b ehaves like body
client b2
. Bo dy
client b1
sends requests to the
server and waits for the responses.
Client b2
does { only in this example { nothing. The
server pro cesses the clients' requests
1
. The new system consists of one server and two client
specications, which may be found on pages 2 (rst client body) and 3 (server bo dy) of the
appendix, resp ectively. The second client bo dy specication is left out for space considerations
(it is very similar to the rst one). Each reference to the example is expressed by \(page,line)",
referring to Estelle code line \line" on appendix page \page".
The following design decisions have been made:
The rst one consisted in reducing the scope of the split operation to only
system mod-
ule instances
which will then be distributed. Splitting the initial Estelle specication into
subsystems (
systemactivity
or
systemprocess
modules) seems to be more \natural" than
to split it into elementary (
activity
or
process
) modules as it is provided in the Pet/Dingo
approach. The subsystems are, by denition, completely indep endent of each other; their struc-
ture and intercommunication is static, i.e. it does not change during system lifetime. These
features reduce considerably the complexity of the split op eration and assure the minimum
interprocess ow exchange between the distributed parts, thus increasing the performance of
such distributed implementations. It should b e noted that splitting the initial specication in
this way does not require any additional considerations to assure the correct behavior of the
distributed implementation. It is guaranteed by construction since asynchronous parallelism
is naturally realized by such distributed implementations.
The second decision had to be made with respect to the number of specicationss to be
generated. There are three p ossibilities to select this number from: the number of system
module headers, the number of system module b odies or the number of module variables.
It was decided [VL94] to select the
number of system b o dies
. For the reasons of this
decision, let's look at the client part of the example. We have one module header (p.1,l.19),
two mo dule b o dies ((p.1,l.24) and (p.1,l.51)) and three mo dule variables (p.1,l.85). Let's rst
assume that only one specication part for the client is produced, according to the number of
module headers. Then, both b o dies have to be kept in the same sp ecication, as they belong
to the same header. A typical situation, however, is, that a designer provides two dierent
implementations of a system, e.g. one in hardware and one in software, by oering two bodies
for one module. Thus, the splitting we did here does not solve the problem, because the relevant
parts were not split. On the other hand, if we produce three specications, one for each client
module variable, we do too much. The specications for
client var[1]
and
client var[3]
will be exactly the same and need not be distinguished. Selecting the number of bodies gives
us exactly the right splitting granularity.
The main design problem was howtoprovide the necessary external communication interface
1
For the sake of brevity, the specication is reduced to its basic, most imp ortant parts.
5
to deal with the communication between the now distributed systems, thereby not violating
the three requirements ab ove.
It was decided [VL94] to introduce, for the external communication,
an additional module
.
The new module is in fact the
root module
of the new specication, and the system module
becomes embedded into it as its child; its header and body remain unchanged. The attribute of
the root module is the same as that of the system ((p.2,l.1) and (p.3.,l.1)). The attribute of the
child module has to be changed: each
systemactivity
becomes an
activity
((p.2,l.32) and
(p.3,l.32)), each
systemprocess
becomes a
process
. The main feature of the new sp ecication
module is the so-called
switchboard
. This switchboard is the representation of the additional
interface described in requirement (2). It consists of a set of internal IPs ((p.2,l.74) and
(p.3,l.65)), a set of transitions and a group of primitive functions and procedures.
Each IP on the switchboard has its counterpart in one of the external IPs in the former
system module. In its initial transition, the root mo dule initializes one module instance of the
former system mo dule ((p.2,l.88) and (p.3.,l.82)) and connects all its switchboard IPs to the
corresponding external IPs of the child module ((p.2,l.89) and (p.3,l.83/84)). Therefore, the
switchboard IPs must have the opp osite channel role of the child module IP.
To handle switchboard IP input and output, the root module has a set of transitions. In fact,
for each IP of the switchboard, there is one transition for each message which may arrive and
one for each message whichmaybesent on the IP. This information may be derived from the
channel description. In general, transitions handling outgoing interactions have a
when
clause
and in their statement part a procedure call to the external interface ((p.2,l.102-107) and
(p.3,l.98-112)). Incoming interactions are handled by transitions having a
provided
clause for
checking the external interface for input and a procedure call in the transition statement block
for reading the message and putting it out to the corresponding switchboard IP ((p.2,l.111-116)
and (p.3,l.116-122)).
To realize the co op eration between the new specications, each switchboard includes several
primitive functions and procedures ((p.2,l.11-16) and (p3.,l.11-16)). These functions provide
an abstract interface to the actual communication implementation. Possible realizations of
these functions may address a TCP socket or an RPC interface or even a hardware device
driver. The functions' implementation thus has to be provided in a library to be linked with
the code generated from the specication.
To conclude, the general scheme of the interface looks like this: every time the former system
module sends a message to its external interface, the new module transfers this message to the
external interface of the specication. Whenever a message arrives at the external interface of
the specication, it is just forwarded to the former system mo dule.
The presence of transitions in the ro ot module is also the reason why this mo dule has to be
attributed. Recall that unattributed modules cannot be active, i.e., they are not allowed to
have transitions. As a result, the attribute of the former system mo dule has to be changed,
too, as no system mo dule maybedened inside another system module.
The result of the whole distribution process can be seen in Figure 2 for our example. The initial
specication consisting of the root module and two system modules/three bodies is split into
6
(b) Resulting Specifications
switchboard
specification ncs;
client_type
system-
activity
server_type
system-
acivity
client_b1
body
client_b2
server_b
body
systemactivity systemactivity systemactivity
client..._b2 server..._b
client.._b1
activity
client_type client_type
activity
server_type
activity
body
client_b1
body
client_b2
body
server_b
(a) Initial Specification
Figure 2: Derivation of the new Sp ecications
three new specications. Each specication ro ot module has one child module representing the
former system module with its associated bo dy and the switchboard IPs connected to the IPs
of their child. During runtime, two processes implementing the rst, one process implementing
the second and one process implementing the third specication will b e started.
At rst glance, the method described above seems to be complex. But let us consider two
solutions, which could have been deemed simpler. Both are based on distribution only of the
subsystems, but without the addition of a new module level. The subsystems become the ro ot
modules of the new specications. The problem which arises immediately is that the systems'
interface, their external IPs, cannot remain in the new specication, as root modules cannot
have external IPs. Thus, away has to be found to cooperate with the other specications.
In the rst possible solution, the system's external IPs are translated into internal IPs. The
advantage here is that the b ody description can remain unchanged, as all references to IPs are
maintained. However, this solution violates requirement (3). The new internal IPs have to be
treated dierently from other IPs. Output on them cannot be handled as an Estelle interaction
and forwarded to the other end of the channel; instead, it has to be mapp ed onto the external
communication interface. Input, on the other hand, will never arrive, as there is no partner IP
where anyone could output anything. Existing Estelle compilers do not know that they have
to handle these IPs dierently. They will not be able to produce running implementations.
The second possible solution calls for translation of all references to the external IPs into
primitive function and procedure calls. Transitions of the system modules would then look like
those of the specication module's switchboard in our new method, with
provided
instead
of
when
clauses and primitive procedure calls instead of
output
statements. This solution
does not violate any of the requirements. Existing compilers will be able to produce working
7
implementations. But the module in which we are interested (the system module) is greatly
altered, rendering the module description illegible for humans and inaccessible to tools, as the
natural Estelle interface description (i.e. IPs) no longer exists.
What can be said about the correctness of the new specications and thus of the method?
The criteria for the correctness of the new method is whether the derived implementation is a
possible implementation of the
original
specication. This cannot be proved formally, but is
induced
by construction
. There are two critical steps in the separation pro cess which may
aect the behaviour of the specication: the separation into several new specications and the
addition of a new module together with the change in attributes of the system mo dules.
The separation of the original specication will preserve the correctness. The reason for this
is that systems are indep endent from each other. They are all running their own Estelle cycle,
and no timing relations or synchronization requirements exist between them. This could be
more dicult if the splitting were possible at the level of
process/activity
modules. The
necessary synchronization between these modules and their parent module might not, in that
case, be expressed prop erly.
For the second problem, we have to check whether the new specication still behaves like
the original system module. The new ro ot module is in fact an explicit description of the
communication handling to other systems. In the original specication, this part is handled
implicitly by Estelle semantics. Thus, the b ehaviour of the child module (former system) will
not be inuenced. In addition, it is the only child and thus will always be selected for execution,
when the its parent module (the root) has no transition to re.
Another problem which may result from the deeper mo dule hierarchy is that of runtime per-
formance of the whole system. We will address this issue in Section 4.
3 Implementation Aspects
We will address here two important implementation issues. The rst one describ es the genera-
tion process of the new specications and its embedding into the Estelle DevelopmentToolset
(EDT) [Bud92], while the second deals with a concrete implementation of a distributed system
using TCP so ckets.
So far, the EDT system did not provide a possibility of distributed implementations. To
integrate it, basically two things had to be done:
1. A tool had to be built to split the initial specication into a set of new sp ecications.
2. The implementation of the external interface functions had to b e provided.
Ad 1.
The separator tool operates on the intermediate form representation of the original
specication. This guarantees the static correctness of the initial specication. The tool
produces one specication le for every system module body. Each le contains the root
8
Inter-
mediate
Form
arbiter
Spec.
Estelle
original
New
Spec.
A
New
Spec.
B
New
Spec.
C
Code
Code
C
Code
C
C++
Code
Code
Generator (1)
Generator (3)
Code
Generator (2)
Tool
Separator
Translator
Estelle
Figure 3: C Code Generation in the new implementation method
module, the module header and b o dy of the former system module, its
modvar
declaration, an
initialization transition and the transitions to handle the switchboard. In addition, a program
is generated (the so-called
arbiter
) whose task is to start the whole system. This program needs
information about on which host to start which module instance and which connections to set
up. The sp ecier has to provide this information by using so-called
qualiedcomments
. These
comments are inserted into the intermediate form by the Estelle translator and are meaningful
to the tool. They have to contain the hostname of the network node (p.1,l.90-94).
2
Ad 2:
In the rst version, a standard TCP socket interface is oered to the user. The functions
concerned with opening of the external interface set up the required TCP connections, reading
and writing are done by reading from and writing on the TCP connections, and closing of the
interface is done by shutting down the TCP connections
3
.
The whole process of C co de production for distributed systems in EDT is visualized in Fig. 3.
The partial specications may be translated into C-code using the Estelle code generator from
EDT. Afterwards, all executables have to be built using a C compiler/linker.
The startup phase of the whole distributed system based on the sockets library works as follows:
2
Please note that, by describing the distribution in this way,we do not violate requirement (3). Still, any
existing Estelle compiler may be used for the implementation at each site.
3
In fact, the close routine will never be used, as it is imp ossible to terminate system modules or close
connections between them.
9
TCP
TCP TCP
TCP
TCP
TCP
TCP TCP
TCP
TCP TCP
TCP
TCP
TCP
machine baker
starter program
machine simone
machine basiemachine duke
client_var[2]
root
client_var[3]
root
client_var[1]
root
server_var
root
Figure 4: Situation during runtime
at each site where there should run a module instance, a
daemon
4
has to be started that waits
for requests to start new module instances. Afterwards, the generated arbiter is run on one
machine. Following the
init
statements and the corresponding qualied comments in the
initial transition of the original sp ecication's root module, requests to start the addressed
module are sent to the corresponding daemon. The program implementing the module is
started by the daemon and immediately connects to the starter program. From there, it gets
necessary information about initialization parameters and connections to be set up. As soon
as it has the information, it tries to establish its connections to the other systems, waiting also
for connection requests from there. When all connections are set up, the module signals to
the starter program that it is ready for execution. The starter program waits for the signals
from all started systems and then sends a run signal to all of them. Now, the normal Estelle
execution cycle of each system starts. Figure 4 shows the situation after system startup. All
connections between the systems are established. The connections to the starter program are
already closed.
The new specication's root mo dule checks the so ckets, resp. the switchboard for incoming
and outgoing messages. As these transitions are checked in the parent module, they always
have priority over the \real" transitions implemented in the former system module. To avoid
starvation of the latter, the function checking the sockets for an input are implemented to
do these checks only sporadically. In a certain percentage of checks, the function returns
immediately with the result \no input", avoiding the execution of the transition. Instead, the
4
This daemon is independent from the Estelle specication and is provided within EDT.
10
right to execute will be passed to the child module.
4 Quantitative Results
As our new method is aimed at distributed system
implementation
,we are mainly interested
in the performance of the resulting implementations. There are two important points which
inuence, from our point of view, the acceptance by users:
1. The resources needed for code generation, compiling and linking a whole distributed
system. These are mainly time and hard disk space.
2. The speed of the resulting implementation. The speed is inuenced bytwo factors of the
new method:
the additional layer in the module hierarchy introduced by the added sp ecication
module
the qualityoftheinterprocess communication (TCP sockets in our example)
To have a means of comparison, we are also interested in the corresponding numbers of the
Pet/Dingo system.
The measurement environment consisted of several Sun Sparc 5 workstations running Solaris
2.3. The compiler used was gcc 2.5.7.
For the measurements concerning the resources, we used a very huge Estelle sp ecication to get
representative results for large systems. Our example is an ISO-FTAM specication with a size
of 543 KBytes of Estelle code. The results concerning time for code generation, compiling and
linking, as well as code sizes for intermediate forms, programming language code (C resp. C++)
and executables maybefound in Table 1.
Compared to the single-process version, the distributed version contains six programs. The
size of the EDT executables is reasonable, while Pet/Dingo, due to the use of C++
5
, always
produces very large programs.
The time for C-code generation in EDT has doubled for distributed implementation, and it
is still acceptable. The measurement includes pro duction of the intermediate form of the
single sp ecication, production of the new specications in Estelle, again production of all
intermediate forms and, nally, C-co de generation. Pet/Dingo performs b etter in this area, as
the C++ code is generated directly from the intermediate form of the original specication.
Compile and link times for the EDT-generated code are very good for such a big system. In
contrast, the C++ compiler takes about seven times as long for the Pet/Dingo code. We
5
Wehave no results for the Pet/Dingo single-process version, as for that, the specication would havetobe
changed. Pet/Dingo always produces distributed versions for specications with more than one system mo dule.
11
FTAM Estelle Specication, 543 KBytes EDT Pet/Dingo
Code Size
Intermediate Form 2005 KBytes 2170 KBytes
Produced C/C++ Code 1264 KBytes 1990 KBytes
Executable (1 process) 544 KBytes {
Executables (dist.) 1520 KBytes 9775 KBytes
Compile Times for FTAM
Code Generation (1 pro cess) 1:06 min. {
Code Generation (distributed) 2:19 min. 1:36 min.
Compiling & Linking (1 process) 1:33 min. {
Compiling & Linking (distributed) 2:37 min. 16:30 min.
Table 1: Characteristic Numbers for EDT and Pet/Dingo
conclude that a user familiar with the single process EDT will not realize big dierences
producing distributed systems. In this area, distributed EDT is preferable to Pet/Dingo.
For our measurements concerning implementation performance, we used our simpler sample
specication consisting of a server and three clients. The bodies of client and server have been
extended compared to the specication in the app endix, but the principles of operation are the
same. In the implementation, two clients were executed at the same site (but in two processes),
one clientata second and the server at a third site.
Further experiments consisted in studying the inuence of the additional layer in the module
hierarchy. To nd out about this, we examined two typical Estelle operations on the system
module layer, a pair consisting of an
init
and a
release
transition and a transition containing
an
output
statement. To exclude the inuence of interprocess communication, we did not
connect the server to its clients, avoiding communication between them. Thus, output was
performed locally in the former system module, and in the
init/release
case, we added
a further module description in the former system which is initialized/released by its father
module. The performance gures for these measurements may be found in Table 2.
Performance Indicator Compiler Single Process Distributed System
EDT 189
s 247
s
Pair of Init/Release
Pet/Dingo 2420
s 2150
s
EDT 120
s 190
s
Output Transition
Pet/Dingo 860
s 760
s
Table 2: Performance Numbers of single pro cess and distributed programs
The additional inuence of the new root module is due to the checking of transition rability.
As it is the father module, its transitions always have priority over the child module (the
12
50
100
150
200
250
0 200 400 600 800 1000
Runtime [s]
Message Size [Byte]
Runtime Measurements for Several Implementations
EDT distributed processes
Pet/Dingo ditributed processes
EDT single process
Pet/Dingo single process
Figure 5: Runtime Comparison between Dierent Implementations
former system module). However, no root module transition is red, as their task is reading
and writing the external interface and no connections are established.
Both actions (
init/release
and
output
) are very fast in the single-process version
6
. They
are, in the distributed version, 50 to 70
s slower, which is still very fast, both absolutely
and compared to Pet/Dingo performance. With a duration of about 200
s of an Estelle
cycle containing an
output
statement, 5000 of these cycles can be executed p er second, which
means that given a message size of 1000 Byte (as in this example), an Estelle throughput of
40 MBit/s can be attained. Thus, the throughput of the whole system will be dominated by
far by interprocess communication and not by an additional module layer.
The problem of Pet/Dingo, especially in the
init/release
case, is the use of C++. For every
module, a very large data structure has to be allo cated due to the deep mo dule hierarchy and
a lot of member functions in each class. In addition, several constructors and destructors are
called. The representation of modules in EDT, by contrast, is very small and ecient. One
of the results of this is that pure processing, without interprocess communication, is faster in
the Pet/Dingo distributed than in the single-process version, where several modules have to
be managed in one process (see lines 2 and 4 in Table 2).
Figure 5 shows the results for the the interprocess communication measurements. We measured
2000 requests for each client, with a message size varying between 0 and 1000 Bytes. The
6
In fact, the gures include not only the transition execution but the whole Estelle cycle of checking tran-
sitions etc.
13
measurements were performed for the single-process and the distributed versions of both EDT
and Pet/Dingo.
The measurements clearly show that in EDT, interprocess communication dominates the ex-
ecution of Estelle commands. This is, to a certain extent, due to the simplicity of the test
specication. However, it can be derived that the message length has almost no inuence on
the runtime, contrary to the Pet/Dingo system. Here, with a larger message, the runtime
increases signicantly. The reason for this is again to be found in C++: Pet/Dingo uses exces-
sively the construct of \strstreams" to copy messages from Estelle domain into TCP domain.
In addition, a complex algorithm for mapping Estelle messages onto memory areas has to
be used because of the complex data structures containing pointers to member functions etc.
In EDT, quick
memcpy()
commands can be used due to the simple implementation. Thus,
compared to Pet/Dingo, the interprocess communication of EDT is more ecient. In absolute
numbers, we have a throughput on the server side of
6000
1000
Bytes
103
s
0
:
5
MBit
s
. This is by no
means the maximum throughput, as larger messages do not inuence runtime too much (up
to a certain limit imposed by TCP), and the server is not yet at its limit.
5 Conclusion and Outlo ok
Wehave presented here a new approach to generating distributed implementations from Estelle
specications. Unlike all other approaches, we distribute the Estelle specication rst and
generate the programming language co de afterwards. The most important advantage of the
presented method is that we still have an Estelle specication at each site of the distributed
system on which all Estelle tools are still applicable. As a disadvantage, we have to introduce
a further layer of modules, which deepens the hierarchy. Measurements show, however, that
this eect is negligible, especially in the context of the very fast code generated by EDT.
The implementation of this method still has the character of a prototype. The design of the
specication generation process is complete and fully implemented. But the handling of the
start phase, i.e. the initial transition of the specication, is sub ject to a redesign process.
Currently, the starter program is directly generated as C-code, representing the connections
to be established in data structures. This manner of handling the initial transition does not
allow complex statements in the initialize transition due to our simple code generator. We are
currently working on the realization of the starter program in Estelle, so that it will be possible
to generate the C-code for it automatically using an existing Estelle compiler.
One application of the new tool we are interested in is the co-design of hard- and software
in one specication. The general structure of the whole system as well as the automata of
single parts can be described in Estelle. After distributing the sp ecication, software code
maybedirectly generated from certain parts, while others may be translated into a hardware
description language like VHDL. An Estelle-to-VHDL translator already exists [WB94]. In
this case, the communication library to be implemented represents the device driver for the
hardware part.
14
Another application may be seen in
multiversion programming
. Using the new metho d, it is
possible to provide multiple diversied implementations of an algorithm or a protocol. This
maybe useful {inthecontext of fault-tolerant computing { for fault masking.
References
[BD87] S. Budkowski and P. Dembinski. An Introduction to Estelle: A Specication Lan-
guage for Distributed Systems.
Computer Networks and ISDN Systems
, 14(1):3{23,
1987.
[Bud92] S. Budkowski. Estelle Development Toolset.
Computer Networks and ISDN Sys-
tems, Special Issue on FDT Concepts and Tools
, 25(1), 1992.
[DAC
+
89] M. Diaz, J.-P. Ansart, J.-P. Courtiat, P. Azema, and V. Chari, editors.
The Formal
Description Technique Estel le
. Elsevier Science Publishers B.V. (North{Holland),
Amsterdam, 1989.
[FH94] S. Fischer and B. Hofmann. An Estelle Compiler for Multipro cessor Platforms. In
R.L. Tenney, P.D. Amer, and M.
U. Uyar, editors,
Formal Description Techniques,
VI
, pages 171{186. Elsevier Science Publishers B.V. (North{Holland), Amsterdam,
1994.
[FHSW89] J. Favreau, M. Hobbs, B. Strausser, and A. Weinstein. User Guide for the NIST
Prototype Compiler for Estelle. Technical Report No. ICST/SNA{87/3, Institute
for Computer Science and Technology, National Institute of Standards and Tech-
nology,February 1989.
[HK94] Thomas Held and Hartmut Konig. Increasing the Eciency of Computer-aided
Protocol Implementations. In
Proceedings of the 14th Symposium on Protocol Spec-
ication, Testing and Verication (PSTV'94), Vancouver, Kanada
, 1994.
[ISO89] International Standards Organization.
Information processing systems - Open Sys-
tems Interconnection - Estelle: A formal description technique base on an extended
state transition model
, 1989. International Standard ISO 9074.
[JJ89] Claude Jard and Jean-Marc Jezequel. A multi-processor Estelle-to-C compiler
to prototype distributed algorithms on parallel machines. In Giuseppe Scollo
Ed Brinksma and Chris A. Vissers, editors,
Protocol Specication, Testing and Ver-
ication IX
, pages 161{174. IFIP WG 6.1, North Holland, 1989.
[KG93] D. Kreuz and R. Gotzhein. A Compiler for the Parallel Execution of Estelle Sp ec-
ications. In H. Konig, editor,
Formale Methoden fur Verteilte Systeme
, pages
161{178. K. G. Saur Munchen, New Providence, London, Paris, 1993.
[RC89] J.-L. Richard and T. Claes. A Generator of C{Code for Estelle. In Diaz et al.
[DAC
+
89], pages 397{420.
15
[SB90] D. P. Sidhu and T P. Blumer. Semi{automatic Implementation of OSI Protocols.
Computer Networks and ISDN Systems
, 18:221{238, 1990.
[SS93] R. Sijelmassi and B. Strausser. The PET and DINGO to ols for deriving distributed
implementations from Estelle.
Computer Networks and ISDN Systems
, 25(7):841{
851, 1993.
[SSC89] P. de Saqui-Sannes and J.-P. Courtiat. Rapid Prototyping of an Estelle Simulator:
ESTIM. In Diaz et al. [DAC
+
89], pages 353{379.
[VL94] Jean-Francois Verdier and Eric Lallet. Moteur d'implementation repartie pour une
specication ESTELLE. Technical report, Institut National des Telecommunica-
tions, September 1994. (in French).
[VLC88] S. T. Vuong, A. C. Lau, and R. I. Chan. Semiautomatic Implementation of Pro-
tocols Using an Estelle{C Compiler.
IEEE Transactions on Software Engineering
,
14(3):384{393, March 1988.
[WB94] J. Wytrebowicz and S. Budkowski. Communication Protocols Implemented in Hard-
ware: VHDL Generation from Estelle. In
VHDL-Forum for CAD in Europe, Fall'94
Meeting, Grenoble, France
, 1994.
A An example sp ecication
(please see next page)
16
