arXiv:1508.07547v2 [] 22 Mar 2016

Protocol Programming: A Connection
of the Digital World
Yanping Chen,1∗ Qinghua Zheng,1 Ping Chen2
1

2

Xi’an Jiaotong University, China
University of Massachusetts Boston, USA

E-mail: ypench@gmail.com, qhzheng@mail.xjtu.edu.cn, ping.chen@umb.edu

The current computer programmings encapsulate attributes and behaviours
into objects, but miss the mechanism to support the connection among objects.
A programming paradigm is presented to connect all objects. The connection
supports communications. Protocols are defined to coordinate the behaviours
between objects, which enable the interaction of objects across different platforms. The connection also provides an efficient mechanism to support the
concurrency, parallelism, distribution, pipeline and adaptability, etc. They
can be governed transparently, autonomously, even adaptively. In this paper,
an implementation is also discussed to show the effectiveness of protocol programming.

Connection is the norm
The connection between entities is an important aspect of the world. Large objects as celestial
bodies or small objects as biomolecules are connected, by gravity or conjugation, and organized
into a galaxy or an organism. The connection should not be treated as an attribute of an object.
It has a powerful influence on the connected objects. For example, gravity controls trajectories
of celestial bodies, chemical reactions determine the transformation between substances. And
relations, e.g., food chain, heredity, etc. judge the fittest and influence the evolution of species.
The connection condenses substances into the cosmos, synthesizes amino acid and brings the
life. All things are influenced or developed by connecting with others.
1

In this article, we define “connection” as the channel for interactions between objects. Usually interactions are not random, they show a clear pattern. The patterned interaction is referred
to as “communication” in this paper. The connection supports communications between objects. It is the core idea of our method, we give an example for easier understanding. Let’s
consider the ocean, the land and the sky as a platform for the the biological world. Animals
wander around the platform. It should be emphasized that the ability for an animal to ramble
is important, referred to as “autonomy”. It enables animals to change to fit its surroundings.
Strolling animals are connected by inhabiting or encountering with each others. In the wild,
passing each other does nothing about the communication. The communication between them
is established by giving birth to, feeding, preying, fighting, etc.
In the digital world, to imitate or encode a system under a programming paradigm, the modularity is an important issue, which supports structured programming. Modules (e.g., classes
or functions (1, 2)) are used to encapsulate objects and partition a system into different parts.
However, in practice, it is common that a complex problem can not be perfectly partitioned. For
example, to design a building, some parts of a building (e.g., the water supply or power system)
are difficult to be encapsulated. This is also known as the crosscutting issue (3). It makes the
code tangled and increases the cost of communication among developers when designing and
developing a system (4). Furthermore, in object-oriented programming, an object is merely
nested in another object as a member variable. The inner object is restricted by the holder that
difficult to be shared with others. It also sacrifices the autonomy of an object, making it difficult
to update independently.
Without a mechanism to support the connection appropriately, a hard partition hurts the
communications between objects. In the traditional programming paradigms, various approaches
are applied to support communications between objects. For example, objects can be used as
function parameters or member variables of other objects. Inheritance is used to represent relations between classes. It does nothing about the communication unless static members are
defined in the declaration (5). Then instantiated objects can share the same variables for communications. Others such as message passing, semaphore, shared memory, socket, etc. are
widely adopted to support communication. Because the lack of the connection between objects,
these approaches are used to support the communication weakened by separating a system into
discrete parts. Traditionally, the connection as a mechanism to support communications has received less attention. The communications between objects are temporary and irregular, mainly
used to exchange data or control resource competition if required. It is rarely formalized as a
2

connection mechanism to support communications.
Compared to the traditional paradigms, connection in protocol programming is developed
into a new territory. Under the protocol programming, programming is divided into two steps:
protocol implementation and domain implementation. Protocol implementation builds an infrastructure to support the communication between objects. Protocols are defined to control
the communication between them. By inheritance from a protocol implementation all instantiated objects are automatically connected into a network. Domain implementation is developed
by traditional programming paradigms, encapsulating attributes and behaviours into objects.
While supported by protocol implementation, partitioning a system into discrete models and
reorganizing them become easier and more effective.

