article711.asp.htm

一个网络游戏程序编写的例子

<P><B>The Domain Name System</B>

<P>IP addresses can get a bit cryptic, and there are certainly a lot of them,
as you have seen (to be specific, there are 4,294,967,296 possible IP
addresses--but this will one day be not-enough! Remember, there are already
about six billion humans on Earth.) While it may be possible in class C
networks and smaller internets to simply maintain a hosts file that
contains the name of every host and an IP to go along with it, this is not
even CLOSE to practical for the 10,000,000+ host Global Internet of today.
A file containing the complete database for all IP addresses would be about
(conservatively) 94,489,280,512 bytes in size: 90,112 megabytes, 88
gigabytes. Few hosts could sustain such a database, and fewer still could
search it. This would limit and centralize network capacity, which would be
a big no-no based on the decentralized Internet philosophy. Moreover, it
would be a real pain to append and mend these records. Therefore, as a
solution to the problems associated with maintaining IP databases, the
Domain Name System (DNS) was developed.

<P>DNS is a hierarchal IP address lookup system that uses text strings to
classify IP addresses in increasing precision. In other words, it uses a
tree system to decentralize the process of looking up hosts. Host addresses
under the DNS take the form host.subdomain.domain. The domain at the
highest level of the tree is called the root domain. The root domain
contains all of the top level domains, among the most common of which are
gov, edu, com, mil, and org, and ISO two-letter country abbreviations.

<P>A name server is a server program that maintains information about the
domain structure and how it relates to IP addresses. Name servers do not
contain information for all parts of the domain name hierarchy; rather,
they contain pointers to other name servers than know about parts of the
domain name hierarchy that they do not. Similarly, if a name server knows
about the structure of a particular part of the domain name hierarchy,
other servers may be linked to it. Other programs called resolvers then
access name servers to map domain names to IP addresses, and vise-versa. In
this manner, host address information can be maintained without
centralizing it, and in such, the network is able to sustain itself without
relying too much on any particular host. Most ISPs maintain (a) name
server(s).

<P>RFCs 882, 1043, and 1035 provide a decent higher-level introduction to DNS.
This is recommended reading for anyone curious as to how it actually works.
Fortunately once again, we get DNS as a freebie with civilized operating
systems.

<P><B>The ICMP Protocol</B>

