ABSTRACT
Recent developments in data communications have been dominated by advances in
high-speed networking and distributed multimedia applications. It is well known that
the communications bottleneck in modern high-speed networks is located in the endsystem. Multimedia applications have increased the set of requirements in terms of
throughput, delay, delay jitter and synchronization. These needs may not all be
directly met by the networks. End-to-end protocols may be necessary to provide the
quality of service (QoS) required by the applications. Fixed end-system protocols are
not able to support the wide range of different application requirements on top of
current networks without including unnecessary functionality.
The aim of this work is to provide a framework for dynamic configuration of
end-system protocols. The framework is implemented along with a module pool,
which consists of set of modules(protocols) providing different services. These
modules enrich the services of the transport infrastructure to fulfill the needs of the
distributed applications. New application requirements can be supported simply by
integrating new appropriate modules and configuring a suitable protocol. An
appropriate connection management protocol facilitates dynamic reconfiguration of
protocols. The evaluation of our proposal shows that by configuring appropriate
protocols increases protocol performance and decreases protocol complexity.
TABLE OF CONTENTS
LIST OF FIGURES .................................................................................................. III
ACKNOWLEDGEMENT: ...................................................................................... IV
1 INTRODUCTION.................................................................................................... 1
1.1 THESIS ................................................................................................................. 2
1.2 STRUCTURE OF THESIS ...................................................................................... 3
2 LITERATURE REVIEW ....................................................................................... 4
2.1 CONFIGURABLE PROTOCOL SYSTEMS ............................................................... 4
2.2 RELATED WORK .................................................................................................. 5
2.2.1 x-kernel ......................................................................................................... 5
2.2.2 Da Ca Po ....................................................................................................... 6
2.2.3 Tau Framework ........................................................................................... 7
2.3 SUMMARY .......................................................................................................... 10
3 PROBLEM STATEMENT .................................................................................. 11
4 IMPLEMENTATION ........................................................................................... 15
4.1 ENVIRONMENT .................................................................................................. 15
4.2 DETAILS OF THE FRAMEWORK ......................................................................... 16
4.2.1 Outline ........................................................................................................ 16
4.2.2 Framework static components ................................................................. 17
4.2.3 Framework Architecture .......................................................................... 19
i
4.2.4 Configuration Protocol ............................................................................ 21
4.2.5 Send Thread .............................................................................................. 22
4.2.6 Receive Thread .......................................................................................... 22
4.2.7 Transport Protocol .................................................................................... 23
4.2.8 System Interface ........................................................................................ 24
4.2.9 Timer Management ................................................................................... 24
4.3 RUN-TIME ENVIRONMENT ................................................................................ 25
4.3.1 Message Forwarding ................................................................................. 25
4.3.2 Synchronization ......................................................................................... 26
4.4 PERFORMANCE TESTING .................................................................................. 26
5 CONCLUSION ...................................................................................................... 30
5.1 SUMMARY .......................................................................................................... 30
5.2 FUTURE WORK ................................................................................................... 30
REFERENCES .......................................................................................................... 31
ii
LIST OF FIGURES
Fig 1 The Da Ca Po 3 layer model............................................................................7
Fig 2 Architecture of τ...............................................................................................8
Fig 3 Generic Framework Interface........................................................................11
Fig 4 Static Components of Framework.................................................................17
Fig 5 Framework Architecture................................................................................19
Fig 6 Control Message Sequence.............................................................................20
Fig 7 Data Message Sequence..................................................................................20
Fig 8 Message Forwarding.......................................................................................25
iii
ACKNOWLEDGEMENT:
I would like to express my sincere gratitude to Dr. Singh for his constant guidance
and encouragement throughout the project. I would like to thank Dr. Dan Andresen
and Dr. Mitch Neilsen for serving on my supervisory committee. I would also like to
thank Dr. Virg Wallentine and the entire department staff for their constant support
throughout my masters program. Last but not the least, I would like to thank all the
members of my family and my friends, for their moral support and encouragement.
iv
Chapter 1
INTRODUCTION
Today’s high-speed network offer much more bandwidth then traditional
networks. This is possible due to usage of various technologies viz optical
switching,fast packet switching etc. This abundance of bandwidth has led to the
development of new distributed applications involving multimedia. Most of the highspeed networks offer end-to-end connectivity which do not meet the requirements of
the distributed applications. There is a need for additional various functionality to
enrich the services offered by network. Most current end-to-end protocols offering
such functionality result in a performance bottleneck in high-speed communications,
due to the insufficient processing power of end-systems and missing configurable
options in the end-system protocols. It is becoming difficult for the current protocols
architectures to keep up with the evolving applications. As its very difficult to predict
what the next generation applications will demand from the network, we need a
flexible and extendable end-to-end system. We propose a new flexible mechanism of
configuring functionalities without layering. Protocol configuring is a mechanism
wherein an application is able to select the necessary functionalities to fulfill its
requirements.
1
1.1 Thesis
The goal of this research is to develop an end-to-end protocol system
which supports wide range of application requirements. This is achieved using
dynamic composition of various protocol functions such as error detection,
encryption, connection management etc. This compositional mechanism of protocol
configuration is particularly useful for applications for which performance is
important. Our work is focussed on showing the importance of being able to
dynamically configure protocols during the run-time. We develop a framework which
allows for dynamic configuration of a protocol stack using a modulepool. We also
demonstrate that actual applications can benefit from dynamic protocol
configurations beyond what is available from the current state of the art.
2
1.2 Structure Of Thesis
The thesis is divided into following main chapters,
Chapter 2: Discussion of related work on the static and dynamic configuration of
protocols.
Chapter 3: A description of an example application using our framework.
Chapter 4: Detailed description of the implementation.
Chapter 5: A summary of thesis and suggestions for future work.
3
CHAPTER 2
LITERATURE REVIEW
Distributed multimedia applications are straining the resources of today’s
networks. The ability to better adapt to available resources may provide applications
to continue working well in situations where non-adaptable applications would fail.
Current technology provides applications with very limited communication control
over the communication protocols. Applications are given the choice of specific
protocol stacks and must work around the fact that they cannot easily change
communication parameters. This leaves the burden of maintaining flexible
communication to the application. Configurable protocol systems solve this problem
by supplying applications with a simple model for communication. The configurable
protocol systems manage the communication resources in an independent, modular
manner that is easily accessible by any application.
2.1 Configurable Protocol Systems
A commonly used abstraction for the protocol processing associated with
communication channel is the protocol stack. A protocol stack defines the modules
used for processing messages and in what order they are executed. Configurable
protocol systems provide applications with the ability to choose communication
functionality from a set of available protocol modules. These protocol modules can be
combined in any correct manner into a protocol stack that can provide the
applications with the appropriate service. Such systems can be classified into two
groups on the basis of when the configuration is performed.
4
Connection Time Configuration:
The first level of configurability allows the application to configure its
communication at connection time. Connection time configuration allows the
application to have different communication channels with different service
requirements, by providing multiple protocol stacks. The limitation here is that once a
communication channel has been configured, it cannot be changed during its lifetime.
Connection-time configuration also limits a channel to handling one type of data
correct, since one type of service must be chosen for the lifetime of the
communication.
Dynamic Configuration:
The second level provides applications with the ability to dynamically
configure communication channels at run time. Dynamic configuration solves the
problem of handling multiple data types over one single channel as well as the
problem of changing service requirements over time.
Some examples of connection time configuration and dynamic configuration
are discussed in the next section.
2.2 Related work
2.2.1 x-kernel
The x kernel is a configurable operating system kernel. Communication
protocols such as ARP,IP,UDP,TCP represent the building blocks of the
configuration. Besides the explicit architecture for constructing and composing
protocols, the x-kernel consists of fixed memory and process management
5
components. The x-kernel supports three fundamental communication objects: Static
and passive protocol objects, Passive but dynamically created session objects, and
Active messages whose data part corresponds to conventional messages. All
protocols objects and their relationships are defined at configuration time of and
represent the protocol supported by the configured kernel. The x-kernel provides
light-weight processes. When a message is generated by a user process, a packet is
dispatched to a “shepherd”. The shepherd then guides the message through a series of
protocols and sessions. Messages flow forward and backward direction via their push
and pop operations respectively.
In the x-kernel, protocols are divided into modules. And these modules are connected
in a protocol graph. Connections can choose a protocol path for their communication.
x-kernel can be basically cited as an example for connection-time configuration. It
provides some of the functionality that we are looking for, like the protocol stack
determination.
2.2.2 Da Ca Po
Da Ca Po provides an environment for the dynamic configuration of protocols.
Configuration is done with respect to application requirements, properties of the
offered network services and the available resources in the end systems. The goal of
the configuration is to reduce the protocol complexity and increase the performance.
Da Ca Po is based on a three-layer model (fig 1), which splits the communications
systems into the layers Application (A), Connection (C), and Transport (T). In layer
C, the end-to-end communication support adds functionality to the T services in such
6
a manner that at the AC interface, a full set of services is provided as needed to
support distributed applications (A). The C layer is decomposed into a set of protocol
functions according to their functionlity.
A
Application
C
Connection
T
Transport
AC-Interface
C Layer- End
System
CT-Interface
Transport Layer
Fig 1: The Da Ca Po 3 layer model
The runtime environment of Da Ca Po links modules to protocols in one UNIX
process and realizes an efficient data transport inside the end system because
operations reducing performance like data copying or UNIX context switches are
minimized in Da Ca Po.
2.2.3 Tau Framework
This section discusses the design and features of τ framework.
Design Overview of τ
7
The primary design objective of τ is to provide two mechanisms (protocol function
composition and multiplexing) in a manner that supports various performance –
enhancing techniques while preserving modularity in some form. The idea is that
these mechanisms should work with an extensible set of policies, in order to support a
wide variety of applications, including the applications whose requirements are not
yet fully understood.
The τ framework (fig2) comprises of three parts:
1. A generic model of protocol processing, in which the protocol functions are
separated from the details of the “glue” that binds them together.
2. A metaheader protocol, which provides the basic mechanism for implementing
the primary functions of τ, namely multiplexing and non-layered flexible protocol
function composition.
3. A set of modular protocol functions, structured according to the generic model.
A Generic Model of Protocol Processing:
Per-endPoint State
Information
User Request
Integrated Protocol Configurations
Demux/
Dispatch
τ metaheader
Protocol Function
Modules
Incoming Messages
Fig 2: Architecture of τ
8
Because protocol functions are not layered in τ, they do not attach their headers
directly to outgoing data units, nor extract them from incoming data units; instead this
is handled by the τ infrastructure. The generic protocol model defines the interface
between the τ infrastructure and each protocol function. From the logical block
diagram of τ implementation , we can see that each protocol function is viewed as a
transducer, which is given inputs and produces outputs. The architectural “glue” is
provided by the τ demux-and-dispatch function. Its selects and coordinates the
between the protocol functions providing them with inputs based on external events
and passing on to the external environment their outputs. The interface is defined in
terms of a set of entry points corresponding their outputs. The interface is defined in
terms of a set of entry points corresponding to various external stimuli: incoming data
unit, user request, timer expiry, etc . This allows the protocol function to base its
behavior on the specific situation indicated by the entry point, without having to first
decide what the situation is.
Metaheader Protocol:
The τ metaheader protocol implements the multiplexing and composition
mechanisms. As such , it contains two kinds of information.
Information that the receiving τ can use to efficently retrieve the relevent state
information for the incoming data unit.
Information indicating which set of protocol functions need to be applied to the
incoming data unit.
9
2.3 Summary
In general, all previously presented approaches provide some degree of
flexibility. Furthermore, they all realize modular protocol implementation in order to
enable flexibility and software reuse.
All approaches are placed on top of network interfaces and are concerned with
protocols in between the network interface and the application. They all decompose
protocols into building blocks, and all of them except x-kernel perform dynamic
configuration.
10
CHAPTER 3
PROBLEM STATEMENT
Traditional distributed applications, such as the file transfer protocol (FTP)
and Telnet exchange mostly textual information. In contrast, modern distributed
multimedia applications combine several information types, including
audio,compressed and uncompressed video, still images and numerical and textual
information. The following example demonstates the combination of data types in a
medical imaging and consultation application and the application’s communication
service requirements. This application demonstrate a typical use of this framework
(fig 3).
Protocol Stacks
Sound
Image
Text
Generic Interface
Network Interface
Fig 3: Generic Framework Interface
11
The medical imaging and consultation application handles and exchanges the
following data types: audio, video, still images, telepointers and text (patient records).
Each type of data has different QOS requirements. To transmit video, still images,
and documents, we need high throughput because of the data volume. While
conference participants may tolerate a certain loss in audio and video data, patients
records must be transmitted error free. Furthermore, the decision whether to compress
still images with a particular compression technique depends on the particular user.
The dynamic part of this application is that it has the ability to request different
protocol stacks on a message by message basis. For example, the application may
start out sending text unencrypted, but at some point during the run decide to increase
security. The application simply informs the framework to make use of a new
configuration for text with some type of security protocol. The application has the
knowledge of what type of service it requires and the framework provides the
functionality to provide that service. However, the use of traditional architectures
(layered protocol architectures) with such an application may result in problems such
as redundancy and inflexibility, which are discussed below.

