A

Technical Seminar report on

DATA ACTIVATION REPLICATED OBJECT COMMUNICATION
Submitted in partial fulfillment of the requirements for the award of degree of
BACHELOR OF TECHNOLOGY
In
COMPUTER SCIENCE AND ENGINEERING
By
P.Saisruthi
(163T1A0579)
Under the guidance of
Mr. K.Vijay Kumar

Department of Computer Science and Engineering

RAVINDRA COLLEGE OF ENGINEERING FOR WOMEN

Approved by AICTE, New Delhi & Affiliated to Jawaharlal Nehru Technological University
Anantapur, Ananthapuramu Pasupula (v), Nandikotkur Road, Kurnool – 518 452, Andhra
Pradesh
www.recw.ac.in
2016-2020
 RAVINDRA COLLEGE OF ENGINEERING FOR WOMEN
Approved by AICTE, New Delhi & Affiliated to Jawaharlal Nehru Technological University
Anantapur Anantapuramu Pasupula (v), Nandikotkur Road, Kurnool – 518 452, Andhra
Pradesh
www.recw.ac.in

Department of Computer Science and Engineering

CERTIFICATE
This is to certify that the Technical Seminar entitled “DATA ACTIVATION REPLICATED
OBJECT COMMUNICATION” is being submitted by P.Saisruthi (163T1A0579) in partial fulfillment
for the award of degree of BACHELOR OF TECHNOLOGY in COMPUTER SCIENCE AND
ENGINEERING Jawaharlal Nehru Technological University Anantapur, Ananthapuramu during the
academic year 2019-20 is a record of bonafide work carried out by him under my guidance and
supervision.

Guide Head of the Department

Mr.K.Vijay Kumar Dr.K.SRINIVAS
Assistant Professor Professor & H.O.D

Date:
 ACKNOWLEDGEMENT

I take immense pleasure to express my deep sense of gratitude to my

be guide Mr.K.Vijay Kumar, Assistant Professor, Department of CSE,
RAVINDRA COLLEGE OF ENGINEERING FOR WOMEN for his guidance and
suggestions, keen interest and thorough encouragement extended
throughout period of Technical Seminar.

With immense pleasure, I express my deep sense of gratitude to my Head of

the Department, Dr.K.SRINIVAS, Department of CSE, RAVINDRA COLLEGE OF
ENGINEERING FOR WOMEN, who had been a source of inspiration and for his timely
guidance in the conduct of my Technical Seminar.

I express gratitude to my Principal, Dr.Krishna Murthy, RAVINDRA

COLLEGE OF ENGINEERING FOR WOMEN for his encouragement and
cooperation in carrying out the Technical Seminar.

I express my deep regards to our Management for facilitating the

required resources for the successful completion of Technical Seminar.

Finally, yet importantly, I would like to express my heartfelt thanks to

my beloved parents for their blessings, my friends/classmates for their help
and wishes for the successful completion of this Technical Seminar.
With gratitude,
P.Saisruthi
(163T1A0579)
ABSTRACT
Programming distributed computer systems is difficult because of complexities in
addressing remote entities, message handling, and program coupling. As systems grow, scalability
becomes critical, as bottlenecks can serialize portions of the system. When these distributed
system aspects are exposed to programmers, code size and complexity grow, as does the fragility
of the system. This paper describes a distributed software architecture and middleware
implementation that combines object-based blackboard-style communications with data-driven
and periodic application scheduling to greatly simplify distributed programming while achieving
scalable performance. Data-Activated Replication Object Communications (DAROC) allows
programmers to treat shared objects as local variables while providing implicit communications.
DAROC is a middleware architectural model, which is loosely based upon on the blackboard
model. This architecture will decrease distributed software development time by abstracting
away much of the communication overhead and scheduling, which most software developers are
burdened with in their application. This approach will still provide a flexible architectural
framework that allow for modularity in its components, which then in turn facilitates overall
system upgrades and modifications. The combination of reduced communication and
synchronization overhead and flexibility will reduce software development time, which has a
direct impact on the overall cost of development and testing.

1
LIST OF FIGURES
S. No Name of the Figure Page No

1 8.2.1 Data Object Parameters 10 10

2 8.2.2 Functional Element Parameter 10 10

3 9.1.1 FEactivation cycle 13

4 9.2.1 (a) Distributed object check in/loop up 15

(b) Distributed object transfer request
5 10.1 .Two FEs interact through DO transfer 16

