ALFred, an ALF/ILP Protocol Compiler for Distributed Application ...

INSTITUT NATIONAL DE RECHERCHE EN INFORMATIQUE ET EN AUTOMATIQUE

ALFred, an ALF/ILP Protocol Compiler for Distributed Application Automated Design. Torsten Braun, Isabelle Chrisment, Christophe Diot, François Gagnon, Laurent Gautier, Philipp Hoschka

N˚ 2786 January 1996

PROGRAMME 1 Architectures parallèles, bases de données, réseaux et systèmes distribués

ISSN 0249-6399

apport de recherche

ALFred, an ALF/ILP Protocol Compiler for Distributed Application Automated Design. T. Braun, I. Chrisment, C. Diot, F. Gagnon, L. Gautier, P. Hoschka* Programme 1: Architectures parallèles, bases de données, réseaux et systèmes distribués Projet Rodeo Rapport de recherche n˚2786- January 1996 90 pages Abstract: This report describes the design and the prototyping of a compiling tool for the automated implementation of distributed applications: ALFred. This compiler starts from the formal specification of an application written in ESTEREL, and then integrates end-to-end communication functions tailored to the application characteristics (described in the specification) and produces a high performance implementation. The report describes tdescribes the communication architecture associated to our automated approach. The compiler is made of two main parts: a control compiler also called ALF compiler; and a data manipulation compiler (the ILP compiler) that combines data manipulation functions in an efficient way (the ILP loop). The ALFred compiler has been designed to allow the development and the analysis of non-layered high performance communication architectures based on ALF and ILP. Key-words: High Performance Protocol Architectures, Formal Description, Tailored Protocols, End-to-End Control, ALF, ILP, Multimedia Applications.

(Résumé : tsvp)

* Email: [email protected]

I N S T I T U T N AT I O N A L D E R E C H E R C H E E N I N F O R M A T I Q U E E T E N A U T O M AT I Q U E Unité de recherche INRIA Sophia Antipolis : 2004, route de Lucioles - B.P. 93 - 06902 Sophia Antipolis cedex (France) Téléphone : +33 93 65 77 77 - Télécopie : (33) 93 65 77 65 - Télex : 970 050 F Établissement public national à caractère scientifique et technologique - Décret No 85.831 du 2 août 1985

ALFred, un Compilateur de Protocoles pour l’Implantation Integree d’Applications Distribuees. Résumé : Ce rapport decrit la conception et le prototypage d’un compilateur pour l’implantation automatisee des applications distribuees: ALFred. Ce compilateur utilise la description formelle d’une application ecrite en ESTEREL, ainsi que la description en C des donnees traitees par l’application; il y integre des modules de communication (pour le controle de bout en bout) choisis selon les caracteristiques de l’application avant de produire automatiquement une implantation hautes performances. Le rapport decrit tout d’abord la maniere dont les applications doivent etre specifiees afin d’etre utilisables efficacement par le compilateur. Le compilateur se compose de deux parties: un compilateur de controle et un compilateur de manipulation de donnees. ALFred a ete concu pour permettre le developpement et l’analyse d’architectures de communication hautes performances ne s’appuyant pas sur une organisation en couche. Mots-clé : Architectures de Communication Hautes Performances, Techniques de Description Formelles, Protocoles Dedies a l’Application, Controle de bout en bout, ALF, ILP, Applications Multimedia.

ALFred, an ALF/ILP Protocol Compiler for Distributed Application Automated Design. 3

1

Introduction

The lack of flexibility and efficiency of the traditional generic and layered communication model has led to consider new approaches when designing communication subsystems. The lack of flexibility is due to the difficulty for the generic subsystems to meet the specific needs of the new applications. RPC, for example, is presently the most world-wide used paradigm to develop distributed applications. However, RPC presents some limits: as it is based on the request/response protocol, RPC is not adapted for multimedia and time constrained applications. The lack of efficiency is induced by generality. Some redundant or useless functionalities are implemented within the generic subsystems in order to be able to satisfy every possible types of applications. Another approach is emerging which consists of implementing protocol subsystems tailored to application requirements. According to this approach, we believe that the application communication requirements can be expressed by using a formal language. The formal method is a way to allow the implementation to mach exactly with the application needs. It is also an approach to the design of complex communication system which cannot be designed by hand. The ALFred protocol compiler provides an environment for the design and the verification of reliable data transmission over communication networks. It addresses specifically the automated integration of end-to-end transmission control function to distributed applications. In its final form, ALFred will automatically design clientserver executable programs starting from an application formal specification written in ESTEREL language for its control part, and in C for data description. The goal of ALFred is to investigate new communication architectures based on ALF an ILP rules [Clark90]. The ALF rule says that the unit of control should be the unit of transmission. This property can be guaranteed at least at the end-to-end level. But there is no control on this while on the network. The ILP rule says that all data manipulations should be made in one loop, in order to reduce to one the data read/write operations which are known to be the most expensive in protocol operations. Previous studies [Chrisment94][Braun95a][Diot95][Roca96] showed that ALF and ILP will provide significant gains only if the protocol architecture is «adapted», i.e no segmentation, flat header structure (no layered architecture), process data on the same elementary unit (which should be a multiple of the bus size). Because of the high level integration of the application with its end-to-end control facilities, a formal design in an automated framework is the only credible approach to the design of this type of communication architecture. ALFred operates in three steps (figure 1). • First, the parser analyses the application specification and produces a new specification which integrates tailored transmission mechanisms.

4

T. Braun, I. Chrisment, C. Diot, F. Gagnon, L. Gautier, P. Hoschka

• Second, the ILP compiler, using the original data description written in C by the application designer, and a description of data manipulation functions introduced by the ALF compiler for transmission control purpose (i.e. checksum, encoding), produces an efficient implementation organized in an ILP loop. A stub compiler then produces a base frame for the communication over the network. • Finally, a classic C compiler is used to link files produced by both the ALF and the ILP compilers to the original user C procedures.

Application Designer

ADU specification in annotated C

ESTEREL application specification

ALF compiler

NDU specification in annotated C Generated Software in C

ISC/ILP stub compiler

include files + interface routines in C

Protocol Functions in C

C compiler

Executable Code

Figure 1. Structure of the ALFred Protocol Compiler

Application Software in C

ESTEREL protocol specification

Protocol Data specification in annotated C


We describe first our approach to high performance communication system architecture. An application QoS (Quality of Service) is defined to allow the automated integration of transmission control modules to the application specification. This section is also positioning our approach to the light of other related projects. Then we explain (section 3) how to write application specifications. The application specification is written with an annotated version of the ESTEREL language for the control part and with C for the data description and the data manipulation functions. Section 4 is dedicated to the ALF compiler which analyzes the application specification to select and integrate the communication modules. Section 5 describes the ILP compiler, from the ILP loop design to the INRIA Stub Compiler modification. Integration of ALF and ILP within the ALFred compiler, and also within a communication subsystem, will be described in section 6. Section 7 presents, both from a quantitative and a qualitative point of view, the performance of the protocol compiler. Automatons designed will be shown. Benchmarks will be done in both LAN and WAN environments. The report concludes with some discussion on our approach, and also on the perspectives for the future evolution of ALFred.

6

2


A New Communication System Architecture

2.1 Efficiency of high performance implementation techniques The requirement for a new protocol architecture is clear. Traditional layered protocol architectures such as the ISO OSI model and the ARPA Internet model are reaching the very end of their lifetime. The artificial separation of concerns in layers is partly due to the hardware architecture of the70's. The service/protocol concept derives historically from the model that presents interfaces between different service providers. There would be a link, network, transport and session provider, perhaps all of which would have different potential vendors. Even in a single vendor software implementation, one could accuse the layered model (TCP/IP or OSI) of causing inefficiency. In fact, the operations of multiplexing and segmentation both hide vital information that lower layers need to optimize their performance. Although it is important to distinguish between the architecture of a protocol suite and the implementation of a specific end system or a relay node, the layered protocol architecture may unnecessarily reduce the engineering alternatives available to an implementor. In fact, a certain degree of flexibility in the way functions are organized within the layers is needed. A proposed solution is to integrate all transmission control layers in a single block, in essence discarding the highly modular layered model in exchange for performance. 2.1.1. ALF and ILP In their SIGCOMM '90 paper [Clark90], Clark and Tennenhouse have proposed Application Level Framing (ALF) as a key architectural principle for the design of a new generation of protocols. ALF is in fact the natural result of advanced networking experiments, which showed the need for ‘‘a rule of three units'' . • A relatively old result is that efficient transmission can only be achieved if the unit of control is exactly equal to the unit of transmission. Obvious penalties for violating this rule are unnecessary large retransmissions in case of errors and inefficient memory usage. • The key idea expressed in [Clark90] is that the unit of transmission should also be the unit of processing. Otherwise, large queues will build up in front of the receiving processes and eventually slow down the application. • We found, through experience with multimedia services, that adaptive applications are much easier to develop if the unit of processing is also the unit of control. According to the ALF principle, applications send their data in autonomous "frames'' (or Application Data Units (ADUs)) meaningful to the application. It is also desirable that the presentation and transport layers preserve the frame boundaries as they pro-


cess the data. In fact, this is in line with the widespread view that multiplexing of application data streams should only be done once in the protocol suite. The sending and receiving application should define what data goes in an ADU so that the ADUs can be processed out of order. The ADU will be considered as the unit of "data manipulation'', which will simplify the processing. For example, an image server will send messages corresponding to well identified parts of the picture. On the receiving side, such frames can immediately be decompressed and the corresponding pixels can be displayed on the screen, thus minimizing response times. Integrated Layer Processing (ILP) is an engineering principle that has been suggested for addressing the increased cost of data manipulation functions on modern workstations. In fact, the performance of workstations has increased with the advent of modern RISC architectures but not at the same pace as the network bandwidth during past years. Furthermore, access to primary memory is relatively costly compared to cache and registers, and the discrepancy between the processor and memory performance is expected to get worse. The memory access is expected to represent a bottleneck [Druschel93]. Protocol processing can be divided into two parts, control functions and data manipulation functions. Example of data manipulation functions are presentation encoding, checksuming, encryption and compression. In the control part there are functions for header and connection state processing. [Clark89] has demonstrated that the control part processing can match gigabit network performance for the most common size of PDUs with appropriate implementations. Data manipulation functions present a bottleneck [Clark90][Gunningberg91]. They consist of two or three phases. First a read phase where data is loaded from memory to cache or registers, then a manipulation or "processing'' phase, followed by a write phase for some functions, e.g., presentation encoding. For very "simple functions", like checksuming or byte swap, the time to read and write to memory dominates the processing time. For other "processing oriented functions", like encryption and some presentation encoding, the manipulation time dominates with current processor speeds. However, the situation is expected to change with the increase of processor performance: the memory access will remain the major bottleneck rather than data processing. The data manipulation functions are spread over different layers. In a classic protocol suite implementation, the layers are mapped into distinct software or hardware entities which can be seen as atomic entities. The functions of each layer are carried out completely before the protocol data unit is passed to the next layer. This means that the optimization of each layer has to be done separately. Such ordering constraints are in conflict with efficient implementation of data manipulation functions [Wakeman92].

8


The main concept behind ILP is to minimize costly memory read/write operations by combining data manipulation oriented functions within one or two processing loops instead of performing them serially as is most often done today. It is expected that the cost reduction due to this optimization will result in better overall performance as it will reduce time consuming memory access. This optimization may be applied within a single data manipulation function (intra-function optimization) or across several functions (inter-function optimization) [Dabbous94]. The interest of the ILP principle (and similar software pipelining principles such as lazy message evaluation and delayed evaluation) has been discussed in [Clark90], [Gunningberg91], [Partridge93b], [O’malley90], [Pehrson92] and [Abbott93a]. Previous work [Gunningberg91][Partridge93][Dabbous94] has demonstrated that there is a performance benefit with ILP. The results show reduced processing time for one PDU, as much as a factor of five when six simple data manipulation functions were integrated. These reported results came from experiments that were isolated from the rest of the protocol stacks and where hand-coded assembler routines were used in order to control register allocation and cache behavior. Abbot and Peterson [Abbott93b] use a language approach to integrate functions, but with less speedup. In [Partridge93b] only two functions are integrated, data copying and checksum calculation, but it is a real operational implementation of UDP. Experience with an implementation of the XTP protocol [Dabbous93] showed improved performance when ILP was used. This implementation is in user address space, which also demonstrates that such implementations can perform as well as kernel tuned implementations. We should go one step further and integrate several of the data manipulation functions in a complete, operational stack in order to understand the architectural implications and the achievable speedup. ALF and ILP were proposed in 1990 and for the time being there is no complete implementation of a communication subsystem based on both concepts. Several reasons make the design of a global framework for integrated implementation based on ALF/ILP concepts now both feasible and attractive: • The increase of processor speeds and of the discrepancy between processor and memory performance is pushing toward the integration of data manipulation operations. • Experience with an implementation of the XTP [Dabbous93] and TCP [Braun95b][Castel94] protocols showed that user level software implementations can perform as well as kernel tuned TCP, while still keeping the flexibility of configurable software. • Performance enhancements to the ASN.1 encoding facilitate the implementation of a presentation filter [Dabbous92]. • Multiple communication services including group communication and variable error control have been studied for a variety of applications (e.g. multimedia vi-


deo conferences with shared workspace, mobile applications). It is very desirable to have a mechanism to customize communication subsystems to specific application needs. 2.1.2. Impact on protocol design The basic idea of ALF and ILP is that the protocol should adapt to the requirements of the application. The application is acknowledged to be best prepared to choose the proper strategies for treating lost or out-of-order data. This design of a flexible integrated architecture requires on the one hand that the communication system have access to the application semantics, and on the other hand that the application have the means to affect the relevant control and synchronization aspects of the communication system. Our approach goes a step forward designing a totally non layered architecture where the application control and the end-to-end transmission control mechanisms are merged in a single automaton (figure 2)..

Application

Protocole N

Protocole N-1 Network Classic architecture

Integrated architecture

FIGURE 2. Transmission control modules integration

This approach is optimal on different aspects: • it reduces the number of state to maintain, • it removes interfaces between concurrent layers, • only one "connection" (and the associated context) has to be managed. This architecture has an immediate consequence: it allows the application to control resource using a single "session" identifier. The same identifier can be used by the underlying network.

10


In order to validate this integrated approach, we wanted to analyze and measure what the real impact of ALF and ILP was on both the architecture and the performance of the communication system.

2.2 Notion of ADU and flow ADU means Application Data Unit, as defined in [Clark90]. It is conceptually the most little data unit that the application can handle independently from each other. ADU are designed by the application and are not manipulated by the transmission control protocol. Because ADUs are at the same time the unit of control, the unit of transmission and the unit of processing, this allow data to be delivered and processed independently by the application. The notion of flow has been introduced to differentiate, within the ADUs designed by an application, those that need the same transmission control mechanisms, or in other words the ADUs that have a functional dependency. For example, in a videoconferencing application, various flows can be defined: one for audio, and one for each video stream. In the JPEG encoding, the control ADUs (Quantizer and Huffman tables) belong to the same flow, because they have to be transmitted with the same transmission control mechanisms (reliable and totally ordered). Data ADUs (made of MCUs) belong to another flow. They can be processed by the application out of order, but after the control ADUs have been processed by the receiving entity.