Redundancy
The layering principle leads to redundant placement of protocol functions into
protocols of several layers. One example in the OSI model includes error control. The
data link layer is responsible for performing error control on data exchanged between
neighboring systems, while the transport layer performs end-to-end error control.
Studies in the context of high-speed networks with low error rates have shown that
12
end-to-end error control in more efficient than link-by-link error control. In other
words, error control should be performed only within the end-systems.

Inflexibility
Traditional protocols cannot be tailored to meet the needs of the application on
top of networks. Consequently, most protocols include a certain amount of overhead
for multiple combinations of the cross product networks – application requirements.
The reduction of protocols to the minimum needed functionality is one step towards a
solution of the “slow-software fast transmission” problem. For example, in an
environment with low error probability and applications tolerating some amount of
unreliability, the protocol does not need to perform error control. Excluding protocol
functions like error control, retransmission, acknowledgement and perhaps resequencing reduces the number of processing steps to handle a packet, and thus
increase protocol performance. Thus the applied protocol mechanisms should be
selected according to the application requirements. For instance, strong application
requirements for low delay jitter could be reflected in a protocol applying a forward
error control mechanism instead of selective retransmission or go-back-n mechanism.
Flexible environments should also support easy integration of new protocol
mechanisms. However, the integration of new protocol mechanism in traditional
protocol architectures demands the specification and implementation of new
protocols, which is a long and troublesome procedure resulting in standardization and
implementation overhead.
The discussion of extending network services to meet the needs of distributed
applications using traditional protocols (e.g OSI Model) leads to the conclusion that
13
new flexible approaches are needed to fulfill the broad range of current and future
application requirements. Our framework is focussed on showing the importance of
flexibility by being able to dynamically configure protocols during the life time of
the communication. Also, we may want to be able to turn protocols on and off during
communication. Our experimental evidence demonstrate that actual applications can
benefit from dynamic protocol configurations beyond what is available from the
current state of the art.
14
CHAPTER 4
IMPLEMENTATION
4.1 Environment
Java is chosen as the language for implementation due to the following reasons,

