COTS Challenges for Embedded Systems

1
E81 CSE 532S Advanced Multi-Paradigm Software
Development
Acceptor/Connector Pattern
Venkita Subramonian, Christopher Gill, Ying
Huang, Marc Sentany Department of Computer
Science and Engineering Washington University,
St. Louis cdgill_at_cse.wustl.edu
2
Context

• Networked system or application
• I.e., communication between remote hosts
• Connection-oriented protocols
• E.g., TCP/IP
• Peer services
• I.e., client and server roles
• Connected via endpoints
• E.g., IP ports
• Endpoints are distinct from connections
• ltip, portgt vs ltltip1,port1gt,ltip2,port2gtgt

3
Client and Server Roles
Listening port

• Each process plays a single role
• E.g., Logging Server example
• Logging Server gets info from several clients
• Roles affect connection establishment as well as
  use
• Clients actively initiate connection requests
• Server passively accepts connection requests
• Client/server roles may overlap
• Allow flexibility to act as either one
• Or, to act as both at once (e.g., in a
  publish/subscribe gateway)

Server
Client
Server/Client
4
Design Challenges

• Flexibility, performance can be lost if we
  tightly couple
• Connection establishment
• Protocol-specific details
• Service handler instantiation and initialization
• Application logic for service processing
• Need to resolve four key design forces
• Changing connection roles to vary application
  behavior
• Adding new services, implementations, and
  protocols
• Connection establishment/initialization vs.
  protocols/services
• Protocols and services more likely to be changed
  or enhanced
• Should not be tightly coupled with connection
  management
• Reduce connection (re-)establishment latency
• Via advanced OS features and new protocols (e.g.,
  SCTP)

5
Solution Approach Separate Concerns
Acceptor
Event sources
Dispatcher
Handler
Connector
Connection establishment, service instantiation
initialization
Event de-multiplexing dispatching
Service handling (connection use)
6
Solution Approach in Detail

• Decouple two consecutive phases of activity
• Connection establishment and initialization
• Service processing
• Decouple three main roles
• Passively accept connection requests
• Acceptor role
• Actively initiate connection requests
• Connector role
• Perform service-specific processing using the
  connection
• Service Handler role
• Also decouple three supporting roles
• Dispatcher (e.g., Reactor or Proactor), Endpoint,
  Handle

7
Detailed Solution Approach, Continued

• Application services
• Encapsulated within peer Service Handlers
• Two factories Acceptor and Connector
• Connect and initialize peer service handlers
• May also allocate and construct service handlers
• Pass handlers their respective Transport Handles
• Separation of phases
• Service handlers may not need to interact with
  acceptor-connector after connection/initialization
  
• Unless handlers take on connector/acceptor roles

8
Detailed Solution Approach, Continued

• Acceptor behaves as a server-side factory
• Listens on a known endpoint
• Connection request events arrive
• Acceptor accepts new connection, gets new
  endpoint handle
• May create new service handler (or be given one
  to use)
• Gives new endpoint handle to the service handler
• Usually invokes the service handlers activation
  method
• Connector behaves as a client-side factory
• Makes connection requests actively
• Contacts remote acceptor at well-known endpoint
• May create new service handler (or be given one
  to use)
• Gives new endpoint handle to the handler
• May invoke the service handlers activation method

9
Solution Structure Overview

• Transport Endpoint
• E.g., addressport
• Allows Service Handlers to exchange requests/data
  over a network
• Transport Handle
• E.g., socket handle
• Hides details of the Transport Endpoint
• Service Handler
• Implements half of an end-to-end service in a
  networked application
• Acceptor
• Passively accepts connection requests on a known
  Transport Endpoint
• Connects and initializes server-side Service
  Handlers
• Connector
• Actively connects and initializes client-side
  Service Handlers
• Dispatcher
• Registers and dispatches Acceptors, Connectors,
  and Service Handlers
• Dispatches events for connection requests,
  service processing

10
Structure Diagram
From POSA2
11
Acceptor/Connector Implementation

• De-multiplexing and dispatching infrastructure
• Handles events that occur on transport endpoints
• Consists of transport and dispatching mechanisms
• Implementation can be subdivided
• Transport mechanisms
• Components often provided by the underlying OS
  platform
• Can be accessed via Wrapper Façade facades
• Dispatching mechanisms
• Dispatcher and event handler components
• E.g., Reactor or Proactor
• Can also be implemented using a separate thread
  per connection

