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

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 – vs, >

Client and Server Roles 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 Listening port

Problem 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)

Solution – (further) separation of concerns Dispatcher Event sources Event de-multiplexing & dispatching Acceptor Connector Connection establishment, service instantiation & initialization Service handling (connection use) Handler

Solution Approach 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

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

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 handler’s 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 handler’s activation method

Solution Structure Overview Transport Endpoint –E.g., address:port –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

Structure Diagram From POSA2

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

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

Implementation, Continued Application –Defines concrete service handlers Define application’s 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

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

Dynamics: Acceptor Scenario Passive Connection Establishment –Passive-mode transport endpoint initialization –Acceptor’s 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

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 handler’s 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?

Acceptor Scenario Interactions From POSA2

Synch/Asynch Connector Behavior Useful to allow connection initiation to be either synchronous or asynchronous –Separate the connector’s connection initiation method from its completion method Synchronous connection establishment –Connector blocks until transport endpoints are connected –Connector calls Service Handler’s 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

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

Dynamics: Connector Scenario I Active Synchronous Connection Establishment Connection initiation –Connector’s initiation method will block the applications thread –Until connection establishment completes synchronously

Dynamics: Connector Scenario I Service handler initialization –After completion, service handler’s 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 ()

Connector Scenario I Interactions From POSA2

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

Dynamics: Connector Scenario II, Continued Service handler initialization –Connector’s connection completion hook method is called –Cleans up resources allocated for connection establishment –Calls the service handler’s open hook method –Service handler’s open method performs specific handler initialization E.g., registers itself with Dispatcher Service processing –Dispatcher calls service handler’s processing hook method E.g., handle_event ()

Connector Scenario II Interactions From POSA2