The WSALookupServiceBegin function initiates a client query that is constrained by the information contained within a WSAQUERYSET structure. WSALookupServiceBegin only returns a handle, which should be used by subsequent calls to WSALookupServiceNext to get the actual results.
INT WSAAPI WSALookupServiceBeginW( LPWSAQUERYSETW lpqsRestrictions, DWORD dwControlFlags, LPHANDLE lphLookup );
A pointer to the search criteria. See the Remarks for details.
A set of flags that controls the depth of the search.
Supported values for the dwControlFlags parameter are defined in the Winsock2.h header file and can be a combination of the following options.
||Queries deep as opposed to just the first level.|
||Returns containers only.|
||Do not return containers.|
||If possible, returns results in the order of distance. The measure of distance is provider specific.|
||Retrieves the name as lpszServiceInstanceName.|
||Retrieves the type as lpServiceClassId.|
||Retrieves the version as lpVersion.|
||Retrieves the comment as lpszComment.|
||Retrieves the addresses as lpcsaBuffer.|
||Retrieves the private data as lpBlob.|
||Any available alias information is to be returned in successive calls to WSALookupServiceNext, and each alias returned will have the RESULT_IS_ALIAS flag set.|
||Retrieves the query string used for the request.|
||A set of flags that retrieves all of the LUP_RETURN_* values.|
||Used as a value for the dwControlFlags parameter in WSALookupServiceNext. Setting this flag instructs the provider to discard the last result set, which was too large for the specified buffer, and move on to the next result set.|
||If the provider has been caching information, ignores the cache, and queries the namespace itself.|
||This indicates whether prime response is in the remote or local part of CSADDR_INFO structure. The other part needs to be usable in either case.|
A handle to be used when calling WSALookupServiceNext in order to start retrieving the results set.
The return value is zero if the operation was successful. Otherwise, the value SOCKET_ERROR is returned, and a specific error number can be retrieved by calling WSAGetLastError.
|There was insufficient memory to perform the operation.|
|One or more parameters were missing or invalid for this provider.|
|The name was found in the database but no data matching the given restrictions was located.|
|The WS2_32.DLL has not been initialized. The application must first call WSAStartup before calling any Windows Sockets functions.|
No such service is known. The service cannot be found in the specified name space.
This error is returned for a bluetooth service discovery request if no remote bluetooth devices were found.
The lpqsRestrictions parameter points to a buffer containing a WSAQUERYSET structure. At a minimum, the dwSize member of the WSAQUERYSET must be set to the length of the buffer before calling the WSALookupServiceBegin function. Applications can restrict the query by specifying other members in the WSAQUERYSET.
In most instances, applications interested in only a particular transport protocol should constrain their query by address family and protocol using the dwNumberOfProtocols and lpafpProtocols members of the WSAQUERYSET rather than by specifiying the namespace in the dwNameSpace member.
It is also possible to constrain the query to a single namespace. For example, a query that only wants results from DNS (not results from the local hosts file and other naming services) would set the dwNameSpace member to NS_DNS. For example, a bluetooth device discovery would set the the dwNameSpace member to NS_BTH.
Applications can also restrict the query to a specific namespace provider by specifying a pointer to the GUID for the provider in the lpNSProviderId member.
Information on namespace providers on the local computer can be retrieved using the WSAEnumNameSpaceProviders, WSAEnumNameSpaceProvidersEx, WSCEnumNameSpaceProviders32, or WSCEnumNameSpaceProvidersEx32 function.
If LUP_CONTAINERS is specified in a call, other restriction values should be avoided. If any are specified, it is up to the name service provider to decide if it can support this restriction over the containers. If it cannot, it should return an error.
Some name service providers can have other means of finding containers. For example, containers might all be of some well-known type, or of a set of well-known types, and therefore a query restriction can be created for finding them. No matter what other means the name service provider has for locating containers, LUP_CONTAINERS and LUP_NOCONTAINERS take precedence. Hence, if a query restriction is given that includes containers, specifying LUP_NOCONTAINERS will prevent the container items from being returned. Similarly, no matter the query restriction, if LUP_CONTAINERS is given, only containers should be returned. If a namespace does not support containers, and LUP_CONTAINERS is specified, it should simply return WSANO_DATA.
The preferred method of obtaining the containers within another container, is the call:
dwStatus = WSALookupServiceBegin( lpqsRestrictions, LUP_CONTAINERS, lphLookup);
This call is followed by the requisite number of WSALookupServiceNext calls. This will return all containers contained immediately within the starting context; that is, it is not a deep query. With this, one can map the address space structure by walking the hierarchy, perhaps enumerating the content of selected containers. Subsequent uses of WSALookupServiceBegin use the containers returned from a previous call.
As mentioned above, a WSAQUERYSET structure is used as an input parameter to WSALookupBegin in order to qualify the query. The following table indicates how the WSAQUERYSET is used to construct a query. When a parameter is marked as (Optional) a NULL pointer can be specified, indicating that the parameter will not be used as a search criteria. See section Query-Related Data Structures for additional information.
|WSAQUERYSET member||Query interpretation|
|dwSize||Must be set to sizeof(WSAQUERYSET). This is a versioning mechanism.|
|dwOutputFlags||Ignored for queries.|
|lpszServiceInstanceName||(Optional) Referenced string contains service name. The semantics for wildcarding within the string are not defined, but can be supported by certain namespace providers.|
|lpServiceClassId||(Required) The GUID corresponding to the service class.|
|lpVersion||(Optional) References desired version number and provides version comparison semantics (that is, version must match exactly, or version must be not less than the value specified).|
|lpszComment||Ignored for queries.|
See the Important note that follows.
|Identifier of a single namespace in which to constrain the search, or NS_ALL to include all namespaces.|
|lpNSProviderId||(Optional) References the GUID of a specific namespace provider, and limits the query to this provider only.|
|lpszContext||(Optional) Specifies the starting point of the query in a hierarchical namespace.|
|dwNumberOfProtocols||Size of the protocol constraint array, can be zero.|
|lpafpProtocols||(Optional) References an array of AFPROTOCOLS structure. Only services that utilize these protocols will be returned.|
|lpszQueryString||(Optional) Some namespaces (such as whois++) support enriched SQL-like queries that are contained in a simple text string. This parameter is used to specify that string.|
|dwNumberOfCsAddrs||Ignored for queries.|
|lpcsaBuffer||Ignored for queries.|
|lpBlob||(Optional) This is a pointer to a provider-specific entity.|
Windows 8.1 and Windows Server 2012 R2: The WSALookupServiceBeginW function is supported for Windows Store apps on Windows 8.1, Windows Server 2012 R2, and later.
|Minimum supported client||Windows 8.1, Windows Vista [desktop apps | UWP apps]|
|Minimum supported server||Windows Server 2003 [desktop apps | UWP apps]|