Conference Protocol Implementations

This section describes the aspects that are important for the construction of the real conference protocol implementation. The environment for which the implementation is designed and developed is discussed in section Platform. The structure of the components of the conference protocol implementation is mentioned in section Structure. How each conference protocol (entity) implementation is configured is explained in section Configuration. The following section Concrete interfaces explains the data units wich are exchanged on the CSAP interface. In section Different implementations we provide the available 28 conference protocol implementations we build.

Platform

The conference protocol considered in this paper is implemented on SUN SPARC workstations using a UNIX-like ( SOLARIS) operating system, and it was programmed using the ANSI-C programming language. Futhermore, we used only standard UNIX inter-process and inter-machine communication facillities, such as uni-directional pipes and sockets.

A pipe is a uni-directional communication mechanism that supports stream-oriented message exhange between processes. Pipes in the SOLARIS operating system are actually bi-directional. By considering pipes as uni-directional communication mechanisms we hope to achieve portability.

A socket is an abstraction that allows the generalization of UNIX file access mechanism for interfacing with different protocols (connection-oriented, connectionless), while having different roles (calling or called users).

Structure

The conference protocol implementation consists of the actual conference protocol entity (CPE) which implements the protocol behaviour, and a user-interface on top of it. The abstract view of the conference protocol implementation is presented in Figure 5. We assume that the user-interface is separated (loosely coupled) from the conference protocol entity (CPE) because we want to isolate the protocol entity. This is realistic because interfaces are often implemented using dedicated software.

Configuration

In order to guarantee that a conference protocol entity has knowledge about existing partners the conference protocol entity reads a configuration file during the initialization phase. This configuration file consists of a set of tiplets (user_id, hostname, port_number). The user_id is an integer value greater than zero and defines a user operating at a CPE which is identified by both hostname and port_number. The hostname is a character string (not longer than 50 characters) and represents a computer system. The port_number is an integer value larger than 1024 and specifies the port to which the CPE is attached.

During the initialization phase one of the triplets is used to initialize the CPE. The other triplets are collected and form the set of potential conference partners.

Concrete interfaces

The conference protocol implementation has, as we can see in Figure 5, two important interfaces, the CSAP and the USAP. The CSAP interface allows communication between the two UNIX processes, user-interface (or the Test-Tool) and CPE. The USAP interface allows communication between the CPE and the underlaying layer.

This CSAP interface is implemented by using two uni-directional pipes. One pipe is used to pass join, datareq and leave service primitives from the user-interface to the CPE, and the other pipe is used to pass dataind service primitives from the CPE to the user-interface.

As mentioned in Section Conference Protocol Service the implementor must fill in the details of the conference service primitives. The format of these data units which are transfered at the CSAP interface is shown in Figure 6. These user data units UDUs look much like PDUs (see Section The Protocol Data Units) because we want to keep the CSAP interface as simple as possible and hence avoid actions like segmentation and reassembly. Note that the service primitive element message is decomposed into a length- and a data-element.

The USAP interface is implementated by sockets. The information that is transfered between the CPE and the underlaying layer are data packages with an address attached to them. The data packages are in fact protocol data units (PDUs) which are sent from one user to another user. For the conference protocol the sending and receiving user are different. The attached address, which consists of an IP address and a port number, identifies the sending (CPE-) user.

Different implementations

This first series of mutant implemenations have in common that the error, a required action which is not specified can be considered as a small programming mistake. We categorize them into three groups: No outputs, No internal checks, No internal updates. The group No outputs involves the mutants 674, 548, 687, 100, 111, 384 and they forget to send an output to the user or peer entity. The group No internal checks involves the mutants 444, 666, 293, 398 and they do not check the boundaries of the internal sets potentential conference partners and conference partners. The last group No internal updates is the largest group and involves the mutants 777, 856, 738, 289, 247, 467, 358, 749, 945, 345, 332, 348, 294, 276, 836, 214, 462 and they do not update the internal sets used, for example the set of conference partners.

The sources of the conference protocol implementation(s) can be retrieved here (confProtImplv2.1.tar.gz)!

