The programmer had to know many details
about the network and sometimes even the hardware. You usually needed to
understand the various “layers” of the networking protocol, and
there were a lot of different functions in each different networking library
concerned with connecting, packing, and unpacking blocks of information;
shipping those blocks back and forth; and handshaking. It was a daunting
task.
However, the concept of networking is not
so difficult. You want to get some information from that machine over there and
move it to this machine here, or vice versa. It’s quite similar to reading
and writing files, except that the file exists on a remote machine and the
remote machine can decide exactly what it wants to do about the information
you’re requesting or sending.
One of Java’s great strengths is
painless networking. As much as possible, the underlying details of networking
have been abstracted away and taken care of within the JVM and local machine
installation of Java. The programming model you use is that of a file; in fact,
you actually wrap the network connection (a “socket”) with stream
objects, so you end up using the same method calls as you do with all other
streams. In addition, Java’s built-in multithreading is exceptionally
handy when dealing with another networking issue: handling multiple connections
at once.
Of course, in order to tell one machine
from another and to make sure that you are connected with the machine you want,
there must be some way of uniquely identifying machines
on a network. Early networks were satisfied to provide unique names for machines
within the local network. However, Java works within the Internet, which
requires a way to uniquely identify a machine from all the others in the
world. This is accomplished with the
IP
(Internet Protocol) address that can exist in two forms:
In both
cases, the IP address is represented internally as a 32-bit
number[68] (so each
of the quad numbers cannot exceed 255), and you can get a special Java object to
represent this number from either of the forms above by using the static
InetAddress.getByName( ) method that’s in java.net. The
result is an object of type InetAddress that you can use to build a
“socket” as you will see later.
As a simple example of using
InetAddress.getByName( ), consider what happens if you have a
dial-up Internet service provider (ISP). Each time you dial up, you are assigned
a temporary IP address. But while you’re connected, your IP address has
the same validity as any other IP address on the Internet. If someone connects
to your machine using your IP address then they can connect to a Web server or
FTP server that you have running on your machine. Of course, they need to know
your IP address, and since it’s assigned each time you dial up, how can
you find out what it is?
The following program uses
InetAddress.getByName( ) to produce your IP address. To use it, you
must know the name of your computer. It has been tested only on Windows 95, but
there you can go to “Settings,” “Control Panel,”
“Network,” and then select the “Identification” tab.
“Computer name” is the name to put on the command
line.
//: c15:WhoAmI.java // Finds out your network address when // you're connected to the Internet. import java.net.*; public class WhoAmI { public static void main(String[] args) throws Exception { if(args.length != 1) { System.err.println( "Usage: WhoAmI MachineName"); System.exit(1); } InetAddress a = InetAddress.getByName(args[0]); System.out.println(a); } } ///:~
In this case, the machine is called
“peppy.” So, once I’ve connected to my ISP I run the
program:
java WhoAmI peppy
I get back a message like this (of
course, the address is different each time):
peppy/199.190.87.75
If I tell my friend this address, he can
log onto my personal Web server by going to the URL http://199.190.87.75
(only as long as I continue to stay connected during that session). This can
sometimes be a handy way to distribute information to someone else or to test
out a Web site configuration before posting it to a “real”
server.
The whole point of a network is to allow
two machines to connect and talk to each other. Once the two machines have found
each other they can have a nice, two-way conversation. But how do they find each
other? It’s like getting lost in an amusement park: one machine has to
stay in one place and listen while the other machine says, “Hey, where are
you?”
The machine that “stays in one
place” is called the
server, and the one that
seeks is called the
client. This distinction
is important only while the client is trying to connect to the server. Once
they’ve connected, it becomes a two-way communication process and it
doesn’t matter anymore that one happened to take the role of server and
the other happened to take the role of the client.
So the job of the server is to listen for
a connection, and that’s performed by the special server object that you
create. The job of the client is to try to make a connection to a server, and
this is performed by the special client object you create. Once the connection
is made, you’ll see that at both server and client ends, the connection is
just magically turned into an IO stream object, and from then on you can treat
the connection as if you were reading from and writing to a file. Thus, after
the connection is made you will just use the familiar IO commands from Chapter
11. This is one of the nice features of Java networking.
For many reasons, you might not have a
client machine, a server machine, and a network available to test your programs.
You might be performing exercises in a classroom situation, or you could be
writing programs that aren’t yet stable enough to put onto the network.
The creators of the Internet Protocol were aware of this issue, and they created
a special address called
localhost to be the
“local loopback” IP
address for testing without a network. The generic way to produce this address
in Java is:
InetAddress addr = InetAddress.getByName(null);
If you hand getByName( ) a
null, it defaults to using the localhost. The InetAddress
is what you use to refer to the particular machine, and you must produce this
before you can go any further. You can’t manipulate the contents of an
InetAddress (but you can print them out, as you’ll see in the next
example). The only way you can create an InetAddress is through one of
that class’s static member methods getByName( ) (which
is what you’ll usually use), getAllByName( ), or
getLocalHost( ).
You can also produce the local loopback
address by handing it the string localhost:
InetAddress.getByName("localhost");
or by using its dotted quad form to name
the reserved IP number for the loopback:
InetAddress.getByName("127.0.0.1");
An IP address isn’t enough to
identify a unique server, since many servers can exist on one machine. Each IP
machine also contains ports, and when you’re setting up a client or
a server you must choose a port
where both client and server agree to connect; if you’re meeting someone,
the IP address is the neighborhood and the port is the bar.
The port is not a physical location in a
machine, but a software abstraction (mainly for bookkeeping purposes). The
client program knows how to connect to the machine via its IP address, but how
does it connect to a desired service (potentially one of many on that machine)?
That’s where the port numbers come in as second level of addressing. The
idea is that if you ask for a particular port, you’re requesting the
service that’s associated with the port number. The time of day is a
simple example of a service. Typically, each service is associated with a unique
port number on a given server machine. It’s up to the client to know ahead
of time which port number the desired service is running on.
The system services reserve the use of
ports 1 through 1024, so you shouldn’t use those or any other port that
you know to be in use. The first choice for examples in this book will be port
8080 (in memory of the venerable old 8-bit Intel 8080 chip in my first computer,
a CP/M
machine).
The socket is the software
abstraction used to represent the “terminals” of a connection
between two machines. For a given connection, there’s a socket on each
machine, and you can imagine a hypothetical “cable” running between
the two machines with each end of the “cable” plugged into a socket.
Of course, the physical hardware and cabling between machines is completely
unknown. The whole point of the abstraction is that we don’t have to know
more than is necessary.
In Java, you create a socket to make the
connection to the other machine, then you get an InputStream and
OutputStream (or, with the appropriate converters, Reader and
Writer) from the socket in order to be able to treat the
connection as an IO stream object. There are two stream-based socket classes: a
ServerSocket that a server uses to “listen” for incoming
connections and a Socket that a client uses in order to initiate a
connection. Once a client makes a socket connection, the ServerSocket
returns (via the accept( )
method) a corresponding server
side Socket through which direct communications will take place. From
then on, you have a true Socket to Socket connection and you treat
both ends the same way because they are the same. At this point, you use
the methods
getInputStream( )
and
getOutputStream( )
to produce the corresponding InputStream and OutputStream objects
from each Socket. These must be wrapped inside buffers and formatting
classes just like any other stream object described in Chapter
11.
The use of the term ServerSocket
would seem to be another example of a confusing name scheme in the Java
libraries. You might think ServerSocket would be better named
“ServerConnector” or something without the word “Socket”
in it. You might also think that ServerSocket and Socket should
both be inherited from some common base class. Indeed, the two classes do have
several methods in common but not enough to give them a common base class.
Instead, ServerSocket’s job is to wait until some other machine
connects to it, then to return an actual Socket. This is why
ServerSocket seems to be a bit misnamed, since its job isn’t really
to be a socket but instead to make a Socket object when someone else
connects to it.
However, the ServerSocket does
create a physical “server” or listening socket on the host machine.
This socket listens for incoming connections and then returns an
“established” socket (with the local and remote endpoints defined)
via the accept( ) method. The confusing part is that both of these
sockets (listening and established) are associated with the same server socket.
The listening socket can accept only new connection requests and not data
packets. So while ServerSocket doesn’t make much sense
programmatically, it does “physically.”
When you create a ServerSocket,
you give it only a port number. You don’t have to give it an IP address
because it’s already on the machine it represents. When you create a
Socket, however, you must give both the IP address and the port number
where you’re trying to connect. (On the other hand, the Socket that
comes back from ServerSocket.accept( ) already contains all this
information.)
This example makes the simplest use of
servers and clients using sockets. All the server does is wait for a connection,
then uses the Socket produced by that connection to create an
InputStream and OutputStream. After that, everything it reads from
the InputStream it echoes to the OutputStream until it receives
the line END, at which time it closes the connection.
The client makes the connection to the
server, then creates an OutputStream. Lines of text are sent through the
OutputStream. The client also creates an InputStream to hear what
the server is saying (which, in this case, is just the words echoed
back).
Both the server and client use the same
port number and the client uses the local loopback address to connect to the
server on the same machine so you don’t have to test it over a network.
(For some configurations, you might need to be connected to a network for
the programs to work, even if you aren’t communicating over that
network.)
Here is the server:
//: c15:JabberServer.java // Very simple server that just // echoes whatever the client sends. import java.io.*; import java.net.*; public class JabberServer { // Choose a port outside of the range 1-1024: public static final int PORT = 8080; public static void main(String[] args) throws IOException { ServerSocket s = new ServerSocket(PORT); System.out.println("Started: " + s); try { // Blocks until a connection occurs: Socket socket = s.accept(); try { System.out.println( "Connection accepted: "+ socket); BufferedReader in = new BufferedReader( new InputStreamReader( socket.getInputStream())); // Output is automatically flushed // by PrintWriter: PrintWriter out = new PrintWriter( new BufferedWriter( new OutputStreamWriter( socket.getOutputStream())),true); while (true) { String str = in.readLine(); if (str.equals("END")) break; System.out.println("Echoing: " + str); out.println(str); } // Always close the two sockets... } finally { System.out.println("closing..."); socket.close(); } } finally { s.close(); } } } ///:~
You can see that the ServerSocket
just needs a port number, not an IP address (since it’s running on
this machine!). When you call accept( ), the method
blocks until some client tries to connect to it. That is, it’s
there waiting for a connection but other processes can run (see Chapter 14).
When a connection is made, accept( ) returns with a Socket
object representing that connection.
The responsibility for cleaning up the
sockets is crafted carefully here. If the ServerSocket constructor fails,
the program just quits (notice we must assume that the constructor for
ServerSocket doesn’t leave any open network sockets lying around if
it fails). For this case, main( ) throws IOException
so a try block is not necessary. If the ServerSocket constructor
is successful then all other method calls must be guarded in a
try-finally block to ensure that, no matter how the block is left, the
ServerSocket is properly closed.
The same logic is used for the
Socket returned by accept( ). If accept( ) fails,
then we must assume that the Socket doesn’t exist or hold any
resources, so it doesn’t need to be cleaned up. If it’s successful,
however, the following statements must be in a try-finally block so that
if they fail the Socket will still be cleaned up. Care is required here
because sockets use important non-memory resources, so you must be diligent in
order to clean them up (since there is no destructor in Java to do it for
you).
Both the ServerSocket and the
Socket produced by accept( ) are printed to
System.out. This means that their toString( ) methods are
automatically called. These produce:
ServerSocket[addr=0.0.0.0,PORT=0,localport=8080] Socket[addr=127.0.0.1,PORT=1077,localport=8080]
Shortly, you’ll see how these fit
together with what the client is doing.
The next part of the program looks just
like opening files for reading and writing except that the InputStream
and OutputStream are created from the Socket object. Both the
InputStream and OutputStream objects are converted to Java
1.1
Reader and
Writer objects using the
“converter” classes
InputStreamReader and
OutputStreamWriter,
respectively. You could also have used the Java 1.0
InputStream and
OutputStream classes
directly, but with output there’s a distinct advantage to using the
Writer approach. This appears with
PrintWriter, which has an
overloaded constructor that takes a second argument, a boolean flag that
indicates whether to automatically flush the output at the end of each
println( ) (but not print( )) statement. Every
time you write to out, its buffer must be flushed so the information goes
out over the network. Flushing is important for this particular example because
the client and server each wait for a line from the other party before
proceeding. If flushing doesn’t occur, the information will not be put
onto the network until the buffer is full, which causes lots of problems in this
example.
When writing network programs you need to
be careful about using automatic flushing. Every time you flush the buffer a
packet must be created and sent. In this case, that’s exactly what we
want, since if the packet containing the line isn’t sent then the
handshaking back and forth between server and client will stop. Put another way,
the end of a line is the end of a message. But in many cases messages
aren’t delimited by lines so it’s much more efficient to not use
auto flushing and instead let the built-in buffering decide when to build and
send a packet. This way, larger packets can be sent and the process will be
faster.
Note that, like virtually all streams you
open, these are buffered. There’s an exercise at the end of the chapter to
show you what happens if you don’t buffer the streams (things get
slow).
The infinite while loop reads
lines from the BufferedReader in and writes information to
System.out and to the PrintWriter out. Note that these
could be any streams, they just happen to be connected to the network.
When the client sends the line consisting
of “END” the program breaks out of the loop and closes the
Socket.
Here’s the client:
//: c15:JabberClient.java // Very simple client that just sends // lines to the server and reads lines // that the server sends. import java.net.*; import java.io.*; public class JabberClient { public static void main(String[] args) throws IOException { // Passing null to getByName() produces the // special "Local Loopback" IP address, for // testing on one machine w/o a network: InetAddress addr = InetAddress.getByName(null); // Alternatively, you can use // the address or name: // InetAddress addr = // InetAddress.getByName("127.0.0.1"); // InetAddress addr = // InetAddress.getByName("localhost"); System.out.println("addr = " + addr); Socket socket = new Socket(addr, JabberServer.PORT); // Guard everything in a try-finally to make // sure that the socket is closed: try { System.out.println("socket = " + socket); BufferedReader in = new BufferedReader( new InputStreamReader( socket.getInputStream())); // Output is automatically flushed // by PrintWriter: PrintWriter out = new PrintWriter( new BufferedWriter( new OutputStreamWriter( socket.getOutputStream())),true); for(int i = 0; i < 10; i ++) { out.println("howdy " + i); String str = in.readLine(); System.out.println(str); } out.println("END"); } finally { System.out.println("closing..."); socket.close(); } } } ///:~
In main( ) you can see all
three ways to produce the InetAddress of the local loopback IP address:
using null, localhost, or the explicit reserved address
127.0.0.1. Of course, if you want to connect to a machine across a
network you substitute that machine’s IP address. When the InetAddress
addr is printed (via the automatic call to its toString( )
method) the result is:
localhost/127.0.0.1
By handing getByName( ) a
null, it defaulted to finding the localhost, and that produced the
special address 127.0.0.1.
Note that the
Socket called
socket is created with both the InetAddress and the port number.
To understand what it means when you print one of these Socket objects,
remember that an Internet connection is determined uniquely by these four pieces
of data: clientHost, clientPortNumber, serverHost, and
serverPortNumber. When the server comes up, it takes up its assigned port
(8080) on the localhost (127.0.0.1). When the client comes up, it is allocated
to the next available port on its machine, 1077 in this case, which also happens
to be on the same machine (127.0.0.1) as the server. Now, in order for data to
move between the client and server, each side has to know where to send it.
Therefore, during the process of connecting to the “known” server,
the client sends a “return address” so the server knows where to
send its data. This is what you see in the example output for the server
side:
Socket[addr=127.0.0.1,port=1077,localport=8080]
This means that the server just accepted
a connection from 127.0.0.1 on port 1077 while listening on its local port
(8080). On the client side:
Socket[addr=localhost/127.0.0.1,PORT=8080,localport=1077]
which means that the client made a
connection to 127.0.0.1 on port 8080 using the local port 1077.
You’ll notice that every time you
start up the client anew, the local port number is incremented. It starts at
1025 (one past the reserved block of ports) and keeps going up until you reboot
the machine, at which point it starts at 1025 again. (On UNIX machines, once the
upper limit of the socket range is reached, the numbers will wrap around to the
lowest available number again.)
Once the Socket object has been
created, the process of turning it into a BufferedReader and
PrintWriter is the same as in the server (again, in both cases you start
with a Socket). Here, the client initiates the conversation by sending
the string “howdy” followed by a number. Note that the buffer must
again be flushed (which happens automatically via the second argument to the
PrintWriter constructor). If the buffer isn’t flushed, the whole
conversation will hang because the initial “howdy” will never get
sent (the buffer isn’t full enough to cause the send to happen
automatically). Each line that is sent back from the server is written to
System.out to verify that everything is working correctly. To terminate
the conversation, the agreed-upon “END” is sent. If the client
simply hangs up, then the server throws an exception.
You can see that the same care is taken
here to ensure that the network resources represented by the Socket are
properly cleaned up, using a try-finally block.
Sockets produce a
“dedicated” connection that persists until
it is explicitly disconnected. (The dedicated connection can still be
disconnected un-explicitly if one side, or an intermediary link, of the
connection crashes.) This means the two parties are locked in communication and
the connection is constantly open. This seems like a logical approach to
networking, but it puts an extra load on the network. Later in the chapter
you’ll see a different approach to networking, in which the connections
are only
temporary.
The JabberServer works, but it can
handle only one client at a time. In a typical server, you’ll want to be
able to deal with many clients at once. The answer is
multithreading, and in languages
that don’t directly support multithreading this means all sorts of
complications. In Chapter 14 you saw that multithreading in Java is about as
simple as possible, considering that multithreading is a rather complex topic.
Because threading in Java is reasonably straightforward, making a server that
handles multiple clients is relatively easy.
The basic scheme is to make a single
ServerSocket in the server and call accept( ) to wait for a
new connection. When accept( ) returns, you take the resulting
Socket and use it to create a new thread whose job is to serve that
particular client. Then you call accept( ) again to wait for a new
client.
In the following server code, you can see
that it looks similar to the JabberServer.java example except that all of
the operations to serve a particular client have been moved inside a separate
thread class:
//: c15:MultiJabberServer.java // A server that uses multithreading // to handle any number of clients. import java.io.*; import java.net.*; class ServeOneJabber extends Thread { private Socket socket; private BufferedReader in; private PrintWriter out; public ServeOneJabber(Socket s) throws IOException { socket = s; in = new BufferedReader( new InputStreamReader( socket.getInputStream())); // Enable auto-flush: out = new PrintWriter( new BufferedWriter( new OutputStreamWriter( socket.getOutputStream())), true); // If any of the above calls throw an // exception, the caller is responsible for // closing the socket. Otherwise the thread // will close it. start(); // Calls run() } public void run() { try { while (true) { String str = in.readLine(); if (str.equals("END")) break; System.out.println("Echoing: " + str); out.println(str); } System.out.println("closing..."); } catch (IOException e) { } finally { try { socket.close(); } catch(IOException e) {} } } } public class MultiJabberServer { static final int PORT = 8080; public static void main(String[] args) throws IOException { ServerSocket s = new ServerSocket(PORT); System.out.println("Server Started"); try { while(true) { // Blocks until a connection occurs: Socket socket = s.accept(); try { new ServeOneJabber(socket); } catch(IOException e) { // If it fails, close the socket, // otherwise the thread will close it: socket.close(); } } } finally { s.close(); } } } ///:~
The ServeOneJabber thread takes
the Socket object that’s produced by accept( ) in
main( ) every time a new client makes a connection. Then, as before,
it creates a BufferedReader and auto-flushed PrintWriter object
using the Socket. Finally, it calls the special Thread method
start( ), which performs thread initialization and then calls
run( ). This performs the same kind of action as in the previous
example: reading something from the socket and then echoing it back until it
reads the special “END” signal.
The responsibility for cleaning up the
socket must again be carefully designed. In this case, the socket is created
outside of the ServeOneJabber so the responsibility can be shared. If the
ServeOneJabber constructor fails, it will just throw the exception to the
caller, who will then clean up the thread. But if the constructor succeeds, then
the ServeOneJabber object takes over responsibility for cleaning up the
thread, in its run( ).
Notice the simplicity of the
MultiJabberServer. As before, a ServerSocket is created and
accept( ) is called to allow a new connection. But this time, the
return value of accept( ) (a Socket) is passed to the
constructor for ServeOneJabber, which creates a new thread to handle that
connection. When the connection is terminated, the thread simply goes
away.
If the creation of the
ServerSocket fails, the exception is again thrown through
main( ). But if it succeeds, the outer try-finally guarantees
its cleanup. The inner try-catch guards only against the failure of the
ServeOneJabber constructor; if the constructor succeeds, then the
ServeOneJabber thread will close the associated socket.
To test that the server really does
handle multiple clients, the following program creates many clients (using
threads) that connect to the same server. Each thread has a limited lifetime,
and when it goes away, that leaves space for the creation of a new thread. The
maximum number of threads allowed is determined by the final int
maxthreads. You’ll notice that this value is rather critical, since if
you make it too high the threads seem to run out of resources and the program
mysteriously fails.
//: c15:MultiJabberClient.java // Client that tests the MultiJabberServer // by starting up multiple clients. import java.net.*; import java.io.*; class JabberClientThread extends Thread { private Socket socket; private BufferedReader in; private PrintWriter out; private static int counter = 0; private int id = counter++; private static int threadcount = 0; public static int threadCount() { return threadcount; } public JabberClientThread(InetAddress addr) { System.out.println("Making client " + id); threadcount++; try { socket = new Socket(addr, MultiJabberServer.PORT); } catch(IOException e) { // If the creation of the socket fails, // nothing needs to be cleaned up. } try { in = new BufferedReader( new InputStreamReader( socket.getInputStream())); // Enable auto-flush: out = new PrintWriter( new BufferedWriter( new OutputStreamWriter( socket.getOutputStream())), true); start(); } catch(IOException e) { // The socket should be closed on any // failures other than the socket // constructor: try { socket.close(); } catch(IOException e2) {} } // Otherwise the socket will be closed by // the run() method of the thread. } public void run() { try { for(int i = 0; i < 25; i++) { out.println("Client " + id + ": " + i); String str = in.readLine(); System.out.println(str); } out.println("END"); } catch(IOException e) { } finally { // Always close it: try { socket.close(); } catch(IOException e) {} threadcount--; // Ending this thread } } } public class MultiJabberClient { static final int MAX_THREADS = 40; public static void main(String[] args) throws IOException, InterruptedException { InetAddress addr = InetAddress.getByName(null); while(true) { if(JabberClientThread.threadCount() < MAX_THREADS) new JabberClientThread(addr); Thread.currentThread().sleep(100); } } } ///:~
The JabberClientThread constructor
takes an InetAddress and uses it to open a Socket. You’re
probably starting to see the pattern: the Socket is always used to create
some kind of Reader and/or Writer (or InputStream and/or
OutputStream) object, which is the only way that the Socket can be
used. (You can, of course, write a class or two to automate this process instead
of doing all the typing if it becomes painful.) Again, start( )
performs thread initialization and calls run( ). Here, messages are
sent to the server and information from the server is echoed to the screen.
However, the thread has a limited lifetime and eventually completes. Note that
the socket is cleaned up if the constructor fails after the socket is created
but before the constructor completes. Otherwise the responsibility for calling
close( ) for the socket is relegated to the run( )
method.
The threadcount keeps track of how
many JabberClientThread objects currently exist. It is incremented as
part of the constructor and decremented as run( ) exits (which means
the thread is terminating). In MultiJabberClient.main( ), you can
see that the number of threads is tested, and if there are too many, no more are
created. Then the method sleeps. This way, some threads will eventually
terminate and more can be created. You can experiment with MAX_THREADS to
see where your particular system begins to have trouble with too many
connections.
The examples you’ve seen so far use
the
Transmission
Control Protocol (TCP, also known as
stream-based
sockets), which is designed for ultimate reliability and guarantees that the
data will get there. It allows retransmission of lost data, it provides multiple
paths through different routers in case one goes down, and bytes are delivered
in the order they are sent. All this control and reliability comes at a cost:
TCP has a high overhead.
There’s a second protocol, called
User
Datagram Protocol (UDP), which doesn’t guarantee that the packets will
be delivered and doesn’t guarantee that they will arrive in the order they
were sent. It’s called an
“unreliable
protocol” (TCP is a
“reliable
protocol”), which sounds bad, but because it’s much faster it can be
useful. There are some applications, such as an audio signal, in which it
isn’t so critical if a few packets are dropped here or there but speed is
vital. Or consider a time-of-day server, where it really doesn’t matter if
one of the messages is lost. Also, some applications might be able to fire off a
UDP message to a server and can then assume, if there is no response in a
reasonable period of time, that the message was lost.
Typically, you’ll do most of your
direct network programming with TCP, and only occasionally will you use UDP.
There’s a more complete treatment of UDP in the first edition of this book
(available on the CD ROM bound into this book, or as a free download from
www.BruceEckel.com).
Now that you understand the basics you
should be realizing that servlets are excellent for server-side Web development.
Elegant and straight forward, they do just about everything for you - right?
Well, almost. Remember early we said all client requests drive through the
service method? This is the well-used, high traffic corridor of the servlet and
more than one client request may come through at the same time. The servlet
engine has a pool of threads that it will dispatch to handle client requests. It
is quite likely that two clients arriving at the same time could beprocessing
through your service( ) or doGet( ) or doPost( ) methods at the
same time. Therefore the service( ) methods and other methods called by
HttpServlet.service( ) (e.g., doGet( ), doPost( ),
doHead( ),etc.) need to be written in a thread-safe manner. Any common
resources (files, databases) that will be used by your client requests will need
to be synchronized.
ThreadServlet is a simple example that
simply synchronizes around the threads sleep( ) method. This will hold up
all threads until the allotted time (5000 ms) is all used up. When testing this
you should start several browsers instances and hit this servlet as quickly as
possible.
//: c15:servlets:ThreadServlet.java import javax.servlet.*; import javax.servlet.http.*; import java.io.*; public class ThreadServlet extends HttpServlet { int i; public void service(HttpServletRequest req, HttpServletResponse res) throws IOException { res.setContentType("text/html"); PrintWriter out = res.getWriter(); synchronized(this) { try { Thread.currentThread().sleep(5000); } catch(InterruptedException e) {} } out.print("<h1>Finished " + i++ + "</h1>"); out.close(); } } ///:~
The servlet API comes with more than just
the classes that implement the servlet interface, GenericServlet and HttpServlet
and the Request and Response objects. The design of HTTP is such that it is a
'sessionless' protocol. A great deal of effort has gone into mechanisms that
will allow Web developers to track sessions. How could companies do e-commerce
if you couldn't keep track of client and the items they have put into their
shopping cart? You couldn't! This may be great for privacy advocates but it does
little to help create robust, commerce driven Web sites.
There are several methods of session
tracking but the most common method is with persistant 'cookies'. The term
cookie sounds cute and could be perceived as a session tracking solution that
was baked up in someone's garage. The fact is that cookies are an integral part
of the Internet standards. The HTTP Working Group of the Internet Engineering
Task Force has written cookies in the official standard in RFC 2109
(http://ds.internic.net/rfc/rfc2109.txt
or check
http://www.cookiecentral.com).
A cookie is nothing more than a small
piece of information sent by a Web server to a browser. The browser stores the
cookie locally and all calls to the server from that browser will contain the
cookie as an identifier. The cookie therefore acts to uniquely identify the
client with each hit of this Web server. It should be noted that clients can
turn off the browsers ability to accept cookies. If your site still need to be
able to session track this type of client then another method of session
tracking (URL rewriting or hidden form fields) will have to be incorporated. The
session tracking capabilities built into the Servlet API are designed around
cookies.
The Servlet API (version 2.0 and up)
provides the javax.servlet.http.Cookie class. This class incorporates all the
HTTP header details and allows the setting of various cookie attributes. Using
the cookie is simply a matter of creating it using the constructor and adding it
to the response object. The constructor takes a cookie name as the first
argument and a value as the second. Cookies are added to the response object
before you send any content.
Cookie oreo = new Cookie("TIJava", "2000"); res.addCookie(cookie);
Cookies are then received by calling the
getCookies( ) method of the HttpServletRequest object which returns an
array of cookie objects.
Cookie[] cookies = req.getCookies();
A session in the world of HTTP and the
Internet is one or more page requests by a client to a Web site during a defined
period of time. If I am buying my groceries on-line, I want a session to be
confined to the period from when I first add an item to my shopping cart to the
point where I checkout. Each item I add to the shopping cart will be a new
connection in the HTTP world, they have no knowledge of previous connections or
items in the shopping cart. The mechanics supplied by the Cookie specification
allows us to perform 'session tracking'.
You should understand that a cookie is an
object that encapsulates that small bit of information that will be stored on
the client side. A Servlet Session object lives on the server side of the
communication channel and its goal is to capture data about this client that
would be useful as the client moves through and interacts with your Web site.
This data may be pertinent for the present session, such as items in the
shopping cart or it may be information you asked the client to enter such as
authentication information entered when the client first entered your Web site
and which should not have to be re-enter before a set time of
inactivity.
The Session class of the Servlet API uses
the Cookie class but really all the session object needs is a unique identifier
stored on the client and passed to the server. Usually this is a cookie and that
is the mechanism we will cover here. Web sites may also use the other types of
session tracking but these mechanisms will be more difficult to implement as
they are not encapsulated into the Servlet API.
Traditional approaches to executing code
on other machines across a network have been confusing as well as tedious and
error-prone to implement. The nicest way to think about this problem is that
some object happens to live on another machine, and you can send a message to
that object and get a result as if the object lived on your local machine. This
simplification is exactly what Java 1.1
Remote Method Invocation
(RMI) allows you to do. This section walks you through the steps necessary to
create your own RMI objects.
RMI makes heavy use of interfaces. When
you want to create a remote object, you mask the underlying implementation by
passing around an interface. Thus, when the client gets a reference to a remote
object, what they really get is an interface reference, which happens to
connect to some local stub code that talks across the network. But you
don’t think about this, you just send messages via your interface
reference.
This
section[71] gives
an overview of Sun Microsystems's Jini technology. It describes some Jini nuts
and bolts and shows how Jini's architecture helps to raise the level of
abstraction in distributed systems programming, effectively turning network
programming into object-oriented programming.
Traditionally, operating systems have
been designed with the assumption that a computer will have a processor, some
memory, and a disk. When you boot a computer, the first thing it does is look
for a disk. If it doesn't find a disk, it can't function as a computer.
Increasingly, however, computers are appearing in a different guise: as embedded
devices that have a processor, some memory, and a network connection—but
no disk. The first thing a cellphone does when you boot it up, for example, is
look for the telephone network. If it doesn't find the network, it can't
function as a cellphone. This trend in the hardware environment, from
disk-centric to network-centric, will affect how we organize our
software—and that's where Jini comes in.
Jini is an attempt to rethink computer
architecture, given the rising importance of the network and the proliferation
of processors in devices that have no disk drive. These devices, which will come
from many different vendors, will need to interact over a network. The network
itself will be very dynamic—devices and services will be added and removed
regularly. Jini provides mechanisms to enable smooth adding, removal, and
finding of devices and services on the network. In addition, Jini provides a
programming model that makes it easier for programmers to get their devices
talking to each other.
Building on top of Java, object
serialization, and RMI (which enable objects to move around the network from
virtual machine to virtual machine) Jini attempts to extend the benefits of
object-oriented programming to the network. Instead of requiring device vendors
to agree on the network protocols through which their devices can interact, Jini
enables the devices to talk to each other through interfaces to
objects.
Jini is a set of APIs and network
protocols that can help you build and deploy distributed systems that are
organized as federations of services. A service can be anything
that sits on the network and is ready to perform a useful function. Hardware
devices, software, communications channels—even human users
themselves—can be services. A Jini-enabled disk drive, for example, could
offer a “storage” service. A Jini-enabled printer could offer a
“printing” service. A federation of services, then, is a set of
services, currently available on the network, that a client (meaning a program,
service, or user) can bring together to help it accomplish some goal.
To perform a task, a client enlists the
help of services. For example, a client program might upload pictures from the
image storage service in a digital camera, download the pictures to a persistent
storage service offered by a disk drive, and send a page of thumbnail-sized
versions of the images to the printing service of a color printer. In this
example, the client program builds a distributed system consisting of itself,
the image storage service, the persistent storage service, and the
color-printing service. The client and services of this distributed system work
together to perform the task: to offload and store images from a digital camera
and print a page of thumbnails.
The idea behind the word federation
is that the Jini view of the network doesn't involve a central controlling
authority. Because no one service is in charge, the set of all services
available on the network form a federation—a group composed of equal
peers. Instead of a central authority, Jini's run-time infrastructure merely
provides a way for clients and services to find each other (via a lookup
service, which stores a directory of currently available services). After
services locate each other, they are on their own. The client and its enlisted
services perform their task independently of the Jini run-time infrastructure.
If the Jini lookup service crashes, any distributed systems brought together via
the lookup service before it crashed can continue their work. Jini even includes
a network protocol that clients can use to find services in the absence of a
lookup service.
Jini defines a run-time infrastructure
that resides on the network and provides mechanisms that enable you to add,
remove, locate, and access services. The run-time infrastructure resides in
three places: in lookup services that sit on the network, in the service
providers (such as Jini-enabled devices), and in clients. Lookup services
are the central organizing mechanism for Jini-based systems. When new
services become available on the network, they register themselves with a lookup
service. When clients wish to locate a service to assist with some task, they
consult a lookup service.
The run-time infrastructure uses one
network-level protocol, called discovery, and two object-level protocols,
called join and lookup. Discovery enables clients and services to
locate lookup services. Join enables a service to register itself in a lookup
service. Lookup enables a client to query for services that can help accomplish
its goals.
Discovery works like this: Imagine you
have a Jini-enabled disk drive that offers a persistent storage service. As soon
as you connect the drive to the network, it broadcasts a presence
announcement by dropping a multicast packet onto a well-known port. Included
in the presence announcement is an IP address and port number where the disk
drive can be contacted by a lookup service.
Lookup services monitor the well-known
port for presence announcement packets. When a lookup service receives a
presence announcement, it opens and inspects the packet. The packet contains
information that enables the lookup service to determine whether or not it
should contact the sender of the packet. If so, it contacts the sender directly
by making a TCP connection to the IP address and port number extracted from the
packet. Using RMI, the lookup service sends an object, called a service
registrar, across the network to the originator of the packet. The purpose
of the service registrar object is to facilitate further communication with the
lookup service. By invoking methods on this object, the sender of the
announcement packet can perform join and lookup on the lookup service. In the
case of the disk drive, the lookup service would make a TCP connection to the
disk drive and would send it a service registrar object, through which the disk
drive would then register its persistent storage service via the join
process.
Once a service provider has a service
registrar object, the end product of discovery, it is ready to do a
join—to become part of the federation of services that are registered in
the lookup service. To do a join, the service provider invokes the
register( ) method on the service registrar object, passing as a
parameter an object called a service item, a bundle of objects that describe the
service. The register( ) method sends a copy of the service item up
to the lookup service, where the service item is stored. Once this has
completed, the service provider has finished the join process: its service has
become registered in the lookup service.
The service item is a container for
several objects, including an object called a service object, which
clients can use to interact with the service. The service item can also include
any number of attributes, which can be any object. Some potential
attributes are icons, classes that provide GUIs for the service, and objects
that give more information about the service.
Service objects usually implement one or
more interfaces through which clients interact with the service. For example, a
lookup service is a Jini service, and its service object is the service
registrar. The register( ) method invoked by service providers
during join is declared in the ServiceRegistrar interface (a member of
the net.jini.core.lookup package), which all service registrar objects
implement. Clients and service providers talk to the lookup service through the
service registrar object by invoking methods declared in the
ServiceRegistrar interface. Likewise, a disk drive would provide a
service object that implemented some well-known storage service interface.
Clients would look up and interact with the disk drive by this storage service
interface.
Once a service has registered with a
lookup service via the join process, that service is available for use by
clients who query that lookup service. To build a distributed system of services
that will work together to perform some task, a client must locate and enlist
the help of the individual services. To find a service, clients query lookup
services via a process called lookup.
To perform a lookup, a client invokes the
lookup( ) method on a service registrar object. (A client, like a
service provider, gets a service registrar through the previously-described
process of discovery.) The client passes as an argument to lookup( )
a service template, an object that serves as search criteria for the
query. The service template can include a reference to an array of Class
objects. These Class objects indicate to the lookup service the Java type
(or types) of the service object desired by the client. The service template can
also include a service ID, which uniquely identifies a service, and
attributes, which must exactly match the attributes uploaded by the service
provider in the service item. The service template can also contain wildcards
for any of these fields. A wildcard in the service ID field, for example, will
match any service ID. The lookup( ) method sends the service
template to the lookup service, which performs the query and sends back zero to
any matching service objects. The client gets a reference to the matching
service objects as the return value of the lookup( ) method.
In the general case, a client looks up a
service by Java type, usually an interface. For example, if a client needed to
use a printer, it would compose a service template that included a Class
object for a well-known interface to printer services. All printer services
would implement this well-known interface. The lookup service would return a
service object (or objects) that implemented this interface. Attributes can be
included in the service template to narrow the number of matches for such a
type-based search. The client would use the printer service by invoking methods
from the well-known printer service interface on the service object.
Jini's architecture brings
object-oriented programming to the network by enabling network services to take
advantage of one of the fundamentals of objects: the separation of interface and
implementation. For example, a service object can grant clients access to the
service in many ways. The object can actually represent the entire service,
which is downloaded to the client during lookup and then executed locally.
Alternatively, the service object can serve merely as a proxy to a remote
server. Then when the client invokes methods on the service object, it sends the
requests across the network to the server, which does the real work. A third
option is for the local service object and a remote server to each do part of
the work.
One important consequence of Jini's
architecture is that the network protocol used to communicate between a proxy
service object and a remote server does not need to be known to the client. As
illustrated in the figure below, the network protocol is part of the service's
implementation. This protocol is a private matter decided upon by the developer
of the service. The client can communicate with the service via this private
protocol because the service injects some of its own code (the service object)
into the client's address space. The injected service object could communicate
with the service via RMI, CORBA, DCOM, some home-brewed protocol built on top of
sockets and streams, or anything else. The client simply doesn't need to care
about network protocols, because it can talk to the well-known interface that
the service object implements. The service object takes care of any necessary
communication on the network.
Different implementations of the same
service interface can use completely different approaches and network protocols.
A service can use specialized hardware to fulfill client requests, or it can do
all its work in software. In fact, the implementation approach taken by a single
service can evolve over time. The client can be sure it has a service object
that understands the current implementation of the service, because the client
receives the service object (by way of the lookup service) from the service
provider itself. To the client, a service looks like the well-known interface,
regardless of how the service is implemented.
Jini attempts to raise the level of
abstraction for distributed systems programming, from the network protocol level
to the object interface level. In the emerging proliferation of embedded devices
connected to networks, many pieces of a distributed system may come from
different vendors. Jini makes it unnecessary for vendors of devices to agree on
network level protocols that allow their devices to interact. Instead, vendors
must agree on Java interfaces through which their devices can interact. The
processes of discovery, join, and lookup, provided by the Jini run-time
infrastructure, will enable devices to locate each other on the network. Once
they locate each other, devices will be able to communicate with each other
through Java interfaces.
There’s actually a lot more to
networking than can be covered in this introductory treatment. Java networking
also provides fairly extensive support for URLs, including protocol handlers for
different types of content that can be discovered at an Internet site. You can
find other Java networking features fully and carefully described in Java
Network Programming by Elliotte Rusty Harold (O’Reilly,
1997).
Last Update:03/13/2000