Connection creates possible
Building a system is usually not a trivial matter. It is often partitioned into discrete modules
(e.g., procedures, functions, objects, agents, aspect, etc.), then a team is set up to implement
each module separately. It is generally accepted that a modular design is the key to successful
programming. All programming paradigms have mechanisms to support structured programming, where the modularity is guaranteed. Systems developed by structured programming have
good stability, efficiency, maintainability and expansibility. The main obstacle for structured
programming is that some problems are difficult to be partitioned. In some projects, design
decision is scattered throughout a system. A hard partition breaks the connections between
modules and hurts the communications between them.
In the digital world, to support the partition and connection between modules, many program paradigms are developed, e.g., agent-oriented programming (6), aspect-oriented programming (7). Based on message passing, mechanisms are proposed for communicating between
threads or processes (e.g., Message Passing Interface (8), Erlang (9), Hoare et al. (10)). The
communication across different systems are also designed (e.g., MapReduce (11), serviceoriented computing (12), CORBA (13)). In a program, mechanisms (e.g., semaphore, shared
memory, socket, message passing) are used to support the communication between partitioned
modules. Because implementation of these mechanisms is not transparent to programmers,
it may lead to many issues such as mutual exclusion, interrupts, data conflict, resource competition, etc. When building a system, these mechanisms increase the burden of design and
implementation, and make the code difficult to understand and maintain. Furthermore, when a
3

system is complex enough, partitioning it, defining the interfaces and integrating every part are
very challenging. The cost to design, develop and maintain such a system and the communication between developers are increased considerably (4).
To better illustrate our ideas, we analyse two systems (the Internet and the biosphere), which
show the motivation of protocol programming.
Since the invention of packet switching theory (14), for half a century, the Internet has expanded into a huge system with billions of access points and numerous applications (15). At
the dawn of computer communication (16), it is difficult to foresee that human society can build
such a complex system. Despite various techniques are developed to accelerate the growth of the
Internet, the most important technique is the Internet protocol deigned for the open-architecture
network environment. Under the internet protocols, every equipment is independently connected into the Internet and the information between them are routed automatically. The Internet protocol hides the underneath implementation of connected modules. By following the
Internet protocol, each part of the Internet can conveniently interact with each other across heterogeneous platforms or systems. Moreover, because the Internet protocol is a connectionless
service, each part can be updated independently.
The biosphere is a largely self-regulated system. The earth can be seen as a platform for life
to compete. Individual organisms of the earth encounter on the land, in the air or the water. The
connection (encounter) is an important aspect for life on the earth. After the connection was
constructed, the interaction between them is not random. They follow inherent patterns (e.g.,
foster, prey, competition, hereditary and variation) in the same way as the protocol. Life in the
biosphere is ruled by these patterns, referred to as laws in biology. Hereditary and variation are
two important laws determining the survival of a species and the evolution of the living nature.
Many factors can disturb the natural stability of the biosphere, e.g., the geographical or climatic
factor, the species diversity and the food chain, etc. They are the motive force for the species
variation. The variation enables that a species can adapt to the environmental change. “survival
of the fittest” ensures that the suitable change is inherited. Accumulated changes in individuals
or species give rise to the evolution of the species.
Designing or constructing a system like the Internet or the biosphere in one step is far beyond
human ability. They are not built, but evolved. Five characteristics can be induced from such
systems. Each system should consist of modules or individuals that are mutually independent,
which enables the separableness. Individuals can interact with each other and the connection
is guaranteed. The interactions between individuals are not random, they follow predefined
4

