Reactor - Brian Foote

1 Douglas C. Schmidt 1998, 1999, all rights reserved, Siemens AG 1998, 1999, all rights reservedReactorTheReactordesign pattern handles service requests that are deliv-ered concurrently to an application by one or more known asDispatcher, NotifierExampleConsider an event-driven server for a distributed logging service. Cli-ent applications use the logging service to record information abouttheir status in a distributed environment. This status informationcommonly includes error notifications, debugging traces, and perfor-mance diagnostics. Logging records are sent to a central logging serv-er, which can write the records to various output devices, such as aconsole, a printer, a file, or a network management communicate with the logging server using a connection-ori-ented protocol, such as TCP [Ste90]: clients and the logging serviceare bound to a connection endpoint designated by an IP address anda TCP port number on the clients and logging server.

2 The port numberuniquely identifies the clients and the logging service, logging service is typically used by multiple clients, each main-taining its own connection with the logging server. Thus the loggingrecords and connection requests which these clients issue can arriveconcurrently at the logging HandlesLoggingServerClientClientClientNe tworkConsoleDatabasePrinterloggingrecord sloggingrecordsconnectionrequest2 Douglas C. Schmidt 1998, 1999, all rights reserved, Siemens AG 1998, 1999, all rights , using multi-threading, to implement the processing oflogging records in the server in a thread-per-connection fashion failsto resolve the following aspects: Efficiency. Threading may lead to poor performance due to contextswitching, synchronization, and data movement [Sch94]. Programming simplicity.

3 Threading may require complex concur-rency control schemes. Portability. Threading is not available on all OS a result of these drawbacks, multi-threading is often neither themost efficient nor the least complex solution to develop a concurrentlogging server. Yet we must handle client requests server application in a distributed system that receives servicerequests from one or more clients applications in a distributed system must handle one or moreclients that send them service requests. Each such request is typical-ly associated with a specific operating system event. For instance, inour logging server example, the request for processing logging recordswithin the logging service is indicated by aREAD event. Before invok-ing a specific service, the server application must therefore demulti-plex and dispatch each incoming event to its corresponding serviceprovider.

4 Resolving this problem effectively requires the resolution ofthe following fiveforces: The server must be available to handle input events even if it iswaiting for other events to occur. In particular, a server must notblock indefinitely handling any single source of events at theexclusion of other event sources since this may significantly delayits responsiveness to other clients. A server must minimize latency, maximize throughput, and avoidutilizing the CPU(s) unnecessarily. The design of a server should simplify the use of suitable concur-rency strategies. Integrating new or improved services, such as changing messageformats or adding server-side caching, should incur minimalmodifications and maintenance costs for existing code. Forinstance, implementing application services should not Douglas C.

5 Schmidt 1998, 1999, all rights reserved, Siemens AG 1998, 1999, all rights reservedmodifications to the generic event demultiplexing and dispatchingmechanisms. Porting a server to a new operating system platform should notrequire significant the synchronous demultiplexing of events with theirdispatching to the service providers that handle these events. In ad-dition, decouple these general-purpose event demultiplexing anddispatching mechanisms from the application-specific dispatching ofevents to services within the service each service the application offers, introduce a separateeventhandler that processes certain types of events. Event handlersregister with aninitiation dispatcher, which uses asynchronous eventdemultiplexer to wait for events to occur. When events occur, thesynchronous event demultiplexer notifies the initiation dispatcher,which synchronously calls back to the event handler associated withthe event.

6 The event handler then dispatches the event to the methodthat implements the requested key participants in the Reactor pattern include the following:Handles identify resources that are managed by an operating resources commonly include, among others, network connec-tions, open files, timers, and synchronization objects. Handles are used in the logging server to identify socket end-points so that a synchronous event demultiplexer can wait for eventsto occur on them. The two types of events the logging server is inter-ested in are connection events and read events, which represent in-coming client connections and logging data, respectively. The loggingserver maintains a separate connection for each client. Every connec-tion is represented in the server by a socket event demultiplexer blocks awaiting events to occur ona set of handles.

7 The blocking does not impede the progress of theprocess in which the synchronous event demultiplexer resides, sinceit only blocks when no events are queued at the handles. It returnswhen it is possible to initiate an operation on a handle without block-ing. A common demultiplexer for I/O events isselect [Ste90], whichis an event demultiplexing system call provided by the UNIX and4 Douglas C. Schmidt 1998, 1999, all rights reserved, Siemens AG 1998, 1999, all rights OS platforms. Theselect call indicates which handles canhave operations invoked on them synchronously without dispatcher defines an interface for registering, removing,and dispatching event handler objects. Ultimately, the synchronousevent demultiplexer is responsible for waiting until events it detects new events, it informs the initiation dispatcher to callback application-specific event handlers.

8 Common events includeconnection acceptance events, data input and output events, andtimeout handler specifies an interface consisting of a hook method[Pree95] that abstractly represents the dispatching operation forservice-specific event handlers derive from the abstract event handler. Eachimplements the methods for a specific service that the applicationoffers. In addition, concrete event handlers implement the inheritedevent dispatching hook method, which is responsible for processingincoming events sent to the service from clients. Applications registerClassInitiationDispatcherRespons ibility Registers EventHandlers Dispatches EventHandlersCollaborator Concrete EventHandlers SynchronousEventDemultiplexerClassHandle Responsibility Identifies operatingsystem resourcesCollaboratorClassSynchronous EventDemultiplexerResponsibility Listens for events Indicatespossibility toinitiate anoperation on ahandleCollaborator Handle Douglas C.

9 Schmidt 1998, 1999, all rights reserved, Siemens AG 1998, 1999, all rights reservedconcrete event handlers with the initiation dispatcher to processcertain types of events. When these events arrive, the initiationdispatcher calls back the hook method of the appropriate concreteevent handler. There are two concrete event handlers in the logging server: log-ging handler and logging acceptor. The logging handler is responsiblefor receiving and processing logging records. The logging acceptoruses the Acceptor-Connector pattern (129) to create and connect log-ging handlers that process subsequent logging records from structure of the participants in the Reactor pattern is illustratedin the following UML class diagram:DynamicsThe following collaborations occur in the Reactor pattern: An application registers a concrete event handler with the initiationdispatcher.

10 At this point, the application indicates the type ofevent(s) this event handler wants the initiation dispatcher to notifyit about when the event(s) occur on the associated HandlerResponsibility Defines aninterface forprocessing eventsCollaborator HandleClassConcrete EventHandlerResponsibility Processes events ina specific mannerCollaboratorEvent Handlerhandle_event()get_handle() InitiationDispatcherhandle_events()regis ter_handler()remove_handler() Synchronous EventDemultiplexerselect()Concrete EventHandler Ahandle_event()get_handle()Concrete EventHandler Bhandle_event()get_handle()Handle<<use>>notifiesownsdispatches*6 Douglas C. Schmidt 1998, 1999, all rights reserved, Siemens AG 1998, 1999, all rights The initiation dispatcher requests each event handler to pass backits internal handle. This handle identifies the event handler to theoperating system.