Distributed Real-Time Systems (TI-DRTS) POSA2: Acceptor/Connector Design Pattern

Transcription

1 Distributed Real-Time Systems (TI-DRTS) POSA2: Acceptor/Connector Design Pattern Version:

2 Abstract The Acceptor-Connector design pattern decouples the connection and initialization of cooperating peer services in a networked system from the processing performed by the peer services after they are connected and initialized Slide 2

3 Context A networked system or application: in which connection-oriented protocols are used to communicate between peer services connected via transport endpoints Slide 3

4 Problem Applications in connection-oriented networked systems often contains a significant amount of code that establishes connections and initializes services This configuration code is largely independent of the service processing code tightly coupling the configuration code with the service code is undesirable Slide 4

5 Solution Decouple the connection and initialization of peer services from the processing these services perform Application services are encapsulated in Service Handlers Connect and initialize peer service handlers using two factories: Acceptor and Connector Both factories cooperate to create a full association between two peer service handlers Slide 5

6 Acceptor/Connector Structure (1) <<notifies>> Dispatcher <<notifies>> +select() +handle_events() +register_handler() +remove_handler() * Connector <<notifies>> * Service Handler Acceptor * Connector() connect() complete() handle_event () peer_stream_ open() handle_event () set_handle() peer_acceptor_ Acceptor() accept() handle_event () Concrete Connector Concrete Service Handler A Concrete Service Handler B Concrete Acceptor Slide 6

7 Acceptor/Connector Structure (2) <<notifies>> * 1 Connector Connector() connect() complete() handle_event () uses * uses owns uses * +register_handler() * Transport Handle 1 <<notifies>> Dispatcher +select() +handle_events() +remove_handler() * Service Handler peer_stream_ open() handle_event () set_handle() Transport Handle 1 owns uses <<creates>> <<notifies>> Transport Handle 1 * 1 owns Acceptor peer_acceptor_ Acceptor() accept() handle_event () * <<activate>> <<activate>> Concrete Connector * 1 Concrete Service Handler A 1 Concrete Service Handler B Concrete Acceptor Slide 7

8 Acceptor Dynamics : Application : Acceptor : Dispatcher 1. Acceptor open() Acceptor accept() Handle1 ACCEPT_ EVENT register_handler() handle_events() Event : Handle2 2. : Service Handler Handle2 Handle2 3. open() Service Handler Events register_handler() handle_event() service() Event 1. Passive-mode endpoint initialize phase 2. Service handler initialize phase 3. Service processing phase Slide 8

9 Motivation for Synchrony If connection latency is negligible e.g., connecting with a server on the same host via a loopback device If multiple threads of control are available and it is efficient to use a thread-per-connection to connect each service handler synchronously If the services must be initialized in a fixed order and the client can t perform useful work until all connections are established Slide 9

10 Synchronous Connector Dynamics : Application : Connector : Service : Dispatcher Handler 1. Service Handler Addr connect() get_handle() Handle 2. Wait for Connection event open() Service Handler Handle register_handler() Events handle_events() handle_event() Event 1. Sync connection initiation phase 2. Service handler initialize phase 3. Service processing phase 3. service() Slide 10

11 Motivation for Asynchrony If client is establishing connections over high latency links If client is a single-threaded application If client is initializing many peers that can be connected in an arbitrary order Slide 11

12 Asynchronous Connector Dynamics : Application : Connector : Service : Dispatcher Handler 1. Service Handler Addr connect() get_handle() Handle Handle register_handler() Connector CONNECT EVENT complete() handle_events() Event 2. open() remove_handler() register_handler() Service Handler Handle Events Event handle_event() 3. service() 1. Async connection initiation phase 2. Service handler initialize phase 3. Service processing phase Slide 12

13 Three Layers <<notifies>> Dispatcher <<notifies>> uses uses * register_handler() * Transport Handle select() handle_events() remove_handler() Transport Handle uses * Transport Handle * Connector uses <<notifies>> * Service Handler <<creates>> owns Acceptor * Connector() connect() complete() handle_event () owns peer_stream_ open() handle_event () set_handle() owns peer_acceptor_ Acceptor() Accept() handle_event () <<activate>> <<activate>> Concrete Connector * Concrete Service Handler A Concrete Service Handler B Concrete Acceptor Slide 13