Simple : Java inherits the C/C++ syntax and many of the object-oriented features
of C++. Also some of the confusing concepts from C++ are either left out of Java
or implement in a cleaner, more approachable manner. This makes it easy to use.

Dynamic : Java programs carry with them substantial amounts of run-time type
information that is used to verify and resolve accesses to objects at run time. This
makes it possible to dynamically link code in a safe and expedient manner.

Object oriented: Java has very clean, usable, pragmatic approach to objects. Also
object model in Java is simple and easy to extend.

Multithreaded support: Java supports multithreaded programming which allows
us to write programs that do many things simultaneously. The Java run-time
system comes with an elegant yet sophisticated solution for multiprocess
synchronization that enables us to construct smoothly running interactive systems.

Portability : Java’s goal of “write once; run anywhere , any time forever” makes it
easy for program portability.

Distributed : Java has an extensive library of routines for easily coping with
TCP/IP and UDP/IP.
The underlying network architecture used is 10Mb/sec Ethernet local area network
consisting of Sun workstations running Solaris 2.6.
15
4.2 Details of the Framework
Different design and implementations paradigms used in the framework are explained
in this section
4.2.1 Outline
The primary objective of this framework is to allow applications the flexibility they
may need based on their QOS requirements. The result of this flexibility includes
allowing the ability to change communication configurations on the fly,

