Protocol-Independent Multicast and Multipoint in the SPI

Just as Windows Sockets 2 allows the basic data transport capabilities of numerous transport protocols to be accessed in a generic manner, it also provides a generic way to use multipoint and multicast capabilities of transports that implement these features. To simplify, the term multipoint is used hereafter to refer to both multicast and multipoint communications.

Current multipoint implementations (for example, IP multicast, ST-II, T.120, ATM UNI, etc.) vary widely with respect to how nodes join a multipoint session, whether a particular node is designated as a central or root node, and whether data is exchanged between all nodes or only between a root node and the various leaf nodes. The Windows Sockets 2 WSAPROTOCOL_INFOW structure is used to declare the various multipoint attributes of a protocol. By examining these attributes the programmer will know what conventions to follow in using the applicable Windows Sockets 2 functions to set up, use, and tear down multipoint sessions.

The features of Windows Sockets 2 that support multicast can be summarized as follows:

• Three attribute bits in the WSAPROTOCOL_INFOW structure.
• Four flags defined for the dwFlags parameter of WSPSocket
• One function, WSPJoinLeaf, for adding leaf nodes into a multipoint session.
• Two WSPIoctl command codes for controlling multipoint loopback and establishing the scope for multicast transmissions. (The latter corresponds to the IP multicast time-to-live or TTL parameter.)

Note  The inclusion of these multipoint features in Windows Sockets 2 does not preclude a service provider from also supporting an existing protocol-dependent interface, such as the Deering socket options for IP multicast.