2.3 A new application QoS model Today, two end-to-end transmission control protocols are generally used: • Unreliable protocols (UDP). This type of protocol can be used when the data transmission does not require any reliability, or when the application provides itself end-to-end transmission control. This is the case of most of the multimedia applications that are available in the Internet (VIC, VAT, IVS, etc). • Fully reliable protocols (TCP) where both reliability and order are provided. Application can consequently rely on the protocol. The application that needs reliability, and that has no constraints in delay uses this type of protocol (FTP, electronic mail, RPC, etc). These two extreme protocols were sufficient when application requirements were limited. But complex multimedia applications, carrying voice, video and data, cannot be satisfied with these two protocols. They need protocols that are tailored to each data flow characteristics. TCP is too reliable for audio and video, and UDP not reliable enough for classic data. Most of the multimedia applications that are available on the Internet (VIC, VAT, IVS, WB, etc) have their own transmission control which

ALFred, an ALF/ILP Protocol Compiler for Distributed Application Automated Design.11

is integrated to the application and use a UDP over IP based communication support (not reliable, not connected). Diaz clearly synthesized the problem [Diaz95] by a three axes model to characterize multimedia applications (figure 3). Reliability, ordering, and time are the three dimensions that characterize a distributed application. We can see on that figure that the protocols we use today are delimitating the same plan. Multimedia application would need protocols that can be anywhere in the cube defined by the three dimensions. reliability 1

.

.

TCP

UDP

0

1

order

1 time Figure 3. Application characterization with three dimensions [Diaz95]

To obtain a fine-grain classification of end-to-end transmission control protocols, we have decomposed transmission control protocols in independent functionalities (e.g acknowledgment, flow control, retransmission, etc). Functionalities and mechanisms are selected and associated to the application for each ADU flow. Based on this three axes representation, we have defined three "application QoS" parameters. These parameters will be used to annotate the application formal specification in order to allow the ALF compiler to select and integrate dedicated and efficient communication facilities to each flow of ADUs within a multimedia application: • Ordering (or resequencing) corresponds to the order in which the data have to be delivered to the user. There are two classic notion of order: "in-sequence" and "out-of-sequence" delivering. We have defined two total ordering relations on ADU designed by the sending application. Tx is the order of transmission. The transmission order is chosen by the sending application by association of a number to each ADU. "In-sequence" ADU delivering corresponds to delivering in the transmission order.

12


Rx is the order of reception at the receiving entity. The reception order is the order in which ADUs are received from the network. Delivering ADUs in the receiving order means "out-of-sequence". We have defined two ordering modules: Tx_ORDER delivers the ADUs in the transmission order. This is the classic reordering function found in TCP or OSI TP4 for example. Rx_ORDER which delivers the ADUs in the Rx order, or as they are received from network. This is the classic out of sequence delivering found in UDP. A third ordering notion we call real-time order (RoT_ORDER) can be defined. With real-time order, ADUs delivered are those received in the transmission order (or where the Tx o Rx relation is verified). In that case, only the most recent ADU is delivered to the application. This type of order is used by the realtime applications that are not interested in obsolete data (obsolete data are those arrived after more recent ones). The association of a timed window mechanism to RoT_ORDER can provide the continuity between Rx_ORDER and Tx_ORDER. A timed window with infinite time-out on buffers is equivalent to Tx_ORDER. With a null time-out, only data received in the transmission order are delivered, so Rx_ORDER. Any time-out value between these to extremes will allow to partially re-order received data. The choice of the time-out will result in a compromise between the delay, the order, and reliability. When the time-out increases, the delay increases proportionally, but loss rate decreases (more ADUs are delivered). • Reliability (or error control) is the mechanism used to detect and possibly correct lost ADUs. This parameter can take two values: Not reliable that assumes no retransmission. Fully reliable that means all ADUs will be delivered. When fully reliability is chosen, a retransmission module is integrated to the application to control the reliable delivering of the concerned flow of ADUs. Retransmission can be based on various type of mechanisms (positive, negative, selective acknowledgment) following the nature of the application and of the network. Note that partial reliability should be defined, as in [Diaz95]. We do not have developed any mechanism for partial reliability. Because partial reliability is closely linked to transmission delays and delivering order, we expect that the timed window mechanism will help us to understand better what is partial reliability and how to control it. • Traffic characterizes the real-time capabilities of an ADU flow. This parameter is concerned with the type of congestion control, access control, and flow control mechanism that will be used to transmit an ADU flow. In our first ALFred prototype, there are two different values for this parameter: No real time traffic and Real time traffic. A real time traffic will be controlled by a rate control mecha-


nism, when non real time traffic will be controlled by a window flow control. But this is too weak for multimedia application and we intend to evaluate a larger range of mechanism in the future, eventually modifying the values and the semantic of the Traffic parameter. Note that the choice of a mechanism can be directed by more of one parameter. For example, if the traffic parameter is set to "real-time" and if ordering is set to "Tx_ORDER", then a timed windows will be introduced on the receiving side, allowing order and reliability to be partial. The adjustment of the time-out is left to the user, or to a QoS manager. These three parameters allow an application designer to theoretically design 8 different protocols. The end of this section describes these protocols. For each parameter combination, an example of multimedia application, or more simply of ADU flow is provided. • Transmission order; reliable; no real time. This protocol does not need more explanation. It is equivalent to TCP. Application like electronic mail, file transfer can use this type of protocol. • Transmission order; reliable; real time. Real-time delivering of ADUs with retransmission. Because the traffic is real-time, a timed window mechanism is provided to control jitter, and to allow partial ordering and partial reliability. HiFi sound and IA/robotic applications could be transmitted with such type of control. • Transmission order; not reliable; no real time. This protocol delivers only ADUs received in sequence (defined above as RoT order), which is equivalent to ADUs transmitted with the smaller delay. The no real time value of the traffic parameter can be judged contradictory. But application like actor/reactor that are not very sensitive to jitter can use such a protocol. • Transmission order; not reliable; real time. Because of the real-time parameter, such protocol is dedicated to applications that are sensitive to jitter and that can accept loss (video, audio with redundant encoding, distributed games). A timed window mechanism can be used to control jitter and loss rate. • Reception order; reliable, no real time. This would be an ALF version of TCP where transmission is totally reliable, but where ADUs can be delivered out of order. Such protocol is useful in case of fixed image transmission. • Reception order; reliable, real time. A protocol for application that need every ADU as soon as possible (like a distributed white-board for example). ADUs are delivered immediately when received. Lost or damaged ADUs will be retransmitted. Transmission delays must be kept minimal.

14


• Reception order; not reliable; no real time. Equivalent to UDP. This is a minimal end-to-end control protocol that should provide only access control and a congestion control mechanism. Examples of application for this type of protocol are applications that want to implement their own end-to-end control. This protocol should be used with an access control mechanism to prevent from network congestion. • Reception order; not reliable; real time. A real-time variant of UDP. The only difference with the non real-time protocol will be on the selection of flow control mechanisms. This could be used for adaptive video transmission.

2.4 Related works Other research groups are currently working on the automated design and implementation of communication subsystems tailored to application requirements. We can mention ADAPTIVE [Schmidt93], Da Capo [Plagemann92], UTS [Richards95], Partial Order Protocols [Diaz95], and USC [Omalley94]. The proposed solutions include developing general purpose protocols that allow flexibility. However these solutions are not operating system independent because the implementations are either part of the kernel, or a server within a micro-kernel based operating system. More details are given on two of these experiences: • Da CaPo [Plagemann92] is a more advanced tool for dynamic configuration of end-to-end transmission control protocols tailored to the application characteristics. A complex heuristic is used to design an independent control automaton for the end-to-end transmission control protocol (called CoRA). There is no integration, and the 3 layer architecture is respected. ALF is not retained as a design principle, which makes more complex the design of the communication support (itself implemented in the kernel space of the host computer). Da CaPo proves that tailoring protocol to the application characteristics is efficient in case of multimedia applications. It also proves that automated design in a formal framework is feasible with high performance. • [Diaz95] also proposes a layered system where classic protocols are used to transmit application data, and where the application automaton is used to synchronize the data received (or transmitted) on the various protocols. The concept of "partial order connections" which is used to optimize the transmission, is very close to ALF. [Diaz95] uses classic transport protocols; in the case of the JPEG player, one could TCP to transmit the control tables, and UDP for the MCU packets. The application automaton is described using Timed Petri Nets. Protocols used, as well as the application automaton, are implemented in the kernel space of the host computer. A common experiment is being carried out to compare the two different approaches.


3

Formal Specification of a Distributed Application

The classic development process for distributed applications is to describe first the application in a natural language and then to use this informal description to design an implementation. If the designer is a network expert, he will include some end-toend control in the application, and rely on simple non reliable protocols like UDP for transmission over network. In that case, the end-to-end control facilities will be integrated to the application. But it requires a very good knowledge of the application and of communication techniques. On the other side, most of the distributed application designers are not networking experts. They are mostly service users and they will design an application that takes advantage of existing facilities like TCP for example, or use RPC generator-like tool. This approach generally results in poor performance that are not acceptable in the case of multimedia application having temporal constrains. It cannot be expected from this type of user to identify precisely what are the requirements of his application. ALFred is designed to serve the second range of application designers, in order to offer them efficient communication facilities tailored to their application characteristics. To make this possible, the protocol compiler needs various informations that are not directly related to the transmission control: • The application must be described in such a way that it is possible to analyze its structure automatically. Using a formal language is the perfect solution; we have chosen ESTEREL [Diot94]. There is no information relative to the end-to-end transmission control facilities at this level of specification. Just a description of the control automaton (that has the form of a Finite State Machine) of the application. The application designer will just have to differentiate the Application Data Unit (or ADU) that will be transmitted over the network. The compiler guarantees that these ADUs will be transmitted in a constituent way, i.e. not segmented by the transmission control functions. • The previous specification is not enough to know what type of communication facility is required to give an application the most efficient possible transmission condition (or QoS). Extra information have to be supplied. They are related to the conditions in which the transmission over the network must be realized. These informations are introduced in the original specification as annotations to the ESTEREL language. They only affect the ADUs that have been identified to cross the network. • Finally, and having defined the control of the application, the application designer also needs to describe the data manipulation functions used for application treatment purpose. It could be for example a compression algorithm, or an encoding scheme. ALFred expects data manipulation functions and ADUs structure to be written in C.

16


The next three sub-sections now describe in detail how a distributed application has to be specified to be efficiently served (compiled and implemented) by the ALFred compiler.

3.1 Control specification in ESTEREL ESTEREL is a control-oriented reactive language [Berry87]. For a complete description, see [Berry92]. We have shown in [Diot94] why ESTEREL is well adapted to the description of communication systems and of distributed applications. As explained previously, we are using a pure ESTEREL syntax for the description of the application control. But annotations, that do not modify the ESTEREL syntax (they are introduced as comments in ESTEREL modules), had to be added to allow the application designer to describe some of the application characteristics that cannot be expressed in ESTEREL. Not modifying the ESTEREL syntax is very important as it allows intermediate verifications using the ESTEREL compiler and the associated verification tools. Communication in ESTEREL is based on signals. An ESTEREL module is a black box with input events and output events that are represented by external signals (Figure 4). When a new event occurs (in input), the ESTEREL module reacts "instantaneously", and in the same instant, issues the result on output events. An ESTEREL signal it is synchronous, and it cannot be delayed or lost.

Input Signals

ESTEREL module

Output Signals

Figure 4. An ESTEREL module architecture

3.1.1. Remote signal This model is particularly adapted to describe separately the two ends of a communication system: the transmitter and the receiver (see figure 5). But it is not totally adapted to the network environment where signals can be lost and duplicated, and where delay and error can be experienced on the data carried out by the signals. So, using ESTEREL signals to describe the network signals of figure 5 would be wrong. Before integration of the transmission control modules, signals are exchanged between the two application entities. There is no network between them and the system can be described with ESTEREL. Once the communication facilities have been integrated, signals exchanged between the application entities are NDUs, for Net-


work Data Units. NDU are made of the former ADUs and also of transmission control data unit that does not contain any application data (NDUs will be described in section 3.3). NDU are carried on "remote signal" because they can be lost or delayed. It becomes wrong to describe the system made of the two application entities plus the network with ESTEREL.

User

Client specification

host environment

network signals

Server specification

host environment

Figure 5. client/server application specification in ESTEREL

The consequence is that the two application entities are specified separately, in two different modules. Then, the behavior of the remote signals has no consequence on the application specification. Locally, we just consider that remote signals occur synchronously. This becomes a major problem when it comes to verification as it is impossible to specify the whole system with a good semantic in ESTEREL (see Appendix 3). The use of the remote signals is similar to the use of original ESTEREL signals. Remote signals have two particularities: the signal name is prefixed with "remote_" and the signal type must be "ADU". The remote signals must be declared in the module's interface: type ADU; output remote_ : ADU; input remote_ : ADU; This example shows how to declare a remote signal either for emission or for reception. The declaration of "inputoutput" remote signal is strictly forbidden. Obviously a remote signal must be used with the same name on both sides of the application specification. The remote signals are more constrained than the basic signals. Only the "emit" and "await" instructions are allowed in the strict following forms: emit remote_ (); await remote_ where is the information to be carried by the signal.

18


The "emit" and "await" instruction semantic change in case of remote signals. First, they are no more synchronous. Second, an "await" can never receive the corresponding emitted signal (signal loss). Finally, the signals can be disordered, e.g. the signals reception order can be different from the signals emission order. For example if a signal is emitted twice, the "await" can catch the second signal emitted first and the first signal emitted after. 3.1.2. Specification structure This section analyzes the global architecture of the specification. The application specification follows a client-server model. Obviously the application designer must provide a client specification and a server one. To allow the ALF compiler to identify the client and the server modules, the module names should match the following patterns: CL_ for the client side SVC_ for the server side Only the main modules have to follow this rules. The ALF compiler allows only one module per specification to be client or server. Moreover, the client and the server modules must have the same name without prefix. For example, a specification named SPEC will have the client module named CL_SPEC and the server module named SVC_SPEC. Both sides are designed on the same skeleton. This skeleton owns two predefined ESTEREL "watching" structures with particular semantics for the remote signals explained below: do do watching Abort; watching Quit; This template introduces two reserved signals named "Quit" and "Abort". Those signals must be declared as pure input signals: input Abort, Quit; The Quit signal ends all the remote signals transmissions, whereas the Abort signal only aborts all the current remote signals transmissions and resets them. The "watching Quit" structure should not be encapsulated in a repeat loop. On the con-