Configuration Protocol – Takes care of dynamic connection management.

SendThread – processes the messages which are meant to be sent to other
ConnectionManager.

ReceiveThread – processes the received messages and takes appropriate actions.

Transport Protocol – uses UDP/IP to send/receive messages to/from the network.

Module Pool – Stack of different protocol functions.
The architecture of framework is divided in three main layers. The topmost
layer is an Application layer and the bottommost layer is the transport layer(UDP/IP).
The actual processing of information is done in the middle layer which constitutes
different threads performing different activities depending the different datatypes.
Also the modulePool resides in the middle layer.
16
4.2.2 Framework static components
The static entities used in the frameworks is as shown in the diagram below.
The TopMessageQ, ApplicationQ(s), clientserverSendQ and clientserverRecvQ are
the instances of MessageListQueue. The State information is stored in various
hashtables which are declared in the class StateInfo. The modulepool comprises of
four objects viz checksum, encryption, retrans and multicastretrans.
TopMessageQ
ApplicationQ(s)
ModulePool
Checksum
Encryption
SystemTables
Retrans
MulticastRetrans
ClientServerRecvQ
ClientServerSendQ
Fig 4 Static components of FrameWork
Systemtables: These are the Hashtables necessary to store information for each
configuration. They include AppIdToDestination table, AppIdToConfigID table,
17
ConfigIdToAppId table and SystemInformation table. The systeminformation table
maps the configId to the modules which are selected for that configuration.
TopMessageQ: This queue holds the messages sent either by the application or
configuration protocol. These messages are picked by the Send Thread for further
processing.
ApplicationQ(s): These queues store the data messages which are picked up by the
applications.
ClientServerSendQ: This queue holds the messages which are sent by the Send
Thread and later picked up by the UDPThread.
ClientServerRecvQ: This queue holds the messages received from the network by
the UDPListenThread.
ModulePool: It’s the protocol stacks which comprises of checksum, encryption,
retransmission and multicastretransmission. It can simply be enhanced by including
any new protocol function.
Checksum: This module performs the function of parity checking [4].
Encryption: This module encrypts the data to provide security[4].
Retrans: This module provides the reliability for unicast transmissions. It uses the
selective retransmission mechanism to provide reliability.
MulticastRetrans: This module provides the reliability for multicast transmissions.
18
4.2.3 Framework Architecture
Application
SendThread
ReceiveThread
Transport Protocol
Data Message
Fig 5 Framework Architecture
Control Message
19
Use Case 1: ctrl message
Application
SystemInterface.register()
ConfigProtocol.doProcessing()
TopMessageQ
SendThread
Transport
Protocol
ClientServerSendQ
Fig 6 Control Message Sequence
Use Case 1: ctrl message
Application
SystemInterface.send()
TopMessageQ
SendThread
Transport
protocol
ClientServerSendQ
Fig 7 Data Message Sequence
20
4.2.4 Configuration Protocol
The configuration protocol processes new configuration requests. The
doProcessing function of this class does the function of assigning configuration
identities to the new requests. The Configuration protocol puts the request messages
in the TopMessage queue which is then taken by the SendThread. Each configuration
is done per message type(data type) per application. A unique identifier is assigned to
each configuration to distinguish the configurations used by different applications
having the same data types. The steps followed by the configuration protocol when
the application requests a new configuration are shown below:
1.
Application requests a new configuration by providing its AppId and the
DataType for which the configuration is desired. This is done by selecting the
desired modules from the modulepool.
2.
The configuration protocol then forms a unique identifier called the configId
for the requested configuration.
3.
It then forms a control message with type “ctrl” and appends it to the AppId,
ConfigId, Data Type and the Modules needed and sends it to the SendThread.
SendThread then negotiates with the peer connection Managers on establishing new
configuration.
21
4.2.5 Send Thread
The SendThread is the thread which process all sorts of messages which are
meant to be passed to the other connectionmanager. It waits for the messages from
the topmessage queue. As soon as the message arrives it first check for the
messagetype. If the message is found to be control then it saves the state of that
control messages in appropriate hashtables and sends it to the clientserverSendQ. If
the message is data then it is passed through different modules according to the
configuration of the message. If the message is timeout then it sends the nack
message for the appropriate messageList.
4.2.6 Receive Thread
It processes the received messages and takes an action according to the
messagetype. If the message is of type data it passes is through different modules
using from its configid. If the message is of type control then it changes the system
tables. If message is of type control acknowledgement then it updates its system
tables to make sure that the new configuration request was accepted. Similarly it
appropriately processes other messages like ‘nack’ and ‘end’.
22
4.2.7 Transport Protocol
It uses UDP/IP suite as an underlying transport machanism. It uses
datagramsocket for message communications. The data sending operation is
performed by UDPThread and data receiving operation is performed by
UDPListenThread.
The steps in the UDPThread is explained as follows,

