With the introduction of Winsock 2, Microsoft provideders with a protocol-independent
API that resolves hosts, protocols, and services in a more flexible and powerful way than
the services that came with Winsock 1.1. The use of these new functions, though, comes
at a price in terms of increased complexity. As with most other Microsoft APIs, the original
functions are still valid and simpler to understand. However, it is worthwhile to pick up this
technology of protocol-independent functions for the resolving of hosts and services because
 by using the concept of protocol independence, we can simplify the whole process of
 resolving host names and services.

     However, before we begin to explorer the new functions, we must lay the foundation by
understanding the rudiments of resolving hosts, protocols, and services. With that background,
you weill be prepared to master the more complex Winsock 2 resolution functions. Therefore,
we'll concentrate on winsock 1.1 resolution functions in this chapter and leave the Winsok 2
 protocol-indenpent functions to the next chapter. Before dealing with the Winsock 1.1 resolution
 functions in detail, we'll examine the translation functions that handle byte ordering.

     Before dipping (浸渍) our toes (脚趾) in the unknown waters of Winsock resolution, let's consider
this question: What is Winsock 1.1 resolution(解析) ? We'll use a simple analogy(模拟) to discover
an answer to this question. You use a telephone directory to look up a telephone number to call your firend.
The telephone directory enables   you to quickly retrieve your firend's telephone number without having to
remember the number. When it comes to host name resolution, the same princi-
ple applies. when you want to connect with a host on the Internet, you need to
know its IP address, which, if you like, is the equivalent of the telephone num-
ber. Hosts on every TCP/IP network, including the Internet, use IP addresses
to identify themselves to each other. Unfortunately, the majority of humans (and
that includes Delphi developers) cannot remember IP addresses in their raw
form. In the early days of the Internet, IP addresses were routinely used but
became impossible when the Internet expanded. To resolve (no pun intended)
this problem, the mechanism of mapping names (essentially aliases) to IP
address came into being. The mapping of these aliases to their IP address is
called host name resolution. Because of mapping names that are user friendly,
that is, easy to remember, you don't need to know the host's IP address, pro-
videdk you know its friendly name.
  Establishing a mapping of a host name with an IP address is not the end of
the equation. Before you can communicate with a TCP/IP host, you need to
know the port upon which the host operates the desired service, like FTP and
HTTP. Extending the telephone directory analogym, you would either know your
firend's extension or speak with the operator to put you through to your friend.
Perhaps in your case, you would speak to the operator to get though. This is
analogous to what we call service resolution. Added to this equation, we must
also resolve service names to their port numbers. Services such as FTP and
HTTP are well known to surfers on the Net, but hosts deal in numbers when it
comes to providing a service like FTP. Again, service names were invented to
make life easier for users. Like host name mapping, it is necessary to map
human understandable service names to their ports, which are numbers that
hosts can understand.
  And that's not all. We also need to resolve transport protocols to their proto-
col numbers. Hosts require knowning which transport protocols are needed to
operate a service. For example, FTP reauires the TCP protocol, which hosts
translate as 6. We will continue to use the telephone directory analogy as we
examine the Winsock 1.1 resolution functions.

Translation Function
  Computers store numbers through byte ordering. There are two ways to repre-
sent numbers, little endian and big endian. Intel processors store numbers in
little endian format-from the least significant byte to the most significant byte
(right to left). On other processors (such as those that run some UNIX sys-
tems), numbers are in big-endian format-from the mostsignificant byte to the
least significant byte-left to right. Since the Internet is a heterogeneous net-
work of different computers, incompatible byte ordering poses a significant
obstacle to communication. To overcome this barrier, current network standards
specify that ports used for communicating between computers should be in net-
work byte order ( otherwise known as big endian format), irrespective of their
native byte ordering. That is, network byte order is big endian for use on the
TCP/IP network. You mustn't forget that network address, datagram length,
and TCP/IP window sizes must also be in network byte order (big endian).
  Figure 3-1 on the following page shows how little endian and big endian num-
bers are stored in memory.
  So, before using resolution functions and starting communications, your
application needs to translate the native host byte (little endian) ordered num-
ber (for example, port number of the host on the PC) to network byte ordered
number first. That is, you must translate the prot number into network byte
order. If this translation is not done, it is very likely that connecting with the
service on the host will never occur, even if the host name resolution works.
Another problem that can cause you to scratch your head is using the port in
host byte order instead of network byte order, which is a common lapse. How-
ever, it is not necessary to convert numberical data into network byte order; only
prot numbers, services, and IP addresses need to be in network byte order.
  The following trivial example shows graphically the effect of converting a
number in host byte order to network byte order and from network byte order
to host byte order:
host: 100d->00000064h
network:64000000h=1677721600d

  The following functions are used to convert from host byte order to network
byte order, or network byte order to host byte order.

function htonl Winsock2.pas
Syntax
  htonl(hostlong:u_long):u_long;stdcall;
Description
  This function translates a 32-bit integer from host byte order to network byte
  order. In other words, it translates an integer in little endian format to big
  endian format.
Parameters
  hostlong: A 32-bit integer in host byte order
Return Value
  The function will return a value in network byte order.
See Also
  htons, ntohl, ntohs, WSAHtonl, WSAHtons, WSANtohl, WSANtohs
Example
  See Listing 3-1 (program EX31).

function htons Winsock2.pas
Syntax
  htos(hostshort:u_short):u_short;stdcall;
Description
  This function translates a 16-bit integer from host byte order to network byte
  order. In other words, it translates an integer in little endian format to big
  endian format.
Parameters
  hostshort: A 16-bit number in host byte order
Return Value
  The function will return a value in network byte order
See Also
  htonl, ntohl, WSAHtonl, WSAHtons, WSANtohl, WSANtohs
Example
  See Listing 3-1 (program EX31).

function ntohl Winsock2.pas
Syntax
  ntohl(netlong:u_long):u_long;stdcall;
Description
  This function converts a 32-bit integer form network byte order to host byte
  order. In other words, it translates an integer in big endian format to little
  endian format.
Parameters
  netlong: A 32-bit integer in network byte order
Return Value
  The function will return a value in host byte order.
See Also
  htonl, htons, ntohs, WSAHtonl, WSAHtons, WSANtohl, WSANtohs
Example
  See Listing 3-1 (program EX31).

function ntohs Winsock2.pas
Syntax
  ntohs(netlong:u_short):u_short;stdcall;
Description
  This function converts a 32-bit integer form network byte order to host byte
  order. In other words, it translates an integer in big endian format to little
  endian format.
Parameters
  netlong: A 32-bit integer in network byte order
Return Value
  The function will return a value in host byte order.
See Also
  htonl, htons, ntohs, WSAHtonl, WSAHtons, WSANtohl, WSANtohs
Example
  See Listing 3-1 (program EX31).