• Choose a category
• All
• Classic-Fiction

Figure 26-7. Reactive logging server interface

The Reactive_Logging_Server class overrides all four hook methods that it inherits from base class Iterative_Logging_Server. Its open( ) hook method decorates the behavior of the base class method to initialize the ACE_Handle_Set member variables, which are part of the wrapper facades that simplify the use of select( ), as shown here:

template void

Reactive_Logging_Server::open () {

// Delegate to base class.

Iterative_Logging_Server::open ();

// Mark the handle associated with the acceptor as active.

master_set_.set_bit (acceptor_.get_handle ());

// Set the acceptor's handle into non-blocking mode.

acceptor_.enable (NONBLOCK);

}

The wait_for_multiple_events( ) method is needed in this implementation, unlike its counterpart in Iterative_Server. As shown in Figure 26-8, this method uses a synchronous event demultiplexer (in this case, the select( ) call) to detect which I/O handles have connection or data activity pending.

Figure 26-8. Using an asynchronous event demultiplexer in the Reactive_Logging_Server program

After wait_for_multiple_events( ) has executed, the Reactive_Logging_Server has a cached set of handles with pending activity (i.e., either new connection requests or new incoming data events), which will then be handled by its other two hook methods: handle_data( ) and handle_connections( ). The handle_connections( ) method checks whether the acceptors handle is active and, if so, accepts as many connections as possible and caches them in the master_handle_set_. Similarly, the handle_data( ) method iterates over the remaining active handles marked by select( ) earlier. This activity is simplified by the ACE socket wrapper facade that implements an instance of the Iterator pattern []for socket handle sets, as shown in Figure 26-9.

[] Gamma et al., op. cit.

The following code implements a Reactive_Logging_Server main program that uses the socket API:

int main (int argc, char *argv[]) {

Reactive_Logging_Server server (argc, argv);

server.run ();

return 0;

}

Figure 26-9. Reactive server connection/data event handling

The first line of our main function parameterizes the Reactive_Logging_Server with the SOCK_Acceptor type, which will cause the C++ compiler to generate code for a reactive logging server that is able to communicate over sockets. This will, in turn, parameterize its Logging_Server base class with both the SOCK_Acceptor and Null Mutex, by virtue of the hard-coded template argument provided when we inherited from it. The second line calls the run( ) template method, which is delegated to the Logging_Server base class, which itself delegates to the various hook methods we implemented in this class.

26.3.3. Evaluating the Sequential Logging Server Solutions

The Reactive_Logging_Server improves upon the Iterative_Logging_Server by interleaving its servicing of multiple clients, rather than just handling one client in its entirety at a time. It does not take advantage of OS concurrency mechanisms, however, so it cannot leverage multiprocessors effectively. Nor can it overlap computation and communication by processing log records while reading new records. These limitations impede its scalability as the number of clients increases, even if the underlying hardware supports multiple simultaneous threads of execution.

Although Iterative_Logging_Server and Reactive_Logging_Server run only in a single thread of control—and are thus not scalable for most production systems—their simplicity high-lights several more beautiful aspects of our OO framework-based design:

Our use of hook methods in the Logging_Server::run( ) template method shields application developers from low-level details—e.g., how a logging server performs IPC and event demulxiplexing operations—thereby enabling the developers to focus on domain-specific application logic by leveraging the expertise of framework designers.