3.4 The ACE_SOCK Class

I l @ ve RuBoard

Motivation

As discussed in Section 2.3, a key cause of accidental complexity in the Socket API stems from the inability of compilers to detect the misuse of socket handles during compilation. The ACE_IPC_SAP class described in Section 3.3 is the first step toward resolving this problem. The remainder of this chapter describes other ACE Socket wrapper facades that address the other problems illustrated in Section 2.3. We start by moving down the inheritance hierarchy in Figure 3.1 and discussing behavior that makes sense at each level, beginning with the ACE_SOCK class.

Class Capabilities

The ACE_SOCK class is the root of the ACE Socket wrapper facade hierarchy. In addition to exporting the methods inherited from ACE_IPC_SAP, ACE_SOCK provides capabilities that are common to other ACE Socket wrapper facades, including the classes discussed later in this chapter. These capabilities include

• Creating and destroying socket handles

• Obtaining the network addresses of local and remote peers and

• Setting and getting socket options, such as socket queue sizes, enabling broadcast/multicast communication, and disabling Nagle's algorithm (described in Sidebar 6 on page 64)

The interface of ACE_SOCK and its relationship to the ACE_IPC_SAP base class is shown in Figure 3.5 and its key methods are shown in the following table:

Method	Description
open() close()	Create and destroy a socket endpoint of communication.
get_local_addr() get_remote_addr()	Return the address of the local and remote peer, respectively.
set_option() get_option()	Set and get socket options.

To prevent accidental misuse, ACE_SOCK is defined as an abstract class; that is, its constructor is declared in the protected access control section of the class. As with ACE_IPC_SAP therefore, objects of ACE_SOCK can't be instantiated directly since they are accessible only to subclasses, such as the connection-oriented wrapper facades described in Section 3.5 through Section 3.7.

The ACE_SOCK class provides a close() method since it doesn't close the socket handle in its destructor. As described in Section A.6.1 on page 255, this design is intentional and prevents errors from occurring when an ACE_SOCK_Stream is passed by value or copied to different objects. Experienced ACE developers use higher-level classes to close the underlying socket handle automatically. For example, the Logging_Handler class described in Section 4.4.2 starting on page 86 closes its socket when the higher-level handler object is closed. The ACE_Svc_Handler class discussed in [SH] also closes the underlying socket handle automatically.

I l @ ve RuBoard