trary the "watching Abort" structure is very interesting when encapsulated in such a loop. These two reserved signals are designed to be used by the application designer. They are local. As relations between signals are very important in ESTEREL to obtain powerful state machines, the signals Abort and Quit should be declared as incompatible between them, and with all the others user input signals: relation Abort # Quit # Client and server modules of an application specification are given in Appendix 6.

3.2 Application QoS annotations The transmission controls aim to define the behavior of the remote signals and consequently of the "emit" and "await" instructions. In fact, all the transmission controls must be specified for each remote signal declared. The syntax of the transmission control list is the following: := ([| | %> ])* := | | Consequently, and as described in the application QoS section, three control types have been defined. The syntax to attach these control informations to the definition of the remote signals is: %#CTRL input remote_: ADU Such annotation must prefix each remote signal declaration (having an ADU type), or each flow declaration (group of ADUs that have the same control properties). The control list must contain all the three control types (RELIABILITY, ORDER, TRAFFIC). A signal or a flow must have the same controls on both sides of the application. For example, TCP-like transmission controls could be: %#CTRL RELIABILITY : TOTAL | ORDER : Tx %> TRAFFIC : NOTIME input remote_MySignal : ADU; The ALFred protocol compiler provides also a way to modify the behavior of signal transmission. It allows to specify a special behavior for a remote signal, in a speci-

20


fied statement block, e.g. to change one or more of the originally declared controls. The syntax is the following: %#LOCAL %#END_LOCAL where: := (%#CTRLremote_;)* Only order control modifications can be allowed in the first prototype.

3.3 Data manipulation description There are already many existing interface specification languages, and each of those could have served as a starting point for the description of data manipulation functions and associated data structures (e.g. XDR [Anonymous87] for ONC/Sun RPC [Corbin90], NIDL for OSF-DCE [Zahn90], ASN.1 [Anonymous88a] defined for the OSI presentation layer [Anonymous88b], [Anonymous88c] and the IDL specified for CORBA [Anonymous93]). The potential advantage of using any of these existing languages for the ALFred* compiler would have been that the existing documentation for these languages could have been reused. Theoretically, a second potential advantage of reusing an existing language is that ALFred could be used directly for already existing applications that were specified this language. A closer look at the current state of the art reveals, however, that none of the existing languages have achieved widespread acceptance by users today. Moreover, as we will see, it is straightforward to use ISC for an application that was originally written using another IDL. Thus, we decided to use annotated C type definitions to specify message formats, instead of one of the already existing IDLs. This has several advantages: • It enables software reuse in client-server applications: Distributed programming environments such as OSF/DCE and Sun/ONC mostly address the development of new distributed applications. In contrast, ISC was geared towards converting an already existing, monolithic application into a client-server application. This requirement occurs quite frequently in practice. In this case, it is clearly desirable to reuse the existing software as much as possible. ISC addresses this issue for applications written in C by using the C source files of the application as the basis * ILP compiler design is based on the extension of ISC, the INRIA Stub Compiler [Hoschka94]. This section consequently refers more to choices motivated by the design of ISC than for its extension to the ILP compiler.


for code generation. The roots of ISC lie in a project that turned the ASN.1 compiler Mavros into a tool usable for software reuse [Mazziotta93], motivated by the need to build a distributed version of the CENTAUR software development environment [Centaur95]. • It facilitates meaningful experiments with high performance marshalling routines: The marshalling operation has been widely recognized as one of the major bottlenecks impeding hosts from making full use of gigabit networking technology. Comparing different approaches to marshalling requires experimenting with benchmarks that are representative for the actual use of distributed systems. However, designing meaningful experiments is difficult today due to the lack of representative, widely used benchmark applications in distributed systems. ISC facilitates benchmarking by making the wealth of existing C applications amenable to marshalling performance analysis. • The code designed in annotated C can replace marshalling code in an existing distributed application. A conventional stub compiler such as rpcgen that generates marshalling code in C will always also produces C header files. These header files can be annotated and fed into ISC, which then produces either more efficient marshalling code or integrated layer processing code. The advantage is that this approach may require only minimal changes to the already existing application code (i.e. only the calls to marshalling functions must be changed). No modification is required for the actual application code, since the type definitions produced by the original stub compiler do not change. For many C struct type definitions, and thus for the major part of an interface specification, marshalling code can be generated without further annotation. However, there are some cases where a direct translation is impossible without additional information. In particular, the following C types require annotation: • union types • string types • array types Annotation is required because some of the semantics of these types that are implicitly known by the programmer when writing the program must be made explicit in order for automatic generation of marshalling routines to be possible To see why annotations are necessary, we have to look at the difference between local data representations and network data representations in some detail. Consider the following example message containing a C union type: typedef struct _msg{ int tag; int number;

22


union _u { int a; char b; X c; } u; } Msg; The field Msg.u may alternatively contain an integer type, a character type or a type X. When transmitting a message of type Msg, it must be possible for the receiver to determine the actual type of the value in Msg.u. This information is represented by an integer value in the integer field Msg.tag. In the unmarshalling routine, the stub compiler must generate code that first tests the value of the Msg.tag field and then, depending on the outcome of the test, calls the unmarshalling routine for the appropriate type (int, char or X). However, nothing in the C source code indicates that it is the Msg.tag field that serves to identify the union type. By only looking at the syntax, the union type might also be defined by the Msg.number field. Thus, a special hint to the stub compiler in form of an annotation is required for distinguishing the Msg.tag field as the discriminator of the union u. The annotations for string and array types are required for similar reasons. A number of proposals for annotating C for the purposes of marshalling code generation have already been made [OMalley94] [Reid87]. However, none of the approaches we are aware of allow the annotation of C union types, which are important for application level protocols. The most recent of these proposals used in USC [OMalley94] requires that the user not only specifies the message types, but also the coding rules to be used for each message field. Such specifications are unnecessary in ISC, because we use uniform data coding rules, namely XDR. Therefore, the coding rules are pre-implemented in the stub generator. However, specifying coding rules for individual fields is useful for staying compatible with the header formats specified by an already existing protocol. Future versions of ISC may allow users to replace the default XDR network data format by their own, customized specification compatible with the header format defined in a protocol standard. Moreover, in contrast to the tools described in [OMalley94] and [Reid93], ISC contains a parser for the complete syntax of the C language. ISC can process arbitrary C source files. In particular, these files may contain not only type declarations, but also function headers, include files and similar non-marshalling related information. Except for eventual type annotations, no manual editing of a C file is required before it can be processed by ISC. ISC has similar design goals as the stub compiler described in [Parrington94], only that this tool processes annotated C++ files, whereas ISC processes C files.


4

The ALF Compiler

This section focuses on the ALF part of the Protocol Compiler. The purpose of the ALF compiler is to automatically generate a communication subsystem tailored to application requirements by applying the ALF model. The Application Level Framing model [Clark90] questions the well-established layering model by proposing shared knowledge between the different layers. ALF says that the applications should be involved in their network communication and that more transmission functionalities and flexibility has to be left to the applications. The basic idea behind ALF is that the communication subsystem has to adapt to the application needs, as opposed to the application having to adapt to the underlying protocol as it is the case with the layered architecture. ALF considers that the application knows better than the transmission subsystem how to process data when there is some loss or/and when data arrive out-of-order. Consequently, the subsystem must know the semantics of the application and the ALF model proposes that the communication processes Applications Data Units (ADUs) which are meaningful for the application and not some packets only specific to the protocol. The ADUs are autonomous data which represent at the same time the unit of transmission, the unit of control and the unit of processing and which can be processed out-of-order by the application at the receiver side.[Chrisment94] shows that ALF is not only a concept but can also provide some improvement on performance due to the possibility of exploiting the out-of-order processing. To make easier the life of the application designer, the ALF compiler offers a certain level of abstraction as provided by the RPC compilers such as RPCGEN[Nelson81]. The ALF compiler uses a specification language approach to express the communication requirements of a distributed application which follows the client-server model. The ALF compiler is composed of two main parts: (cf Figure 6): • The ALF Parser which produces a formal specification integrating the adapted transmission mechanisms into the application specification. • The ALF Generator which has in charge to generate the execution environment and the implementation into the application language.

4.1 The ALF Parser The ALF Parser selects and integrates the dedicated communication facilities into the formal specification of a distributed application and produces a formal integrated specification. As input of the ALF Parser, the application designer has to provide: • The control and synchronization aspects of the application using the ESTEREL formal specification language. The designer decomposes the specification of a distributed application into a specification for the client side so-called CL_.strl and a specification for the service side so-called SVC_.strl where is the application name and .strl is an extension for the ESTEREL files. Annotations have been added in the ESTEREL language to be able to describe different types of communication controls (also called the application QoS). These annotations have been introduced in section 2. The corresponding transmission modules, and the way they are integrated to the application specifications will be described in this section.

ADU specification in annotated C

ESTEREL application specification

Application Software in C

Application Designer

ALF Parser

Parser

ESTEREL protocol specification

ESTEREL

integrated specification

Execution Environment Generator

NDU specification in annotared C

ALF generator ( ESTEREL compiler)

Protocol data specification in annotated C

Generated Software in C

Figure 6. Architecture of the ALF Compiler

• The semantics of the Application Data Units which will be transmitted over the network and which must be described in a annotated C file. The annotated C language is described section 5. • The C software that are specific to the application. It containts essentially the contents of routines and the definition of some data types which appear within the ESTEREL specification.


4.1.1. Transmission control modules We show hereafter how is build the protocol according to the application specification. The protocol is composed of four types of transmission control modules: the initialization modules, the application QoS management modules, the synchronization modules and the emission/reception modules. The signals interface for these different modules can be found in the Appendix 6.

Integrated Specification QoS Modules Flow i

Initial Application Specification Synchronization

Flow modules

Initialization Emission and Reception

signals ADU modules

modules Flow j

Figure 7. QoS modules integration

Initialization modules These modules are common to all flows and ADUs. The are automatically and systematically integrated to an application specification in order to initialize ADU flows. As the relation client-server is not symmetrical, to initiate a network connection requires that the program knows which role (client/server) it has to play. • FLOW_OPEN_CLNT is integrated into the client specification. It has in charge to open a flow from the client point of view. The module create a flow context (tg_flow_ctx) associated to each flow identifier (tg_flow_id). The destination of the flow is the server address. • FLOW_OPEN_SVC is integrated into the server specification. It awaits for a request coming from a client and searches the associated context according to the flow identifier. This flow context (tg_flow_ctx) is then broadcast within all the system.

26


End-to-end transmission control The end-to-end control modules implement the application QoS parameters presented in section 2. • ORDER parameter: An ESTEREL module has been described for each type of order (Tx, Rx). The order modules are specified at the ADUs level, and are integrated in parallel with the application specification as an ADU can be received at any time. In all order modules, When an ADU is received (signal rADU_rcv), the module emits the tg_seq_N signal which represents the global sequence number of the received ADU. This signal allows other communication modules, especially the acknowledgment handler module, to know the sequence number of the current received ADU even it has not been delivered to the application. • RELIABILITY parameter: When full reliability is chosen, a RETRANS module has in charge, at the sender side, to retransmit NDUs when a loss is detected or when retransmission timer has expired. At the receiver side, the adequate acknowledgment policy will be integrated; there are three available. The NACKLIST_HANDLER module specifies the Negative Acknowledgment strategy, the ACKLIST_HANDLER module the Positive Acknowledgment strategy and the CACKLIST_HANDLER module the Cumulative Acknowledgment strategy. •TRAFFIC parameter: Presently only the window flow control for no real time traffic is specified. At the sender side the flow control is achieved by the SLOW_START module which communicates with the retransmission module (if RELIABILITY has been required) to inform it to do retransmission because data are missed (tl_retrans_ loss) or because the retransmission timer has expired (ctrl_timer_transmis sion_end). The SLOW_START module encapsulates the FLOW_ONOFF module which activates or desactivates a signal (tl_flow_ready) to specify whether the flow control allows the application to send data through network. At the receiver side, the EMISSION_CTRL module is used to send the needed control information. For example, to generate a protocol with functionalities equivalent to those of TCP the following parameters have to be selected: Tx ORDER, Total RELIABILITY and No real-time TRAFFIC. For UDP: Rx_ORDER, No RELIABILITY and No real-time TRAFFIC. Synchronization modules: In our compiler, the type of traffic or of reliability can change temporarily, within a block of instructions, provided that synchronization points have been defined. These synchronization points will guarantee that a protocol terminates properly before the


transmission starts again with new parameters. The parser has to analyze the initial application specification and to detect when the protocol changes to insert these synchronization points which are realized by the following modules. • BEGIN_ORDER_ADU informs the ordering module that application is ready to receive a specific ADU • END_ORDER_ADU informs the ordering module that application is no longer interested in a specific ADU • BEGIN_TRAFIC_NOTIME and END_TRAFIC_NOTIME are the synchronization modules for the window flow control • BEGIN_TRAFIC_REALTIME and END_TRAFIC_REALTIME are the synchronization modules for the Rate Control • END_TRAFIC ends the current traffic control. It is used when it is not possible to know the current type of traffic (in a watchdog statement for example). • BEGIN_RELIABILITY_TOTAL and END_RELIABILITY_TOTAL are the synchronization point for the total reliability. • BEGIN_RELIABILITY_NONE and END_RELIABILITTY_NONE are the synchronization point for no reliability. • END-RELIABILITY ends the current type of reliability. It is used like the END_TRAFFIC module. END_TRAFFIC and END_RELIABILITY communicate with the TRAFFIC_STA TE and RELIABILITY_STATE modules to evaluate the current protocol. A new type of control starts with the BEGIN_xxx statement and terminates with END_xxx. In the current prototype, only the reliability synchronization modules are specified. Emission and reception modules: Modules which carried out the ADUs emission (EMISSION_ADU) and reception (RECV_ADU) replace the ESTEREL emit and await statements for the remote signals. Remote signals are signals containing data which have to be sent to and/or received from the network. We shown section 3 that the ESTEREL emit and await statements have a semantics which cannot be applied for the remote signals. The EMISSION_ ADU module tests whether the ADU can be sent. If the flow control authorizes the emission, a timer is set (ctrl_timer_transmission_start), a NDU is built and sent at the same time to the RETRANS module to buffer it(tg_send_NDU) and to the remote host (r_send_NDU). The RECV_ADU module encapsulates the ESTEREL await statement into a watchdog statement to trap the time-out signal (ctrl-timer_ADU_end) and to re-send the last NDU which has been already sent (ctrl_ last_packet_send).

28


4.1.2. Module integration We show below how the modules described in the previous subsection are integrated into the initial specification. We also present selection and integration rules applied by the ALF parser. All QoS communication modules which implements the protocol mechanisms (reliability/order/traffic) are integrated in parallel with the application specification because the events which come from the network are asynchronous and can occur at any time. These communication modules are related to a flow (reliability/traffic modules) or to an ADU within a flow (order modules). If there are several flows, the same modules can appear several times within the integrated specification. For each flow, the parser makes the integration in two steps: it adds first the modules related to the flow and then it integrates the modules related to the ADUs belonging to the flow. The emission, reception, initialization and synchronization modules are integrated directly into the initial specification. They interact, through signals, with the QoS management modules. 1.