or evolved patterns. Then the communication between them is established. For a system that
supports evolution, individuals have the ability to change, which enables the fittest is reserved,
and the adaptability is possible.
A system is a set of interdependent and interacting modules (components or individuals),
which forms an integrated whole. If partitioned modules are unrelated, the system is static and
inactive, shows no interaction. In a dynamic, autonomous or adaptive system, the interconnectivity between modules is required. The separableness ensures that a system can be partitioned
into modules, so each module can be designed or developed independently. It is the premise
for concurrency, parallelism and distribution. Modules of a system can be connected by structural, functional, behavioural relationships. The connection bands partitioned modules together.
Then the interaction between modules would occur frequently. Many interactions are not random. They will show some kind of patterns (e.g., protocols and laws in the Internet and the
biosphere). These patterns are the manufactured products of the communication, which makes
them coordinate, compete, develop and struggle for existence. The connection supports communications. In traditional paradigms of the digital world, the communication is supported by
limited approaches, e.g., semaphore, shared memory. They are mainly designed for exchanging
data between partitioned modules in a system. No valid channel is provided for every object
that they can communicate without any constraints.
Motivated by issues discussed above, a protocol programming paradigm is presented for
designing and implementing a system. Protocols are predefined communicating patterns. They
are used to connect and coordinate each module in a system. In this paradigm, programming is
divided into two aspects: protocol implementation and domain implementation. Protocol implementation provides a platform for connecting or coordinating instantiated objects. Domain
implementation can use the traditional methods to encapsulate objects. But supported by a protocol implementation, when designing and encoding a system, the development process become
simple. Because the communication can be designed to be connectionless, modules can have
the ability to update itself without stopping the system.
In order to show the methodology of protocol programming, next, we give a simple discussion about the implementation developed in our work.

5

Protocol Implementation
Our protocol implementation has two layers: transmission layer and service layer. The transmission layer supports the connection, providing a channel for communication. In this layer, a
protocol is designed to establish a thread network, referred to as the connecting network. The
service layer supports the connected objects to register, require and execute a service according
to a defined protocol. The framework about the programming paradigm is shown in Figure 1.
Object
2

Working Thread

2
2
2

Domain Layer

Domain Imp.

2

Acting Thread

Service Layer

Connecting Thread
Configuring Thread
Connecting Network

Transmission Layer

Protocol Imp.

Executing Thread

Figure 1: Protocol Programming Architecture
The protocol implementation is divided into different layers. Each layer is implemented by
a class. If a class implements a non-bottom layer, this class should inherit from a parent class
that implements a lower layer. It is better that each layer is designed to be transparent, only the
interface is known by the upper layer the same as the OSI model (17). Every object instantiated from the transmission layer is connected into the connecting network, where all messages
between objects are transmitted automatically. In the service layer, the service configuration,
registration, request and execution are performed. In the domain layer, each object implements
specific work. Next, the paradigm is discussed.
In the protocol implementation, the connection and communication are done by transmitting
messages from one thread to another. Unlike transmitting an IP package through the Internet,
in a local environment, all messages share the same memory space. Therefore, only the address
of message is posted between threads. The structure of a message is given as follows, where

6

PMessage is a class. Every message is an instantiation of this class or its sub-class.
PMessage{
LAYER m Layer;
ACTION m Action;
ADD m Intend;
ADD m Creator;
bool m NeedEchoF lag;
size t m T imeT oLive;
TIME m CreateT ime;
vectorhADDi m Route v;
vectorhstringi m P aram v; }
The LAYER and ACTION are enumerated data types. The field m Layer is used to indicate
which layer a message should be delivered for further processing. Three types are defined, representing each layer respectively. Each layer supports a certain numbers of actions suggested
in the field m Action. The ADD represents the address (or identification) of an object. The
fields m Intend and m Creator are the destination and creator of a message. In the field
m NeedEchoF lag, a true value indicates that a response is required by m Creator. The
m T imeT oLive is a hop count used to limit a message’s lifetime. The m CreateT ime can
be used to line up arrived messages for avoiding problems such as data access violation when
accessing a critical resource. When a message is transmitted through the network, the field
m Route v can be used to record the route information. The field m P aram v stores parameters of message.

