Game Development Reference
In-Depth Information
Internet and its two most common Internet protocols: the transport control protocol
(TCP) and the user datagram protocol (UDP).
You probably have some familiarity with TCP and UDP. You might have heard that
UDP is what all good network games use, and TCP is for chat windows. The truth, as
usual, is a little more complicated than that. TCP is a guaranteed, full-duplex proto-
col. It looks and feels just as if there were no remote connection at all. You can write
code that simply pulls bits out just as they were sent in, in the right order, with noth-
ing missing and no duplications. It is easier to program because you don
'
t have to
worry so much about wacky Internet problems that can happen during packet trans-
mission: packet loss, packet splitting, or even corruption. The best analogy is a pipe
—
what goes in will come out the other side, or you
ll receive an error telling you some-
thing bad happened to the connection. The possibility of problems exists, and you
should watch out for socket exceptions. Unlike files or UNIX-style pipes, you won
'
'
t
get an
marker.
UDP is a little more like sending messages by using those crazy bicycle messengers
you see in downtown areas. You don
'
tknowwhenorevenifyourpackagewillget
to its destination. You also won
“
end of file
”
t be informed if the package (your data) was split
into multiple pieces during the transmission. I guarantee you that if you required a
bicycle messenger to carry a 10,000-page document, that person would get friends
to help, and it would be up to the receiver to make some sense of it when it all
arrived.
By design, UDP is fairly lightweight, but the messages aren
'
t guaranteed to arrive at
their destination in any order, to arrive in one piece, or to arrive at all. TCP, the
guaranteed delivery service, doesn
'
t give its guarantees of a pipe-like connection
lightly. It does its work by having the receiver acknowledge the reception of a com-
plete, uncorrupted packet of data by sending a message back, essentially saying,
“
OK, I got packet #34, and it checks out, thanks.
”
'
If the sender doesn
'
t receive an
acknowledgement, or an ACK,
it will resend the missing or otherwise corrupted
packet.
Of course, you don
t have to wait to receive the ACK before sending another mes-
sage; you can set your TCP connection to allow you to stuff data in as fast as you
want. It will send the data as quickly as possible and worry about keeping track of
the ACKs internally. This kind of socket is called a nonblocking socket because it
operates asynchronously. A blocking socket can be useful if you want to enforce a
rigid exchange between two computers, something like talking over a two-way
'