Emission and reception

The emission and reception modules replace the ESTEREL emit and await statements for the remote signals. Figure 8 below shows how a remote signal is in transit from the emission primitive to the reception primitive. Integrated Specification Initial Application Specification QoS Modules

emit remote_ADU; EMISSION_ADU

NETWORK Integrated Specification Initial Application Specification RECV_ADU await remote_ADU;

Figure 8. Emission and reception modules integration


2.

Initialization and termination

The initialization modules are integrated at the beginning of the application specification. They permit the communication modules to be started at the same time than the application. With the optional loop, the application designer can express the possibility to re-initialize the communication modules after the interruption. We saw in the previous section than the Abort and Quit signals allow the transmission communication to be ended normally or abruptly. In order the Qos modules can be terminated from the application specification, the parser gives the possibility to integrate termination modules into the watching Quit statement and interruption modules into the watching Abort statements. But, presently, only the initialization modules have been written and are integrated. 3.

Synchronization

The parser integrates the synchronization modules to modify the protocol during a flow. The protocol modification is done into two steps: end of the previous protocol and beginning of the new one. Generally only some QoS parameters of the protocol do change. At a given instant, a flow or an ADU, can have only one QoS parameter of the same type. Three types of changes are detected by the parser: Integrated Specification Initial Application Specification % Initialization application do [loop] % optional loop Initialization modules do Application modules watching Abort Interruption modules [end loop] watching Quit Termination modules

Transmission Control modules

Figure 9. Initialization and termination modules integration

• Simple change. The end of the old protocol and the beginning of the new one are sequential

30


• Multiple changes. The protocol change is multiple when there are several possible protocols before or after the synchronization point. This case is due to the ESTEREL statements like if...then...else...end if or loop... end every.. End module for QoS X: A synchronization point

Begin module for QoS X: B Figure 10. simple protocol change.

• Indefinite change. A protocol change is indefinite when the previous characteristic for the flow cannot be determined at the compile time. This case is due to the ESTEREL preemptive statements like do... watching or every do... end every. For this type of change, we specify one global termination module for each QoS parameters (END_RELIABILITY/END_TRAFFIC) which has in charge to check the current state of the flow at the run time and to call the adequate module. End module for QoS Y: C

End module for QoS Y:C

End module for QoS X: A

End module for QoS X: B

Begin module for QoS Y: D

synchronization point

Begin module for QoS X: B Figure 11. multiple protocol change

4.2 The ALF Generator The ALF Generator starts from the integrated ESTEREL specification to build the Network Data Unit specification and to produce the execution environment in the host language (in the C language in our case). The ALF Generator includes the ESTEREL compiler.


4.2.1. Construction of the Network Data Units (NDUs) A NDU is the unit of data processing and switching with the network. There are two types of NDUs (Figure 12): • the NDUs which contains some information control related to the acknowledgments and the congestion/flow control. • the NDUs which contains the Application Data Units. header

control information

NDU-CNTL header

adu header

adu

NDU-ADU Figure 12. NDU description

The description of the NDUs used by the integrated application appears in a file _ndu.h.anno which is produced by the ALF Generator from: • the Application Data Unit (ADU) specification which is written by the application designer in the _adu.h.anno file. Each ADU has to be defined as C struct type like: typedef struct adu_type{ /* structure of the ADU */ } adu_type; • the Protocol Data Unit specification which is written by the protocol designer in the ctrl.h.anno file and which describes the structure of all control information packets. • the ESTEREL integrated specification which is produced by the ALF parser. The client and server integrated specification are analyzed to determine what types of ADU and of Control Information are used and a C union NDU type is generated. An example of NDU type is given below: typedef struct tel_ndu{ int x; /* specify the type of NDU */ union { ndu_cctrl ndu_cctrl; /* Information Control */ ndu_ectrl ndu_ectrl; ndu_remote_line ndu_remote_line; /* ADU */ } v; } tel_ndu; The Network Data Unit manipulation part is implemented by the stub routines which are generated by the ILP compiler described in the next section.

32


4.2.2. Generation of the execution environment (C software) The execution environment achieves the interaction between a synchronous behavior represented by the integrated specification described in ESTEREL and the asynchronous world represented by the external environment (the user and/or the network). This execution environment is composed of: • A control part implementing the integrated finite state machines (CL/SVC_ _pars.c). These automaton are generated by the ESTEREL compiler. • A asynchronous/synchronous interface (or Input Events Collector) which collects the events which comes from the external environment (User/ Network) and produces the signals to the automaton (CL/SVC__pars_protocol.c CL/ SVC__pars.h). •

A synchronous/asynchronous interface (or Output Events Collector) which collects the signals which comes from the automaton et produces the signals to the environment (CL/SVC__pars_protocol.c CL/SVC__pars.h).

These elements will be defined in section 6 as there are interacting with the ILP compiler described in the next section.


5

The ILP Compiler

The ALF compiler generates code implementing the finite state automaton for an application-specific protocol. However, managing the protocol state is only one task of protocol processing. The second task consists in manipulating application data. A data manipulation function can be generally defined as any function in a protocol stack that processes the content of an application message. Typical data manipulation functions are copying data between application memory and network buffer, calculating a checksum over the data or encrypting it. The overhead of data manipulation in a protocol stack can be very high since it is proportional to the number of bytes in a message and to the memory access time. Data manipulation overhead often dominates the overhead of managing the protocol state, since the latter is only proportional to the number of messages exchanged. Optimization of data manipulation code in a protocol stack is thus very important for overall protocol performance. Integrated layer processing (ILP) is an optimization technique for data manipulation code [Clark90][Abbott93b][Braun95a]. This technique reduces the number of main memory accesses required during data manipulation combining all the data manipulation functions in a single loop (the ILP loop). Saving memory accesses is very important, since with the current development of technology, CPU cycle time decreases much faster than memory cycle time [Hennessy90], increasing the relative overhead of memory accesses in a program. ILP code is difficult to implement and maintain manually. This is because it abandons the conventional layered implementation architecture of protocol code in favor of a closely integrated implementation of data manipulation functions. Therefore, researchers have proposed to automate the generation of ILP data manipulation code [Abbott93b][Braun95a]. The ILP compiler extends previous work on automatic generation of ILP code. It allows the automatic generation of ILP code while being used in the same way as a traditional stub compiler. As with traditional tools, the ILP compiler allows code generation starting from a specification of the application interface. Thus, the use of ILP is transparent to the application programmer, and the ILP compiler can be used in the same way as any other stub compiler.

5.1 Integrating ILP code into a Stub Compiler 5.1.1. Overview In order to implement the ILP compiler, the INRIA stub compiler (ISC) was extended (see Appendix 4). The ILP extensions for ISC (ISC/ILP) described hereafter concern enhancements of the marshalling and unmarshalling routines for integrated data manipulation processing. ILP requires that several data manipulations such as encryption or checksum calculation are performed within a single loop, i.e.

34


without reading the data from the CPU to main memory and back for each data manipulation function. The ILP-enhanced ISC compiler generates stub routines for the most important data manipulation functions in a protocol stack, namely calculating a checksum, encrypting data and marshalling*. The data manipulations for sending are performed after marshalling a message and the data manipulations for receiving are performed before unmarshalling. The extensions only support to add data manipulations, which are in the communication stack architecture, on a lower level than marshalling. ISC generates marshalling code for XDR (eXternal Data Representation [Anonymous87]). XDR uses 4 byte processing units. Therefore, the unit of 4 bytes is selected as the basic processing unit size for all data manipulations according to the word filter concept [Abbot93b]. Future work will address the integration of data manipulation functions with processing unit sizes bigger than 4 bytes (e.g. the8-byte units of DES encryption). This requires some changes in the structure of the marshalling code generated by ISC. Most importantly, it is necessary to in-line the marshalling functions that handle the components of a composite type (e.g. a struct type) into the marshalling function that handles the composite type. Figure 13 shows an example of the relation between marshalling and two other data manipulation functions, namely checksum and encryption. C data representation

memory marshalling

unmarshalling

checksum encrypt

checksum decrypt

registers/ cache memory memory

Network Data Representation

Figure 13. Integration of (un)marshalling routines and data manipulation

The marshalling operation reads the data to be marshalled from the main memory into registers or cache memory, performs the marshalling operations and stores the * An easy addition to the initial set of data manipulation functions handled by ISC is computing the signature of a message for authentication. Data compression functions are more difficult to integrate, because they change the size of the application data. An example are the functions used by multimedia applications, e.g. the conversion between a local image format and JPEG. However, these functions often require so much CPU time that the usefulness of integrating them into an ILP loop is questionable.


marshalled data into a register. All data manipulation functions following the marshalling function read the marshalled data from this register. Only the last function data finally writes the register content into the destination memory. Received data is read into the registers, the data manipulation functions are performed, and finally, the unmarshalling operation writes the unmarshalled data into the destination memory. The original ISC compiler generated marshalling code starting from an interface specification in C. As it can be seen in figure 14, from a user point of view, the changes in ISC due to the generation of ILP code are minimal. In addition to the standard input to a stub compiler, the user has to provide the file IF_ilp.h that contains macro definitions for the data manipulation functions that should be integrated into the marshalling functions. ISC/ILP then generates enhanced marshalling functions containing calls to the data manipulation macros at appropriate places. Note that when ISC/ILP is used within the ALFred framework, the C modules are generated by the ALF compiler data description using annotated C

macro include file IF_ilp.h


(un)marshalling procedures

C compiler

(un)marshalling object code

Figure 14. ILP enhancement of the INRIA Stub Compiler (ISC)

5.1.2. Implementation of ILP Marshalling Procedures In this section, we show how ISC integrates marshalling code with other data manipulation functions. The following code excerpt demonstrates the general structure of the original marshalling code generated by ISC: *write_ptr++ = f(*type_ptr);/

36


In this example, f() is a marshalling routine, write_ptr is a pointer to a 32-bit word in a network data buffer, and type_ptr is a pointer to the application data value that is marshalled. From this excerpt it can be seen that marshalling works in principle by writing the marshalled value into the network data buffer, and then incrementing the pointer to the buffer. The following code excerpt shows how this code can be extended to an ILP routine: intreg = f(type_ptr); data_manipulations_send(intreg,write_ptr,ilp_var); write_ptr++; We see that after marshalling a 4-byte word, the result is written into the register intreg and not into main memory as with the original marshalling code. Then, a macro call is inserted that processes the value stored in the register. The macro which we will refer to as ILP loop body performs all data manipulation functions except for marshalling, and writes the final result into the network data buffer..

5.2 The ILP Configuration Tool 5.2.1. Overview Two problems occur when integrating several data manipulation functions into an ILP loop body: • The functions must be integrated in the correct order. • A mismatch between the sizes of different processing units of the data manipulation functions must be resolved. To avoid unnecessary implementation errors, and to speed up the implementation of ILP code, an ILP configuration tool called ILPconfig has been developed for ISC. This tool automatically generates an ILP loop body from a given set of nonintegrated data manipulation functions. figure 15 shows how ILPconfig blends in to the overall architecture of ISC/ILP. This tool has for input a file containing a configuration description (IF_ilp.cfg). For each data manipulation function to be integrated into the ILP loop body, IF_ilp.cfg contains specifications of several parameter values such as the order and the processing unit sizes of the data manipulation functions. These specifications are written in a simple configuration language that is defined in Appendix 5. The ILP configuration tool generates up to three files: • IF_ilp.h contains the two ILP loop bodies, namely data_manipula tions_send and data_manipulations_recv. The actual macros and auxiliary functions are implemented in the files ilp.h and ilp.c.


• common_ilp.h contains a definition of a data structure for internal purposes and for variables and results required by the different data manipulation functions. Furthermore, it contains a routine for initializing variables of the defined data structure. It may also contain the data structure which is common to all processed input files, in the case that the configuration tool is used for different input files. The file IF_ilp.h can be used directly by the marshalling routines generated by ISC. The developed configuration tool simplifies ILP programming further. It is sufficient for the user to describe the data structures using the annotated C language and the configuration of the data manipulations within the ILP loop body.

data description using annotated C

ILP loop body configuIF_ilp.cfg ration description


(un)marshalling procedures

application dependant

ILP configuration tool

include files

IF_ilp.h common_ilp.h

macro and function library

C compiler

(un)marshalling libraries

}

ilp.o

Figure 15. ILP Compiler and ILP Configuration Tool

ilp.h ilp.c

}

predefined

38

6


ALF and ILP compilers in the ALFred Framework

The relation between the ALF and ILP compilers is done through the specification of the NDUs (Figure 1). As explained in Section 4.2, the NDUs represent the information transmitted over the network and their description is generated by the ALF compiler in a NDU specification file. This file is then taken as input by the ILP compiler which produces the stub routines achieving all data manipulations in one only loop. The data manipulations (checksum, encryption...) to be applied on all the NDUs are described in a NDU configuration file (cf Section 5.2). The NDU configuration file is the union of the ADU configuration file written by the application designer and the configuration file giving the data manipulations for the control information. The interaction between the control automaton and the stub routines within the execution environmment (Figure 16) is achieved by the Input and Output Events Collectors. USER User Commands

User Commands

Automaton Control (Synchrone)

NDU Output Events Collector

Stub Routines

User Commands Input Exceptions Cntl ADU

Events Collector

ILP loops

NDU

NDU NETWORK

Figure 16. Execution Environment

The incoming NDUs are received by the Input Events Collector which unmarshalls the NDUs and applies the ILP loop processing by calling the routine. ilp_receive__ndu (). Then the Input Events Collector analyzes


the contents of the ilp result structure and generates the appropriate signal towards the automaton. If the values of one or more data manipulation results differ between sender and receiver, an error value is returned. This value contains the number of the lowest level where the results differ. Presently, in case of errors,the NDU is not delivered to the automaton and is considered as lost. But it could be envisaged that some ILP errors have to be signaled to the application like some keys problems during the un-encryption. The outcoming NDUs are sent by the automaton through an emit statement to the Outpout Events Collectors which marshalls the NDU and applies the ILP loop processing by calling the routine ilp_send__ndu (). If something wrong happens during the ilp processing, the automaton has to be stopped. The main reasons are indeed either a programming error or a memory problem For further details about the ilp routines, refer to the Appendix 5.

40

7


Prototype Evaluation

