1.5 Example: A Networked Logging Service
It's been our experience that the principles, methods, and skills required to develop and use reusable networked application software cannot be learned solely by generalities or toy examples. Instead, programmers must learn concrete technical skills and gain hands-on experience by developing and using real frameworks and applications. We therefore illustrate key points and ACE capabilities throughout this book by extending and enhancing the networked logging service example introduced in C++NPv1, which collects and records diagnostic information sent from one or more client applications.
The logging service in C++NPv1 used many of ACE's wrapper facades in a two-tier client/server architecture. This book's logging service examples use a more powerful architecture that illustrates a broader complement of capabilities and patterns, and demonstrates how ACE's frameworks can help achieve efficient, predictable, and scalable networked applications. This service also helps to demonstrate key design and implementation considerations and solutions that will arise when you develop your own concurrent object-oriented networked applications.
Figure 1.10 illustrates the application processes and daemons in our networked logging service, which we outline below.
Figure 1.10: Processes and Daemons in the Networked Logging Service
Client application processes (such as P1, P2, and P3) run on client hosts and generate log records ranging from debugging messages to critical error messages. The logging information sent by a client application contains the time the log record was created, the process identifier of the application, the priority level of the log record, and a variable-sized string containing the log record text message. Client applications send these log records to a client logging daemon running on their local host.
Client logging daemons run on every host machine participating in the networked logging service. Each client logging daemon receives log records from that host's client applications via some form of local IPC mechanism, such as shared memory, pipes, or sockets. The client logging daemon uses a remote IPC mechanism, such as TCP/IP, to forward log records to a server logging daemon running on a designated host.
Server logging daemons collect and output the incoming log records they receive from client applications via client logging daemons. A server logging daemon2 can determine which client host sent each message by using addressing information it obtains from the underlying Socket API. There's generally one server logging daemon per system configu-ration, though they could be replicated to avoid a single point of failure.
Figure 1.11 (page 22) shows the progression of networked application servers that we'll develop and use in this book. These client and server logging daemons will illustrate how to use the ACE frameworks and wrapper facades with the following concurrency models.
Concurrency Model |
Section |
Reactive |
3.5, 4.2, 5.4 |
Thread pool |
4.3, 4.4, 6.3 |
Thread-per-connection |
7.2, 7.3 |
Producer/consumer |
6.2, 7.4, 9.2 |
Proactive |
8.2 8.5 |
Figure 1.11: Logging Server Examples