The UDPThread starts by opening a UDP socket connection. It contains the
mapping of server name and port number to alphabet in the form of address
Table. This address table is established at the start of connection manager which
copies the content of system file.

When it receives a message from the clientserverSendQ, it removes the
destination name from the message, packs the message into a string and sends it
to the peer whose address is obtained from the address table.
The steps in the UDPListenThread is explained as follows,

The UDPListen Thread is initiated by the UDPThread.

When the UDPListen Thread receives a message from the network, it unpacks
the message and sends the message to the clientserverRecvQ from where the
Receive Thread picks that message.
23
4.2.8 System Interface
The framework interfaces with the applications using the SystemInterface class.
The necessary functions to for this are
Register(): Registers an channel with a give set of properties.
SendMessage(): Used to send data message to other connection manager(s).
ReceiveMessage(): Used to receive the message for a particular channel. The channel
name had to be provided as parameter.
Join(): Used as non-blocking join by an application.
JoinBlock(): Used as blocking join by an application. The application can use this
interface to make sure that a channel was not formed before it registers one.
4.2.9 Timer Management
The framework is responsible for the timer management. It starts a timer thread for
the control messages and Generic timer thread for all other messages. When an event
in the timer queue times out, the generic timer thread picks that up and puts in the
internal message queue which is then processed by internal message thread. The timer
thread takes care of the control message time out events.
24
4.3 Run-Time Environment
The runtime environment is provided by the sendThread and receiveThread.
4.3.1 Message Forwarding
SendThread
Application
1
2
3
4
Transport
protocol
ReceiveThread
Fig 8 Message Forwarding
The send Thread receives the data message to be send and passes it through
different modules. As the message is passed from each modules returns with its call
whether to forward the message or not. Each module is provided the information of
where its header position is, when the reconfiguration is done. So the modules can
attach or remove headers to the message. Therefore the messages reach the transport
layer using the Send Thread.
The receive Thread does the reverse of Send Thread. It picks the messages
from the transport layer and passes the messages through each of the modules as
defined in its configuration. Each modules returns a boolean variable which
determines whether to drop the message or to pass it on to the next module.
25
4.3.2 Synchronization
As the multiple threads access the queues and also different system tables we have
used the Java synchronized method to ensure that only one thread is having access to
the resource at a time. Also object notification technique of Java was used for
achieving blocking.
4.4 Performance Testing
We carried out performance testing on a 10Mbps LAN on different Sun Servers
running Solaris 2.5/2.6.
For the unicast channels we tested using different modules and the results were
displayed in the following table.
The test file is of different sizes were used for testing. Time was recorded when the
first transmission is made. Time was also recorded at the received end after the
receipt of last transmissions. The difference between two recorded time was taken as
the total transmission time from end to end.
Modules Used
For 5 KB File
Time Taken
No Framework
387 mSec
No Module
946 mSec
Checksum
1145 mSec
Checksum, Encryption
1439 mSec
Checksum, Encryption, Retrans
1512 mSec
26
Module Used
For 10 KB file
No Framework
716 mSec
No Module
1566 mSec
Checksum
1922 mSec
Checksum, Encryption
2174 mSec
Checksum, Encryption, Retrans
2215 mSec
Module Used
For 20 KB file
Time Taken
Time Taken
No Framework
1310 mSec
No Module
2639 mSec
Checksum
2932 mSec
Checksum, Encryption
3024 mSec
Checksum, Encryption, Retrans
3612 mSec
For Multicast Channels, we used three different servers and carried out the test using
the same set module as did for the unicast channels.
As in the case of unicast channel testing we used files of different sizes. The average
receipt time is subtracted from the start time of the sender to record to the total
transmission time. The result is recorded in the following tables.
27
Modules Used
Time Taken
For 5 KB file
No Framework
685 mSec
No Module
1682 mSec
Checksum
1744 mSec
Checksum, Encryption
Checksum, Encryption, Multicastretrans
Modules Used
For 10 KB file
1987 mSec
2117 mSec
Time Taken
No Framework
1035 mSec
No Module
2899 mSec
Checksum
3107 mSec
Checksum, Encryption
3368 mSec
Checksum, Encryption, Multicastretrans
3784 mSec
Modules Used
For 20 KB file
No Framework
2160 mSec
No Module
5373 mSec
Checksum
5611 mSec
Checksum, Encryption
5946 mSec
Checksum, Encryption, Multicastretrans
7122 mSec
28
From the performance evaluation we conclude that the framework will have relatively
good performance for applications sending long messages in less number.
29
CHAPTER 5
CONCLUSION
5.1 Summary
Dynamic configurable protocol stack is an efficient way of end-system
protocols that support wide range of application requirements. We conclude that this
work will suggest future research activities.
Our experience suggests that applications can simplify their design and
improve their performance by dynamically configuring protocol functions. Such a
general approach includes the overhead in comparison to highly specialized
monolithic protocols, but the diversity of current and future multimedia application
requirements and network services makes it hard to implement for every combination
a special protocol. The multithreaded architecture of framework makes it possible to
improve the performance on a multiprocessor system.
5.2 Future work
As a future work we suggest to provide applications with feedback from the
network and to provide a mechanism to evaluate the module properties. We also
propose to use dynamic configuration into the transport layer. Framework can also be
extended by providing simultaneous execution of different modules.
30
REFERENCES
[1]
Vogt M., Plagemann T., Plattner B., Walter T.: “A Run-time Environment for
DaCaPo”, in Proc. Of INET’93, Int, Networking Conf. Internet Society, San
Francisco, August 1993.
[2]
Plagemann T., Plattner B., Vogt M., Walter T., “A Model for Dynamic
Configuration of Light-Weight Protocols”, in: Proc. IEEE Third Workshop on
Future Trends of Distributed Computing Systems, Taipei, Taiwan, April 92.
[3]
Kravets R., Calvert K., Schwan K., “Dynamically Configurable
Communication Protocols and Distributed Applications: Motivation and
Experience”, College of Computing Technical Report GIT-CC-96-16.
[4]
Nandyal S., “A Framework for Protocol Composition”, a Master’s Project,
Kansas State University 1998.
[5]
Plagemann T., “Framework for Dynamic Protocol Configuration”, Swiss
Federal Institute, 1994.
[6]
Hutchison N. C., Peterson L. L., “The x-kernel: Architecture for implementing
Network Protocols”. Department of Computer Science, University of Arizona,
1990.
[7]
Bach M. J, “Design of the UNIX Operating System”, Prentice-Hall Software
Series, Prentice-Hall International Inc. 1986.
[8]
Suryanarayan S, “Connection Management Protocol”, Master’s Thesis,
Kansas State University 1998.
31