To evaluate ALFred, a client-server based JPEG [Wallace90] image player has been implemented. The client is a menu based program that allows interaction with a user. The user can request an image to be displayed, abort an image transfer, or exit the program. The JPEG image is decomposed into a set of ADUs (Application Data Units) that can be received and processed out of order. However, the quantization and Huffman tables must be transferred in order from the server to the client prior to the main image transfer. Image related ADU can be transmitted and delivered out of sequence. In other words, the level of reliability required for the tables is different from the rest of the image. Two versions of this application have been implemented: • A hand-coded version based on ALF (called ALF) that runs over its own protocol. This protocol (called TPALF) is a user-level protocol that runs over UDP/IP. It was modified from the 4.3BSD TCP implementation. The main changes were to allow out-of-order processing of incoming data and to handle ADUs as opposed to streams packets. • An automatically generated version using ALFred. The automated implementation is generated in two steps. Firstly, the application specification of the JPEG server is translated into its integrated specification using the parser described in section 4. In the second compilation step, the intermediate ESTEREL specification is processed by the ESTEREL compiler to produce C code. This C code accesses C modules that describe the application and its data structures. These modules were written by the application programmer. The protocol function calls inserted by the parser are accessed from a protocol library that is currently being developed. Finally the executable for the JPEG server was created by using a C compiler to compile and link all the modules together. The ESTEREL version of the JPEG player runs directly over UDP/IP. Three issues concerning the automated JPEG player implementation can be analyzed.

7.1 The design issue The automated approach improves the flexibility and modularity of ALF based programs. This is best illustrated by an example. In the hand-coded implementation, the TPALF protocol is used during all the life of the application. The TPALF protocol allows out of order delivery of data. This is beneficial during the actual image transfer but goes contrary to design modularity, as the application must understand the protocol and explicitly reorder the JFIF table specifications. The protocol specified by ESTEREL changes during the life of the application, providing ordered delivery for the table specifications, and allowing out of order delivery of the image


ADUs. Thus the application software was not required to implement any communication protocol functionality resulting in an improved software structure. The generalization of this result is that if a protocol is not able to re-configure its functionality during the life of a connection (using ESTEREL or by any other means) then it should be designed to provide a level of functionality somewhere between the highest and lowest levels required during the life of a connection. If the protocol always provides the highest level of functionality, then the benefits of removing protocol functions cannot be exploited when the extra functionality is not required (for example forcing data to be ordered when the application no longer requires it). Always providing a lower level of functionality implies that the application is responsible for the additional protocol functions when required (for example the application must re-order some of the data). This results in poorly structured software. Moreover, the states number of the integrated automaton is less than the sum of the states numbers of automata used for integration. For exemple, the client specification has 5 states and the selected communication modules represent 32 states. After integration, the ESTEREL description including application and communication modules is composed of 12 states.

7.2 The performance issue In the table 3 we compared the execution speed between the code generated by the ESTEREL compiler and the handcoded code. Experiments were carried out on a local Ethernet network and on a local FDDI network at INRIA Sophia Antipolis. Experiments were performed using Sun20 workstations running Solaris (the average value of 200 measures is given). The throughput represents the amount of compressed image data divided by the time spent to transmit it, Over the Ethernet network, the results of the ESTEREL automated implementation and of the handcoded implementation are very similar. Table 3: Throughput between handcoded and ESTEREL versions Ethernet

FDDI

ALF manuel

7,93 Mbits/s

50,02 Mbits/s

ALF/ESTEREL

7,74 Mbits/s

41,13 Mbits/s

It is difficult to conclude because the bottlneck is obviously due to the network. In order to better analyze the impact of the automated version, we run our tests on a FDDI network where the protocol processing is the bottleneck. We observe, then, that the manual implementation gives better results (about 20 %) than the automated

42


version. If the ESTEREL specification allows a better integration of the transmission control into the application, it produces some additionnal functions calls. Every input event (ADU, control packet) involves, at least, three functions calls toward the ESTEREL automaton. [Castel95] has shown that it is possible to optimize the automaton ESTEREL and to produce a resulting code as efficient as the manual implementation. [Castel95] focuses essentially on TCP, and especially, on the TCP input path.

7.3 The code issue ESTEREL produces a code which is comparable in size to the code written in C language as shown in the table 4. client

serveur

handcoded ALF

422 183 octets

106 111 octets

ALF/ESTEREL

433 177 octets

111 844 octets

Table 4: Throughput between handcoded and ESTEREL version The ESTEREL automaton represents only 4% of the whole object code at the client side and 17% at the server side. The automated version gives a protocole more adapted and integrated to the application. In the manual version, the TPALF protocol is implemented as a user-level library containing all functions even those never used either by the client or the server side.


8

Discussion

Based on the automated implementation of the ILP and ALF concepts, this paper shows that a new high performance protocol architecture is desirable for efficient implementation of multimedia applications. We propose to base this efficient protocol architecture on three concepts: • ALF, which is a design principle allowing efficient processing of the application data units; • Automated integration of transmission control facilities tailored to the application requirements. We showed its feasibility in the case of an experiment with a JPEG image player. The situation with ILP is more discutable. It has been shown in previous works [Braun95a] that ILP is only efficient if the data manipulations are inlined, if function calls are avoided, and finally if data processing cost is minimal. Using function calls would cause N function calls for each processing unit with N as the number of different data manipulations. Moreover, experimental results obtained by two of us (Braun and Diot) for a DEC-Alpha CPU indicate that implementing the ILP kernel as a macro may have an adversary effect on the performance of a CPU instruction cache [Braun95a]. While inlining reduces the number of CPU instructions executed by the ILP code, it may significantly increase the number of instruction cache misses of the code. The cache miss ratio is, however, is another important factor influencing the execution speed of a program on a RISC processor. It appears that the increased number of instruction cache misses due to inlining can completely hide the performance benefit of the lower number of data cache misses due to the use of ILP. Finding an inlining strategy for ILP code that optimizes both the cache miss ratio and the instruction count is thus subject of future work. It has been demonstrated too in this report that the automated integration of transmission control functions in an application formal specification is possible in practice. Performance results confirm that, in term of code organization, size, and efficiency, the automated approach is almost as efficient as the hand-coded approach. Using this approach, a completely automated and efficient implementation of distributed applications is possible. We are now working to a second prototype of the ALFred compiler that will be an enhanced version of the one designed in this document on many aspects: • Protocol tailoring will be improved from experiment results and also from other research results. New functionalities will be added, as well as new control mechanisms (access control, congestion control, etc.). • ALFred will be extended to serve a larger range of applications, including multipoint multimedia applications.

44


• The notion of "application adaptivity" will be introduce to the application QoS. This will make possible the automated design of adaptive application using ALFred. Adaptiveness will be able to adapt to resources available on the network, even in association with guaranteed bandwidth services. • Operating System dependencies are being analyze to determine what are the OS functions required, and how ALFred can be made independent of the host Operating System (or mostly independent). • Performances of ALFred will be improved. The problem of performance will be analyzed from the code generation aspect, the ALFred overall architecture, and the execution environment including interfaces and real-time kernel support.


9

References

[Abbott93a] M. B. Abbott, L. Peterson. A Language-based Approach to Protocol Implementation. IEEE/ACM Transaction on Networking. Vol. 1, No. 1, February 1993. [Abbott93b] Abbott, M., & Peterson, L. (1993). Increasing Network Throughput by Integrating Protocol Layers. IEEE/ACM Transactions on Networking, 1(4), 600610.October 1993. [Anonymous87] Anonymous. XDR: External Data Representation Standard (Request For Comments 1014). Sun Microsystems. [Anonymous88a] Anonymous. Specification of Abstract Syntax Notation One (ASN.1) (ISO Standard8224). ISO. [Anonymous88b] Anonymous. Connection Oriented Presentation Protocol Specification (ISO Standard8823). ISO. [Anonymous88c] Anonymous. Connection Oriented Presentation Service Specification (ISO Standard8823). ISO. [Anonymous93] The Common Object Request Broker: Architecture and Specification, Revision 1.1 (Manual91.12.1). Object Management Group. [Berry87] G. Berry, P. Couronne, and G. Gonthier. Synchronous Programming of Reactive Systems: An Introduction to ESTEREL. INRIA Research Report No. 647. March 1987. [Berry92] G. Berry and G. Gonthier. The ESTEREL Synchronous Programming Language Design , Semantics, Implementation. Journal of Science of Computer Programming. Vol. 19, No. 2, pp. 87-152. 1992. [Braun95a] Braun, T., & Diot, C. Protocol Implementation using Integrated Layer Processing. In ACM SIGCOMM '95, (pp. 151-161). [Braun95b] T. Braun, C. Diot, A. Hoglander, V. Roca. An Experimental User Level Implementation of TCP. INRIA research report number 2650. September 1995. [Castel94] C. Castelluccia and W. Dabbous. "Modular Communication Subsystem Implementation using a Synchronous Approach". Usenix Symposium on High Speed Networking. Oakland, August 1994 [Castel95]Castellucia, C., Dabbous, W. HIPPCO: A High Performance Protocol Code Optimizer. INRIA Research Report No. 2748. December 1995 .

46


[Centaur95] Centaur 2.0 manual, INRIA, CROAP project, 1995. [Chrisment94] I. Chrisment. "Impact of ALF on Communication Subsystems Design and Performance". Proceedings of the First International Workshop on High Performance Protocol Architectures 94. December 1994. Sophia Antipolis. [Clark89] D. D. Clark, V. Jacobson, J. Romkey, H. Salwen. An Analysis of TCP processing Overhead. IEEE communications. 27(6). pp. 23-29. June 1989. [Clark90] Clark, D., & Tennenhouse, D. Architectural Considerations for a New Generation of Protocols. In ACM SIGCOMM '90, (pp. 200-208) [Corbin90] Corbin, J. (1990). The Art of Distributed Applications. 1990: Springer. [Dabbous92] W. Dabbous et al. Applicability of the Session and the Presentation Layers for the Support of High Speed Applications. Technical Report Number 144. INRIA. October 1992. [Dabbous93] W. Dabbous and C. Huitema. XTP Implementation under UNIX. Research report No. 2102. INRIA. November 1993. [Dabbous94] W. S. Dabbous. High Performance Transport and Presentation Mechanisms for Integrated Communication Subsystem. Proceeding of the 4th IFIP workshop on Protocols for High Speed Networks. Vancouver. August 1994. [Diaz95] M. Diaz, K. Drira, A. Lozes, and C. Chassot. On the Definition and representation of the Quality of Service for Multimedia Systems. Proceedings of the IFIP High Performance Networking Conference. Palma (Spain). September 1995. [Diot94] C. Diot, R. de Simone and C. Huitema, "Communication Protocol Development using ESTEREL". First International HIPPARCH workshop. INRIA Sophia Antipolis. December 15-16, 1994. [Diot95] Diot, C., Chrisment, I., & Richards, A. Automated Implementation of Distributed Applications. Proceedings of the 5th IFIP HPN ’95. Chapman&Hall. September 1995. [Druschel93] P. Druschel, L. Peterson. Fbufs, a High Bandwidth Cross-domain Transfer Facility. Proceeding of the 14th ACM symposium on Operating Systems Pinciples. December 1993. [Gunningberg91] P. Gunningberg, C. Partridge, T. Sirotkin, and B. Victor. Delayed Evaluation of Gigabit Protocols. Proceedings of the second MultiG Workshop. June 1991.