Transmission Layer
The main purpose of the transmission layer is to build an infrastructure for message transmission. We design a class named as PTrans to do this. Three threads are created in each
instantiated object of PTrans: configuring thread, connecting thread and acting thread, used for
configuration, connection and action respectively. They run concurrently.Five kinds of actions
are defined in the transmission layer: CONFIG, HELLO, ECHO, TICK and EXIT.
All messages are posted through the connecting thread. A connecting thread retrieves messages from its message queue. If a message’s destination matches itself, the message is taken
off. Otherwise, it is retransmitted according to a routing protocol. Because other messages in
its message queue may be waiting for transmitting, it is not reasonable to spend too much time
for processing a message in the connecting thread. The connecting thread pushes its message
7

into a transmitting message list and return immediately. All messages in the list are processed
by the acting thread. If the message list is empty, the acting thread is blocked. If a message is
added, the connecting thread sets a semaphore. Then the acting thread is waken up to process
the arrived message.
In protocol programming, the most important problem is how to make every object connected. The topology of connecting network determines the strategy to establish it. In our
implementation, we design a tree structure. The object in the structure also is referred to as
node. The Master is the root of the structure and a leaf node is an object without any child. In
our implementation, every object is identified by the connecting thread handle. The child object
(the child) is used as a member variable of a parent object (the parent). The child has its parent’s
connecting handle as a parameter for initialization. Then, after all objects are initialized, except
the root object, every object knows its parent’s connecting handle.
After a child is initialized, using parent’s connecting handle, the child reports its connecting
handle to its parent by posting a CONFIG message, then waits for a response. The parent
collects the child’s identification from the message and posts a message in return. After this
process, each pair of parent and child know the connecting threads between each other. All
configuring threads exist except that in the Master, which will be running until the system
terminates.
The configuring thread in Master broadcasts a HELLO message to all its children to start a
connecting process. The Master will wait until all responses of its children are returned. After
a HELLO is received from its parent, every object also broadcasts a HELLO to its children.
It responds an ECHO to its parent in two conditions: all feedbacks from children are returned
or it has not child at all. In a concurrent environment, some threads may be blocked or suspended, if a time-out error occurs,, the Master can restart a new connecting process. When
children’s ECHO arrive at the Master, it means that every object is instantiated successfully.
A connecting tree structure is established.
All messages are transmitted in the connecting network. If there is no message to process, a
connecting thread is blocked by calling a GetMessage(&msg, ...) function. A blocked connecting thread is aroused by arrived messages. Because all threads are running concurrently that
some threads may be jammed or blocked, the TICK message is used to check the state of an
object. The EXIT is used for system to exit. Every node retransmits this message to its children.
All nodes from the leaves to the root will release its resources and send a response to its parent.
It the arrived message does not belong to the transmission layer, the acting thread calls a
8

pure virtual function Trans Outlet to process it.
Interface
The connecting thread and the Trans Outlet are the interface between the transmission layer
and the service layer. In the service layer, a requirement is submitted by using the handle as
parameter to post messages, and the Trans Outlet is overridden to provide services.

Service Layer
In this paper, a domain service (or a service for short) is defined as a function that can be
executed to support a request in an application. It is provided in the domain layer. The service
layer doesn’t provide any domain service. The major function of the service layer is to supervise
the services provided in the domain layer.
The service layer is implemented by a PService class inherited from the PTrans. The pure
virtual function Trans Outlet in transmission layer is overridden in the PService class. Because the PTrans is inherited, any object instantiated from the PService class is automatically
connected into the connecting network. If a matched message cannot be processed in the transmission layer, the function Trans Outlet will be called. Three actions are defined in the service
layer: REG, REQ and ACK.
Because the implementation of service layer is transparent and independent from the domain
service. Therefore, the service layer should be given the information about a domain service.
A PServicedepict class is defined to contain this information, named as the service description. Each service must have a service description. The content of the service description is
introduced next.
The service register is started by the Master through broadcasting a REG message to its
children. The REG message is spread from the root node to all leaf nodes. Every node collects
service descriptions from its children and reports all services it knows to its parent. When the
service description transmits through the connecting network, routing information is collected.
With this protocol, every object contains service descriptions about it and its children. The
Master knows the all services in a system.
If a service is requested by an object, it is done by packaging a REQ message into the
connecting network, where the name of the service and possible parameters are filled. In our
implementation, a string matching strategy is used to match a service. When requesting a

