Synopsis Of

Implementation of LLC using Reactor communication Pattern

Submitted By

Ritu Bansal
Roll No.8928

Under the Guidance of

Dr.M.P.Diwakar
Scientific Officer (H) BARC Mumbai

In the partial fulfillment of the requirements for the degree of

Master of Technology in

Computer Science

Banasthali Vidyapith,Jaipur Campus Banasthali Universiry Apr-2009

1. Introduction
Distributed computing is a promising technology for improving collaboration through connectivity and interworking; performance through parallel processing; reliability and availability through replication; scalability and portability through modularity; extensibility through dynamic configuration and reconfiguration. Object-oriented (OO) programming languages, components, and frameworks are widely touted technologies for reducing software cost and improving software Quality. Object oriented design patterns and framework are well regarded for their ability to help alleviate costly rediscovery and reinvention of core distributed software concepts and abstractions. Patterns provide a way to encapsulate design knowledge that offers solutions to standard distributed software development problems. Frameworks provide reusable software components for applications by integrating sets of abstract classes and defining standard ways that instances of these classes collaborate. Frameworks are tightly integrated with key distributed programming tasks (such as call establishment, service initialization, error handling, flow control, and event demultiplexing). The Reactor Pattern combines the demultiplexing of input and output (I/O) events with other types of events, such as timers and signals. At the core of the Reactor implementation is a synchronous event demultiplexer, such as select or WaitForMultipleObjects. When the demultiplexer indicates the occurrence of designated events, the Reactor automatically dispatches the method(s) of pre-registered event handlers, which perform application specified services in response to the events.

2. Motivation
The basic idea of State Machine is to separate classes which implement transition logic (Context) and state classes. To provide an interaction between Context and state classes we use events which are basically objects that state objects pass to Context. A difference from the State pattern is the way the next state is determined. In State next state is explicitly pointed out by the current state. In the proposed pattern it is done by notifying the Context with an event. After that its a Contexts responsibility to react and possibly change the state. This is done according to the state chart. The advantage of this design solution is that state classes may be designed independently. They dont need to be aware of each other.

Motivation of using Reactor Pattern:

Context aware application is complex. Patterns are a recent software engineering problem solving discipline.

The Reactor pattern should be applied when an application must handle events from multiple clients concurrently without incurring the programming complexity, performance overhead, and non portability of multithreading. Developing an effective server mechanism for demultiplexing and dispatching client request requires the resolution of the forces: Concurrency Efficiency Programming simplicity

Adaptability Portability Separation of concerns

Often, a more convenient, efficient and portable way to develop a logging server is to use Reactor Pattern. Reactor pattern integrates the synchronous demultiplexing of events and the dispatching of their corresponding event handlers. It also decouples the implementation of application specific services from the general purpose events demultiplexing and dispatching mechanism.

3. Objective
To Implement LLC (Logical Link Control) using Communication Pattern Reactor. these Patterns we have implemented will be used in the real time framework of Data Acquisition System.

4. Scope
The component Reactor and Logical link layer of the Data Link Layer we have implemented will be used in the real time framework for Data Acquisition system. These components can be updated and extended without the need to modify, recompile, relink or often restart running application. It is an object-oriented (OO) framework that implements core concurrency and distribution patterns for communication software. The scope of reuse can be significantly larger than by using traditional function libraries, or even conventional OO class libraries.

5. Description
I have implemented LLC using Reactor communication Pattern. I have implemented three state machines (Connection STM, Data STM & Test STM) in the Logical Link Control (LLC) using Design pattern.

I have used state machine design pattern for implementing these three state machines. An intent of state machine is to make it possible for an object to alter its behavior when its internal state changes. State machine pattern is a combination of State and Observer Design Pattern .In state pattern behavior of object depends on its state. In this pattern events are used to let the machine know that the state should be changed. This allows centralization of the machine transition logic and loosens coupling between state classes. In this pattern transition between states are based on event driven mechanisms. The classes I have implemented in these three State machines are:

