3.1 Overview

I l @ ve RuBoard

ACE defines a set of C++ classes that address the limitations with the Socket API described in Section 2.3. These classes are designed in accordance with the Wrapper Facade design pattern [SSRB00]. ^[1] They therefore encapsulate the functions and data provided by existing non-object-oriented APIs within more concise , robust, portable, maintainable , and cohesive object-oriented class interfaces. The ACE Socket wrapper facade classes presented in this chapter include:

^[1] In the rest of this book, we use the term ACE wrapper facade to indicate an ACE class designed using the Wrapper Facade pattern.

ACE Class	Description
ACE_Addr	The root of the ACE network addressing hierarchy.
ACE_INET_Addr	Encapsulates the Internet-domain address family.
ACE_IPC_SAP	The root of the ACE IPC wrapper facade hierarchy.
ACE_SOCK	The root of the ACE Socket wrapper facade hierarchy.
ACE_SOCK_Connector	A factory that connects to a peer acceptor and then initializes a new endpoint of communication in an ACE_SOCK_Stream object.
ACE_SOCK_IO ACE_SOCK_Stream	Encapsulate the data transfer mechanisms supported by data-mode sockets.
ACE_SOCK_Acceptor	A factory that initializes a new endpoint of communication in an ACE_SOCK_Stream object in response to a connection request from a peer connector.

Figure 3.1 illustrates the key relationship between these classes. These ACE Socket wrapper facades provide the following benefits:

• Enhance type-safety by detecting many subtle application type errors quickly; for example, the passive and active connection establishment factories don't provide methods for sending or receiving data, so type errors are caught at compile time rather than at run time.

• Ensure portability via platform-independent C++ classes.

• Simplify common use cases by reducing the amount of application code and development effort expended on lower-level network programming details, which frees developers to focus on higher-level, application-centric concerns.

Figure 3.1. The ACE Connection-Oriented Socket Class Relationships

Moreover, ACE Socket wrapper facades retain efficiency by using inline functions to enhance the software qualities listed above without sacrificing performance. ACE's efficiency- related design principles are discussed further in Section A.6 on page 255.

The structure of the ACE Socket wrapper facades corresponds to the taxonomy of communication services, connection/communication roles, and communication domains shown in Figure 3.2. The classes in this figure provide the following capabilities:

• The ACE_SOCK_* classes encapsulate the Internet-domain Socket API functionality.

• The ACE_LSOCK_* classes encapsulate the UNIX-domain Socket API functionality.

Figure 3.2. Taxonomy of the ACE Socket Wrapper Facades

It's instructive to compare the structure of the ACE classes in Figure 3.2 with the functions shown in Figure 2.1 on page 42. The classes in Figure 3.2 are much more concise since they use the ACE Socket wrapper facades to encapsulate the behavior of multiple socket functions within C++ classes related by inheritance. In addition to the classes that support connection establishment and communication, ACE also provides a related set of addressing classes. We examine their capabilities in Section 3.2 and their underlying design principles in Section A.4.2. Figure 3.1 depicts the associations between these classes and the other ACE classes in the connection-oriented Socket API family.

The remainder of our discussion in this chapter focuses on the ACE connection-oriented Internet-domain wrapper facades because they're the most widely used ACE IPC mechanism. The classes are arranged in the hierarchy shown in Figure 3.1. To avoid duplication of code, common methods and state are factored into abstract classes, which aren't instantiated directly. Subclasses then add appropriate methods and enforce proper usage patterns. For example, connection-oriented networked applications are typified by asymmetric connection roles between clients and servers. Servers listen passively for clients to initiate connections actively [SSRB00], as shown in Figure 3.3. Even in peer-to-peer applications, in which applications play the role of both client and server, connections must be initiated actively by one of the peers and accepted passively by the other.

Figure 3.3. Roles in the ACE Socket Wrapper Facade

The functions in the C Socket API can be distinguished by the three different roles they play for connection-oriented protocols, such as TCP:

1. The active connection role (connector) is played by a peer application that initiates a connection to a remote peer

2. The passive connection role (acceptor) is played by a peer application that accepts a connection from a remote peer and

3. The communication role (stream) is played by both peer applications to exchange data after they are connected.

This chapter motivates and describes the capabilities of the ACE Socket classes that collectively provide the connection and communication roles outlined above. Keep in mind the points noted in Sidebar 4 regarding UML diagrams and C++ code in this book.

I l @ ve RuBoard