2
TABLE OF CONTENTS

ABSTRACT i

LIST OF FIGURES ii

1. INTRODUCTION 1

2. HISTORY 2

3. OBJECTIVES 3

3.1 MAJOR DAROC OBJECTIVES 3

3.2 DAROC At A Glance 3

3.3 Goals of DAROC 3

4. BLACKBOARD WAS CHOSEN AS THE STYLE OF CHOICE 4

5. IMPLEMENTATION OBJECTIVES OF DAROC 5

6. DAROC AS A MIDDLEWARE SOLUTION 6

7. DAROC: EXTERNAL ARCHITECTURE DETAILS 8

7.1. Data Objects: 8

7.2. Functional Elements: 8

7.3. Constraints: 8

8. DAROC DISTRIBUTION OBJECT SPACE 9

8.1 Single Writer Rule(SWR): 9

8.2 Initialization the data object: 10

8.3. DAROC’s Error Manager: 11

8.4. Garbage Collection within DAROC: 11

8.5. Error Manager 11

8.6. DONAR 11

3
 8.7. FEBAR 12

8.8. DO Packaging in the FEBAR Manager: 12

8.9.Parsing and Data Object Wrapping: 12

8.10. Retrieval of a Data Object Step by Step: 13

9. FE ACTIVATION CYCLE 14

9.1. Distributed object transfer: 15

10. HOW ARE DO’S AND FE’S LINKED TOGETHER 17

11. PERFORMANCE AND BOTTLENECKS 18

12. CONCLUSION 19

13. REFERENCES 20

4
 1. INTRODUCTION
Distributed software is normally inherently more complex than normal,
sequential monolithic software. The complexity arises from local issues, like buffer
and concurrency management, to network-centric problems of naming, addressing,
and message passing. Middleware solutions, like CORBA and others, have been
developed to abstract or hide some of the communication details, but the
distributed nature of the system is often still exposed and some complexity and
overhead are generally associated with such approaches. Developers must consider
aspects such as communications and scheduling in addition to the functional
algorithm of the code they are writing. For example, if a middleware solution
provides a remote procedure call (RPC) mechanism, the developer must choose
between blocking and non-blocking calls, and if non-blocking, worry about buffer
usage and synchronization upon completion. If, instead, the communication
approach is message based, the programmer must compose the message, send it,
receive the reply, and decode the reply message. All of this work is in addition to
the required implementation of the function the program or module is intended to
perform.
The concepts behind DAROC arose from the goal of eliminating the burden of
communications and scheduling from the application programmer while
maintaining performance and scalability of the system. By giving programmers the
view of communicating through shared objects, very natural interactions between
programs are facilitated. With the introduction of the single-writer rule and
activation based on data changes from data-flow and data-driven systems,
distributed systems issues such as race conditions and explicit scheduling are
eliminated. While the single writer rule for data objects (DO) may be seen by some
as a significant constraint on expressiveness, it eliminates behavior that limits
scalability or would cause significant confusion or overhead to manage.

DEPT. of CSE., RCEWPage 1

 2. HISTORY
Historically, the blackboard model arose from abstracting features of the
HEARSAY-II speech understanding system, which was developed around 1971 and
finished around 1976. The HEARSAY-II project is considered the most influential on
the development of the blackboard model. HEARSAY-II was a project under the
DARPA Speech Understanding Project that started in 1971. The Speech
Understanding Project goal was to design and implement a system that accepted
continuous speech from cooperative speakers that were issuing commands in a
quiet room with a good quality microphone. HEARSAY-II, in particular, was able to
answer queries about computer science abstracts stored in a database. HEARSAY-II
is important because it is noted as being the first true blackboard system.
The HASP project is another example of a blackboard system which added
even more credibility that the blackboard was a general problem-solving method
and a robust one. Shortly thereafter, many applications programs were developed
in which the solution space was modeled around the blackboard model. Since
applications problems varied greatly along with the interpretation of the
blackboard model, the overall design of each application differed widely.
The backboard model of problem solving has not undergone any substantial
changes in the last three decades. The term “blackboard” appeared in the Artificial
Intelligence literature in 1962 when Newell was concerned with the problems of
programs organized along a generate-and-test search model. Such programs were
restricted in their data access and had inflexible control posed by traditional
program structures. Newell realized that maintaining the isolation of specific
routines, but allowing all the subroutines to make use of a common data structure,
could alleviate the difficulties. Newell used the blackboard metaphor to describe
such a system as follows.
We can think of a set of workers, all looking at the same blackboard: each is