12
Implementation, Continued

• Connection management
• Creates service handlers
• Passively or actively connects service handlers
  to remote peer service handlers
• Activates service handlers after they are
  connected
• All interfaces should be abstract/generic
• Offer implementations these interfaces
• I.e., concrete general-purpose acceptors and
  connectors
• Define generic acceptor and connector bridges
• define interface polymorphism vs. parameterized
  types
• implement generic/abstract methods

13
Implementation, Continued

• Application
• Defines concrete service handlers
• Define applications end-to-end services
• Can also define service concurrency strategies
• May customize concrete acceptors and connectors
• E.g., as factories to create application-specific
  handlers
• E.g., to provide customized IPC mechanisms
• Components instantiate generic/abstract service
  handler, acceptor, and connector interfaces

14
Acceptor Initialization

• When Acceptor initialization method is called
• E.g., through a call to its open() method
• Acceptor binds to a transport endpoint
• Specified by a given address for that transport
• E.g., a TCP/IP address and port
• Often useful to run acceptor reactively
• I.e., register the acceptor as yet another
  handler with a reactor
• Reactor will call the acceptor when a connection
  request event arrives on its endpoint

15
Dynamics Acceptor Scenario

• Passive Connection Establishment
• Passive-mode transport endpoint initialization
• Acceptors connection initialization method is
  called
• Sets up the transport endpoint, binds it to a
  transport address
• Acceptor listens on this endpoint for connection
  requests
• Acceptor registers itself with dispatcher

16
Dynamics Acceptor Scenario

• Service handler initialization
• Dispatcher notifies acceptor when connection
  request arrives
• Acceptor creates a new connected transport
  endpoint, encapsulates it via a transport handle
• Acceptor creates a new service handler
• Gives the transport handle to the service handler
• Calls the handlers initiation hook method
• The hook method performs specific handler
  initialization
• Service processing
• Service handlers exchange data through connected
  transport endpoints
• When all exchanges are complete, service handlers
  shut down
• All handles and endpoints are shut down and
  resources released
• Why is this step important?

17
Acceptor Scenario Interactions
From POSA2
18
Synch/Asynch Connector Behavior

• Useful to allow connection initiation to be
  either synchronous or asynchronous
• Separate the connectors connection initiation
  method from its completion method
• Synchronous connection establishment
• Connector blocks until transport endpoints are
  connected
• Connector calls Service Handlers activation hook
  directly
• Reasonable alternative if
• Connection establishment latency is very low
• It is possible and efficient to use a
  thread-per-connection model
• Services must be initialized in a fixed order
• Clients cannot do useful work until multiple
  connections have been established

19
Asynchronous Connection Establishment

• Connector initiation method returns once request
  sent
• Service handler is activated by connection
  completion method (e.g., by registering it with a
  reactor)
• Dispatcher notifies connector when transport
  endpoint is ready
• Beneficial if
• Establishing connections over high latency links
• Using multiple connections per thread
• Initializing many peers that can be connected in
  an arbitrary order
• Clients can make progress by using connections
  independently

20
Dynamics Connector Scenario I

• Active Synchronous Connection Establishment
• Connection initiation
• Connectors initiation method will block the
  applications thread
• Until connection establishment completes
  synchronously

21
Dynamics Connector Scenario I

• Service handler initialization
• After completion, service handlers open hook
  method is called directly
• Open method performs handler-specific
  initialization
• E.g., registers itself with the Dispatcher
• Service processing
• Mediated by Dispatcher upcalls to service handler
  hook method
• E.g., handle_event ()

22
Connector Scenario I Interactions
From POSA2
23
Dynamics Connector Scenario II

• Active Asynchronous Connection Establishment
• Connection initiation
• Invoke connector initiation method as in Scenario
  I
• Connector registers itself, transport handle with
  the dispatcher
• Thus application thread does not block
• Connector receives connection completion
  notification from dispatcher

24
Connector Scenario II, Continued

• Service handler initialization
• Connectors connection completion hook method is
  called
• Cleans up resources allocated for connection
  establishment
• Calls the service handlers open hook method
• Service handlers open method performs specific
  handler initialization
• E.g., registers itself with Dispatcher
• Service processing
• Dispatcher calls service handlers processing
  hook method
• E.g., handle_event ()

25
Connector Scenario II Interactions
From POSA2