We examine the usefulness of component-based software-engineering for the implementation of software communication systems. We present an architecture that allows to divide protocol software into fully de-coupled components that can be plugged together using visual builder tools to rapidly prototype flexible, robust, and application-tailored communication protocols. We show the feasibility of component-based protocol engineering by demonstrating how a simple transport protocol was realized. A discussion about advantages and impacts concludes this paper. 1. Introduction While a general purpose transport protocol such as TCP has been for many years the protocol of choice for popular applications like telnet or ftp, first problems with the use of TCP arose with the success of http [25]. For new applications like audio- and video-streaming, TCP is completely unsuited. We belief that the popularity of the world wide web and new technologies like Sun's Jini (TM) [16] will produce a number ...

The layered architecture of middleware platforms (such as CORBA, SOAP, J2EE) is a mixed blessing. On the one hand, layers provide services such as demarshaling, session management, request despatching, quality-of-service (QoS) etc. In a typical middleware platform, every request passes through each layer, whether or not the services provided by that layer are needed for that specific request. This rigid layer processing can lower overall system throughput, and reduce availability and/or increase vulnerability to denial-of-service attacks. For use cases where the response is a simple function of the request input parameters, bypassing middleware layers may be permissible and highly advantageous. Unfortunately, if an application developer desires to selectively bypass the middleware, and process some requests in the lower layer, she has to write platform-specific, intricate low-level code. To evade this trap, we propose to extend the middleware platform with new aspect-oriented modeling syntax, code generation tools, and a development process for building bypassing implementations. Bypassing implementations provide better use of server's resources, leading to better overall client experience. Our core contribution is this idea: aspect-oriented extensions to IDL, additional code generation, along with an enhanced run-time, can enable application developers to conveniently bypass middleware layers when they are not needed, thus improving the server's performance and providing more "operational headroom".

In this paper, we describe a method for implementing Presentation Processing Engine (PPE) modules that allow applications to process media objects and control the frame rate, spatial resolution, and SNR. PPE modules implement compression/decompression algorithms (e.g., JPEG, MPEG, etc.) as well as image processing functions such as rotate, scale, and dither. We have developed a library of reusable compression and image processing modules that can be composed together to implement PPEs. The PPE implementation is bound at run-time according to the application’s QoS requirements, available resources, and the compression format of the media object. PPEs can be dynamically reconfigured to adjust to changes in the quality of service required. These capabilities allow the PPE to tailor the access and delivery of the objects to the computing and communication capabilities of client sites as well as adapt to changes in resource availability and user preferences. Our compositional approach to building PPEs promises to achieve (1) a significant amount of functional reuse without sacrificing the ability to make low level modifications to the PPE implementation and (2) significant performance gains by allowing image processing functions to be inserted into processing pipelines at intermediate stages of compression. 1

this paper decouples the compositional structure of modules, which perform transformations on a data stream, from the algorithms used to implement these modules. Both may be changed dynamically and independently, to allow an implementation to adapt its functionality and resource requirements to the run-time environment. This pattern distinguishes itself from purely configurable pipeline patterns by addressing the tension between modularity and performance. 2 Motivation

lwIP is an implementation of the TCP/IP protocol stack. The focus of the lwIP stack is to reduce memory usage and code size, making lwIP suitable for use in small clients with very limited resources such as embedded systems. In order to reduce processing and memory demands, lwIP uses a tailor made API that does not require any data copying. This report describes the design and implementation of lwIP. The algorithms and data structures used both in the protocol implementations and in the sub systems such as the memory and buffer management systems are described. Also included in this report is a reference manual for

1 Intent The Adaptive Configuration pattern described in this paper decouples the compositional structure of modules, whichperform transformations on a data stream, from the algorithms used to implement these modules. Both may be changed dynamically and independently, to allow an implementation to adapt its functionality and resource requirements to therun-time environment. This pattern distinguishes itself from purely configurable pipeline patterns by addressing the tension between modularity and performance.

Prolac is a new statically-typed, object-oriented language for network protocol implementation. It is designed for readability, extensibility, and real-world implementation; most previous protocol languages, in contrast, have been based on hard-to-implement theoretical models and have focused on verification. We present a working Prolac TCP implementation directly derived from 4.4BSD. Our implementation is modular---protocol processing is logically divided into minimally-interacting pieces; readable---Prolac encourages top-down structure and naming intermediate computations; and extensible---subclassing cleanly separates protocol extensions like delayed acknowledgements and slow start. The Prolac compiler uses simple global analysis to remove expensive language features like dynamic dispatch, resulting in end-to-end performance comparable to an unmodified Linux 2.0 TCP. 1

Syntax Notation 1) language and the RO-notation (Remote Operation notation) language 1 . For both languages, automatic code generation tools have been developed. All OSI application layer standards use ASN.1 in order to specify data structures such as mail messages or directory entries that are exchanged in distributed applications. ASN.1 allows to define complex data types, which are encoded in a standardized exchange format, the so-called transfersyntax. To automate the tedious task to program the encoding and decoding routines by hand, socalled ASN.1 compilers can be used (e.g. MAVROS [Huit91], Pepsy [Onio89], [Neuf90], [Harv91] and [Koiv92]). Today, ASN.1 is a well-established language that has been used not only in all OSI application layer standards, but also for non-OSI standards such as the Internet Simple Network Management Protocol (SNMP) and the Open Document Interchange Format (ODIF). The performance and expressiveness of ASN.1 is equal to or even better than that of s...

this paper.

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. PREFACE This document is an updated version of RFC 1716, the historical Router Requirements document. That RFC preserved the significant work that went into the working group, but failed to adequately describe current technology for the IESG to consider it a current standard