DEPT. of CSE., RCEWPage 2

 able to read everything that is on it, and to judge when he has something
worthwhile to add to it.

3. OBJECTIVES
The short-term goal of DAROC is to provide a programming environment that
will allow both undergraduate and graduate students the ability to gain some
exposure and experience in programming distributed applications.
The long term goal is a bit more ambitious .The DAROC architecture will
address problems such as distributed simulation and battle management scenarios.
3.1 MAJOR DAROC OBJECTIVES
• Eliminate message-passing code implemented by the programmer,
communication achieved by the reading and writing of objects on the blackboard.
• Eliminate control component, burden of scheduling is placed on the OS not on
the application program.
• Activate functional elements in DAROC periodically or based on data changes
when performing computations.
• Reduce code complexity allowing an “average” programmer to rapidly develop
distributed applications.
• Capability for fault recovery via data replication
DAROC consists of two primary components; functional elements (FE) are
active and perform computations and analyze the system state, and the
blackboard, which is the structure that holds data objects (DO) that make up the
blackboard. Unlike functional elements, data objects are passive and do not
perform computations.
3.2 DAROC At A Glance
The desire of DAROC is to empower programmers to be able to write
components of distributed systems without being a distributed systems expert.
3.3 Goals of DAROC
● Reduce software development costs, error-proneness and inflexibility

DEPT. of CSE., RCEWPage 3

 associated with distributed systems applications.
● Reduce code complexity so that the “average” programmer is able to build
distributed systems.
● Provide a tool to better prepare students for the ever-growing need in the job
market for experienced distributed systems programmers.

4. BLACKBOARD WAS CHOSEN AS THE STYLE OF CHOICE

The blackboard style has a big advantage when it comes to simplicity. The
blackboard style consists of one connector that all components use, which of
course is the blackboard itself. Another big advantage is evolveability, because new
types of components can be easily written. The blackboard style naturally lends
itself to increased concurrency. Multiple components can read and write
blackboard data and perform their assigned computations concurrently if possible.
The DAROC architecture has a partial influence from the object to oriented
approach, in that DAROC data objects consist of data and associated operations
that the functional elements can exploit in an object-oriented fashion. A functional
element can’t communicating directly with another functional element DAROC uses
a data-activation approach to activate functional elements, which cause functional
elements to be implicitly activated, based on changes to data object states or
periodic changes.
The DAROC architecture was partially influenced by the object-oriented
approach, in that DAROC data objects consist of data and associated operations
that the functional elements (FEs) can exploit in an objectoriented fashion.
However, with DAROC, functional elements do not know anything about the
identities of other functional elements and do not have to. There is no such thing as
a functional element communicating directly with another functional element.The
implicit invocation also has its influence in DAROC. DAROC uses a data-activation
approach to activate functional elements, which cause functional elements to be
implicitly activated, based on changes to data object states or periodic changes.
Like implicit invocation, DAROC components can be very heterogeneous and lend
themselves to reusability in a variety of contexts. However, DAROC, unlike other

DEPT. of CSE., RCEWPage 4

 pure implicit invocation styles, has knowledge of what components will respond to
an event, which in DAROC refers to updates to a data object. DAROC uses
subscription lists that are used to link functional element to data objects.
Therefore, while DAROC is primarily based around the blackboard style, in
reality, like the vast majority of systems built, it is heterogeneous in nature,
combining some parts of the blackboard, implicit invocation, and object-oriented
styles as part of its architecture.

5. IMPLEMENTATION OBJECTIVES OF DAROC

The first objective is to eliminate message-passing code that is written by
the programmer. In addition, communication is achieved by the reading and writing
of objects on the blackboard. This objective was first achieved because of the use of
the underlying blackboard architecture. The second objective is that there is no
control component and the burden of scheduling is placed on the operating system
not on the application program. DAROC is not implemented with a control
component. It uses a data-driven technique to schedule the activation of functional
elements. The third objective is that DAROC uses data-driven activations as
opposed to an event driven approach. In DAROC, the data-activation approach is
implemented via a list of input conditionals associated with each data object in a
functional elements subscription list. When a data object is changed, the input
conditional for that data object is changed in the subscription list. The functional
element continuously checks the input conditionals of its subscription list until all
have been updated since the last activation. The final objective of DAROC is to
provide fault recovery capability via data replication. The DAROC space that makes
up the blackboard contains all the state information of the system. No state
information is to be stored in the functional elements.

