Software Engineering Seminar

GT-SARG (Georgia Tech Software Architecture Reading Group

CS 8112 Winter Quarter 1995
Moderator: Gregory Abowd

Return to GT-SARG topic overview

Jan 30: Domain Specific Software Architectures

Discussant: Bobby Krupczak

Readings

Schmidt and Suda
O'Malley and Peterson
The OSI Reference Model, ISO 7498

Additional readings

Hutchinson and Peterson
A Stream Input-Output System by D. M. Ritchie

Summary of readings

These papers were chosen because they offer a range of information on one domain specific software architecture, namely, the field of communications protocol software. Papers were chosen so that several, different protocol software architectures (or subsystems) were highlighted. The papers offer a range of information on the domain of of communications protocol software that may be used to determine the characteristics of any domain specific software architecture.

Summary of discussion

We started the seminar with several assertions that were aimed at jump-starting the discussion:

Developing protocol software is a dirty, ugly business . . . .
Seriously, protocols are difficult, cumbersome, and expensive to develop and test in today's computing environments. To ease this burden, protocol programmers have generally done the following:
- subdivided the task into layers or modules and organized them into a protocol graph
- *developed them within a protocol environment or subsystem
- ported protocol code rather than develop it from scratch

We then presented some background information and definitions in order to clarify the discussion as well as a set of questions that the discussion might address. I summarize the terminology first.

A subsystem is a development and/or runtime environment in which protocol implementations operate. It arranges operating systems resources (like buffers, timers, devices) into a coherent framework that reduces the burden of protocol development.
A protocol graph represents the organization and relationship of individual protocols and implementations so that they may provide communication services. Nodes represent protocols and implementations while edges represent their interconnection. Several types of protocol graphs can exist. Often a standards body (e.g. ISO, Internet) define a protocol architecture graph specifying how protocols are organized. Alternatively, their is the protocol graph representing what protocols are actually instantiated and in use inside a particular system. This latter type is what we refer to as the protocol graph. How a subsystem supports its implementation can be of great importance.
A protocol (for the purpose of our discussion) is a software or hardware module that corresponds to a single, monolithic protocol (TCP) or corresponds to a single, atomic protocol function (e.g. header checksumming) intended for use in conjunction with other protocols. (I realize this is a somewhat vague definition, but I wish to avoid various baggage associated with this area.)

Questions intended for discussion:

What is the difference between a software architecture and a reference model? (The first paper was on the OSI Reference Model)
How does the framework/subsystem shape or dictate the software architecture and protocol implementation?
Can we abstract domain-specific software architectures?

We then moved to a discussion on why protocol software constituted a separate problem domain. I offered several items that may or may not distinguish protocol software architecture from other problem domains. Regardless, they are an attempt at classifying the types of features and functionality that "good" subsystems should provide.

Protocols often provide complex services (communication)
They manipulate data and compose pieces in almost arbitrary combination (hopefully without expensive copy operations)
Users often desire to "fiddle" with the protocols to control their actions
We desire high performance
We want portability and resuability of protocol code
Protocols interact with a variety of media and hardware
We want protocol implementations to be flexible and provide a variety of services

Next, we tackled the concept of a protocol subsystem in more depth. We utilized the taxonomy and survey from the Schmidt and Suda paper (as well as ongoing work by the presenter). Subsystems embody a protocol model and a set of support services which they offer to protocol programmers. A protocol model constists of a set of syntactic and semantic interfaces (including those explicit and implicit, usage conventions, etc.), a process architecture, and a protocol graph. A process architecture can be considered the protocol's computational model in that it specifies how communications entities like layers, messages, connections (etc.) are bound to the underlying unit of scheduling. Alternatives include horizontal (process per layer), and vertical (synchronous, function invocation between layers). Support services include buffer/memory facilities, protocol-independent routing table support, and protocol independent multiplexing and demultiplexing.

The OSI Reference Model

We then proceeded to a discussion on the OSI Reference Model; much of the discussion centered on the question if it really was a software architecture. I believe the consensus was that it indeed was a software architecture although it certainly was not an implementation specification. (Unfortunately, many in the networking community have misconstrued it to be an implementation specification; the results have been somewhat disastrous and might be considered the "dark ages" of the communications community.) The following points were offered about the OSI Reference Model:

It specifies layering to subdivide complexity
Address are hierarchical
It specifies layered multiplexing (another source of performance problems)
Interface between layers through well-defined service access points (SAPs)
NOT AN implementation specification
Peers must communicate via protocol data units (PDUs)
It is connection-oriented (although the Reference Model has made some amends)
It seems to embody the elements of software architecture

The BSD Subsystem

We next spoke briefly about the BSD protocol subsystem (no assigned reading on this subsystem due to a lack of more formal material on it). This subsystem is commonly referred to as "sockets" and has existed in most BSD derived operating systems. (Sockets is merely an application interface or API to the underlying protocol subsystem). BSD defines a three-layer protocol model consisting of application interface protocols, network-interface protocols, and all others. It utilizes a synchronous, vertical process architecture. It can be characterized as having better performance than Streams. On the other hand, it is a clumsy, ugly programming and user environment. In defense, its over 20 years old. Lastly, its implementation of TCP/IP has served as the basis for most TCP/IP implementations in use today.

The Streams Subsystem

The Streams subsystem sought to replace the traditional UNIX method for connecting processes to terminals or network devices with a flexible, consistent subsystem supporting modular protocols. It is probably most similar as a pipe and filter architecture. It has questionable performance due to its combination of horizontal and vertical process architectures. It does support the dynamic modification of the protocol graph -- something most other subsystems do not support. Unfortunately, few, if any, current protocol implementations make use of this feature. Its protocol model is built on the traditional UNIX device -- it has interfaces for open, close, read, write, and control.

The x-Kernel

We then moved to the x-kernel protocol subsystem. Its designers wished to ease the burden of protocol development but not at the expense of protocol performance. It embodies the philosophy of its designers:

Layering is good
Constrain of the protocol programmer because the subsystem designers are smarter

It defines micro, virtual, and anchor protocols in addition to the more common, monolithic definition. They specify a threaded vertical process architecture where a separate thread accompanies or escorts each message through the protocol graph. Its protocol graph is built at compile time with no run-time modification supported. Protocol code is divided into protocol objects and session objects. Session objects contain state information for active communication while protocol objects provide multiplexing and demultiplexing to session objects.

Running Discussion

Throughout the seminar, we discussed the performance implications associated with each subsystem or framework. Starting with the OSI framework, we discussed the implications of layered-multiplexing and horizontal process architectures. Layered multiplexing is a result of several things: first, resource sharing necessitates multiplexing; second, the OSI reference model explicitly defines multiplexing at each layer. Subsequently, layered multiplexing has crept into most protocol architectures. We discussed one scheme where multiplexing decisions are made at exactly one place in the protocol graph -- at the bottom, or at the lowest point in the protocol graph. The x-Kernel recognizes this artifact and offers subsystem support for its efficient implementation -- wherever the protocol programmer chooses to do so. BSD and Streams do not provide such support.

Horizontal process architectures were another theme we discussed throughout the seminar. Horizontal protocol architectures can be characterized as an approach where process or threads reside in each layer. They communicate with one another via messages (protocol packets, for example). These architectures can be exploited for pipelined parallelism but can be detrimental to performance due to the overhead of context switching. We discussed how each subsystem approaches this topic. Streams provides a combination of both horizontal and vertical process architectures. x-Kernel and BSD provide a strict vertical protocol architecture. My own work has shown BSD to substantially out-perform Streams when all else is held constant.

Conclusions

The discussion closed with some conclusions regarding software architecture and, more specifically, protocol software architecture. We believe that Streams, BSD, and the x-Kernel are, indeed, software architectures. The OSI Reference Model, in all probability, is one as well. The field of protocol software architecture is still somewhat immature with plenty of research opportunities.