View page as slide show

Communication software and architecture

Background

  • Communication system specification (standard) gives rules how to implement a system
  • Specification have to be followed in implementation to ensure interoperability between different systems
    • For example session layer protocol specification can be implemented in:
      • Android phone: Linux, java language, ARM architecture
      • Symbian phone: Symbian, C++, ARM architecture
  • It should noted that protocol specification gives only model for communication part of the system, you have to have model to other application requirements as well

Implementation Areas

  • System structure: layered component architecture
  • Implementation on internal messages (primitives)
  • Implementation of encoding and decoding of external messages (PDU)
  • Implementation of message exchange logic: state machines
  • Adapting communication components to application functionality
  • Adapting communication components to operating system functionality

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 form in which the message is transferred.
  • Encoding and decoding functions are needed to change the message from transfer syntax to local syntax.
  • Encoded protocol messages will be inserted into primitives, that are used to communicate with lower layer.

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

  • 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
  • Protocol message will be transmitted as payload of primitive to lower layer
  • Protocol message will be extracted from primitive when it arrives from lower layer
  • Lower layer defines the format in which primitive is passed.
  • Buffers are used to store incoming and outgoing message, until process is ready to handle them
  • Queue determines the order of which the messages in buffer are handled.
  • 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

  • Communication systems follow the event driven programming paradigm
    • Programming is waiting an event before it continues.
    • Program behaviour depends on what events arrive.
  • The way in which this is done and the API to do this is operating system specific
  • An event is anything that needs the attention of the system.
    • Quite commonly Message or Timer

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

Polling

  • Polling is when you sit in an endless loop, constantly checking an input queue
  • Events can be also polled rather than just waited. For example:
void EventDispatcher::loop()
{
    while(1) {
	    pause(10MS); // Pause the thread 10 milliseconds	
        Event* event = getevent();
        if(event) {
            process_event(event);
        }
    }
}
  • Checking mail from mailbox vs. mailman ringing door bell and bringing mail to you.

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.
Last modified: 2013/07/01 14:42