6. DAROC AS A MIDDLEWARE SOLUTION

DAROC exposes two architectural components to programmers: functional
elements are active and perform computations and analyze the system state, while
data objects that make up the communication method between FEs and notionally

DEPT. of CSE., RCEWPage 5

 reside on the blackboard. Unlike functional elements, data objects are passive and
do not perform computations. DOs are strongly typed data objects, ostensibly
defined with an architecture and programming language-independent description,
but for this prototype, normal C++ objects are used. The prototype requires that
DOs are contiguous data structures (no pointers, for example) for simplicity,
because of the difficultly in transferring linked objects between different address
spaces. Eventually, with the addition of packing methods, complex noncontiguous
objects can be supported. Functional elements are the active entities in a DAROC
system and compose the distributed application software. The scheduling of FEs is
managed by the middleware, and FEs are not designed to be continuously running
programs, but programs that are activated when needed, at which point, they
perform their function and then deactivate until the next time they are needed.
There is no limit to the size and complexity of an FE. FEs can be as small as a simple
data transformation, as large as a compiler, as complex as a target tracking
correlation filter or a graphics engine to draw system status displays. Details of FE
activation are provided below. FEs get their name because they are intended to be
functional (in the mathematical sense) program components. This means that FEs
should compute their results based on their inputs (DOs on the blackboard) and
produce results to be stored in DOs on the blackboard. While it is not enforced,
ideal DOs should not store state internally, but should store state in DOs on the
blackboard. These guidelines provide some very valuable features to DAROC
systems:
1. Since the system state is stored on the blackboard and FEs do not store
internal state, debugging is simplified. Developers can monitor and record the
system state unobtrusively by retrieving DOs of interest from the blackboard. In
addition, the FE should return identical results each time it is activated with a
specific set of inputs. Therefore, the functional correctness of the FE can be
debugged independently of the running system using test generators to stub out
the rest of the system.

DEPT. of CSE., RCEWPage 6

 2. Fault detection and recovery can also be facilitated by taking periodic
snapshots of the blackboard. In non-real-time simulations, these snapshots can be
used to restart a system after node failures. In embedded systems experiencing
software failures, these snapshots can be used to replay the state of the system in
the lab to help maintainers duplicate, identify, isolate, and repair the faulty code.
3. If the DAROC middleware enforces replication of all DOs on more than
one node, recovery from a node failure can be performed transparently. The FEs
that were on the failed node can be restarted on another node, and using their
most recent state and input DOs from the blackboard can achieve the proper
results without any recovery code written by the FE programmer.

7. DAROC: EXTERNAL ARCHITECTURE DETAILS

7.1. Data Objects:
DAROC currently supports data objects defined as any standard ANSI/ISO
C++ data type such as integers, floats, doubles, characters, and arrays. However,
these data types must be wrapped in a trivial abstract data class to be able to be
integrated into DAROC. The “build” function is part of DAROC and is used to build
and initialize the DAROC components around the newly created object. DAROC fully
supports any abstract data type the user creates. Data object is stored contiguously
in memory that is to say that compound data objects, such as link lists of data
objects, and other any other types of a non-contiguous fashion are currently not
supported because pointers have no meaning in the memory space of distributed
machines.
7.2. Functional Elements:
Functional elements are always created as an abstract data type. In their
simplest form, they consist of a “build” function to create and instantiate the
DAROC components around the functional element and the FEactivation Function.
There are no data members in this functional element.

DEPT. of CSE., RCEWPage 7

 7.3. Constraints:
Each functional element and data object consists of a name and an ID field.
The name field is any unique generic name that the user calls the object. The ID,
which is also unique, is defined internally within DAROC and can be used to better
describe the object. The ID field consists of three parts. It always starts with a ‘/DO’
or a ‘/FE’ to discern between a data object and a functional element. The next part
that is appended is the local host name, i.e. east.ece.uci.edu. Finally, there is a dash
and monotonically increasing integer appended to the name. One final constraint
of mention, is that of the error manager. Currently there are eighteen statically
defined error messages. The error manager in its current state can hold up to one
hundred error messages. All of the data object and functional element name and ID
constraints can be changed in the bblib.h file, and the error manager can be
expanded in the errorman.h file.