14 Implementation Steps 1. Implement the demultiplexing/ dispatching infrastructure layer components 2. Implement the connection management layer components 3. Implement the application layer components Slide 14

15 Gateway Example Sattelite Each service in a peer use the gateway to send and receive status info, bulk data and commands to satellites Gateway Computer Tracking Station Peer Ground Station Peer Ground Station Peer Slide 15

16 1.2. Implement the Dispatching Mechanisms A dispatcher is responsible for associating requests to their corresponding acceptors, connectors and service handlers Use the Reactor for synchronous demultiplexing (follow the Reactor guidelines) Use the Proactor for asynchronous demultiplexing (follow the Proactor guidelines) Can be implemented as a separate thread using the Active Object pattern or Leader/Followers thread pools Slide 16

17 Gateway Example 1.1 Select the transport mechanisms uses Socket API with passive-mode and data mode sockets transport handles = socket handles transport address = IP host address and TCP port number 1.2 Implement the dispatching mechanisms using components from the Reactor pattern within a single thread of control using a Singleton Reactor (GoF) Slide 17

18 UML Template Class Notation Generic notation Event_Handler Concrete Binding to SOCK_Stream Wrapper façade class IPC_STREAM Service_Handler Service_Handler <SOCK_Stream> Slide 18

19 Service_Handler Class Definition template <class IPC_STREAM> class Service_Handler : public Event_Handler { public: typedef typename IPC_STREAM::PEER_ADDR Addr; // Hook template method, defined by a subclass virtual void open() = 0; IPC_STREAM &peer() { return ipc_stream_; } Addr &remote_addr() { return ipc_stream_.remote_addr(); } void set_handle(handle handle) {ipc_stream_.set_handle(handle);} private: // Template placeholder for a concrete IPC mechanism wrapper // façade, which encapsulate a data-mode transport endpoint and // transport handle IPC_STREAM ipc_stream_; }; Slide 19

20 2.2 Define the Generic Acceptor Interface A generic acceptor is customized by the components in the application layer A customization can be made by using one of two general strategies: Polymorphism Using subclassing and a Template Method accept (GoF) The concrete service handler is created by a Factory Method (GoF) Parameterized types accept is also here a Template Method (GoF), which delegates to the IPC mechanism configured into the acceptor class, The service handler can also be supplied as a template parameter Slide 20

21 Inheritance - Parameterized Types trade-offs Parameterized types may incur additional compile and link-time overhead but generally compile into faster code Inheritance may incur additional run-time overhead due to the indirection of dynamic binding but is generally faster to compile and link Slide 21

22 Acceptor Template Class Event_Handler Acceptor SERVICE_HANDLER, IPC_ACCEPTOR Both of these concrete types are provided by the components in the application layer Slide 22

23 Acceptor Class Definition template <class SERVICE_HANDLER, class IPC_ACCEPTOR> class Acceptor : public Event_Handler { public: typedef typename IPC_ACCEPTOR::PEER_ADDR Addr; Acceptor (const Addr &local_addr, Reactor *r); virtual void handle_event(handle, Event_Type); protected: virtual void accept(); // template method virtual SERVICE_HANDLER *make_service_handler(); virtual void accept_service_handler(service_handler *); virtual void activate_service_handler(service_handler *); virtual HANDLE get_handle() const; private: IPC_ACCEPTOR peer_acceptor_; // template placeholder }; Slide 23

24 Acceptor Constructor template <class SERVICE_HANDLER, class IPC_ACCEPTOR) Acceptor<SERVICE_HANDLER, IPC_ACCEPTOR>::Acceptor( const Addr &local_addr, Reactor *reactor) { // initialize the IPC_ACCEPTOR; peer_acceptor_.open(local_addr); } // register with <reactor> reactor->register_handler(this, ACCEPT_MASK); Slide 24

25 Acceptor Event Handling In the Gateway Example: the dispatcher is a Reactor calling the handle_event method defined in the Event_Handler base class and specialized in the Acceptor class :Reactor 1. handle_event() :Acceptor 1.1 accept() GoF Adapter method Acceptor::handle_event() { accept(); } Slide 25

26 Acceptor::accept Method template <class SERVICE_HANDLER, class IPC_ACCEPTOR) void Acceptor<SERVICE_HANDLER, IPC_ACCEPTOR>::accept() { // GoF: Factory Method creates a new <SERVICE_HANDLER> SERVICE_HANDLER *service_handler= make_service_handler(); // Hook method that accepts a connection passively accept_service_handler(service_handler); } // Hook method that activates the <SERVICE_HANDLER> by // invoking its <open> activation hook method activate_service_handler(service_handler); Example off a GoF Template Method Slide 26

27 Peer Host specific Classes Event_ Handler Service_ Handler <Sock_Stream> Bulk_Data_ Handler Command_ Handler * Status_ Handler * * Acceptor <Status_Handler, SOCK_Acceptor> Acceptor <Bulk_Data_Handler, SOCK_Acceptor> Acceptor <Command_Handler, SOCK_Acceptor> Slide 27

28 Peer Host Main Program typedef Acceptor<Status_Handler, SOCK_Acceptor> Status_Acceptor; int main() { // Initialize three concrete acceptors to listen for connections on // their well-known ports Status_Acceptor s_acceptor(status_port, Reactor::instance()); Bulk_Data_Acceptor bd_acceptor(bulk_data_port, Reactor::instance()); Command_Acceptor c_acceptor(command_port, Reactor::instance()); } // Event loop that accepts connection request event and processes // data from a gateway for (; ;) Reactor::instance()->handle_events(); Slide 28

29 Gateway specific Classes Event_ Handler * Initiation Dispatcher Service_ Handler <Sock_Stream> Command_ Router * Bulk_Data_ Router * Status_ Router * Connector <Peer_Router, SOCK_Connector> Slide 29

30 Gateway Main Program typedef Service_Handler<SOCK_Stream> Peer_Router; typedef Connector<Peer_Router, SOCK_Connector> Peer_Connector; int main() { Peer_Connector peer_connector(reactor::instance()); vector<peer_router> peers; get_peer_addrs(peers); // initialize the three routers from a config. file typedef vector<peer_router>::iterator Peer_Iterator; } for (Peer_Iterator peer= peers.begin(); peer!= peers.end(); peer++) { peer_connector.connect( (*peer), peer->remote_addr(), Peer_Connector::ASYNC); } for ( ; ;) Reactor->instance()->handle_events(); Slide 30

31 Acceptor/Connector Benefits Reusability, portability, & extensibility This pattern decouples mechanisms for connecting & initializing service handlers from the service processing performed after service handlers are connected & initialized Robustness This pattern strongly decouples the service handler from the acceptor, which ensures that a passive-mode transport endpoint can t be used to read or write data accidentally Efficiency This pattern can establish connections actively with many hosts asynchronously & efficiently over long-latency wide area networks Asynchrony is important in this situation because a large networked system may have hundreds or thousands of host that must be connected Slide 31

32 Acceptor/Connecter Liabilities Additional indirection The Acceptor-Connector pattern can incur additional indirection compared to using the underlying network programming interfaces directly Additional complexity The Acceptor-Connector pattern may add unnecessary complexity for simple client applications that connect with only one server & perform one service using a single network programming interface Slide 32

33 Applying the Reactor and Acceptor-Connector Patterns in JAWS The Reactor architectural pattern decouples: 1.JAWS generic synchronous event demultiplexing & dispatching logic from 2.The HTTP protocol processing it performs in response to events Reactor handle_events() register_handler() remove_handler() <<uses>> handle set Synchronous Event Demuxer select () * Handle * notifies dispatches * owns HTTP Acceptor handle_event () get_handle() Event Handler handle_event () get_handle() HTTP Handler handle_event () get_handle() Slide 33

34 Acceptor/Connector and Reactor The Acceptor-Connector design pattern can use a Reactor as its Dispatcher in order to help decouple: 1.The connection & initialization of peer client & server HTTP services from 2.The processing activities performed by these peer services once they are connected & initialized Slide 34

35 Reactive Connection Management in JAWS Slide 35

36 Reactive Data Transfer in JAWS Slide 36

37 Known Uses Unix network superservers Inetd, Listen Use a master acceptor process that listen for connections on a set of communication ports Inetd services: FTP, Telnet, Daytime and Echo CORBA Object Request Brokers (ORB) Web Browsers Netscape + Internet Explorer use the asynchronous version of the connector component to establish connections with servers associated with images embedded in HTML pages Project Spectrum A high-speed medical image transfer system Slide 37

38 Relation to other POSA2 Patterns Slide 38

39 Acceptor-Connector part two Connector class Concurrency strategies Slide 39

40 Connector Class (1) template <class SERVICE_HANDLER, class IPC_CONNECTOR> class Connector : public Event_Handler { public: enum Connection_Mode { SYNC, ASYNC }; typedef typename IPC_CONNECTOR::PEER_ADDR Addr; Connector(Reactor *reactor): reactor_(reactor) { } // Template Method void connect( SERVICE_HANDLER *sh, const Addr &remote_addr, Connection_Mode mode) { connect_service_handler(sh, remote_addr, mode); } // Adapter Method virtual void handle_event(handle handle, Event_Type) { complete(handle); } protected: virtual void complete(handle handle); Slide 40

41 Connector Class (2) template <class SERVICE_HANDLER, class IPC_CONNECTOR> class Connector : public Event_Handler { // Continued from previous slide virtual void connect_service_handler(const Addr &addr, Connection_Mode mode); int register_handler(service_handler *sh, Connection_Mode mode); virtual void activate_service_handler(service_handler *sh); private: IPC_CONNECTOR connector_; // C++ standard library map that associates <HANDLES> with // <SERVICE_HANDLER> s for pending connections typedef map<handle, SERVICE_HANDLER*> Connection_Map; Connection_Map connection_map_; Reactor *reactor_; } Slide 41

42 Connector::connect_service_handler() template <class SERVICE_HANDLER, class IPC_CONNECTOR> class Connector< SERVICE_HANDLER, IPC_CONNECTOR>:: connect_service_handler(service_handler *svc_handler, const Addr &addr, Connection_Mode mode) { try { connector_.connect(*svc_handler, addr, mode); // activate if we connect synchronously activate_service_handler(svc_handler); } catch (SystemEx &ex) if (ex.status() == EWOULDBLOCK && mode == ASYNC) { // register for asynchronously call back reactor_->register_handler(this,write_mask); // store <service handler *> in map connection_map_[connector_.get_handle()]= svc_handler; } } } Slide 42

43 Connector::complete() template <class SERVICE_HANDLER, class IPC_CONNECTOR> class Connector< SERVICE_HANDLER, IPC_CONNECTOR>::complete( HANDLE handle) { Connection_Map ::iterator i = connection_map_.find(handle); if (i == connection_map_.end() ) throw. // we just want the value part of the <key,value> SERVICE_HANDLER *svc_handler = (*i).second; // Transfer I/O Handle to <service_handler> svc_handler->set_handle(handle); reactor_->remove_handler(handle, WRITE_MASK); connection_map_.erase(i); } // connection is complete so activate handler activate_service_handler(svc_handler); Slide 43

44 Examples of Flexibility Each concrete service handler could implement a different concurrency strategy Status_Router can run in a separate thread Bulk_Data_Router as a separate process Command_Router runs in the same thread as the Reactor The concurrency strategy is implemented in the open() hook method Slide 44

45 Status_Router Class class Status_Router: public Peer_Router { public: virtual void open() { // Make this handler run in separate thread Thread_Manager::instance()->spawn( &Status_Handler::svc_run, this); } static void *svc_run(status_handler *this_obj) { for (; ;) this_obj->run(); } // receive and process status data from/to peers virtual void run() { char buf[bufsiz]; peer().recv(buf, sizeof(buf)); // routing takes place here } }; Slide 45

46 Bulk_Data_Router Class class Bulk_Data_Router: public Peer_Router { public: virtual void open() { // activate router in a separate process if (fork() ==0) { // this method can block because it runs in its own process for (; ;) run(); } } // receive and route bulk data from/to peers virtual void run() { char buf[bufsiz]; peer().recv(buf, sizeof(buf)); // routing takes place here } Slide 46