COMSCRIPT : A New Language for Building Flexible Protocol Stacks Giovanna Di Marzo, Murhimanya Muhugusa, Christian Tschudin, Eduardo Solana and Ju¨rgen Harms Centre Universitaire d’Informatique, University of Geneva
[email protected]
Abstract The last trends in Protocol Stacks Architectures lead to an increase of flexibility in Protocol Stacks in reaction to the current static and predefined stacks. COMSCRIPT is a new language and a new environment inside which protocol entities are handled and whole protocol stacks are completely configured and dynamically modified. This paper presents how the dynamical (re)configuration of protocol stacks is actually realized in a COMSCRIPT environment. On the basis of some implementation examples, we show some experiments made with the COMSCRIPT environment. Keywords: computer communications, protocol implementation, protocol stack configuration, flexible protocol stack, code downloading, COMSCRIPT.
1 Introduction Classical communication software adheres to well defined standards. In these standards, two communicating hosts have identical preconfigured protocol stacks. The use of standard enforces the partners to strictly implement all the layers of the protocol stack. Moreover, it is difficult to establish a communication between hosts using different standards. These last years, interest has been focused to let protocols become more flexible. Some interesting proposals have been given by [OMall 91] with “micro protocols” or by [Plage 93] with the Da Capo Architecture. All these proposals are alternatives to the classical static and predefined protocol stacks. Following the same idea, we present here another approach that goes further in the protocol stack flexibility. This approach is based on a new interpreted language, COMSCRIPT, that enables an application to dynamically configure itself the protocol stack as it needs. The philosophy adopted here breaks the idea of the protocol stack being a black box for the application and goes beyond other similar approaches in the sense that the protocol stack can be completely overturned by the application.
2
COMSCRIPT as an Environment
The COMSCRIPT approach is an environment inside which processes are executed concurrently. Processes are organized along This work is supported by Swiss National Fund for Scientific Research (FNSRS) grant 20-34’070.92
a process hierarchy: a parent process creates one or more children processes. Processes are event-driven and react to events which occur on synchronization points, called s-points. Three types of events are handled by the COMSCRIPT environment: (1) a data exchange with another process or with the outside world; (2) a pure synchronization of 2 processes (without data exchange); (3) an elapsed timeout period. When an event occurs on a s-point, a special code, the event handler, associated to the s-point is executed to handle the event. S-points are linked to special buffers, called gates. The links between s-points and gates provide communication channels. To exchange data or to synchronize their execution, two processes have to be connected by such channels. Processes communicate synchronously through gates of zero length queue and asynchronously otherwise. The parent process is responsible for creating gates and for linking s-points of its children to the gates, allowing in this way its children processes to communicate. Moreover, the parent process can break and change these links at any moment, according to its needs. Figure 1 shows the parent process P and
P
gate
link /?in
/!out
event handler
P1
P2
Figure 1: Processes linked through s-points and gates its children P1 and P2 linked together in order to allow an asynchronous data exchange between them through a gate of size 3. P1 is offering data through the output s-point /!out, while P2 is receiving data through input s-point /?in. Communication channels become manipulable objects in COMSCRIPT: links between s-points and gates are easily reconfigurable. This reconfiguration of “s-points-gates” links allows the reconfiguration of protocol stacks as presented in section 4. A process may want to communicate with another process running on another machine. This operation requires the process to be able to connect to the world outside its COMSCRIPT envi-
ronment. In this purpose special s-points, called device s-points have been designed. Device s-points are owned by a device driver. A device driver is seen by COMSCRIPT processes as an external process with which they can interact through its device s-points. Device drivers accessible from the C OMSCRIPT environment are, amongst others, the access to the file system, the access to the system console, the access to the Ethernet and the access to the TCP and UDP sockets.
3
COMSCRIPT as a Language
COMSCRIPT is also an interpreted programming language. The COMSCRIPT language derives from POSTSCRIPT1 . It inherits then the execution model of POSTSCRIPT and most of its operators. New operators and data structures have been added to allow the handling of concurrent processes as well as their synchronization. In the following example, we use some operators, like the fork operator that creates a process; the createsync and creategate operators that creates s-points and gates respectively; and the link operator that attaches a given s-point to a gate. See [Tschu 92] for the complete list of all operators available in COMSCRIPT. 1 2 3 4 5 6 7 8 9
/a { %indicates pure synchronization done clear (a: init starts ... ) print flush /_in 0 createsync begin /handler { pop (a synchronized) print flush} def end (a: init done.) print flush } def %a
synchronization) on line 31, and then links the two s-points (of a and b) to the just created gate, with the link operator on line 32.
4
Dynamic Reconfiguration of Protocol Stacks
A protocol stack is a layer of protocol entities with the application, at the top of the stack, and a communication medium (for example the Ethernet), at the bottom of the stack. In COMSCRIPT, we can accurately reproduce the classical layered approach: each layer becomes a COMSCRIPT process; the Service Access Points (SAP) of a stack layer become s-points of the corresponding COMSCRIPT process; the interaction between two neighbor layers is realized through C OMSCRIPT communication channels between the two corresponding COMSCRIPT processes. But the COMSCRIPT approach confers more liberty to get farther away the static view: some layers of the protocol stack can be added or removed whenever necessary; layers can be splitted to speed up the communication; etc. This section provides some examples of a dynamic reconfiguration of a protocol stack.
4.1 Initialization of Protocol Stacks In the initialization phase, a COMSCRIPT device is used to open the application to the outside world. After the initialization of the stack, the first module is pushed on top of the stack.
10 11 12 13 14 15 16 17 18 19 20
Application
/b { %indicates pure synchronization done clear (b: init starts ... ) print flush /_out 0 createsync begin /handler { pop (b synchronized) print flush} def end (b: init done.) print flush } def %b
/?in
Application /?in
/!out
Stack Handler
/!out
{ M1 1 insert} /?split /?insert /?remove /?reset
/?upin
/!upout
M1 M1
/?downin
/!downout
/?split /?insert /?remove /?reset
Device s-points
21 22 23 24 25 26 27 28 29 30 31 32 33 34
/go { %Starts program %a, b started /a load fork dup wait /syncdict get /_in get /b load fork dup wait /syncdict get /_out get pause pause (now linking ...) print flush %a, b linked 0 creategate dup 2 index exch link 2 index exch link pop pop (linking done) print flush } def %go
The code above shows two processes, whose behavior is given by procedures a and b, defined at lines 1-9 and lines 12-20 respectively. Process a possesses the s-point / in, created on line 5 with the createsync operator, while b possesses the s-point / out, created on line 16. In both cases, the associated handler (line 6 and 17 respectively) is limited to the printing of a message indicating that the synchronization has occurred. The parent process, by the mean of the go procedure, on lines 23-34, starts the two children processes a and b with the fork operator on line 25-26. It then creates a gate of size 0 (for pure 1 POSTSCRIPT
c is a registered trademark of Adobe Systems Incorporated.
Initialisation
First Module Inserted
Figure 2: Initialization of protocol stack Figure 2 shows the insertion of a first module (a C OMSCRIPT process representing a protocol entity) between the application and the device. This module can contain the functionality of the whole stack or only of a layer of the stack.
4.2 Inserting modules The application can decide, during its execution to modify the stack. For example it can add a whole layer inside the stack, for pipelining purpose; it can also split or duplicate a module for efficiency or parallelism purposes. This is done by breaking the links between two neighbor modules; the new module is then attached to the two previous ones by linking its s-points with the s-points of the other two. Figure 3 shows the insertion of module M2 on top of the stack, between module M1 and the application.
Application
Application
Stack Handler
/!out
/?in
module by another new one. Application
/?upin
/?split /?insert /?remove
/?downin
{M2 2 insert}
/?reset
/!downout
/?downin
/!downout
/?upin
/!upout
M2
/?split /?insert /?remove /?reset
/!out
/?in
Stack Handler
M2
M1
Application
/!out
/?in
/?upin
/!upout
Stack Handler /!upout
Figure 6 shows the replacement
/!out
/?in
Stack Handler /?upin
/!upout
/?downin
/?upin
/!upout
M3
M3 /!downout
/?downin
/!downout
M1 /?downin
/?upin
/!upout
/!downout
/?downin
M2’ /!downout
/?upin
/!upout
Figure 3: Insertion of modules in a protocol stack
/?split /?insert {2 remove M2’ 2 insert} /?remove /?reset
/?downin
/!downout
/!downout
/?split /?insert /?remove
/?upin
/!upout M2’
M1 /?downin
/?upin
/!upout
M2
/?reset
M1 /?downin
/!downout
Application Application /!out
/?in /!out
/?in
Stack Handler
Stack Handler /!upout
/?split
{M1b 1 split}
/?split
/?upin
/!upout
/?insert /?remove
M1 /?downin
/!downout
/?reset
/?upin
/!upoutb
/?upinb
M1 M1b
/?downin
M1b /!downout
/?downinb
/?insert /?remove /?reset
/!downoutb
Figure 6: Replacing modules in a protocol stack of the middle module M2 by the new module M2’. This is done by (1) removing M2 and (2) adding M2’.
Figure 4: Splitting layers in a protocol stack
5 Implementation Examples Figure 4 shows the layer previously made of module M1 changed to a layer made of two modules, M1 and M1b, running in parallel.
4.3 Removing modules An application can not only insert modules, it can also remove modules from a stack if it needs so. Figure 5 shows the removing Application /!out
/?in
Stack Handler
Application /?upin
/!upout
/?in
/?downin
/!downout
/?upin
/!upout
M3
/?upin
/!upout
/!out
Stack Handler
M3
/?downin
/!downout
M2 /?downin
/!downout
/?upin
/!upout
/?split /?insert /?remove
{ 2 remove}
/?reset
/?upin
/!upout
/?split /?insert /?remove /?reset
M1 /?downin
In the previous sections we have presented the basic concepts of COMSCRIPT and the way these concepts let us dynamically (re)configure protocol stacks. Getting far away from this abstract view of COMSCRIPT, we present now some concrete implementations realized in COMSCRIPT. They are of different types: implementations of both well known low-level and high-level protocols, configuration of a remote protocol stack by downloading of code, or implementation of COMSCRIPT servers providing several services. As we said before, COMSCRIPT processes interact with external events by the means of special s-points, the devices. An application can access the network at different levels: (1) at the lowest level, directly accessing the Ethernet, this is done by an application connected to a NIT access device; (2) at a transport level, directly accessing the TCP or UDP protocol by the mean of ActiveTCP, PassiveTCP, or UserDatagram devices.
/!downout
5.1 Low and High-level protocols
M1 /?downin
/!downout
Figure 5: Removing modules in a protocol stack of the middle module in a three layered stack.
4.4 Replacing modules At any moment the application can modify a stack module, either by adding or removing some of its s-points or by modifying the links between its s-points and gates, or by changing the handler associated to the s-points, or more drastically by replacing the old
The TCP/IP protocol stack of figure 7 is built on top of a NIT access. The EtherDemux process receives frames directly from the Ethernet. It then offers the data part of these frames to either the IP process or the ARP process according to the type of the frames. The IP process takes off the header part of the received packet and offers the data part either to a TCP or to an UDP process. The ARP process receives ARP packets from the EtherDemux process and updates its address resolution table. When an IP packet has to be sent, i.e. when the IP process offers an IP packet to the ARP process, ARP resolves the ethernet address, encapsulates the packet in an Ethernet frame and offers it to the NIT device. This COMSCRIPT stack reproduces most of the functionalities of the TCP/IP protocol suite. It is completely designed and implemented in the COMSCRIPT environment.
Host Machine UDP
TCP
ComScript Environment FTP server FTP Command Handler IP
Client /!ip_out
/?ip_in
ARP /?arp_in /!ip
/!arp_out
PassiveTCP device
/!arp Network EtherDemux /?rnit
Figure 8: FTP COMSCRIPT server
nit device
Handler, entirely dedicated to the handling of its FTP requests.
Figure 7: TCP/IP protocol stack COMSCRIPT TCP - UDP servers
5.2 COMSCRIPT Servers COMSCRIPT servers are C OMSCRIPT processes connected to the network at either a low level (NIT access) or at a high level (TCP, UDP). They are waiting for requests from applications (Clients). Depending on the server the effect of these requests can vary greatly: a whole protocol stack is created; a file is transferred using the FTP protocol; etc. We present here 3 servers, each built on top of high-level protocols: the COMSCRIPT FTP server implementing the well known FTP service and the COMSCRIPT TCP and COMSCRIPT UDP servers. These two last servers allow C OMSCRIPT applications, possibly running in another COMSCRIPT environment, to access the environment where the server is running. These two servers are dedicated to the execution of C OMSCRIPT code sent by remote COMSCRIPT applications. A COMSCRIPT FTP server The COMSCRIPT FTP server process of figure 8 is connected to the network by the mean of the PassiveTCP device, that provides it an access to the TCP sockets. This COMSCRIPT FTP process is built on top of a TCP protocol and waits for Clients connections on one of the s-points of the PassiveTCP device. Once a connection is received from a Client, the server creates a new process, the FTP Command Handler process, that is specially dedicated to the Client requets. The server creates another instance of the PassiveTCP device, it links the FTP Command Handler process to this device, and informs the Client of the port on which it can send FTP requests. The Client is then directly connected to a FTP Command Handler that is entirely dedicated to its requests. Once this connection has been done, the server breaks the connection between itself and the Client, this one working now autonomously with the FTP Command Handler. If more Clients request connections to the COMSCRIPT FTP server, each one will be provided with its own FTP Command
COMSCRIPT TCP or UDP servers are C OMSCRIPT processes built on top of the TCP or UDP protocol respectively; i.e. they are linked to devices accessing TCP or UDP sockets. The role of these servers is to execute a piece of COMSCRIPT code sent to them by a remote COMSCRIPT application. In the TCP case, when the Client requests a connection, the TCP server creates a new C OMSCRIPT environment specially dedicated to the Client. This environment is then able to execute COMSCRIPT commands of the Client. There will be as much new COMSCRIPT environments created as Clients connected to the TCP server. The TCP server is used when a Client needs exclusive access to a COMSCRIPT environment. This case is similar to the case of the FTP server except that the new created process handle COMSCRIPT code instead of FTP commands. In the UDP case, there is only one COMSCRIPT environment, which is shared by all Clients. The execution of COMSCRIPT code by a COMSCRIPT server running in a remote COMSCRIPT environment is especially interesting as it is the key for remote code downloading, as explained in the next subsection.
5.3 Remote Configuration of a Protocol Stack Let us consider two hosts that do not have the same preconfigured protocol stack. To realize a communication between such hosts, the one that initiates the communication has nothing to do but to send the code of its own protocol stack to the COMSCRIPT UDP server running in the other host. The execution of this code leds to the creation of a protocol stack inside the remote host, so that the two hosts can now communicate using this protocol stack. Figure 9 shows the different phases of this operation: 1. Application A, running in the COMSCRIPT environment CS-A, sends some piece of COMSCRIPT code to the UDP server running in the C OMSCRIPT environment CS-B;
CS-B
CS-A
UDP server A 2’ 3 2
UDP device
1
UDP device
Figure 9: Configuration of a remote protocol stack 2. The server executes the code resulting in the creation of a whole protocol stack; and (2’) in parallel A executes in CS-A the same code producing the same protocol stack. 3. The communication occurs between the two hosts using the so created protocol stacks.
6 Current State of COMSCRIPT A COMSCRIPT interpreter prototype has been implemented and provides a COMSCRIPT environment as described in the examples. This prototype has been derived from the POSTSCRIPT interpreter G HOSTSCRIPT [Ghost 91], where all graphics operators were removed and new operators for enabling concurrent processes have been added. The COMSCRIPT interpreter is currently running on SunOS 4.1.3 and on Solaris 2.2 operating systems. This prototype has demonstrated that the abstract model presented in sections 2 and 3 is well suited to realize dynamic (re)configuration of protocol stacks. All the examples described in section 5 have been successfully implemented within the COMSCRIPT environment. Neither performances, nor security aspects have been yet considered in the current prototype, as we were mostly concerned with the realization of the basic aspects underlying the COMSCRIPT model.
7 Related Work and Discussion The field of dynamic reconfiguration of protocol stacks is currently investigated by several research works. O’Malley and Peterson, present in [OMall 91] and [OMall 92] their approach, where protocols are obtained from a composition of different micro and virtual protocols. The set of all possible combinations is represented by a protocol graph. During the initialization phase of the communication, the best path (which best fulfills the needs of the application) is chosen amongst all the paths in the protocol graph. This solution provides some flexibility, but it is limited to the initialization phase. Moreover all the micro protocols must be implemented by the two commu-
nicating hosts and there is no possibility to change the protocol graph after the initialization phase. The UNIX SYSTEM V STREAMS [Strea 90] approach allows to push and pop protocol modules on top of the stack and this is possible at run time. The protocol stack architecture proposed by Plagemann and Plattner [Plage 93] uses a 3 layered stack. The first layer represents the application, the middle layer configures the protocol stack that best fulfills the requirements of the application. The bottom layer represents a transport infrastructure. This approach is similar to that of [OMall 92] in the sense that the protocol is chosen amongst a graph, but it differs from it by the possibility to have more than one protocol graph and by the capability of the middle layer to change the protocol during the communication if it doesn’t fulfill anymore the application’s requirements. COMSCRIPT goes further in the protocol stack reconfiguration, in the sense that an application can at any moment modify any module in the protocol stack. As the protocol stack is changed, when the needs change, a COMSCRIPT application can gain performance by avoiding layers imposed by standards, that are not necessary for it. Interoperability is increased with the C OMSCRIPT environment, as hosts not having identical preconfigured protocol stacks can communicate. The remote downloading of code produces a protocol stack which is used for communication. What is needed to achieve code downloading is that the two hosts be running the COMSCRIPT environment and be connected through a communication medium, not necessarily reliable.
8 Conclusion COMSCRIPT is both an interpreted language and an environment well suited for the dynamic reconfiguration of protocol stacks. As an environment, COMSCRIPT allows the execution of concurrent processes. As a language, it is derived from P OSTSCRIPT sharing its simple execution model, its syntax and some of its operators and data structures. The dynamic reconfiguration of protocol stacks is realized in COMSCRIPT by the manipulation of communication channels which are links between s-points and gates. The examples implemented in the COMSCRIPT environment show that COMSCRIPT provides not only the necessary ingredients to implement protocol stacks in the framework of standards, but it allows also the creation of more flexible protocol stacks. In a community of COMSCRIPT nodes, one node can download COMSCRIPT code for execution in a remote one, making possible the (re)configuration of a remote protocol stack. Our approach goes beyond similar other approaches in the sense that the application has direct access to the code of the protocol stack, and is free to modify this code whenever it wants.
References [Adobe 90] Adobe Systems Incorporated, editor. PostScript
Language: Reference Manual, Addison-Wesley, fifteenth edition, 1990. [Cohen 86] Cohen N. H., Ada as a second language, McGrawHill, Inc. 1986. [Comer 86] Comer D. E., Internetworking with TCP/IP; Volume I; Principles, Protocols, and Architecture, Second edition, Prentice-Hall International, 1991. [Ghost 91] Deutsch L. P. (Aladdin Enterprises), GhostScript— An Interpreter for the PostScript Language, distributed under the GNU General Public License. [Hopcr 79] Hopcroft J. E., Ullman J. E, Introduction to Automata Theory, Languages, and Computation, Addison-Wesley, 1979. [Hutch 91] Hutchinson N. C., Peterson L. L., The x-kernel: An Architecture for implementing network protocols, In: IEEE Transactions on Software Engineering, Jan. 1991, pp. 64–76. [Muhu 92] Muhugusa M., Solana E., Tschudin Chr. F., Harms J., ComScript — Implementation and Experiences, Internal report, Universite´ de Gene`ve, Nov. 1992. [NeWs 90] Sun Microsystems, Inc. NEWS 2.1 Programmer’s Guide, June 1990. [OMall 91] O’Malley S. W., Peterson L. L.,A Highly Layered Architecture for High-Speed Networks, In Marjory J. Johnson, editor, Protocols for High-Speed Networks II, pp 141–156, Elsevier, 1991. [OMall 92] O’Malley S. W., Peterson L. L.,A Dynamic Network Architecture, In: ACM Transactions on Computer Systems, Vol. 10, No. 2, May 1992, pp. 110-143. [Plage 92] Plagemann T., Plattner B., Vogt M., Walter T.,A Model for Dynamic Configuration of Light-Weight Protocols, In: IEEE Third Workshop on Future Trends of Distributed Computing Systems, Taipei, Taiwan, April 1992, pp. 100–106. [Plage 93] Plagemann T., Plattner B., Modules as Building Blocks for Protocol Configuration, Proceedings International Conference on Network Protocols, ICNP’93, San Francisco, CA, Oct. 19–22, 1993, pp. 106–115. [Plage 94] Plagemann T., Gotti A., Plattner B., CoRA — A Heuristic for Protocol Configuration and Resource Allocation, Submitted to IFIP Fourth International Workshop on Protocols for High-Speed Networks, Vancouver, Canada, Aug. 10–12, 1994. [Rose 90] Rose M. T., The open book: a practical perspective on OSI, Englewood Cliffs: Prentice-Hall, Inc. 1990. [Strea 90] Sun Microsystems, Inc. STREAMS Programming Manual, March 1990.
[Tschu 91] Tschudin Chr. F., Flexible Protocol Stacks, In SIGCOMM’91 Conference on Communications Architectures & Protocols, pp. 197–204, Sept. 1991. [Tschu 92] Tchudin Chr. F., Muhugusa M., Solana E., Tschudin Harms J., ComScript — Concept and Language, Internal report, Universite´ de Gene`ve, Nov. 1992. [Tschu 93] Tschudin Chr. F., On the Structuring of Computer Communications, Ph.D Thesis no. 2632, Universite´ de Gene`ve, 1993. [Muhu 94] Muhugusa M., Di Marzo G., Tschudin Chr. F., Solana E., Harms J., ComScript: An Environment for the Implementation of Protocol Stacks and their Dynamic Reconfiguration, to be published in the proceedings of ISACC’94, Monterrey, Mexico, Oct. 26-27, 1994.