8. DAROC DISTRIBUTION OBJECT SPACE

While DOs appear to be local objects to the code in an FE, DOs are uniquely
identified by name in the global system space. In the current prototype, DOs are
referenced using a single-level global naming scheme, but DAROC’s goal is to utilize
a robust hierarchical one. The goal is to combine a set of FEs along with the DOs
they advertise as external interfaces and the internal DOs used to store state and
communicate between the FEs as a modular component that can be reused
between projects and simply inserted into systems as needed. The blackboard does
not distinguish between DOs used within a component group and DO used to
communicate between components. Instead, the naming scheme separates the
two. Since DOs are referenced by name when they are created or opened, FEs from
one component group will tend to only access DOs that are explicitly defined as
external interfaces by other components. At this moment, there is nothing to
prevent an FE from opening an “internal” DO from another component, but

DEPT. of CSE., RCEWPage 8

 internal interfaces may change more frequently and with less documentation than
external ones, so doing so may invite trouble. Safeguards to prevent unauthorized

access to objects may be added in the future if needed.

8.1 Single Writer Rule(SWR):

The distributed object space of DAROC allows DOs to be read by any
number of FEs, but each DO can only be written by a single FE. This is known in
DAROC as the single-writer rule. By using a single-writer rule as part of a
programmer’s implementation of the distributed system, we are able to easily
eliminate race conditions, ambiguity problems, and complex locking mechanisms
found in other distributed solutions that allow shared-write access to data. While
the single-write rule initially seems like a significant restriction to application
programmers, we found that programmers quickly adapt because of the simplicity
of the rule. In addition, almost any situations that “need” multiple writers to a
single shared object can use a moderator object to accept inputs from the multiple
writer FEs and then pass the appropriate value on to the destination DO. This
approach is very scalable and does not require global locking or other expensive
synchronization. DAROC data objects can be of arbitrarily complex data types. All
the simple data types are currently supported such as integers, doubles, and
characters, as are structured abstract data types, arrays, and combinations thereof.
The only limitation currently is that all data objects that the user creates must be
contiguous storage type objects. At this point, linked lists, trees, and other non-
contiguous data types are not supported. A wrapper method to pack and unpack
these object types could be added to provide support in future revisions.
DOs are referenced within FE code using normal object pointers. The
DAROC middleware creates and manages the space for an FE’s DOs, so the FE can
simply access them as local objects. DAROC guarantees the consistency of all DOs in
use by an FE while the FE is in its execution cycle (see below). When the FE is not
executing, DOs written by other FEs are updated atomically, so no FE sees a partial
update to a DO. In addition, different FEs may have be using different instances of

DEPT. of CSE., RCEWPage 9

 common DOs. For example, if one FE has a long execution cycle, it will use the
instances of its DOs that were current when its execution cycle began. Other FEs
that start later may see more recent instances of those same DOs. When an FE
completes an execution cycle, DAROC automatically provides the current instance
of DOs written by that FE to other FEs that want them. By guaranteeing consistency
during execution, DAROC provides a simple, natural, expected behavior model to
application programmers.
The transfer of DOs between nodes is handled automatically by the DAROC
middleware. Application FEs are not aware of whether the source of any DO they
use is local or remote, so DAROC provides location transparency. Since all
communication is done through named data objects, the distributed nature of the
system is hidden from application programmers. Systems engineers can assign FEs
to the same node for performance or other considerations, but the code does not
change and the logical behavior remains consistent no matter the placement.
8.2 Initialization the data object:
Data objects have three required parameters and as many user-defined
parameters as deemed necessary by the programmer.

8.2.1

Functional elements have five required parameters and as many user defined
parameters as deemed necessary by the programmer.

DEPT. of CSE., RCEWPage 10

 8.2.2

The activation of the functional element does not depend on updates to

data
objects but only on changes in time. The ignore IC parameter must be a 0 or 1,
while the activation delay is any real number greater than or equal to 0.
8.3. DAROC’s Error Manager:
The error manager is an attempt to provide a consolidated error messaging
system for future DAROC developers and application programmers. The error
manager is not intended to be a static entity and should be amended by the
programmer.
sample call to the error manager
BBerror.Send(0, "FE::FE()");
The first parameter is the index of the error message to be displayed. The second
parameter consists of a character string.
8.4. Garbage Collection within DAROC:
DAROC currently deallocates any memory that was dynamically allocated
for a functional element or data object along with all pthread mutexes if the
program exits cleanly. The linked lists that make up the DONAR and FEBAR
managers are also properly deallocated when the program exits cleanly.
8.5. Error Manager
The error managers data member is just an array of strings that contain the
statically defined messages. Error messages can be called using the send member
function with the appropriate index and any additional information can passed to

