View page as slide show

Communication software and architecture

Layered architecture and implementation

layered-entities.jpg

  • Layer n-provides service to layer n+1 and uses services of layer n-1
  • Communication between layers are conducted via layer interfaces
  • Implementing layer n do not require knowledge about the implementation of layer n-1, Only layer n-1 interface is needed
  • Implementation of layer n do not have depend on layer n+1 and its functionality

Protocol classes in single layer

protocol-classes.jpg

Protocol system

protocol-system.jpg

  • High level class that encapsulates the whole protocol system
    • describes the system structure
  • Has one or more environment interfaces
  • Consists of one or more protocol entities

Environment interfaces

environment-interfaces.jpg

  • communications out of the protocol stack
  • communication interface
    • low level communications (out of software stack)
    • communication to files
    • communication to user or application using the stack
  • auxiliary interfaces
    • test interface to provide test cases to communicating entity
    • management interface to affect entity behaviour

Protocol entity

  • The main class for protocol layer e.g. Communicating protocol Object (CPO)
  • Has storage space for internal information
  • Entity interface which is used the communication within system (e.g. primitives)
  • Peer interface is for handling communications between entities located in different protocol systems
  • Several CPOs can exist in single layer
    • CPOs have to have identifiers for communication

Protocol Behaviour

  • Describes the internal behaviour of entity
    • How to respond to incoming events (messages)
  • EFSA
  • Several concurrent connections are possible that are in different state
    • e.g. several clients using server
    • Connection manager CPO handles creation and destruction of connection CPOs
    • Router provides the messages to the CPO handling the corresponding communication
    • manager-worker pattern can be used

Protocol data flow

  • Transmission of messages between CPO's
    • moving message from one object to another
  • Communication (virtual) channels are created between CPO's
    • conduits, connected ports ..
  • En/decoding
    • from local syntax to transfer syntax
  • parameters
  • routing and scheduling

.

Protocol messages

  • Local syntax: the form in which the message fields are handled in the implementation
  • Transfer syntax: The specification for

Supporting classes

  • Timers
    • Additional signals for special conditions
    • Prevent endless waiting
    • Allow timing of events
    • Can be implemented as special CPO
      • Provides own timer messages
  • Schedulers
    • In communication system several events can happen simultaneously.
    • Scheduling needed to handle the processing order of events (messages)

Protocol Frameworks

  • Reusable design of all or part of a system
    • provide commonly used components needed for creating protocol
  • Help to transform the design into implementation
    • layered architecture support
    • Simple and efficient way to create and configure functionality of different communicating objects
  • Support for testing and analysis
  • external tools
  • Several frameworks exists
    • CVOPS, OVOPS,
    • conduits+ based: OVOPS++, JVOPS, Jacob
  • Frameworks can provide many alternatives for message passing
    • Internal message queues for passing of message structures
    • moving simply a message pointer from one CPO to another
    • Using visitor pattern
  • For scheduling several possible approaches which can be interchangeable in framework
    • Round robin
    • Prioritized schedulers
    • debugging schedulers
  • Frameworks provide different types of support for EFSA
    • Special EFSA languages
    • Class libraries containing base classes for EFSA implementations
    • Simple switch case solution

State machine implementation

  • In a proper state machine design you should be able to identify from the code one to one equivalents to the following FSM components.
    • Events
    • States
    • Current state
    • Event handler functions for each state
  • State machines with nested case statements
    • Switch on state first then switch on event type
    • behaviour code inside case statements
    • Hard to upkeep and handle
  • State Jump Table
    • State Jump Table contain array of states, events and pointers to functions to be called in each states.
    • When event is raised, common FSM code will search the table to find a function that has to be called depending on the current state.
    • No behaviour code inside FSM

C Implementation

  • Extract the message from input device.
  • Find what transition function has to be called based on the current state and input type
  • In transition function perform required tasks, message output etc in the transition function
  • Change the state if required
  • Events such as Timer expiries which don’t map to messages should be modelled using the same structure as messages
  • Events can be modeled with enumeration
    • messages, timers etc.
 enum EventType {ConReq, ConRsp, Ack,  TimerExp...} 
  • States can be enumerated too
 enum states {idle, WaitForAck, connected...} 
  • switch case state machine
 switch (current_state)
        case (idle): /* or case (1) */
          switch (event):
             case (1): TransitionFunction (event,state)
             ...
        case (WaitForAck):
           switch (event):
             ...
  • table FSM
    • structure
 
    int (*ptr2transition)(msg, event) = NULL; 
    fsmTable[event][state]=ptr2transition function 
  • Initialisation of table
    fsmTable[idle,ConReq] = ConnectionRequest
    fsmTable[idle,Ack] = defaultFunc