<P>An integral part of IP is ICMP. It is difficult to explain the role of the
the Internet Control Message Protocol from an application programming
standpoint, because it is really a low-level sort of thing that's a direct
part of IP. However, to state it simply, ICMP is used by gateways (devices
which connect the various networks of an internet) to communicate with
hosts or vise-versa. Its application is in reporting or querying errors in
the data transaction process. Because of the nature of ICMP, I will not
discuss its specifics. The only real application-level use for ICMP that I
have ever run across is the ping network utility, which sends ICMP packets
to test whether or not a remote host is accessible and measure the
transaction time between that host and another (this is sometimes called
the "ping time"). While this might have applications in a game, excessive
pinging can clog things up, something which we want to avoid doing in a
multiplayer simulation. (In fact, there is a common [but stupid, primarily
because you're basically giving away your address to the person you're
cracking, and it's illegal] denial-of-service attack called flood pinging
which is rather similar...)

<P><B>The GGP Protocol</B>

<P>The Gateway to Gateway Protocol is another protocol that lives with IP. It
is designed for communication about routing between two gateways. Suffice
it to say that it does not concern us at all, because obviously we are not
managing IP-level transactions.

<P><B>The ARP and RARP Protocols</B>

<P>The Address Resolution Protocol and Reverse Address Resolution Protocol are
designed to take Internet addresses and convert them to specific local
hardware addresses. This task is obviously way beyond the scope of what we
need to consider for application-level TCP/IP programming.

<H1>Physical Protocols and Why we Don't Care</H1>

<P>Physical protocols are protocols which manage actually moving a piece of
data across an internet. IP deals with working data through routers on a
"high level", but it does absolutely nothing about actually getting data
from one router to the next. This is where physical protocols come into
play: Once a piece of data has reached a router via IP and the data needs
to move on, the services of a physical protocol are called upon to do this
moving on. The router slops another header on top of the IP header (and
sometimes adds a footer to the end) and ships the packet away. When the
destination router receives it, it peals the header off, and appends
another one which will be needed to get it to the next router, which
repeats the process, ad yada yada yada. The only time that we even remotely
care about physical protocols is when we're talking about the last leg in
the data transaction process for the typical end-user/gamer: From the ISP
to the modem.

<P>The Point to Point Protocol (PPP) is the most commonly used physical
protocol for transferring such data between modems. Let's say that a packet
destined for a dial-up user has been sent from a remote host and has
finally been routed to the appropriate place on the ISP. For the ISP to
actually route the packet to the user's machine, a physical protocol needs
to be called upon. This is probably going to be PPP. So the ISP attaches
the PPP header and footer and ships the packet over to the user via the
established PPP modem connection, it is received by the user's modem, and
picked up by whatever local low-level telecommunications support is
running. The PPP header is then pealed off by the local host's PPP support,
and the IP header is seen. The IP header is processed, pealed off, and the
TCP or UDP header is seen. The local host uses the information in the TCP
or UDP header to direct the packet to the correct port on the local host,
then peals the headers away, leaving just the data to be processed by an
application running on that port.

<P>We care about that process for three reasons: First of all, it's
interesting, second of all, it's easy to explain, and finally, because it
sounds impressive. Other than that, we needn't concern ourselves with
physical protocols. They are at a way lower level than we will ever touch
as practical game programmers. The only time when we will even remotely
care about PPP is when we're optimizing and investigating where overhead
comes from.

<P>If we were actually implementing TCP/IP support for a new platform, then
yes, we'd care about physical protocols quite a bit, or if we were going
into overkill mode and doing it all ourselves, we'd care about it. But as
it is, if we've got support for TCP/IP on our target platform, then it's
almost a given that there will be atomic support for PPP or SLIP or an
equivalent physical protocol in place and active. My other articles on
multiplayer technologies for Game Programming MegaSite have been primarily
extremely low-level, concerned mainly with programming for the modem: If I
were to continue that trend, I would go into the specifics of PPP and the
hell of implementing it and all the layers of complexity above it.
Unfortunately, I don't think that perplexed.com has a big enough disk for
that, and I'd be wasting your time. So, we don't really care.

<H1>TCP/IP Programming</H1>

<P>When we speak of developing TCP/IP applications, we rely on four layers of
functionality:

<OL>
    <LI>An application protocol specific to what we're trying to do (SMTP, for instance)
	<LI>TCP or UDP to oversee data transaction
	<LI>IP, to actually transmit data packets to a given destination
	<LI>Physical protocols like PPP to make data transfer happen.
</OL>

<P>Most of these layers are supported directly by the operating system. Our
task usually comes into play when it boils down to implementing or
supporting a specific application-level protocol, whether standard (as
would be the case with a common system utility like finger or sendmail) or
propietary (as would be the case with Quake).

<P>On any civilized platform, layers 2-4 will be provided for you. If you have
to implement any of layers 2-4, you're not dealing with a civilized
platform and you're probably wasting your time. Those operating systems
which support development of TCP/IP applications with components that are
part of the main operating system API are said to have "native" Internet
support. Examples of such operating systems are 4.2BSD, Windows NT, and
Windows 95. Operating systems which require the use of a propietary API for
applications which utilize TCP/IP are said to have no native support for
TCP/IP. Examples of these operating systems include Windows 3.11 and DOS.

<P><B>Win32 TCP/IP Support: WinSock</B>

<P>Win32 supports TCP/IP via WinSock, a port of the popular Berkley Sockets
technology. Socket, of course, refers to a TCP or UDP socket in a
connection. WinSock suffered from some slight loss of elegance when it was
ported from BSD, namely because of fundamental differences between BSD and
Win32. The most visible change for experienced Berkley Sockets developers
would be that you have to (as in, must) initialize and de-initialize the
WinSock library. On a deeper, uglier level, files and sockets were--before
2.0--completely different ball-parks in WinSock, because of course BSD !=
Windows 95. A recent effort in 2.0 has endeavored to cover the tracks of
the Win32 platform by making this situation ad-hocable. (Thank you, come
again.) WinSock, like Berkley Sockets, is purely procedural.

<P>What you should not use WinSock for is implementation of extremely common
application-level TCP/IP protocols, if you can at all avoid it or if you
don't need excessive control. Win32 already provides rather sufficient
application-protocol-level Internet support for mail protocols, HTTP, FTP,
and gopher. For most purposes, this support is enough. Low-level
implementation of these protocols would be tremendously educational, but
otherwise, a waste of time (for the most part; although you might consider
writing an HTTP or FTP server for Windows 95).

<P>On a personal note, I think WinSock is a stupid name, even if it is also a
bad pun. I would've preferred that it be called "Lose Underwear." People
can identify with this more. Frequently, I have observed that people lose
underwear, whereas they very seldom win socks, unless they're playing a
game of five card stud without a full deck or they're the 72nd shopper at
K-Mart. That's just me, though.

<P><B>Initializing the WinSock Library</B>