DEPT. of CSE., RCEWPage 11

 the function as a string in the second parameter.
8.6. DONAR
The DONAR acts as a local name services manager. All data objects that are
created on a node register themselves with the DONAR. When a functional element
needs to find the address of data object it sends its request to the DONAR. The
DONAR is nothing more than a global link list of data objects on that particular
node. A DONAR node consists of the name of the data object, its ID, its address in
memory and a pointer to the next node. The actual link list contains all of the
standard items such as a pointer to the first node and last node and its size.
8.7. FEBAR
The FEBAR like the DONAR is a link list. However, the FEBAR is not a global
name services manager. Every functional element has its own FEBAR, which it uses
to store copies of the data objects that it needs to read from to perform its
computation. It also contains the copies of data objects that will eventually be
written back to the blackboard. FEBAR node consists of the name of the data
object, the address of the data object, and a tag specify if it is an input buffer or
not. All buffers with an isinputbuffer set to “0” will be written back to the
blackboard. The buffer data member is the storage location of the DO. The actual l
ink list contains all of the standard items such as a pointer to the first node and last
node and its size. The FEBAR retrieves data objects to be operated on based on
their name. The three main member functions of the FEBAR are
• FEBARgetbuffer,
• FEBARoverwritebufferlist and
• FEBARpost.
The FEBARgetbuffer function retrieves the data object and passes it to the user’s
application function where it is cast and the data members and functions can then
be exploited.
The FEBARoverwritebufferlist is an essential part of the FE activation. This function
finds all the latest copies of data objects the FE needs and overwrites their old

DEPT. of CSE., RCEWPage 12

 copies of data objects with fresh copies.
The FEBARpost is another essential part of the FE activation cycle. The FEpost
function finds all of the data objects in its FEBAR list that is tagged as an output
buffer and copies the newly calculated data object back to its blackboard location.
Until this function completes, the results of the calculation are not committed.
8.8. DO Packaging in the FEBAR Manager:
Data objects throughout DAROC are stored merely as character buffers. This
allows for the simple transfer of objects in the system and will facilitate replication.
When the user operates on data objects in an application function, they are in
actuality operating on the copies of data objects stored in the FEBAR manager.
8.9.Parsing and Data Object Wrapping:
Parsing is an essential piece of reducing code complexity. The ‘$’ is used in
DAROC in front of a data object to wrap that object with DAROC code once it is run
through the parser.
All data objects must have the ‘$’ parse symbol in front. The code will not be able
to be compiled after it is run through the parser if a data object is missing the parse
symbol.
8.10. Retrieval of a Data Object Step by Step:
The wrapped application code calls the FE wrap function and passes the
name of the data object that the user requests. The data object request is passed
to the FE get buffer function code, which is still part of the functional element
source code.
The FE get buffer function passes control and the request to its associated FEBAR.
The FEBAR uses its own FEBAR get buffer function and calls the find DO name,
which searches through the FEBAR’s link list for the requested data object.

9. FE ACTIVATION CYCLE

DEPT. of CSE., RCEWPage 13

 9.1.1

The FE handler is the initial point of control when the FE is created.

Assuming the functional element if not periodic based, it will continuously check
the data objects in its input list. Once they all have been updated since the last
activation, the input condition parameter is set to true and control is passed to the
user execution logic which is just the application function. Once the application
function completes, control is passed back to the FE handler, which subsequently
writes back the newly calculated data objects to the blackboard. There are
comments about preconditions and post-conditions in the FE handler.This
intelligence is currently not in DAROC but most likely will be added in the future.
Every functional element is created as a single POSIX thread, which controls the
functional element payload. The functional element consists of wrapper code
generated by the DAROC toolset to manage DOs and the application function
written by the programmer to perform the work of the FE. Data objects are read
and written by the FEs in the system as often as needed. A handler associated with
each FE checks the specified set of data objects needed by the FE to perform its
computation. When the handler notices a new instance of any of the DOs in its set,