State pattern

Messages

  • Messages as structure
struct Message {
    enum MessageType message_type;
    char  contents[MSGLEN];
};
  • Message as Class
    • contains at least type and contents
    • possible additional functions to handle the message and its contents
      • encoding and decoding rules may be implemented, although in many case it is better to have implement them where the encoding is used.

PDU en/decoding

  • Information to be sent to peer entity has to be encoded in PDU format
  • Encoded PDU's are transported in lower layer as a payload of primitive
  • Received PDU has to be decoded and identified

Message passing

  • Inter Layer Communication
    • All OSI and ITU protocols are layered protocols
    • In OSI the communication between layers is modelled as primitives
    • Primitives are like messages in that they are input events to state machines
  • When a message is extracted from an input buffer and passed through code, the message shouldn’t be copied as this is resource intensive. Instead references to the message should be passed.

Handling multiple connections

  • Multiple higher layer connections may use a single lower layer connection
    • Multiplexing needed
    • Same primitive may transmit PDUs for several connections without distinquishing the connections itself.
  • Identifiers
    • Global identifier (PDU ID) can be different than local one (CPO ID)
    • Peer entities may have different amount of conenctions and the implementations may use different ways to identify the internal CPOs

Event Driven Programming

  • There are two ways to write code that responds to events
  • Event driven programming
  • Polling

Polling

  • Polling is when you sit in an endless loop, constantly checking an input queue
  • For example:
void EventDispatcher::loop()
{
    while(1) {
	    pause(10MS); // Pause the thread 10 milliseconds	
        Event* event = getevent();
        if(event) {
            process_event(event);
        }
    }
}

Disadvantages of Polling

  • Task has to pause between polls to allow time for other tasks to be scheduled in
  • Response time - between event occurring and action being performed depends on duration of the pause
  • If fast response time is required this method consumes significant processor time (power)
  • Polling should be avoided in most cases. Instead of polling an event driven (for example interrupt driven) approach should be used.

Valid excuses for using Polling

  • Operating System limitations
  • Hardware limitations - no interrupts available
  • Writing low level device drivers and hardware interrupts are not available

Event Driven Programming

  • The alternative is to use a blocking routines that waits for one of several events you have signified
  • The way in which this is done and the API to do this is operating system specific
  • We will consider the case of Unix which is a very common OS for telecommunications applications.

What is an Event ?

  • An event is anything that needs the attention of the system.
  • Real Time (or Embedded) Systems exist to service events
  • When an event occurs in the real world, an embedded system must recognize the event and take some action in a timely fashion.
  • Embedded systems are often called “event-driven” systems.

Is a signal the same thing as an event?

  • The words event, interrupt, signal, and exception all refer to the same thing: something important happened and we have to take care of it.
  • UNIX software signal is the same thing as a Motorola 68040 hardware interrupt: something happened “out there” and our system needs to respond to that time-critical event.

How do Interrupts Get Generated and Serviced?

  • Microprocessors have a special input pin or pins which are used by external hardware to signal the microprocessor that some external event needs attention. These are the interrupt pins.
  • For example: when a message arrives on a network device such as an Ethernet chip, it applies a signal to an interrupt pin on the microprocessor to interrupt whatever software is currently running.
  • The microprocessor then saves whatever program thread was running and vectors to the interrupt handler which is associated with the interrupt.
  • The Ethernet interrupt service routine (ISR) runs to completion, doing whatever work needs to be done to take care of the arrival of the packet from the network.
  • When the ISR is finished, the control returns to the program thread.

Typical Interrupts

  • External (pin) Interrupts
  • Timer Interrupts
  • SW Interrupts
  • Power Down (Dying Gasp) Interrupt
  • Processor Exception Interrupt

Concurrency

  • In communicating system events happen at same time
  • Priorities are needed to decide which event is handled when
    • The priority of event determines whether it should have precedence over other task
    • High priority tasks usually
      • require little processing time to run
      • cannot tolerate long delays
    • Low priority events usually
      • take longer time to execute
      • there is no impacts if they are delayed
    • Tasks may have same priority and they are then usually served in round robin fashion
Last modified: 2013/07/01 14:42