As the number and variety of Web- and network-based applications continues to increase, so does the need for flexible communication protocols and services to support them. Traditionally, a major impediment to deployment of new protocols is the need to upgrade millions of end-systems with compatible implementations. At the same time, Java-a language explicitly designed to support development and distribution of new applications via the Web-is emerging as a (potentially) ubiquitous system platform. It is therefore natural to consider whether Java might speed the introduction of protocols to better support new applications. We investigate the tradeoffs involved in using Java for protocol implementation and deployment. Using insights from a Java-based protocol suite and supporting subsystem we have implemented, we describe the benefits of using the Java language and quantify the performance cost of implementing a protocol in Java for various combinations of interpretation and compilation. We find that the present performance cost of using Java-based protocols is roughly equivalent to four years of hardware performance gains, i.e., interpreted, Java-based protocol performance on current hardware is roughly equivalent to the performance of compiled C code on four-year-old hardware.

Deploying protocols is an expensive and time-consuming process today. One reason is the high cost of developing, testing, and installing protocol implementations. To reduce this difficulty, protocols are developed and executed within environments called protocol subsystems, and protocol software is often ported instead of being coded from scratch. Unfortunately, today a variety of protocol subsystems offer a plethora of features, functionality, and drawbacks; the differences among them often reduce the portability and reusability of protocol code, and therefore present barriers to the deployment of new protocols. In this paper, we consider differences in subsystems and their effect on the portability and reusability of protocols and protocol implementations. We then propose two different approaches, each optimized for a different situation, that allow protocol code implemented in one subsystem to be used without modification within other subsystems, and thus reduce the barriers to protocol deployment. We relate our experiences designing, implementing, and measuring the performance of each approach using, as a baseline, an AppleTalk protocol stack we have developed.

Because protocol software is difficult and expensive to implement and test, it is often ported between systems instead of rewritten from scratch. Unfortunately, porting protocol software can be as difficult as from-scratch development, due to inherent differences in subsystem design. Thus, protocol subsystems can have a profound effect on the portability of a protocol implementation. We propose an approach permitting the incorporation of new protocols into a subsystem other than their "native" one without the drawbacks or expense of porting and original development. Our approach is based on protocol module encapsulation, which allows unmodified protocol code developed for one protocol subsystem to be used within another. We relate our experiences designing, implementing, and measuring the performance of our protocol encapsulation modules, using an AppleTalk protocol stack as a baseline.

Protocol software is often difficult and expensive to implement and test in today's computing environments. Several things are done to reduce this difficulty: communications software is subdivided into layers and organized into a protocol graph; communications software is developed within a protocol or networking subsystem; and it is often ported rather than developed from scratch. Today, a multitude of subsystems offer different features, functionality, and drawbacks; the differences among them often reduce portability and efficiency of protocol code. We consider these differences in subsystems and their effect on the portability and performance of protocol implementations. We propose an approach for combining the better features of protocol subsystems by constructing protocol graphs composed of protocols residing in different subsystems. Our approach uses adapter modules spanning the inter-subsystem boundary. We relate our experiences designing, implementing, and measuring the performance of several such adapters using an AppleTalk protocol stack we have developed as a baseline.

The authors consider the use of parallelism and configurability to increase throughput and reduce protocol processing latencies. They obtain experimental results on parallel protocol performance using a prototype implemented on a shared memory multiprocessor. The results demonstrate the utility of parallel protocol processing, and they indicate the further research necessary for constructing viable communication protocols for large-scale parallel machines. Based on these experiences, the design of an object-oriented framework for parallel protocol programming which facilitates parallel protocol development and helps maximize protocol performance on a wide variety of multiprocessors is presented.>