DEPT. of CSE., RCEWPage 14

 it enters a verification phase. In this phase, the FE handler first determines which
data object has changed, and then checks if any other DOs in its set have been
updated since the last time it activated the FE’s application function. The normal
activation condition in the prototype is the “AND” condition, so if all DOs in the
handler’s set have changed, the FE handler will pass control to the application
function that performs the work of the FE. While the AND activation condition is
the default, OR conditions or more complex Boolean or state-machine operations
are just as easily possible .For example, the user may want to activate the FE every
third update to an input DO; rather than embedding that logic into the application,
it is better to specify it as an activation condition in order to keep the functionality
separate from scheduling concerns. If the activation criteria are not met, the
handler will wait until it detects further change in its DO set.
9.1. Distributed object transfer:
Location-transparent implicit DO transfer between distributed system
nodes is provided by DAROC. A Name Server, written in Python, allows the FE
handlers to look up the “home node” of any data object. The handlers can then
query the home node for each DO they need to determine the status of the DO.
Figure shows how an FE handler looks up the source information for a DO from the
Name Server. Fig. 2b shows an FE handler requesting an updated DO instance. The
response message will either contain the new instance or notification that the DO
has not been updated. Because current implementation of DAROC is an
experimental prototype, we are still evaluating the best update method to use for
DO transfers.

DEPT. of CSE., RCEWPage 15

 9.2.1

As of this writing, a “pull” approach is used, where the FE handlers contact

home nodes of DOs to determine if they have been updated. The DAROC
middleware on those nodes will then either respond with the updated DO instance
or notification that no change has occurred since the last time the FE received the
DO. The automatic transfer of DO instances to nodes that use them means that the
“current” instance of a DO may reside on more than one node. This natural
replication mechanism provides a simple redundancy approach that can be used to
recover from node failures. If the replication is enforced so that all DOs exist on at
least two nodes, then recovery from failure of one of the nodes can occur without
any explicit recovery programming from the user.

DEPT. of CSE., RCEWPage 16

 10. HOW ARE DO’S AND FE’S LINKED TOGETHER
Functional elements maintain a subscription list of all data objects in their
data set that they either read or write. Data objects also have the ability of
maintaining a list of functional elements that can operate on them.
The current implementation of DAROC is one in which the functional
elements pull update changes from the blackboard as opposed to the blackboard
pushing update changes out to the appropriate functional elements. Data objects
of type “input” are those that are read only. Data objects of type “output” are
those data object it will write its results back to.

10.1

11. PERFORMANCE AND BOTTLENECKS

There are three components in the DAROC architecture that can be a future
source of bottlenecks that result in performance hits. DAROC currently is not in a
stage of maturity in which distributed simulations can be performed.
DAROC Bottlenecks:
• Centralized Name Services
• Blocking Lock Mechanism
• Inflexibility of Functional Element Activation’s
• Copies of Data Objects
Activation Analysis:
The systems specifications are as follows:
• Intel 810 Chipset
• GHz celeron processor

DEPT. of CSE., RCEWPage 17

 • 384 MB of memory

12. CONCLUSION
Current distributed programming paradigms force communication and
scheduling code into the application code of the program. This method is highly
error prone due to the complexity of programming in a distributed environment
and leads to limited scalability.
DAROC, a data-activated middleware approach whose goal is to ease distributed
programming for people who are not distributed systems experts. DAROC is a
network transparent environment in which all accesses are seen as local from the
programmer’s point of view. Data-activation in a loosely based blackboard model
simplifies scheduling while providing a mechanism for data replication. The
evolving tool kit will also enhance this simple, yet powerful distributed
programming environment.

DEPT. of CSE., RCEWPage 18

 13. REFERENCES
● https://www.seminarstopics.com/seminar/5803/daroc-technology
● https://www.cin.ufpe.br/~cct/sbes2008/Stack2003.pdf
● https://www.sciencedirect.com/science/article/pii/S0167739X0400192X
● https://www.semanticscholar.org/paper/A-middleware-architecture-to-
facilitate-distributed-Stack-
Hsiao/2767768788d0dd1ea2ffcce4a89eae580a06a1bf
● https://www.researchgate.net/publication/221133764_A_Middleware_Archit
ecture_to_Facilitate_Distributed_Programming_DAROC_Data-
Activated_Replicated_Object_Communications
● https://dl.acm.org/doi/10.5555/1125403.1125415

DEPT. of CSE., RCEWPage 19