Function Extension Mechanism in the SPI

Since the Windows Sockets DLL itself is no longer supplied by each individual stack vendor, it is no longer possible for a stack vendor to offer extended functionality by just adding entry points to the Windows Sockets DLL. To overcome this limitation, Windows Sockets 2 takes advantage of the new WSAIoctl function to accommodate service providers who wish to offer provider-specific functionality extensions. This mechanism presupposes, of course, that an application is aware of a particular extension and understands both the semantics and syntax involved. Such information would typically be supplied by the service provider vendor.

In order to invoke an extension function, the application must first ask for a pointer to the desired function. This is done through the WSAIoctl function using the SIO_GET_EXTENSION_FUNCTION_POINTER command code. The input buffer to the WSAIoctl function contains an identifier for the desired extension function and the output buffer will contain the function pointer itself. The application can then invoke the extension function directly without passing through the Ws2_32.dll.

The identifiers assigned to extension functions are globally unique identifiers (GUIDs) that are allocated by service provider vendors. Vendors who create extension functions are urged to publish full details about the function including the syntax of the function prototype. This makes it possible for common and/or popular extension functions to be offered by more than one service provider. An application can obtain the function pointer and use the function without needing to know anything about the particular service provider that implements the function.