1. CSTMContext:
It is a class that encapsulates the transition logic. It implements the state machine interface and holds an instance of the current state.

2.

CStateMachine:

In this class we are defining states of the machine that will be either complete or pending. And we are creating Dictionary for making a table of events and transition for a state. In this class we have a HandleSTMEvent () function which will match the current event with the state event. It will handle the Entry and Exit action of the State machine. If the events are matches then it will change the state otherwise will be in the same state.

3. CSTMTransition:
In this class we are having transition properties GetSTMTransition () which will return the current transition and SetSTMTransition () which will set the current transition.

4. CSTMState:
In this we are Creating delegates for EntryEventHandler, ExitEventHandler and for the Transition Event Handler and then we are generating event for these delegates.

5. CSTMEvent:

It is having a Abstract function Compare() that is using for comparing the current event with the state machine event.

6. ISTMHandler (Interface):
It is an interface having abstract function Handle() function for handling the STM.

7. ConnectionSTM:
In this class we are creating all the events, states and handlers for the connection state machine. All the transitions conditions for the Connection STM are implemented in this class. In this class we are having a timer for timeout and other events and handlers. We are creating STM using Abstract factory design Pattern.

8. DataSTM:
In the data STM we are creating all the events, states and handlers for the Data state machine. All the transitions conditions for the Data STM are impleneted in this class.

9. TestSTM:
In the data STM we are creating all the events, states and handlers for the Test state machine. All the transitions conditions for the Test STM are implemented in this class. An implementation of the logical link layer of the data link layer is for communication through RS232. The functions of this module is to establish connection with its peer, tackle errors in communication, acknowledges any packet that is being received correctly, and give an error free frame to the application layer. Header and CRC values are added to application packets to be sent across the channel. It arranges to retransmit data if not received correctly its peer. It also tests the healthiness of the communication periodically. Classes used in the implementation of LLC are:

10. LLCHandler:
This is the main class which will handle all three state machines. In this class we will read the Packet and then prepare the packet for transmission, check the packet for the error with the CRC. It will handle all the Input, Output and dispatch the packet for all state machines.

11. CAbstractFactory:
6

This class is implemented using abstract factory design pattern for creating the state machine. The Reactor Pattern developed to provide an event handling infrastructure. The Reactor Pattern combines the demultiplexing of input and output (I/O) events with other types of events, such as timers and signals. At the core of the Reactor implementation is a synchronous event demultiplexer, such as select or WaitForMultipleObjects. When the demultiplexer indicates the occurrence of designated events, the Reactor automatically dispatches the method(s) of pre-registered event handlers, which perform application specified services in response to the events. Classes used in the implementation of Reactor Pattern are:

12. CPacket:
This class is used for creating the packet using Serial header and TCP Header. We can read and write the data from packet as any of the data type (int, float, char).We can set and update the length of the packet.

13. CReactor:
The Reactor defines the public interface for the Reactor framework.It illustrates the key public methods in the Reactor class. The methods in the Reactor can be grouped into the following general categories:

Manager methods : The constructor and open methods create and

initialize objects of the Reactor by dynamically allocating various implementation objects. The Reactors destructor and close methods deallocate these objects. In addition, to support the common use-case of one event loop per application process, there is a static instance method that returns a pointer to a singleton Reactor, which is created and managed by the Singleton pattern. I/O-related methods: Applications can register concrete event handlers that derive from ACE Event Handler with an ACE Reactor via its register handler method. Likewise, concrete event handlers can be removed via its remove handler method. Event-loop methods: After registering its initial concrete event handlers, an application enters an event-loop that typically calls an Reactors handle events method repeatedly. This method gathers the handles of all registered concrete event handlers, passes them to the underlying OS event demultiplexing call, e.g., select or WaitForMultipleObjects, and then can block for an application-specified time interval awaiting the occurrence of various events, such as data events to arrive on socket handles or timer deadlines to expire. Subsequently, when

I/O events occur and the handles become ready, the Reactor notifies the appropriate pre-registered concrete event handlers by invoking their handle hook method(s) defined by the application to process the event(s).