This packages is 'tar'-ed and gnu-zipped. The first thing you have to do is to un-'gnuzip' this package with the command "gunzip confProtImplv2.1.tar.gz". The resulting file (confProtImplv2.1.tar) must be un-'tar'-ed before you obtain the conference protocol sources. This can be done with the command "tar xvf confProtImplv2.1.tar". This makes a directory called stuff where it puts all the necesary files. Inside the package there is a file called INSTALLandINFO.txt which you should read first before you start chatting. It is a short manual of the conference protocol implementation. Note that your configuration file e.g. 'config.txt' is valid otherwise the implementation will terminate directly (see also Section Configuration).

Alternative implementations

A single process based version of the conference protocol is also available. (confprotv3c2.tgz) This IUT has two additional advantages. There are currently 60 single error mutant implementation available. This means that theoretical 2^60 erroneous implementation can be derived (See ./IUT/mutants.txt for details). And this implementation can emit coverage data. For each block of code (branch coverage) it can emit a line of text on stderr that represents the block that is covered.

How to use coverage

We first compile the implementation in such way that it is enabled to emit coverage data on stderr. We do this by defining the macro MarkCoverage() with _MarkCoverage(__FILE__, __LINE__) as can be seen in coverage.h. When the source is compiled, for example with make confprot, the conference data blocks are also determined and stored to the file covdatafile. This file must be consistent with the executable, otherwise the coverage measurement might be out of sink. Note if coverage experiments are done, please, make a backup of the executable and the coverage data file. With the conference protocol we need to separate the coverage data from the normal user data. A trick is to use the unix program tee to duplicate the stderr and store it to disk. This can be done as follows GUI -c configfile.txt |& tee logfile. The GUI is the combined user and the iut module. The later implements the conference protocol. Here the stderr is piped to the program tee which stored a copy to file logfile. But it also writes it to stdout so we still see the information of the GUI. But to filter out the coverage lines we use |grep -v "^LOG COVERAGE" - which we add to the pipeline. See demo.sh and conferenceprotocol for more details. The coverage and other logging data are stored in a file, let's assume logfile. With this program the user interface sometimes add a prefix to the coverage data but also format of the coverage data is not completely as desired so we need to transform it a little bit. First we select all lines that contain coverage information by grep "LOG COVERAGE " logfile > idfile. From these lines we have to retrieve the id part. This we do with a script script_getid which is in the coverage directory. This delivers a sequential list of ids which are in fact coverage block representatives. If we feed these to the coverage program cov which is available in the coverage directory. For example like "cov -d ./IUT/covdatafile < idfile" were a lot of lines are displayed. If you look at it the percentage it increases, so the last line gives us the highest coverage information for this session. To display only the last line we use tail -1 at the end of the pipeline. Note sometimes it can occur that no conference protocol is registered. If this happens it is most likely that the particular port is occupaid.

We did a small test:

1. make veryclean
2. make all
3. ./demo.sh and played a little bit...(type help for help)
4. grep "LOG COVERAGE " logfile1 | ./coverage/script_getid | ./coverage/cov -d ./IUT/covdatafile | tail -1

and the result was: LOG COVERAGE total=129 todo=54 done=75 percent=58.139534 id=confprot.c:103

If you are only interested in the percent value. Just simply append ./coverage/script_getpercent to the pipeline and you'll get 58.139534 as answer.

tcl/tk based GUI

We added also a first experimental tcl/tk GUI to the conference protocol implementation. The current version of the GUI cannot handle the coverage data very good. One way is to turnning off the emmiting of coverage data. The tcl/tk GUI can be called with cpg.tcl.

A TCP version of the conference protocol

A server-client process based version of the conference protocol is also available. (confprotv3tcpcs.tgz) This version introduces a small server that forwards the messages send by the clients. The clients still administer their partners set locally. In this way the specification of the conference protocol is the same.

Prev	Table of Contents	Next
Chapter 11: Conference Protocol Formal Specifications		Appendix A: Conference Protocol References