9

service, the synchronization and asynchronization should be considered. In asynchronously
calling, the object keeps going after a requirement was posted. Otherwise, it is blocked to wait
an ACK message. The message is packaged by calling a requesting function defined in the
PService class, then transmitted from the requesting object towards the Master. If an object
has a service description matching this requirement, the message is retransmitted to the provider
directly by routing information in the service description.
If a REQ message arrives at its provider, the message is appended into a local message
list of the PService class, named as the service message list. An executing thread defined in
the class is always waiting for processing each message respectively. Two approaches can be
used to implement a service: a thread or a function. Their addresses are stored in the service
description. In the service description, two fields are declared to indicate which approach is
supported and whether or not the service is reenterable.
Many mechanisms can be designed to support the execution of a service. For example, for
a specific service, if the service is executed by a thread, then the service message can be posted
into the thread directly. If a service is declared in a class in the domain layer, then for each
arrived message, a new object of the class can be instantiated to handle this service. If the codes
are reenterable, it is possible to create a new thread to process each message separately and
concurrently. Furthermore, the dynamic scheduling can be designed to support the load balancing. These mechanisms are automatically supervised in the service layer. Only the service
descriptions are shared between the service layer and the domain layer.
After a REQ message is executed, if a response is required in the synchronously calling, it
will return an ACK message.
Interface
One interface of the service layer is the requesting function, where the REQ message is generated and posted into the connecting network. Another interface is a service description list. It is
a member variable of the PService class used by the domain layer to report its services.

Domain Implementation
In domain implementation, the traditional programming methods can be used to provide the
domain services. However, by inheriting a protocol implementation, all instantiated objects are
connected into the connecting network. Every connected object can communicate with each
10

other by predefined protocols. Therefore, the difficulty to partition a problem into discrete tasks
is reduced. Following the predefined protocol, every module can be developed independently.
Because the concurrency, distribution, or load balancing, etc. can be supported transparently by
the protocol implementation, it also reduces the burden to develop the domain implementation.

Evaluation
Three classes, inherited from the PService, are declared in the domain layer. Each provides
a toy service, named as Service1, Service2 and Service3. They separately execute 1 × 106 ,
2 × 106 and 1 × 106 Floating Multiply Instructions (FMI). Three objects are instantiated from
each class respectively. They are connected into a connecting network with a Master object
instantiated from the PService class.
In the first experiment, the monotone model runs every service in a single function without
transmitting message. In the sequence model, the Master orderly executes each service by
synchronously posting the REQ message to the three objects. In the pipeline model, the objects
are organized in a line and asynchronously called from one to another. They are executed
simultaneously. Because the computation complexity of the Service2 is doubled, it becomes
the bottleneck in the pipeline model. In the super pipeline, two objects are instantiated to
provide the Service2 service. Running time1 of the four models is shown in Figure 2(a).
5

16
14

105

104

103

4

10

Speedup

Time (sec.)

12

106

Monotone
Sequence
Pipeline
Super pipeline

8
6

3

2

4

1
2
100 200 300 400 500 600 700 800 900 1000

100 200 300 400 500 600 700 800 900 1000

Rounds

Rounds

(a) Time Consuming

(b) Speedup of Super Pipeline

Figure 2: Evaluation of Protocol Programming
In Figure 2(a), the performance of the monotone model can be seen as a benchmark. In the
1

The evaluation uses a Window 7 OS with Intel i5-2400 3.10GHz 4 Core CPU and a 8 GB memory.

11