14. Event Handler Class:

This base class specifies the interface used by the Reactor to control and coordinate the demultiplexing and dispatching of concrete event handlers. The Reactor implements its event-driven callback mechanism via concrete event handlers, which inherit from Event Handler. Concrete event handlers typically provide an I/O handle that the Reactor can retrieve via the get handle method. When an application registers a concrete event handler with the Reactors register handler method, the Reactor calls back to the get handle method on the concrete event handler to retrieve the underlying I/O handle. If a concrete event handler is used entirely to handle signals or timers, the get handle method can be a no-op.

15. Select Reactor Class:

The select-based Reactor contains three arrays of Event Handler. These arrays store pointers to registered concrete event handlers that process various types of events specified by applications. The Handle Set class provides an efficient wrapper for the underlying fd set bitmask data type. An fd set maps the I/O handle name-space onto a compact bit-vector representation and provides operations for enabling, disabling, and testing bits corresponding to I/O handles.The fd sets are passed to the select call when an application calls the Reactor handle events method.

6. Conclusion:
State Machine pattern improves State and inherits its main idea to encapsulate the state-dependent behavior in a separate class. The State Machine pattern improves State in the following aspects. When using State Machine it is possible to design state classes independently. Thus the same state class could be used in several automata. This eliminates the major disadvantage of State reuse issues. In State transition logic is distributed throughout state classes which introduces coupling between them. State Machine addresses this issue. It separates transition logic and the behavior in a particular state. As opposed to State, State Machine doesnt cause interface redundancy.

The functions of LLC module is to establish connection with its peer, tackle errors in communication, acknowledges any packet that is being received correctly, and give an error free frame to the application layer. Header and CRC values are added to application packets to be sent across the channel. It arranges to retransmit data if not received correctly its peer. It also tests the healthiness of the communication periodically. A Reactor Pattern is used in many different ways. It is not limited to object oriented world. As shown, it is procedural programming too. Reactor serialized single threaded event loop can simplify the coordination of otherwise independent event handling services. Variants, on other hand may bust the event loops simplicity. In trivial implementation, the pattern is part of the operational system for implementing software interrupts. In that case, architect and programmers alike might still again from the Reactors conceptual encapsulation of native event demultiplexing mechanisms, such as Select(),and WaitForMultipleObject().From a higher-level point of view, it is particularly worth the extra structuring effort, when effectively combined with other patterns to support concurrent handling to events.

7. References:
1. D. C. Schmidt, Reactor: An Object Behavioral Pattern for Concurrent Event

Demultiplexing and Event Handler Dispatching, in Pattern Languages of Program Design (J. O.Coplien and D. C. Schmidt, eds.), pp. 529545, Reading, Massachusetts: Addison-Wesley, 1995.
2. The Design and Use of the ACE Reactor An Object-Oriented Framework for Event

DemultiplexingDouglas C. Schmidt and Irfan Pyarali fschmidt,[email protected] Department of Computer Science Washington University, St. Louis 3. Design Patterns Elements of Reusable Object Oriented Software -Erich Gamma , Richard Helm, Ralph Johnson & John Vlissides 4. The Anthology of the Finite State Machine Design Patterns Paul Adamczyk University of Illinois at Urbana-Champaign Department of Computer Science 5. .NET Book Zero-Charles PetZold

8. Proposed contents of the Report:

9

Section 1

This section describes the introduction of the project. This includes the overview, objective, motivation & scope of the project. This section provides the overview of the design pattern including classification of the design patterns and how to use the design pattern. This section provides the Introduction of LLC &describes the functions of data link layer. This section provides the overview of State machine design pattern it also describe the motivation, structure and consequences of the state design pattern. This section provides the details about the Reactor Pattern. It includes introduction, structure, feature, Applicability, consequences of using Reactor pattern. This section gives implementation details of the project. It addresses the features of the c# and gives all the details of the classes implemented.

Section 2

Section 3 Section 4

Section 5

Section 6

10