E81 CSE 532S: Advanced Multi-Paradigm Software Development

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@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 • <ip, port> vs <<ip1,port1>,<ip2,port2>>

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

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

6. 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

7. 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. 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

9. 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-sideService Handlers • Connector • Actively connects and initializes client-sideService 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 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

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 • 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

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 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?

17. Acceptor Scenario Interactions From POSA2

18. 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

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 • Connector’s initiation method will block the applications thread • Until connection establishment completes synchronously

21. 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 ()

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. 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 ()

25. Connector Scenario II Interactions From POSA2