sequence model, because synchronously calling is used, the time consuming is increased due to
message transmitting. In the pipeline model, the expense caused by transmitting messages can
be offset by allowing the services to be processed simultaneously. The super pipeline has a load
balancing mechanism, therefore, the highest performance is received.
In Figure 2(b), the speedup2 of the super pipeline model is compared using different numbers of FMI. When the number of FMI is decreased exponentially in each service, the speedup
is decreased accordingly. When the number of FMI is decreased to 103 , the cost of transmitting
message negated the superiority of the super pipeline. Therefore, the speedup is less than 1.
The implementation has a very high speedup, because, instead of a single thread, multi
threads are used to implement the services. The main advantage of protocol programming is
that the concurrency is managed automatically by the protocol implementation.

Discussion
In protocol programming, three types of objects exist: the Master object, the Server object
and the Router object. The Master is designed for governing a system. It is also helpful to
use multi-master objects in a system. Each performs a specific assignment. The Server refers
to the object who provides the service. A Router is a node, which only transmits messages and
no service or management is assigned. It can can be used to organize a system or partition the
message space. In a system, mixed objects can be used.
After a system is initialized, every object inherited from the PService class will have at
least three threads. All communications between them are performed by message transmitting.
Therefore, the concurrency is naturally supported. When a system is running, objects can be
added or erased from the connecting network dynamically, which can be used to support the
dynamic scheduling and the load balancing.
Because the connecting network provides a connectionless service to all objects, the service
provided by the program can be updated without stopping the system. Other methods developed in the Internet protocol can be introduced for the protocol implementation, e.g., domain
name service, error control, structured naming strategy, etc. In addition to keeping the program
and the service description locally, Both can be registered and stored in a remote server, then
accessed though the Internet. If a service is supported in a remote system, the message can be
transmitted across the Internet and executed in the remote system. If possible, the program can
2

It is computed by dividing the time consuming in the monotone model and the super pipeline model.

12

also be downloaded directly and run locally.
In summary, the advantages of the protocol programming include: (a) a novel paradigm for
programming is presented, which divides the process into two aspects: protocol implementation
and domain implementation. (b) the connection as a mechanism to support communication for
programming is emphasized and developed. (c) protocols are designed to control the communication between objects, which enables the communications across heterogeneous programs,
systems and the Internet. (d) Because one protocol implementation can be shared by different
applications, it ensures a broad range of code reuse. (e) mechanism such as concurrency, parallelism, distribution, pipeline and adaptability, etc. can be governed transparently, autonomously,
even adaptively. (g) it supports the autonomy of objects, which enables an object to update itself
when the system is running.

References
1. P. Hudak, ACM Computing Surveys 21, 359 (1989).
2. D. J. Armstrong, Communications of the ACM 49, 123 (2006).
3. T. Elrad, M. Aksit, G. Kiczales, K. J. Lieberherr, H. Ossher, Communications of the ACM
44, 33 (2001).
4. F. P. Brooks, The mythical man-month, vol. 1995 (Addison-Wesley Reading, MA, 1975).
5. R. J. Wirfs-Brock, R. E. Johnson, Communications of the ACM 33, 104 (1990).
6. Y. Shoham, Artificial intelligence 60, 51 (1993).
7. G. Kiczales, et al., Aspect-oriented programming (Springer, 1997).
8. W. Gropp, E. Lusk, N. Doss, A. Skjellum, Parallel computing 22, 789 (1996).
9. J. Armstrong, R. Virding, C. Wikström, M. Williams (1993).
10. C. A. R. Hoare, Communications of the ACM 21, 666 (1978).
11. J. Dean, S. Ghemawat, Communications of the ACM 51, 107 (2008).
12. M. P. Papazoglou, Proceedings of the WISE ’03 (IEEE, 2003), pp. 3–12.
13

13. J. Siegel, Communications of the ACM 41, 37 (1998).
14. L. Kleinrock, RLE Quarterly Progress Report 1 (1961).
15. B. M. Leiner, et al., ACM SIGCOMM Computer Communication Review 39, 22 (2009).
16. T. Marill, L. G. Roberts, Proceedings of the AFIPS ’66 (ACM, 1966), pp. 425–431.
17. H. Zimmermann, IEEE Transactions on Communications 28, 425 (1980).

14

