I l @ ve RuBoard |
Section 5.1 discussed server concurrency dimensions, with the reactive server on page 106 being one of the design choices. The reactive server model can be thought of as "lightweight multitasking," where a single-threaded server communicates with multiple clients in a round- robin manner without introducing the overhead and complexity of threading and synchronization mechanisms. This server concurrency strategy uses an event loop that examines and reacts to events from its clients continuously. An event loop demultiplexes input from various event sources so they can be processed in an orderly way. Event sources in networked applications are primarily socket handles. The most portable synchronous event demultiplexer for socket handles is the select() function and its handle sets, discussed on page 125 in Section 6.1. This chapter describes the following classes that can be applied to simplify and optimize the use of these facilities in reactive servers:
The interfaces of the ACE_Handle_Set and ACE_Handle_Set_Iterator classes are shown in Figure 7.1. These wrapper facades provide the following benefits: Figure 7.1. ACE_Handle_Set & ACE_Handle_Set_Iterator Class Diagrams
The ACE::select() wrapper methods encapsulate the select() system function and use the ACE_Handle_Set class to simplify handle passing. A reactive version of the logging server is used to illustrate how these ACE wrappers can simplify networked application programming. |
I l @ ve RuBoard |