INFO: Do Not Use Two Sockets to Separate QOS Notification from Data Transfer (228857)

SUMMARY

Attempting to use two sockets for the purpose of segregating Quality Of Service (QOS) setup/notification functionality from the actual data transfer functionality (with QOS applied on the transfer) is not supported.

Developers are advised to use the same socket for both QOS setup/notification and for data transfer. This recommendation applies to both User Datagram Protocol (UDP) and Transfer Control Protocol (TCP) sockets opened with the QOS Service Provider (QOSSP).

Developers should avoid the following scenario:

1. Create and bind a socket using the QOSSP.
2. Set QOS on that socket using WSAAccept, WSAConnect, WSAIoctl(SIO_SET_QOS), or WSAJoinLeaf.
3. Set the socket option SO_REUSEADDR on that socket.
4. Create another socket and bind to the same local address as the first socket.
5. Use one of the sockets for QOS setup/notification (that is, waiting for and handling FD_QOS notification) and use the other socket for data transfer, with QOS applied to the transfer.

The problem with this scenario is that Winsock leaves undefined the behavior of these two sockets, which have the same local address. For example, it is not defined which socket would receive data. In the above scenario, it does not matter which socket has QOS set.

A second scenario, which involves duplicating a QOS socket for use in another process, is also not supported. For additional information about this scenario, please click the article number below to view the article in the Microsoft Knowledge Base: Instead of using one of the above two scenarios, developers are advised to design their applications to perform as follows:

1. Open a socket with the QOSSP.
2. Set QOS for the socket using WSAAccept, WSAConnect, WSAIoctl(SIO_SET_QOS), or WSAJoinLeaf.
3. Send/receive data using that socket.
4. Handle all QOS setup/notification using that socket.