B.3 WinSock 2 Interface Elements for Multipoint and Multicast

B.3.2. Flag bits for WSASocket()

• 
  WSA_FLAG_MULTIPOINT_C_ROOT, for the creation of a socket acting as a c_root, and only allowed if a rooted control plane is indicated in the corresponding WSAPROTOCOL_INFO entry.
  
• 
  WSA_FLAG_MULTIPOINT_C_LEAF, for the creation of a socket acting as a c_leaf, and only allowed if XP1_SUPPORT_MULTIPOINT is indicated in the corresponding WSAPROTOCOL_INFO entry.
  
• 
  WSA_FLAG_MULTIPOINT_D_ROOT, for the creation of a socket acting as a d_root, and only allowed if a rooted data plane is indicated in the corresponding WSAPROTOCOL_INFO entry.
  
• 
  WSA_FLAG_MULTIPOINT_D_LEAF, for the creation of a socket acting as a d_leaf, and only allowed if XP1_SUPPORT_MULTIPOINT is indicated in the corresponding WSAPROTOCOL_INFO entry.
  

B.3.3. SIO_MULTIPOINT_LOOP command code for WSAIoctl()

When d_leaf sockets are used in a non-rooted data plane, it is generally desirable to be able to control whether traffic sent out is also received back on the same socket. The SIO_MULTIPOINT_LOOP command code for WSAIoctl() is used to enable or disable loopback of multipoint traffic.

B.3.4. SIO_MULTICAST_SCOPE command code for WSAIoctl()

When multicasting is employed, it is usually necessary to specify the scope over which the multicast should occur. Scope is defined as the number of routed network segments to be covered. A scope of zero would indicate that the multicast transmission would not be placed “on the wire” but could be disseminated across sockets within the local host. A scope value of one (the default) indicates that the transmission will be placed on the wire, but will not cross any routers. Higher scope values determine the number of routers that may be crossed. Note that this corresponds to the time-to-live (TTL) parameter in IP multicasting.

B.3.5. WSAJoinLeaf()

The function WSAJoinLeaf() is used to join a leaf node into the multipoint session. The function prototype is as follows:
SOCKET WSAAPI WSAJoinLeaf ( SOCKET s, const struct sockaddr FAR * name, int namelen, LPWSABUF lpCallerData, LPWSABUF lpCalleeData, LPQOS lpSQOS, LPQOS lpGQOS, DWORD dwFlags );
See below for a discussion on how this function is utilized.

B.4. Semantics for joining multipoint leaves

In the following, a multipoint socket is frequently described by defining its role in one of the two planes (control or data). It should be understood that this same socket has a role in the other plane, but this is not mentioned in order to keep the references short. For example when a reference is made to a “c_root socket” , this could be either a c_root/d_root or a c_root/d_leaf socket.
In rooted control plane schemes, new leaf nodes are added to a multipoint session in one or both of two different ways. In the first method, the root uses WSAJoinLeaf() to initiate a connection with a leaf node and invite it to become a participant. On the leaf node, the peer application must have created a c_leaf socket and used listen() to set it into listen mode. The leaf node will receive an FD_ACCEPT indication when invited to join the session, and signals its willingness to join by calling WSAAccept(). The root application will receive an FD_CONNECT indication when the join operation has been completed.
In the second method, the roles are essentially reversed. The root application creates a c_root socket and sets it into listen mode. A leaf node wishing to join the session creates a c_leaf socket and uses WSAJoinLeaf() to initiate the connection and request admittance. The root application receives FD_ACCEPT when an incoming admittance request arrives, and admits the leaf node by calling WSAAccept(). The leaf node receives FD_CONNECT when it has been admitted.
In a non-rooted control plane, where all nodes are c_leaf’s, the WSAJoinLeaf() is used to initiate the inclusion of a node into an existing multipoint session. An FD_CONNECT indication is provided when the join has been completed and the returned socket descriptor is useable in the multipoint session. In the case of IP multicast, this would correspond to the IP_ADD_MEMBERSHIP socket option. ⁴
There are, therefore, three instances where an application would use WSAJoinLeaf():

1. 
   Acting as a multipoint root and inviting a new leaf to join the session
   
2. 
   Acting as a leaf making an admittance request to a rooted multipoint session
   
3. 
   Acting as a leaf seeking admittance to a non-rooted multipoint session (e.g. IP multicast)
   

B.4.1. Using WSAJoinLeaf()

As mentioned previously, the function WSAJoinLeaf() is used to join a leaf node into a multipoint session. WSAJoinLeaf() has the same parameters and semantics as WSAConnect() except that it returns a socket descriptor (as in WSAAccept()), and it has an additional dwFlags parameter. The dwFlags parameter is used to indicate whether the socket will be acting only as a sender, only as a receiver, or both. Only multipoint sockets may be used for input parameter s in this function. If the multipoint socket is in the non-blocking mode, the returned socket descriptor will not be useable until after a corresponding FD_CONNECT indication has been received. A root application in a multipoint session may call WSAJoinLeaf() one or more times in order to add a number of leaf nodes, however at most one multipoint connection request may be outstanding at a time.
The socket descriptor returned by WSAJoinLeaf() is different depending on whether the input socket descriptor, s, is a c_root or a c_leaf. When used with a c_root socket, the name parameter designates a particular leaf node to be added and the returned socket descriptor is a c_leaf socket corresponding to the newly added leaf node. It is not intended to be used for exchange of multipoint data, but rather is used to receive FD_XXX indications (e.g. FD_CLOSE) for the connection that exists to the particular c_leaf. Some multipoint implementations may also allow this socket to be used for “side chats” between the root and an individual leaf node. An FD_CLOSE indication will be received for this socket if the corresponding leaf node calls closesocket() to drop out of the multipoint session. Symmetrically, invoking closesocket() on the c_leaf socket returned from WSAJoinLeaf() will cause the socket in the corresponding leaf node to get FD_CLOSE notification.
When WSAJoinLeaf() is invoked with a c_leaf socket, the name parameter contains the address of the root application (for a rooted control scheme) or an existing multipoint session (non-rooted control scheme), and the returned socket descriptor is the same as the input socket descriptor. In a rooted control scheme, the root application would put its c_root socket in the listening mode by calling listen(). The standard FD_ACCEPT notification will be delivered when the leaf node requests to join itself to the multipoint session. The root application uses the usual accept()/WSAAccept() functions to admit the new leaf node. The value returned from either accept() or WSAAccept() is also a c_leaf socket descriptor just like those returned from WSAJoinLeaf(). To accommodate multipoint schemes that allow both root-initiated and leaf-initiated joins, it is acceptable for a c_root socket that is already in listening mode to be used as in input to WSAJoinLeaf().
A multipoint root application is generally responsible for the orderly dismantling of a multipoint session. Such an application may use shutdown() or closesocket() on a c_root socket to cause all of the associated c_leaf sockets, including those returned from WSAJoinLeaf() and their corresponding c_leaf sockets in the remote leaf nodes, to get FD_CLOSE notification.

Download 1.64 Mb.

Share with your friends: