WinSock 1.1 Compatibile Name Resolution for TCP/IP

151 WinSock 1.1 Compatibile Name Resolution for TCP/IP

152 Introduction

• 
  gethostname()
  
• 
  gethostbyaddr()
  
• 
  gethostbyname()
  
• 
  getprotobyname()
  
• 
  getprotobynumber()
  
• 
  getservbyname()
  
• 
  getservbyport()
  

Asynchronous versions of these functions were also defined:

• 
  WSAAsyncGetHostByAddr()
  
• 
  WSAAsyncGetHostByName()
  
• 
  WSAAsyncGetProtoByName()
  
• 
  WSAAsyncGetProtoByNumber()
  
• 
  WSAAsyncGetServByName()
  
• 
  WSAAsyncGetSetvByPort()
  

There are also two functions (now implemented in the WinSock 2 DLL) used to convert dotted IPv4 internet address notation to and from string and binary representations, respectively:

• 
  inet_addr()
  
• 
  inet_ntoa()
  

All of these functions are specific to IPv4 TCP/IP networks and developers of protocol-independent applications are discouraged from continuing to utilize these transport-specific functions. However, in order to retain strict backwards compatibility with WinSock 1.1, all of the above functions continue to be supported as long as at least one name space provider is present that supports the AF_INET address family (these functions are not relevant to IP version 6, denoted by AF_INET6).

153 Basic Approach

Most getXbyY() functions are translated by the WinSock 2 DLL to a WSAServiceLookupBegin/Next/End() sequence that uses one of a set of special GUIDs as the service class. These GUIDs identify the type of getXbyYoperation that is being emulated. The query is constrained to those NSPs that support AF_INET. Whenever a getXbyY function returns a hostent or servent structure, the WinSock 2 DLL will specify the LUP_RETURN_BLOB flag in WSALookupServiceBegin() so that the desired information will be returned by the NSP. These structures must be modified slightly in that the pointers contained within must be replaced with offsets that are relative to the start of the blob's data. All values referenced by these pointer fields must, of course, be completely contained within the blob, and all strings are ASCII.

154 getprotobyname and getprotobynumber

These functions are implemented within the WinSock 2 DLL by consulting a local protocols database. They do not result in any name resolution query.

155 getservbyname() and getservbyport()

The WSALookupServiceBegin() query uses SVCID_INET_SERVICEBYNAME as the service class GUID. The lpszServiceInstanceName field references a string which indicates the service name or service port, and (optionally) the service protocol. The formatting of the string is illustrated as "ftp/tcp" or "21/tcp" or just "ftp". The string is not case sensitive. The slash mark, if present, separates the protocol identifier from the preceding part of the string. The WinSock 2 DLL will specify LUP_RETURN_BLOB and the NSP will place a servent struct in the blob (using offsets instead of pointers as described above). NSPs should honor these other LUP_RETURN_* flags as well:

LUP_RETURN_NAME -> return the s_name field from servent struct in lpszServiceInstanceName

LUP_RETURN_TYPE -> return canonical GUID in lpServiceClassId It is understood that a service identified either as "ftp" or "21" may in fact be on some other port according to locally established conventions. The s_port field of the servent struct should indicate where the service can be contacted in the local environment. The canonical GUID returned when LUP_RETURN_TYPE is set should be one of the predefined GUID from svcs.h that corresponds to the port number indicated in the servent structure.

156 gethostbyname()

The WSALookupServiceBegin() query uses SVCID_INET_HOSTADDRBYNAME as the service class GUID. The host name is supplied in lpszServiceInstanceName. The WinSock 2 DLL specifies LUP_RETURN_BLOB and the NSP places a hostent struct in the blob (using offsets instead of pointers as described above). NSPs should honor these other LUP_RETURN_* flags as well:

LUP_RETURN_NAME -> return the h_name field from hostent struct in lpszServiceInstanceName

LUP_RETURN_ADDR -> return addressing info from hostent in CSADDR_INFO structs, port information is defaulted to zero. Note that this routine does not resolve host names that consist of a dotted internet address.

157 gethostbyaddr()

The WSALookupServiceBegin() query uses SVCID_INET_HOSTNAMEBYADDR as the service class GUID. The host address is supplied in lpszServiceInstanceName as a dotted internet string (e.g. "192.9.200.120"). The WinSock 2 DLL specifies LUP_RETURN_BLOB and the NSP places a hostent struct in the blob (using offsets instead of pointers as described above). NSPs should honor these other LUP_RETURN_* flags as well:

LUP_RETURN_NAME -> return the h_name field from hostent struct in lpszServiceInstanceName

LUP_RETURN_ADDR -> return addressing info from hostent in CSADDR_INFO structs, port information is defaulted to zero

158 gethostname()

The WSALookupServiceBegin() query uses SVCID_HOSTNAME as the service class GUID. If lpszServiceInstanceName is NULL or references a NULL string (i.e. ""), the local host is to be resolved. Otherwise, a lookup on a specified host name shall occur. For the purposes of emulating gethostname() the WinSock 2 DLL will specify a null pointer for lpszServiceInstanceName, and specify LUP_RETURN_NAME so that the host name is returned in the lpszServiceInstanceName field. If an application uses this query and specifies LUP_RETURN_ADDR then the host address will be provided in a CSADDR_INFO struct. The LUP_RETURN_BLOB action is undefined for this query. Port information will be defaulted to zero unless the lpszQueryString references a service such as "ftp", in which case the complete transport address of the indicated service will be supplied.

Download 1.64 Mb.

Share with your friends: