the host using the HTTP protocol behind the scenes. Figure 18.1
illustrates how ports and protocols work.
<P>
<A HREF="f18-1.gif" ><B>Figure 18.1 : </B><I>A conceptual look at protocols and ports.</I></A>
<P>
All standard service assignments are given port values below 1024.
This means that ports above 1024 are considered available for
custom communications, such as those required by a network game
implementing its own protocol. Keep in mind, however, that other
types of custom communication also take place above port 1024,
so you might have to try a few different ports to find an unused
one.
<H2><A NAME="TheClientServerParadigm"><B><FONT SIZE=5 COLOR=#FF0000>The
Client/Server Paradigm</FONT></B></A></H2>
<P>
So far, I've managed to explain a decent amount of Internet networking
fundamentals while dodging a major issue: the client/server paradigm.
You've no doubt heard of clients and servers before, but you might
not fully understand their importance in regard to the Internet.
Well, it's time to remedy that situation, because you won't be
able to get much done in Java without understanding how clients
and servers work.
<P>
The client/server paradigm involves thinking of computing in terms
of a client, who is essentially in need of some type of information,
and a server, who has lots of information and is just waiting
to hand it out. Typically, a client connects to a server and queries
for certain information. The server goes off and finds the information
and then returns it to the client. It might sound as though I'm
oversimplifying things here, but for the most part I'm not; conceptually,
client/server computing is as simple as a client asking for information
and a server returning it.
<P>
In the context of the Internet, clients are typically computers
attached to the Internet looking for information, whereas servers
are typically larger computers with certain types of information
available for the clients to retrieve. The Web itself is made
up of a bunch of computers that act as Web servers; they have
vast amounts of HTML pages and related data available for people
to retrieve and browse. Web clients are those of us who connect
to the Web servers and browse through the Web pages. In this way,
Netscape Navigator is considered client Web software. Take a look
at Figure 18.2 to get a better idea of the client/server arrangement.
<P>
<A HREF="f18-2.gif" ><B>Figure 18.2 : </B><I>A Web server with multiple clients.</I></A>
<P>
At this point, you might be wondering how the client/server strategy
impacts Java game programming. Well, Java games run within the
confines of a Web page, which is accessed via client Web browser
software such as Netscape Navigator. Each player in a network
Java game is running the game within a Web browser, which means
that each player is acting as a client. When the players attempt
to communicate with each other, you are left with Web clients
trying to transfer information among themselves, which can't happen
directly. The solution is for the clients (players) to communicate
with each other through the server; the server effectively acts
as a middleman routing information among the clients. Don't worry
if this sounds kind of strange; you'll learn the details later
today.
<H2><A NAME="Sockets"><B><FONT SIZE=5 COLOR=#FF0000>Sockets</FONT></B></A>
</H2>
<P>
One of Java's major strong suits as a programming language is
its wide range of network support. Java has this advantage because
it was developed with the Internet in mind. The result is that
you have lots of options in regard to network programming in Java.
Even though there are many network options, Java network game
programming uses a particular type of network communication known
as sockets.
<P>
A <I>socket</I> is a software abstraction for an input or output
medium of communication.
<P>
Java performs all of its low-level network communication through
sockets. Logically, sockets are one step lower than ports; you
use sockets to communicate through a particular port. So a socket
is a communication channel enabling you to transfer data through
a certain port. Check out Figure 18.3, which shows communication
taking place through multiple sockets on a port.
<P>
<A HREF="f18-3.gif" ><B>Figure 18.3 : </B><I>Socket communication on a port.</I></A>
<P>
This figure brings up an interesting point about sockets: data
can be transferred through multiple sockets for a single port.
Java provides socket classes to make programming with sockets
much easier. Java sockets are broken down into two types: stream
sockets and datagram sockets.
<H3><A NAME="StreamSockets"><B>Stream Sockets</B></A></H3>
<P>
A <I>stream socket</I>, or connected socket, is a socket over
which data can be transmitted continuously.
<P>
By continuously, I don't necessarily mean that data is being sent
all the time, but that the socket itself is active and ready for
communication all the time. Think of a stream socket as a dedicated
network connection, in which a communication medium is always
available for use. The benefit of using a stream socket is that
information can be sent with less worry about when it will arrive
at its destination. Because the communication link is always &quot;live,&quot;
data is generally transmitted immediately after you send it. This
method of communication is the method you will use tomorrow to
write a sample network game, NetConnect4.
<P>
<CENTER><TABLE BORDERCOLOR=#000000 BORDER=1 WIDTH=80%>
<TR><TD><B>Note</B></TD></TR>
<TR><TD>
<BLOCKQUOTE>
A practical example of data being sent through a streaming mechanism is RealAudio, a technology that provides a way to listen to audio on the Web as it is being transmitted in real time.</BLOCKQUOTE>

</TD></TR>
</TABLE></CENTER>
<P>
<P>
Java supports streamed socket programming primarily through two
classes: <TT><FONT FACE="Courier">Socket</FONT></TT> and <TT><FONT FACE="Courier">ServerSocket</FONT></TT>.
The <TT><FONT FACE="Courier">Socket</FONT></TT> class provides
the necessary overhead to facilitate a streamed socket client,
and the <TT><FONT FACE="Courier">ServerSocket</FONT></TT> class
provides the core functionality for a server. Here is a list of
some of the more important methods implemented in the <TT><FONT FACE="Courier">Socket</FONT></TT>
class:
<BLOCKQUOTE>
<TT><FONT FACE="Courier">Socket(String host, int port)<BR>
Socket(InetAddress address, int port)<BR>
synchronized void close()<BR>
InputStream getInputStream()<BR>
OutputStream getOutputStream()</FONT></TT>
</BLOCKQUOTE>
<P>
The first two methods listed are actually constructors for the
<TT><FONT FACE="Courier">Socket</FONT></TT> class. The host computer
you are connecting the socket to is specified in the first parameter
of each constructor; the difference between the two constructors
is whether you specify the host using a string name or an <TT><FONT FACE="Courier">InetAddress</FONT></TT>
object. The second parameter is an integer specifying the port
you want to connect to. The <TT><FONT FACE="Courier">close</FONT></TT>
method is used to close a socket. The <TT><FONT FACE="Courier">getInputStream</FONT></TT>
and <TT><FONT FACE="Courier">getOutputStream</FONT></TT> methods
are used to retrieve the input and output streams associated with
the socket.
<BLOCKQUOTE>
<TT><FONT FACE="Courier">The ServerSocket class handles the other
end of socket communication in a client/server scenario. Here
are a few of the more useful methods defined in the ServerSocket
class:<BR>
ServerSocket(int port)<BR>
ServerSocket(int port, int count)<BR>
Socket accept()<BR>
void close()</FONT></TT>
</BLOCKQUOTE>
<P>
The first two methods are the constructors for <TT><FONT FACE="Courier">ServerSocket</FONT></TT>,
which both take a port number as the first parameter. The <TT><FONT FACE="Courier">count</FONT></TT>
parameter in the second constructor specifies a timeout period
for the server to automatically &quot;listen&quot; for a client
connection. This is the distinguishing factor between the two
constructors; the first version doesn't listen for a client connection,
whereas the second version does. If you use the first constructor,
you must specifically tell the server to wait for a client connection.
You do this by calling the <TT><FONT FACE="Courier">accept</FONT></TT>
method, which blocks program flow until a connection is made.
The <TT><FONT FACE="Courier">close</FONT></TT> method simply closes
the server socket.
<P>
You might be thinking that the socket classes seem awfully simple.
In fact, they are simple, which is a good thing. Most of the actual
code facilitating communication via sockets is handled through
the input and output streams connected to a socket. In this way,
the communication itself is handled independently of the network
socket connection. This might not seem like a big deal at first,
but it is crucial in the design of the socket classes; after you've
created a socket, you connect an input or output stream to it
and then forget about the socket.
<P>
The <TT><FONT FACE="Courier">Socket</FONT></TT> and <TT><FONT FACE="Courier">ServerSocket</FONT></TT>
classes are the classes you'll use a little later today to build
a simple networking applet. You'll get to see how easy it is to
communicate using Java and sockets.
<H3><A NAME="DatagramSockets"><B>Datagram Sockets</B></A></H3>
<P>
The other type of socket supported by Java is the datagram socket.
Unlike stream sockets, in which the communication is akin to a
live network, a datagram socket is more akin to a dial-up network,
in which the communication link isn't continuously active.
<P>
A <I>datagram socket</I> is a socket over which data is bundled
into packets and sent without requiring a &quot;live&quot; connection
to the destination computer.
<P>
Because of the nature of the communication medium involved, datagram
sockets aren't guaranteed to transmit information at a particular
time, or even in any particular order. The reason datagram sockets
perform this way is that they don't require an actual connection
to another computer; the address of the target computer is just
bundled with the information being sent. This bundle is then sent
out over the Internet, leaving the sender to hope for the best.
<P>
On the receiving end, the bundles of information can be received
in any order and at any time. For this reason, datagrams also
include a sequence number that specifies which piece of the puzzle
each bundle corresponds to. The receiver waits to receive the
entire sequence, in which case it puts them back together to form
a complete information transfer. As you might be thinking, datagram
sockets are less than ideal for network game programming, simply
because of the implied time delays and sequencing complexities.
<H2><A NAME="AReusableSocketClass"><B><FONT SIZE=5 COLOR=#FF0000>A
Reusable Socket Class</FONT></B></A></H2>
<P>
You've now learned enough about network theory and the Java networking
support to write some code. Before you can think in terms of writing
network game code, however, you need to develop some code that
helps facilitate the core communications necessary for a game.