[Hennessy90] Hennessy, J., & Patterson, D. (1990). Computer Architecture: A Quantitative Approach. Palo Alto: Morgan Kaufmann Publishers. [Hoschka94] Hoschka, P., & Mazziotta, S. Introducing ISC: the INRIA stub compiler (Internal Working Report). INRIA-Rodeo, September 1994. [Huitema95] Huitema, C. The Mavros homepage (URL:http://www.inria.fr/rodeo/ personnel/huitema/mavros-home.html). [Mazziotta93] Mazziotta, S. Specifications d'interfaces pour la distribution d'applications existantes (Interface specifications for distributing existing applications) (M.S. Thesis, University of Nice-Sophia Antipolis, 1993). [Nelson81] B. J. Nelson. "Remote Procedure Calls". ACM Transactions on Computer Systems. May 1981. (Also PhD thesis, CMU-CS-81-119). [Oeschlin94] P. Oeschlin and S. Leue. "Enhancing ILP using Common Case Anticipation and Data Dependence Analysis. First HIPPARCH workshop. INRIA Sophia Antipolis. December 15-16, 1994. [OMalley90] S. O’Malley and L. L. Peterson. A Highly Layered Architecture for High Speed Networks. Proceedings of the IFIP workshop on Protocols for High Speed networks. Palo Alto (CA). 1990. [OMalley94] O'Malley, S., Proebsting, T., & Montz, A. USC: A Universal Stub Compiler. In ACM SIGCOMM '94, (pp. 295-307). [Parrington94] Parrington, G. A Stub Generation System for C++ (Technical Report 65). University of Newcastle, BROADCAST Project (URL:http://arjuna.ncl.ac.uk/ arjuna/papers/stubgen-c++.ps) . [Partridge93] C. Partridge and S. Pink. A Faster UDP. Submitted to IEEE Transaction on Networking. [Pehrson92] B. Pehrson, P. Gunningberg and S. Pink. Distributed Multimedia Applications on Gigabit Networks. IEEE Networks. Vol. 6 No. 1. January 1992. [Plagemann92] T. Plagemann, B. Plattner, M. Vogt, T. Walter. "A Model for Dynamic Configuration of Light-Weight Protocols" Proceedings of the third workshop on FTDCS. Tapei. Taiwan. pp. 100-110. April 1992. [Reid93] Reid, I. RPCC - A Stub Compiler for Sun RPC. In USENIX Summer '93, (pp. 357-366).

48


[Richards95] A. Richards. The Universal Transport Service, an Adaptive end-toend pPotocol Analysis and Design.. PhD thesis. University of Technology of Sydney. Australia. July 1995. [Roca96] V. Roca, T. Braun, and C. Diot. Design of Efficient Communication Architectures for Open Systems. Draft paper to be submitted. Available on request to one of the authors. Sophia Antipolis. 1996. [Schmidt93] D. Schmidt, B. Stiller, T. Suda, A.N. Tantawy, and M. Zitterbart."Language Support for Flexible, Application-Tailored Protocol Configuration". Proceedings of 18th conference on Local Computer Network. 1993. [Wakeman92] I. Wakeman, J. Crowcroft, Z. Wang, and D. Sirovica. Layering Considered Harmful. IEEE Networks. January 1992. [Zahn90] Zahn, L., Dineen, T., Leach, P., Martin, E., Mishkin, N., Pato, J., & Wyant, G. (1990). Network Computing Architecture. Englewood Cliffs: PrenticeHall.


10 Appendix List of the Appendix: Appendix 10.1: The parser manual Appendix 10.2: ALF Parser: Signal Naming Appendix 10.3:Verification using ESTEREL environment Appendix 10.4ISC-ILP User manual Appendix 10.5ILPconfig User manual Appendix 10.6Communication module interfaces Appendix 10.7Integrated specification interface

50


10.1 Parser Manual The ALFred Parser runs under CENTAUR [Centaur95], a language designer tool. We assume in this section that the Centaur environment and the ESTEREL environment are correctly installed. Both environments can be licenced for free to no profit (academic) organizations. 10.1.1. Parser configuration As the Parser uses a modified ESTEREL version, the easiest way to configure CENTAUR is to backup your ~/contrib/ESTEREL directory and to make a link to ~/ lgautier/contrib/ESTEREL. cd ~/contrib mv ESTEREL .ESTEREL.org ln -s ~lgautier/contrib/ESTEREL . In addition, if you would like to run CENTAUR under Solaris, you have to add the following lines to your ~/.centaur.rdb file: centaur*font: -*-*-*-r-*-*-15-*-*-*-*-*-*-* Centaur.StserverManager.sepia1.Host: where is the name of a Sun workstation under sunOS4. Then, you need to access the Parser tools. They are available in the ~lgautier/parser/ bin directory. So add it to your path: (ksh)$PATH=$PATH:~lgautier/parser/bin (tcsh)%set path=($path ~lgautier/parser/bin) That should be enough to have your Parser environment ready. In case of unexpected problem, please contact [email protected]. 10.1.2. Naming conventions The ALFred protocol compiler creates many intermediate files between the ESTEREL application specification and the final executable program. It is time to define the conventions used for the file naming. The original ESTEREL specification is composed of the client and the server parts. The files containing this specifications must be named as following: Client side:.cl.strl Server side:.svc.strl


A first intermediate file is created before the Parser is called. It contains the original specification together with the ALFred ESTEREL libraries (communication modules): Client side:CL_.strl Server side:SVC_.strl These files are used by the Parser to generate the ESTEREL integrated specification, which names are the following: Client side:CL__pars.strl Server side:SVC__pars.strl From the integrated specification files, you can obtain the "mauto" files: Client side:CL_.ec Server side:SVC_.ec and the "atg" files with "fc2" format: Client side:CL_.fc2 Server side:SVC_.fc2 We see next how to obtain all this different files in the next chapters. 10.1.3. Using the Parser First you have to create the intermediate files containing the ESTEREL specification together with the ALFred ESTEREL libraries. To do that, run the following commands: Client side:apmake CL_.strl Server side:apmake SVC_.strl Note that your original ESTEREL files should be named ".cl.strl" and ".svc.strl". Once these temporary files are created, you can use the Parser in the CENTAUR environment. First, run Centaur: centaur The Centaur menu appears:

52


Open an editor by selecting Editor in the View pulldown menu:

The editor view appears. You will load your client and server specifications separately in this Editor window. The procedure is the same for either the client part or the server part, so only the client specification will be used in the following examples. Load the specification in the Editor by selecting Read in the File menu:

Then enter the name of the intermediate specification file in the query box:

If your specification do not load, you have made one or more syntax errors. Correct your specification and try again. Notice that you can use parallel the ESTEREL


compiler on the original specification to test its syntax. You must also use carefully the ";" symbol. The Parser understand it like a sequential operator: do not place any ";" at the end of sequential instructions lists. If errors occur anyway, you surely have made an error in the annotations (cannot be detected by the ESTEREL compiler). When the program is loaded, you run the Parser by selecting the "Parser" item either in the ALFred menu or in the popup menu obtained by handling the right button of your mouse:

As everything goes well, the result editor view appears with the integrated specification within between few seconds or few minutes, depending on your work station. If any problem occurs, check your original specification again to fix it.

54


Once you have your integrated specification, you have to save it. Choose the "write" item in the file pulldown menu:

Following the name conventions, the integrated specification file name must be:

The Parser work is now finished. Then you can analyzes your integrated specification, or more precisely, its finite state machine. You can use a finite state machine analyzer like "mauto" or whatever you prefer. Moreover, you can visualize the corresponding graph with "atg" for example. The "apmake" command provides some useful functions to help you generating "mauto" and "atg" files. To get the ".ec" mauto file, enter the following commands: Client side:apmake CL_.ec Server side:apmake SVC_.ec To get the ".fc2" format atg file, enter:


Client side:apmake CL_.fc2 Server side:apmake SVC_.fc2

56


10.2 ALF Parser: Signal Naming 10.2.1. Signal type definitions The modules and the signals used in those modules are hardly related, so we can define the following levels for the signals: 1.Application signals: These signals are linked to the application, that means they can be used in every modules. Abort and Quit are application signals. 2.Flow signals: These signals are linked to a specific flow. They are used in the flow modules and ADU modules dependant of this flow. 3.ADU signals: These signals are linked to a specific ADU and also to the related flow. They can only be used in the ADU modules. The remote_ signals are ADU signals. These levels allows the parser to associate all the modules signals with their related flows and ADUs. Relations between module levels and signal levels

Application level modules a

a

a Modules of flow A f a a f Modules of remote signal 1 r f a a f r

a

a a

f a

f a

Modules of flow B f a a

f

Modules of remote signal 2 r f a

Application level signals Flow level signals ADU level signals

Communication module

All the signals used in the modules must be redefined in the integrated specification.


There are three places where the signals can be defined. Here are these signal domains: 1.External signals: These signals are used for the input and output of the integrated specification. They are defined as input or output in the ESTEREL declarations. The network signals and control signals are external. 2.Global signals: These signals are used for the communications between the application part and the transmission part of the integrated specification. They are defined with the signal Esterel keyword. 3.Local signals: These signals are used only for the communication between local modules associated with the same flow. Signals areas 10.2.2. Signals naming

Integrated specification Global modules area

Local modules area Transmission part

Application part g e

e

User interface l g e

Intern local signals Intern global signals Extern signals

l g e

g e

e

Network interface

Communication module

The signals used in the protocol modules are renamed in the integrated specification in order to avoid the use of one signal name for different ADUs or flows. Here are the prefixing rules to apply, listed by domain and by level: 1.External signals:

58


1.1Application level: Signals used by the user to control the transmission: Prefix to apply: "user_" examples: user_Quit, user_Abort 1.2Flow level: Signals that are transmitted over the network: Prefix to apply: "r_" Signals for the transmission control Prefix to apply: "ctrl_" examples: timer control "ctrl_timer_start" 1.3ADU level: ADU signals defined by the user like "remote_" Prefix to apply: "ADU_" Signals that are transmitted over the network: Prefix to apply: "rADU_" 2.Intern global signals: 2.1Application level: Not implemented. 2.2Flow level: Prefix to apply: "tg_" 2.3ADU level: Prefix to apply: "gADU_" 3.Intern local signals: 3.1Application level: Not implemented. 3.2Flow level: Prefix to apply: "tl_" 3.3ADU level: Prefix to apply: "lADU_" A summary of the signal naming conventions is found in the annexe B.


10.3 Verification Using ESTEREL environment As part of the HIPPARCH project, a prototype compiler is being developed for the automatic generation of communication systems based on the design principles of ALF/ILP [Clark90]. The prototype compiler takes the specification of a client/server application written in a formal specification language and produces an efficient implementation in C. In the first phase of HIPPARCH, the specifications of the client/server applications were specified independently using an annotated version of the formal specification language ESTEREL. Because the client and server were specified independently, the verification process consisted only in verifying local behavior. Global behavior of the application was not verified because there is no verification tool that permits verification of the parallel composition of two or more independently specified ESTEREL specifications. Given that verification of local properties is not sufficient, we propose here a new model which is adequate for the verification of properties related to the global behavior of the system. 10.3.1. Prototype Compiler Before introducing our model for verification, we give a short description of the prototype compiler which will help the reader understand some of the particular issues we must deal with. Figure 1 shows the compilation process from an application specified in Annotated ESTEREL to the implementation in C. The compilation is performed in two distinct phases. First, Annotated ESTEREL is transformed into standard ESTEREL and second, standard ESTEREL into C. Annotated ESTEREL has a set of keywords that specifies the nature of the underlying communication protocol. The Annotated ESTEREL compiler uses these keywords to integrate the appropriate set of end-to-end transmission control modules to the application specification. After the integration of the transmission control modules, the resulting specification is compiled using the standard ESTEREL compiler. The standard ESTEREL compiler integrates transmission control and user-defined functions to produce the complete C implementation.

60


Annotated Esterel

Client

Annotated Esterel Compiler

Standard Esterel

Server

Esterel Transmission Control Modules

Integrated Client

Standard Esterel Compiler

Annotated Esterel Compiler

Integerated Server

C functions - communications - user-defined

C implementation

Standard Esterel Compiler

C implementation

Figure 17. From Annotated ESTEREL to C

10.3.2. Communicating Processes in ESTEREL A major concern for the design of a new model is the specification of a realistic communication mechanism between client/server. Previously, client/server communication was modeled by standard ESTEREL signals which are based on instantaneous broadcasting. Unfortunately, instantaneous broadcasting is not an appropriate model for communication between remotely located processes because it is not possible to serialize their execution. A new programming paradigm called Communicating Reactive Processes (CRP) that unifies the capabilities of asynchronous and synchronous concurrent programming languages has been introduced. Unfortunately, the version that implements CRP channels is no longer compatible with the current version of ESTEREL. Instead, we specify a simple synchronous rendez-vous mechanism using basic ESTEREL constructs and for each CRP-like channel, we specify a separate module. This approach is less general than the CRP model. For example, rendez-vous are


atomic operations, i.e. exceptions during the process of a rendez-vous cannot be raised. Below, we present a simple example of the communication between a receiver and a network. In this example, a single rendez-vous is performed to exchange a message from the network to the receiver. The network may delay the message indefinitely before handing it to the receiver. This is accomplished by awaiting on the external input signal Deliver_message. The specification is close to a realistic model of communication where await Message_for_you is a blocking receive which assumes that the network will deliver Message once Message_for_you has been broadcasted. 10.3.3. Verification Model We solve verification of global properties by integrating the client and server modules within a single ESTEREL specification. Communication between client and server is accomplished by the CRP-like channels presented in section 3. All CRP-like channels are embedded within a single module which we call the network module. The characteristics of the channels are deduced from the set of keywords present in the client/server specifications. These keywords specify characteristics of the communication such as messages being delayed, lost, duplicated, reordered, etc. [isabelle]. With this new model, we can split the verification process in two practically independent parts: • Application Level Verification: verification of application assuming correct behavior of the transmission control modules. • Communication Level Verification: verification of transmission control modules according to all possible set of keywords of Annotated ESTEREL. Although the specifications of the client and server are integrated for verification purposes, the compilation process from Annotated ESTEREL to C will differ only slightly. In the new version of the Annotated ESTEREL compiler, the compiler will start by extracting the client and server specifications from the integrated specification. The remaining parts of the compilation process remain unaffected. Application Level Verification For verification of the correctness of an application, the application developer only needs to be concerned with a partial view of the system (see figure 2). The application developer supplies the client/server specifications and determines which network module is appropriate. For practical purposes, a library of network modules should be provided to the user for each possible set of keywords. The keywords of Annotated ESTEREL guarantee a specific behavior of the underlying communication protocol. In this context, the developer can abstract away from communication

62


details and rely solely on the network model to specify his application and verify desired properties. Server in Annotated Esterel

Client in Annotated Esterel

Rendez-vous Client - Network

Rendez-vous Server - Network

Network Module specified by keywords in Client/Server Specifications

Figure 18. Verification Model for an Application

Verification of the Communication Library For the verification performed by the application developer to have any meaning, the ESTEREL communication library must specify a unique and non-ambiguous protocol for an arbitrary set of keywords specified by the application. Verification of the transmission control modules is similar to the verification of an application. Given a set of transmission control modules, we insert a network module and verify that for arbitrary messages, the transmission control modules have the proper functionality. In this case, the model of the network must be as close as possible to the behavior of a real network. That is, the network model must include messages being delayed, lost, corrupted, duplicated, etc. The generality associated with the unpredictable behavior of a network makes the verification task very difficult. Fortunately, verification of the transmission control modules can be performed once and for all by the designers of these modules.


Keywords of Annotated Esterel

Transmission Control Modules Client

Transmission Control Modules Server

Network Model

Figure 19. Verification Model for Communication Modules

64


10.4 ISC-ILP User Manual 10.4.1. Input File To generate marshalling stubs, ISC scans the input file for constructs relevant to marshalling stub generation. A stub will be generated for each type definition and each declaration of a structure type in the input file, i.e. for all constructs of the form typedef ; and struct ; In the following, we will uniformly refer to both of these constructs as type definitions. We are still experimenting with the annotation language, in order to find a good balance between ease of use and ease of implementation. The current version of the language was defined in [Mazziotta93]. In the meantime, the annotation language was found to be useful for practical purposes, e.g. for annotating the C header files of the JPEG demonstration application used in the HIPPARCH project [Diot95]. 10.4.2. Annotations Adding Type Semantics •OCTETSTRING(stringname,lengthname): indicates that the length in bytes of stringname is contained in lengthname. stringname is the name of a struct field of type char *. lengthname is the name of a struct field of type int. In the current version of ISC, both fields must be contained within the same struct definition. Example: typedef struct _os { char *ch; OCTETSTRING(string.ch, string.lg) int lg; } string; •LIST(arrayname,length): indicates that length contains the current length of arrayname. Example: typedef struct _foo { int nb; int a[10]; LIST(foo.a,foo.nb) } foo;


•CHOICE(unionname, discriminator): indicates that the field discriminator serves for distinguishing between different alternatives for the type of the field unionname. In the current version of ISC, length has to be a field name in the struct containing arrayname. Example: typedef struct _s { union _u { int a; char b; X c; } u; CHOICE(s.u,s.index) int index; } s; •IGNORED(fieldname) This IGNORED annotation indicates that no marshalling code should be generated for fieldname, which is a struct field. Example: typedef struct _s { int a; private b; IGNORED(s.b) } s; •BOOLEAN(typename) The BOOLEAN annotation indicates that typename is used as a boolean type. This is irrelevant for the XDR network data format currently used by ISC. It is important, however, for other network data formats such as the Packed Encoding Rules (PER) that represent boolean types as 1-bit values, and not as 32-bit values (resulting in a more compact network data representation). A code generator for PER may be added in a future version of ISC. Example: typedef int bool;

BOOLEAN(bool)

10.4.3. Annotations Controlling Modularity Annotations controlling modularity deal with the issues introduced by include files. These are text files that are included into the C source file by a preprocessor (cpp) before the file is passed to the C compiler. An include file usually contains type definitions that are referenced by the types defined in the C header file passed to ISC. Marshalling code must thus not only be generated for types contained in the application’s C header file, but also for any type defined in an include file that is referenced by one of the types in the application header file. The following annotations are defined to handle include files:

66


•EXPORT(type1, type2, type3, ...): generate marshalling routines only for the type definitions whose names are contained in the list of type names following the EXPORT annotations. If the input file does not contain an EXPORT directive, marshalling code is generated for all type definitions in the file. • IMPORT(type, filename) This macro imports the definition of type from the include file filename. filename must contain the specification of the path in the UNIX file system. A missing import annotation will result in an error message of ISC. Import annotations do not, however, trigger the generation of marshalling code for the imported type. Generating this code requires to also execute ISC on filename. Example: typedef struct _s { int a; foo b; IMPORT(foo,/usr/include/x.h) } s; The exact handling of include files in ISC is left for further study. The currently implemented solution is unsatisfactory. Therefore, we recommend to create a new header file containing all type definitions relevant for marshalling when the types for which marshalling code should be generated are distributed over several header files. 10.4.4. Defining Integrated Data Manipulations (IF_ilp.h) The file IF_ilp.h must contain definitions for the following two macros: •#define data_manipulations_send(intreg,dst,ilp_var) {} This macro contains the code for the data manipulation functions that should be integrated into the coding routines The parameter intreg is the 4 byte register variable containing the marshalled value. dst is the address of the 32-bit word in the memory buffer containing the data in network format. The parameter ilp_var is a variable used for internal purposes by the data manipulation routines. For example, when the message contains several checksum processing units, the checksum value after marshalling checksum processing unit N is stored in ilp_var, so that it is accessible when computing the checksum for the checksum processing unit N+1. •#define data_manipulations_recv(src,intreg,ilp_var) {}


This macro contains the code for the data manipulation functions that should be integrated into the decoding routines. src is the address of the next 32-bit word that has to be manipulated in the memory buffer contain the message in network data format. The parameter intreg is the 4 byte register variable into which the value is written after all data manipulations functions have been processed. The marshalling function will read its input from intreg. The parameter ilp_var is a variable that is used for internal purposes by the data manipulation routines, as explained for the data_manipulations_send macro. ilp_var contains any additional fields required by the data manipulation functions. It must be defined within IF_ilp.h in the following form: typedef struct ILP_VAR_TYPE{ ... } ILP_VAR_TYPE; It is possible to execute different data manipulations for different header files by defining individual IF_ilp.h include files for each header file. However, the data manipulations are the same for all data types defined within an annotated C file. Different data manipulations for several data structures contained in a single annotated C file could be supported by additional annotations describing which kind of data manipulations should be processed after (before) (un)marshalling the data structure. This is a subject for future work. 10.4.5. Application Programming Interface The encoding and decoding functions for a type definition named TYPE have the following interfaces: •(int *) TYPE_xdrc(ILP_VAR_TYPE *ilp_var, int *dst, TYPE *src); The function TYPE_xdrc takes three parameters. ilp_var is a pointer to a global variable containing the values for internal variables of the integrated data manipulation functions*. dst is a pointer to a contiguous memory buffer of 32bit words into which the data should be written after all data manipulation func* It is not yet clear whether it is really necessary to pass ilp_var at each procedure call. The potential disadvantage is an increase in the procedure call overhead due to an additional parameter. The alternative is storing the value of ilp_var in a global variable instead. The disadvantage of using global variables commonly cited - the difficulty of maintaing the code - does not apply to the code produced by ISC, since it is automatically generated, and thus never "maintained" by a human programmer.

68


tions have been processed*. src is a pointer to the variable value that should be marshalled. The function returns a pointer to the 32-bit word in dst immediately following the last word written into the dst buffer. •(int *) TYPE_xdrd(ILP_VAR_TYPE *ilp_var, int *src_start, int *src_end, TYPE *dst); The function TYPE_xdrd takes four parameters: ilp_var is a pointer to a global variable containing the values for internal variables of the integrated data manipulation functions. src_start and src_end are pointers marking the beginning and end of a contiguous memory buffer of 32-bit words containing the value to be decoded. dst is a pointer to the variable into which the decoded value should be written. The function returns a pointer to the word immediately following the last decoded word in the receive buffer, i.e. to src_end+1. 10.4.6. Example Use First, the application programmer has to define the data structure to be marshalled. We use the following variable length string type as an example: string.h.anno: typedef struct _string { unsigned int length; char *buffer; OCTETSTRING(string.buffer, string.length) } string; The annotation OCTETSTRING is used to describe which component contains the string length value. Then the user calls ISC with string.h.anno as input file. ISC generates three different files: an include file with the C type to be used by application programs (string.h), a file containing the marshalling routines for the string type (string_xdrc.c) and a file containing the unmarshalling routines (string_xdrd.c). string.h: typedef struct _string { unsigned int length; char *buffer; } string; string_xdrc.c: * Note that the code assumes that int types are 32-bit values.


int * string_xdrc(ilp_var,asn1z,x) ILP_VAR_TYPE *ilp_var; register int *asn1z; string * x; { #ifdef ILP register int intreg; #endif {int l,l0; /* marshalling of the length information */ l=(*x).len; #ifdef ILP ASN1_INTXDR(intreg1,(*x).len);/* store marshalling result in register */ data_manipulations_send(intreg,asn1z,ilp_var);/* ILP data manipulations*/ #else ASN1_INTXDR(*asn1z,(*x).len);/* marshalling and write result directly */ #endif asn1z++; /* marshalling of the variable string*/ #ifdef ILP {int n; for(n=0;n>2);n++) {intreg=*(((int*)((*x).s))+n);/* read 4 bytes into register */ /* ILP data manipulations*/ data_manipulations_send(intreg,asn1z+n,ilp_var); } } #else ASN1_MOVE((*x).len,(char *)asn1z,l);/* copy string to destination */ /* memory*/ else #endif if ((l%4)!=0) *asn1z & tab_pad[l%4]; asn1z+=(l+3)>>2;} return(asn1z); } string_xdrd.c: int * string_xdrd(ilp_var,asn1z,asn1zm,x) ILP_VAR_TYPE*ilp_var; register int*asn1z,*asn1zm; string * x; { #ifdef ILP register int reg; #endif if (asn1z == 0) return (0);

70


/* marshalling of the length information */ #ifdef ILP /* ILP data manipulations */ data_manipulations_recv(asn1z,intreg,ilp_var); /* store unmarshalling result in register*/ ASN1_XDRINT((*x).len,intreg); #else /* store unmarshalling result directly*/ ASN1_XDRINT((*x).len,*asn1z); #endif /* length check*/ if ((asn1z == 0) || (asn1z+ (((*x).len+3) >> 2)+ 1>asn1zm)){ fprintf(stderr,"\nlength problem\n");return (0);} asn1z++; #ifdef ILP { int n; /* ILP data manipulations*/ for(n=0;n>2;n++){ data_manipulations_recv(asn1z+n,intreg,ilp_var); asn1z[n]=intreg;} } #endif (int *)(*x).s=asn1z; asn1z+=((*x).len+3)>>2; return(asn1z); } We see that the ILP loop bodies are embedded within #ifdef - #endif statements. This allows to decide whether or not the ILP extensions shall be executed or not at the time the C code is compiled. This can be done by defining or “undefining” the macro name ILP.


10.5 ILPconfig User Manual 10.5.1. Configuration Language To specify the desired ILP loop body for sending and receiving data, a simple ILP configuration language has been developed. This language prevents the application programmer from implementing an ILP loop body for each possible combination of data manipulations. Instead, it is only necessary to provide a macro library (ilp.h), which must contain the macros for the different data manipulations specified in a uniform format. If the basic processing unit size of a data manipulation is N*4 bytes, N 32-bit integer registers are required in the parameter list. In addition to these registers, the parameter list may contain parameters, which have to be described in the ILP description using the RESULT and the VARIABLE keywords. #define macro_name(integer1, ..., integerN, parameter1, ..., parameterN) {...} Each data manipulation takes the N registers as input, manipulates them, and substitutes the initial contents by the final result. A complete ILP loop body configuration description consists of a set of several data manipulation functions. Each single data manipulation function is described within a separate block independent of the other functions. Thus, each ILP description (IF_ilp.cfg) contains a block for each data manipulation function that should be integrated into the ILP loop body. The beginning of a block is indicated by the sequence “["blockname"]”. Each block consists of an arbitrary number of assignments. For one data manipulation function there exists exactly one block for both the send and receive data manipulation. description: block {block} block: “[“blockname”]” assignment {assignment} assignment: keyword"="value keyword: "POSITION"|"NEXT"|"MACRONAME_S"|"MACRONAME_R"|"LENGTH"| "VARIABLE"|"RESULT"|"FINAL_S"|"INIT" There are several assignments for each block. Some of them are mandatory and must appear in each block (M). Others are optional, but must appear with a certain

72


value exactly once in a description file (O1) or at most once in a block (O). Finally, there are optional keywords, which may appear arbitrarily often within a block (A). The allowed keywords are shown in Table 1 . Some data manipulation functions may use other parameters that must be initialized before the ILP code is executed (e.g., key tables for encryption). Moreover, the can return their own results (e.g., checksum calculation). To specify additional parameters the VARIABLE and RESULT assignments must be used. VARIABLE=(t_name,v_name,i_value)means that an parameter v_name of type t_name is required. The variable may be initialized with the optional value i_value, which is a constant value. The syntax for the RESULT assignment is quite similar: RESULT=(t_name,v_name,i_value). TABLE 1. Keyword

Explanation

POSITION

O1

POSITION allows to describe whether the data manipulation is on highest level (POSITION=TOP) or on the lowest level (POSITION=BOTTOM). Only the values TOP and BOTTOM are allowed. There must exist exactly one assignment (POSITION=TOP) and exactly one assignment (POSITION=BOTTOM) within a description file.

NEXT

M

pointer to the next lower data manipulation function on the send side.

MACRONAME_S

M

macro name for the data manipulation in the send ILP loop body.

MACRONAME_R

M

macro name for the data manipulation in the receive ILP loop body.

LENGTH

M

length of the basic processing unit size of the data manipulation function. It is assumed that the input processing unit size equals the output processing unit size. The case of different input and output length parameters is currently not supported.

VARIABLE

A

parameter for initializations

RESULT

A

parameter for results

FINAL_S

O

function for final result processing on the send side


TABLE 1. Keyword

Explanation

FINAL_R

O

function for final result processing on the receive side

INIT

O

one-time initialization routine

The data types for VARIABLE and RESULT variables are currently limited to simple types such as scalar types or pointers to scalar types. RESULT variables have been introduced in addition to variable variables to support an advanced protocol architecture for ILP processing, which we will explain in a later section. RESULT variables may be processed after the ILP loop body by special functions. Note that also the following definitions are only necessary to support the advanced ILP protocol architecture as described in Section 1.5. The special functions are defined using the FINAL_S and FINAL_R assignments according to the format FINAL_S=(function1(res_list1), tionN(res_listN)) or

...,

func-

FINAL_R=(function1(res_list1), tionN(res_listN)).

...,

func-

These two functions contain any “clean-up code” required after the execution of the ILP code. They must be implemented in a separate library to be linked to the application program. The input parameters of these functions must match the sequence of their definition in the ILP configuration description. However, the functions expect a pointer value to the specified variable type. A res_list is a list of an arbitrary number of RESULT variables, which must be defined in the corresponding block. The last assignment is the INIT assignment. INIT=initfunction. The function initfunction contains initializations of the internal variable used by the data manipulation functions. This function also allows some initializations, which must be performed only once, e.g. encryption tables at the beginning of an application program. In contrast to the initializations of the RESULT and VARIABLE variables, which are performed for each ILP loop body (e.g., for each packet), the initializations described in initfunction are performed only once. 10.5.2. A Configuration Example The following example shows the use of the ILP configuration tool. Assume that we want to integrate the two data manipulation macros CHECKSUM and ENCRYPTION. The following shows a configuration file for this integration:

74


string_ilp.cfg: [CHECKSUM] MACRONAME_S=tcp_checksum MACRONAME_R=tcp_checksum LENGTH=4 RESULT=(u_int,xsum,0) POSITION=BOTTOM FINAL_S=(TCP_xsum_final(xsum)) FINAL_R=(TCP_xsum_final(xsum)) [ENCRYPTION] MACRONAME_S=safer_encrypt MACRONAME_R=safer_decrypt NEXT=CHECKSUM LENGTH=8 POSITION=TOP VARIABLE=(char*,key) VARIABLE=(u_int*,logtab) VARIABLE=(u_int*,exptab) INIT=safer_ilp_init CHECKSUM uses a RESULT variable with the name xsum of type u_int. This variable is initialized to 0 at the beginning of each ILP loop body. For each ILP loop body the function TCP_xsum_final may perform final processing steps on the result variable. The CHECKSUM data manipulation is on the lowest level of the ILP loop body (BOTTOM). ENCRYPTION is on the highest level of the ILP loop body (TOP). The top level function is performed first for sending and last for receiving, while the bottom level function is performed first for receiving but last for sending. The macros to be used for the ILP data manipulations must be defined in the macro library ilp.h, while the file ilp.c must be used for defining functions for initialization and final result processing. The following shows the content of these files for our example: ilp.h: #define writereg(intreg,dst) *((int *)(dst))=(intreg) #define readreg(src,intreg) (intreg)=*((int*)(src)) #define tcp_checksum(intreg,sum) (sum)+=((intreg)>>16)+((intreg)&0xffff) #define mat1(a1,a2,c1,c2) ((c1)=(a1)+((c2)=(a1)+(a2)))


#define invmat1(a1,a2,c1,c2) ((c2)=(a2)-((c1)=(a1)(a2))) #define safer_encrypt(intreg1,intreg2,key,logtab,exptab){\ register byte8 r0,r1,r2,r3,s0,s1,s2,s3;\ r0 = (byte8) exptab[(byte8)((intreg1 >> 24) ^ key[0])];\ r1 = (byte8) logtab[(byte8)((intreg1 >> 16) + key[1])];\ r2 = (byte8) logtab[(byte8)((intreg1 >> 8) + key[2])];\ r3 = (byte8) exptab[(byte8)(intreg1 ^ key[3])];\ mat1(r0, r1, s0, s1);mat1(r2, r3, s2, s3);\ intreg1 =((((int)s0) 8) + key[6])];\ r3 = (byte8) exptab[(byte8)(intreg2 ^ key[7])];\ mat1(r0, r1, s0, s1);mat1(r2, r3, s2, s3);\ intreg2=((((int)s0)key,key,10); ilpptr->exptab=exp_tab; ilpptr->logtab=log_tab; saferk64_init(ilpptr->key,ilpptr>exptab,ilpptr->logtab); } The file common_ilp.h contains the definition of the internal ILP variable and an initialization procedure for initializations, which are required before each ILP loop body. common_ilp.h: #define ENCRYPTION_ID 1 #define CHECKSUM_ID 2 /*------------------ILP_VAR_TYPE------------------*/ typedef struct _ILP_VAR_TYPE { int counter, error; int buffer0; int *address0; char* key; u_int* logtab;


u_int* exptab; int xsum; }ILP_VAR_TYPE; /*------------------ILP_INIT---------------------*/ #define ilp_init(ilp_ptr){\ (ilp_ptr)->error=0;\ (ilp_ptr)->counter=0;\ (ilp_ptr)->xsum=0;\ } The file string_ilp.h contains the macros for ILP processing to be included into the (un)marshalling routines. The data manipulation macro for sending collects the data in 4 byte steps (the basic unit size of the XDR marshalling routine) and performs the data manipulations for each L bytes (L: lowest common multiple of the processing units of all data manipulation functions). The receive data manipulation macro takes L bytes and delivers the data to marshalling in 4 byte steps. string_ilp.h: #include "ilp.h" #include "common_ilp.h" /*-----------------ILP_LOOP_SEND------------------*/ #define data_manipulations_send(intreg,dst,ilp_ptr)\ switch((ilp_ptr)->counter){\ case 0:\ (ilp_ptr)->buffer0=(intreg);\ (ilp_ptr)->address0=(dst);\ (ilp_ptr)->counter++;\ break;\ case 1:\ (ilp_ptr)->counter=0;\ safer_encrypt((ilp_ptr)>buffer0,(intreg),(ilp_ptr)->key,\ (ilp_ptr)->logtab,ilp_ptr)->exptab);\ tcp_checksum((ilp_ptr)->buffer0,(ilp_ptr)>xsum);\ tcp_checksum((intreg),(ilp_ptr)->xsum);\ writereg((ilp_ptr)->buffer0,(ilp_ptr)>address0);\ writereg(intreg,dst);\ break;\ } /*-----------------ILP_LOOP_RECEIVE--------------*/

78


#define data_manipulations_recv(src,intreg,ilp_ptr)\ switch((ilp_ptr)->counter){\ case 0:\ (ilp_ptr)->counter++;\ readreg(src,intreg);\ readreg(((int*)(src))+1,(ilp_ptr)->buffer0);\ tcp_checksum((intreg),(ilp_ptr)->xsum);\ tcp_checksum((ilp_ptr)->buffer0,(ilp_ptr)>xsum);\ safer_decrypt((intreg),(ilp_ptr)>buffer0,(ilp_ptr)->key,\ (ilp_ptr)->logtab,ilp_ptr)->exptab);\ break;\ case 1:\ (intreg)=(ilp_ptr)->buffer0;\ (ilp_ptr)->counter=0;\ break;\ } 10.5.3. ALFred Application Programming Interface The file IF_ilp.c contains C code for the following two functions. •int *ilp_send_TYPE(ilpresult, buffer, TYPEptr) ILP_RES *ilpresult; int *buffer; TYPE *TYPE_ptr; This function is used for sending ADUs. ilpresult is a pointer to the generated type for storing the ILP data manipulation results. This variable may be initialized by the application program before the ILP code is executed, or read after the ILP code has bee executed. buffer is a pointer to the output buffer to which the marshalled and manipulated data are written. TYPEptr is a pointer to an ADU. The function returns a pointer to the end of the buffer, to which the data has been written during marshalling and data manipulations. •int ilp_receive_TYPE(ilpresult_r,ilpresult_s,buffer,bufferend,TYPEptr) ILP_RES *ilpresult_r; ILP_RES *ilpresult_s; int *buffer; int *bufferend; TYPE *TYPEptr; This function is used for receiving ADUs. The first two parameters of this function contain the data manipulation results. ilpresult_r contains the results calculated at the receiver during unmarshalling and data manipulation. ilpresult_s contains the result calculated at the sender. The next two parameters are pointers to the beginning (buffer) and the end (bufferend)


of the received data. The last parameter TYPEptr is the pointer of the unmarshalled variable. If the values of one or more data manipulation results differ between sender and receiver, an error value is returned. This value contains the number of the lowest level where the results differ. The ILP configuration tool is called by ilpconfig . The extensions are switched on per default. To avoid the extensions ilpconfig single must be called. 10.5.4. An Example for using ALFred ILP_RES.h.anno: /*------------------ILP_RES-------------------*/ typedef struct _ILP_RES { int xsum; }ILP_RES; string_ilp.c: #include "string.h" #include "ILP_RES.h" #include "padding.h" extern int *string_xdrc(),*string_xdrd(); ILP_VAR_TYPE ilpvar; int *ilp_send_string(ilpresult, buffer, stringptr) ILP_RES *ilpresult; int *buffer; string *stringptr; { int *bufferend, lcm; pad padvar; /* ILP loop body for the ADU */ ilpvar.xsum = ilpresult->xsum; ilp_init(&ilpvar); bufferend=string_xdrc(&ilpvar, buffer, stringptr); /* padding */ lcm=8; padvar.length=lcm-(((char *)bufferend)-((char *)buffer)+sizeof(int))%lc padvar.buffer=malloc(padvar.length); memset(padvar.buffer, (char)0, padvar.length); bufferend=pad_xdrc(&ilpvar, bufferend, &padvar); free(padvar.buffer); /* result processing */ TCP_xsum_final(&(ilpvar.xsum)); ilpresult->xsum = ilpvar.xsum; ilp_init(&ilpvar);

80


bufferend=ILP_RES_xdrc(&ilpvar, bufferend, ilpresult); return(bufferend); } int ilp_receive_string(ilpresult_r, ilpresult_s, buffer, bufferend, stringptrILP_RES *ilpresult_r; ILP_RES *ilpresult_s; int *buffer; int *bufferend; string *stringptr; { int *bufferptr, error=0; pad padvar; /* ILP loop body for the ADU */ ilpvar.xsum = ilpresult_r->xsum; ilp_init(&ilpvar); bufferptr = string_xdrd(&ilpvar, buffer, bufferend, stringptr); /* padding */ bufferptr = pad_xdrd(&ilpvar, bufferptr, bufferend, &padvar); /* result processing */ TCP_xsum_final(&(ilpvar.xsum)); ilpresult_r->xsum = ilpvar.xsum; ilp_init(&ilpvar); bufferptr=ILP_RES_xdrd(&ilpvar, bufferptr, bufferend, ilpresult_s); /* error handling */ if (bufferptr == bufferend) error = 0; else error = -1; if (ilpresult_s->xsum != ilpresult_r->xsum) error = CHECKSUM_ID; return(error); } ilp_init_string() { safer_ilp_init(&ilpvar);


10.6 Communication module interfaces We show hereafter how we designed the protocol building blocks. The protocol designer has, firstly, to apply some rules about the signal naming when he writes the modules: 1.the signals used to communicate only between protocol mechanism communication modules are to be prefixed by tl_ 2.the signals used to communicate with modules of the application specification part are to be prefixed by tg_ 3.the signals to be sent to or received from network are to be prefixed by r_ 4.the signals containing an ADU are to be prefixed by rADU_ when the signals have to be emitted to or received from the network or ADU_ otherwise. 5.the signals used to communicate with the user must be prefixed by user_ 6.the signals used to communicate with the execution environment must be prefixed by ctrl_ 10.6.1. Initialization modules .

tg_flow_id

FLOW_OPEN_CLNT tg_flow_ctx

ctrl_svc_addr

FLOW_OPEN_SVC

ctrl_flow_id

Figure 20. Initialization modules Interface

tg_flow_ctx

82


10.6.2. Application QoS management modules

tg_flow_ctx

TX_ORDER

r_ADU-type

tg_seq_NS

r_seq_NS r_seq_NS_ADU

ADU_rcv

rADU_rcv user_Abort

tg_flow_ctx r_seq_NS rADU_rcv

RT_ORDER

tg_seq_NS ADU_rcv

user_Abort

tg_flow_ctx r_seq_NS r_seq_NS_ADU rADU_rcv user_Abort

FIGURE 21. Order modules Interface

RoT_ORDER tg_seq_NS ADU_rcv


tg_flow_ctx tg_seq_NS

CACKLIST_HANDLER

tl_loss

ACKLIST_HANDLER

tl_noloss

NACKLIST_HANDLER

tl_CTRLIST

user_Abort tg_flow_ctx

EMISSION_CTRL

tl_loss tl_noloss tl_CTRLIST

r_send_CTRL

tg_reliable user_Abort tg_flow_ctx tl_retrans_loss

RETRANS ctrl_timer_transmission_start

tl_retrans_noloss tl_retrans_timer

tg_end_SYNC

tg_send_NDU

tg_flow_retrans

tg_begin_SYNC r_ectrl r_cctrl tg_end_transmission user_Abort

Figure 22. Reliability Modules Interface

r_NDUToResesnd

84


.

tg_flow_ctx

SLOW_START

ctrl_timer_transmission_end r_ectrl

tl_retrans_loss FLOW_ONOFF

tl_retrans_noloss

r_cctrl

tl_retrans_timer

user_Abort

tl_flow_ready

Figure 23. Traffic Modules Interface


10.6.3. Synchronization modules

BEGIN_RELIABILITY_TOTAL tg_begin_SYNC tg_is_reliable

BEGIN_RELIABILITY_NONE tg_is_not_reliable END_RELIABILITY tg_end_SYNC

END_RELIABILITY_TOTAL tg_end_transmission

tg_flow_retrans

END_RELIABILITY_NONE

tg_flow_ctx tg_is_reliable

RELIABILITY_STATE

tg_is_not_reliable user_Abort

Figure 24. Reliability Synchronization Modules Interface

tg_reliable

86


10.6.4. Emission and Reception modules

tg_flow_ctx

EMISSION_ADU ctrl_timer_transmission_start

ADU_send

r_send_NDU

tg_flow_ready

tg_send_NDU user_xoff user_xon

RECV_ADU ctrl_timer_ADU_start ADU_rcv ctrl_timer_ADU_end

Figure 25. Send and Receive Modules Interface

ctrl_last_NDU_send ctrl_timer_ADU_stop


10.7 Integrated specification interface

The ALF parser produces an ESTEREL specification which integrates into the initial application specification the adapted transmission mechanisms. This section presents the interface of the integrated specification, that means how the ESTEREL specification interacts with the external environment. This interaction is achieved through signals. We describe the interface into four parts: the data interface, the network interface, the user interface and the control interface.

out

User

in

user_Quit user_Abort user_xxx C o n t r o l

ctrl_xxx

user_xxx user_xon/user_xoff

INTEGRATED

SPECIFICATION

r_ectrl r_cctrl r_seq_NA r_seq_NR r_seq_NS

r_NDU

in

Network

r_seq_NS r_seq_NS_ADU r_ADU_type r__rcv out

Figure 26. Integrated Specification Interface

Note that within the integrated specification, all signals are renamed by the ALF parser in order to be sure of the uniqueness of the signals names. 10.7.1. The data interface The data interface represents the definition of abstract data type. The resulting specification manipulates three main abstract data type. Abstract means the implementation is relegated to the host language in which the automaton produced by the ESTEREL compiler will be generated (i.e in C language). The three data type are the following:

88


•type ADU: Application Data Unit that a particular network application is prepared to handle out-of-order with respect to other ADUs. For a given application, several types of ADUs may be described. •type CNTL: Control Packet which contains information related to the acknowledgments and the congestion/flow control. Several control packets may be described. •type NDU: Network Data Unit which represents the unit of data processing and switching with the network. An NDU may contains either an ADU or some control information. 10.7.2. The network interface The network interface handles NDUs emission and reception. But on the opposite side of the output network interface, the input network interface is not reduced to an input signal of type NDU, since there are some information associated to the NDU which are used by the control automaton. These information have already been extracted from the NDU as separate signals by the Input Events Collector: r_seq_NS: global sequence number of the current received NDU. This sequence number identifies the NDUs related to a flow. r_seq_NS_ADU: sequence number specific to the current received ADU. This sequence number identifies an ADU of a given type within a flow.Therefore a NDU which contains an ADU has two sequence numbers as there can have several types of ADUs belonging to the same flow. r_ADU_type: type identifier of the current ADU. r_seq_NA: last number of ADU which has been received in sequence. r_seq_NR: number of received ADUs by the remote host r__rcv: current received ADU. r_cctrl: common control NDU It has to be included in all control NDU. It specifies the next number to be expected (seq_NA) and the number of received ADUs by the remote (seq_NR). r_ectrl: error control NDU which is only used to convey error control information. It is sent when data are missing otherwise the ctrl NDU is used. The additional fields provides either the sequence number of any non-contiguous ADUs received (Selective Positive Acknowledgments) or of any not received ADUs (Selective Negative Acknowledgments). 10.7.3. The user interface The user provides the user_Quit signal to inform that he wants to end properly the automaton. That means in the reliable mode, all sent ADUs have to be acknowledged by the remote. The user provides the user_Abort signal to inform that he want to stop the automaton in the current state. The automaton will emit a user_xoff to stop the sending of the ADUs by the application and a user_xon to resume it.


10.7.4. The control interface The control interface interacts within the execution machine like the timer manager. ctrl_timer_transmission_start: signal to start a timer when an ADU is sent. ctrl_timer_transmission_stop: signal to stop the timer related to the ADU emission because the ADU has been acknowledged. ctrl_timer_transmission_end: signal emitted by the execution machine when the timer related to the ADU emission has expired. ctrl_timer_ADU_start:.signal to start a timer which is set when an ADU is awaited. ctrl_timer_ADU: signal to inform the application that the remote host or the network communication should have some problems. The expected ADU has never been received. ctrl_timer_ADU_stop: signal to stop the timer related to the ADU because the ADU has been received. ctrl_timer_ADU_end: signal emitted by the execution machine when the timer related to the ADU has expired.

Unité de recherche INRIA Lorraine, technopôle de Nancy-Brabois, 615 rue du jardin botanique, BP 101, 54600 VILLERS-LÈS-NANCY Unité de recherche INRIA Rennes, IRISA, Campus universitaire de Beaulieu, 35042 RENNES Cedex Unité de recherche INRIA Rhône-Alpes, 46 avenue Félix Viallet, 38031 GRENOBLE Cedex 1 Unité de recherche INRIA Rocquencourt, domaine de Voluceau, Rocquencourt, BP 105, LE CHESNAY Cedex Unité de recherche INRIA Sophia-Antipolis, 2004 route des Lucioles, BP 93, 06902 SOPHIA-ANTIPOLIS Cedex

Éditeur Inria, Domaine de Voluceau, Rocquencourt, BP 105 LE CHESNAY Cedex (France) ISSN 0249-6399

ALFred, an ALF/ILP Protocol Compiler for Distributed Application ...

ALFred, an ALF/ILP Protocol Compiler for Distributed Application ...

Suggest Documents

Compiler Application (COMPILER) - Erlang

An Optimizing High Performance Fortran Compiler for Distributed ...

An Overview of the PARADIGM Compiler for Distributed ... - CiteSeerX

An application-specific protocol architecture for wireless ...

An application-specific protocol architecture for

The PARADIGM Compiler for Distributed-Memory ... - CiteSeerX

D'Caml: A Native Distributed ML Compiler for

Compiler Techniques for Effective Communication on Distributed ...

HPF Compiler for Distributed Memory MIMD ... - CiteSeerX

An Architecture for Mobile, Distributed Application ... - CiteSeerX

Human Authentication Protocol for Distributed

Distributed Java Compiler - Semantic Scholar

A Distributed Solution Protocol that Computes an

FLIP: an Internetwork Protocol for Supporting Distributed ... - CiteSeerX

an ultra-low power and distributed access protocol for ... - CiteSeerX

Anubis: An Attestation Protocol for Distributed Context-Aware ...

An Advanced Commit Protocol for MLS Distributed ... - CiteSeerX

An Efficient Distributed Coverage Hole Detection Protocol for Wireless ...

An Architecture for An Open Compiler - CiteSeerX

psi: a silicon compiler for very fast protocol ... - Semantic Scholar

Lightweight Security Protocol for Distributed Wireless ... - CiteSeerX

Hybrid Energy Efficient Distributed Protocol for Heterogeneous ...

protocol support for distributed multimedia applications - CiteSeerX

Distributed Relay Protocol for Probabilistic Information-Theoretic ...