Copyright ©1996, Que Corporation. All rights reserved. No part of this book may be used or reproduced in any form or by any means, or stored in a database or retrieval system without prior written permission of the publisher except in the case of brief quotations embodied in critical articles and reviews. Making copies of any part of this book for any purpose other than your own personal use is a violation of United States copyright laws. For information, address Que Corporation, 201 West 103rd Street, Indianapolis, IN 46290 or at support@mcp .com.
Notice: This material is excerpted from Special Edition Using Java, ISBN: 0-7897-0604-0. The electronic version of this material has not been through the final proof reading stage that the book goes through before being published in printed form. Some errors may exist here that are corrected before the book is published. This material is provided "as is" without any warranty of any kind.
Connectivity to the Internet is probably one of the reasons you are interested in Java. The future of computing may be that Java applets from all over the Internet will be capable of running instantly-the same way that HTML pages are publishable today. In this chapter, I discuss the special network-aware classes in Java (in the java.net package) that make writing programs for communication over the Internet easier than in most other languages.
In this chapter we will:
Introduce the Java socket classes
Explain how the Internet uses sockets
Write a prototype Internet telnet server, for remote login
Write a prototype telnet client that talks to our server
Write a prototype program that sends a datagram packet
Write a prototype program that receives a datagram packet
Explore security issues that may shape the future of Java network programming
Java has the same UNIX roots as the Internet. It's designed from the ground up as a networking language. I will first discuss the URL class, which provides a number of ways of specifying an Internet resource. Then I will discuss how Java makes network programming easier by encapsulating connection functionality in socket classes. I will discuss the following socket classes:
A commercial example of customized transmission protocol is Netscape's Secure Sockets Layer (SSL) for ensuring that such transactions as credit card purchases can be transmitted securely over the Internet (see http://www.netscape.com/info/security-doc.html).
I will also touch on security considerations inherent in this new vision of distributed worldwide applets. The goal is to lay the foundation for whatever Java network programming your application might require.
In chapter 26, "Protocol Handlers," the author used the Socket class to develop a Finger protocol. You can think of an Internet server as a set of Socket classes that provide additional capabilities-generally called services. Examples of services are electronic mail, Telnet for remote login, and File Transfer Protocol (FTP) for transferring files around the network. If the server to which you are attached provides Web access, then there is a Web service available as well.
Each service is associated with a port. A port is a numeric address through which service requests (such as asking for a Web page) are processed. On a UNIX system, the particular services provided are in the /etc/services file. Here are a few lines from a typical /etc/services file:
|
| |
|
|
|
|
| |
|
|
|
|
|
The first column displays system name of the service (daytime). The second column displays the port number and the protocol, separated by a slash (13/udp). The third column displays an alias to the service, if any. For example, smtp (the standard Simple Mail Transfer Protocol), also known as mail, is the implementation of e-mail service.
Communication of Web related information takes place at Port 80 using the TCP protocol. To emulate this in Java, you use the Socket class. Daytime, the service to get the system date and time, occurs at Port 13 using the UDP protocol. A daytime server to emulate this in Java would use the DatagramSocket object.
The URL class contains constructors and methods for managing a URL: an object or service on the Internet. The TCP protocol requires two pieces of information: the IP address and the port number. So how is it possible that when you type
you get Yahoo's home page?
First, Yahoo has registered its name, allowing yahoo.com to be assigned an IP address (say 205.216.146.71).
<
Actually it's a bit more complicated than that. There's a service called DNS, for Domain Naming Service, that translates www.yahoo.com into 205.216.146.71. This enables you to type www.yahoo.com instead of having to remember the IP address.
An interesting sidelight is that one network name can map to many IP addresses. This may be necessary for a site, like Yahoo, that accommodates large volumes of traffic and needs more than one IP address to service the traffic. The actual internal name for 205.216.146.71, for example, is www7.yahoo.com. DNS can translate a list of IP addresses assigned to yahoo into www.yahoo.com. This is a useful feature, but also opens up a security hole, which is discussed in "Will Security Considerations Disable Java Applets?" later in this chapter.
So the IP address is known.
Now what about the port number? If not specified, the server's port in /etc/services is used.
The /etc/services is the filename on UNIX servers. On other platforms, the filename will probably be different. On a Windows NT server, for example, the file may be called simply services. Ask your server administrator.
The usual Web service port is 80, so if it is not specified, the Yahoo server uses that port. The actual URL specification is filename:port. Test this. If you type
you also get Yahoo's home page.
There's no hard and fast rule that the Web server reside on port 80. This is, however, becoming the Internet custom. In the early days of the Web, you'd find URLs with strange port addresses. Using port 80 saves keystrokes. URLs are hard enough to remember without having to remember the port number as well.
An interesting sidelight: If you request another protocol, such as in ftp://ftp.microsoft.com, the port number is derived from the protocol. So if Microsoft's FTP port was 21 (in their /etc/services file), the server would map the ftp: protocol name to Port 21 using the IP address, ftp.microsoft.com.
The first part of the URL (http) means that we're using the HyperText Transmission Protocol, the protocol for handling Web documents. And if no file is specified, most Web servers are configured to fetch the file called index.html. So the IP address and the port are determined either by explicit specification of all the parts of the URL or by using defaults.
The URL class allows for these variations in specification. There are four constructors, as follows:
public URL(String spec) throws MalformedURLException; public URL(String protocol, String host, int port, String file) throws MalformedURLException; public URL(String protocol, String host, String file) throws MalformedURLException; public URL(URL context, String spec) throws MalformedURLException;
You can thus specify each piece of the URL, as in URL("http","www.yahoo.com",80,"index.html"), or enable the defaults to take over, as in URL("http://www.yahoo.com"), letting Yahoo figure out all the pieces.
Sockets are based on a client/server model. One program (the server) provides the service at a particular IP address and port. The server listens for service requests, such as requests for Web pages, and fills the order. Any program that wants to be serviced (a client, such as a Web browser) needs to know the IP address and port to communicate with the server.
An advantage of the socket model over other forms of data communication is that the server doesn't care where the client requests come from. As long as the client is sending requests according to the TCP/IP protocol, the requests will reach the server-provided the server is up and the Internet isn't too busy. (What the particular server program does with the request is another matter. The Finger server of Chapter 26, "Protocol Handlers," could be programmed to reject requests from external clients, as many Finger servers are.)
This also means that the client can be any type of computer. No longer are we restricted to UNIX, Macintosh, DOS, or Windows platforms. Any computer that supports TCP/IP can talk to any other computer that supports it through this socket model. This is a potentially revolutionary development in computing. Instead of maintaining armies of programmers to port a system from one platform to another, you write it once-in Java. Any computer with a Java virtual machine can run it.
Java socket classes fit nicely into this picture. You implement a server by creating subclasses of Thread, overriding the run() method. The Java virtual machine can then perform the thread management without the program having to worry. So with a few lines of code, you can write a server that can handle as many data communications sessions as you want. And data transmission is simply a matter of calling the Socket methods.
The procedure for creating a server is to create a ServerSocket object, which listens on a particular port for client requests. When it recognizes a valid request, it creates a Socket object through which the data conversation can take place. This socket is like a pipe through which data can pass back and forth. In fact, it's very similar to a UNIX pipe. The stream classes are used to route data back and forth efficiently.
The following program is a prototype for a line-oriented Telnet server, enabling remote logins to a network on the Internet. The server prompts the client for ID and password and, if the user is authorized, prints a welcome message. For our network, the Telnet service is on port 23.
Listing 28.1 TelnetServer.java-A Prototype Telnet Server
1. import java.net.ServerSocket;
2. import java.net.Socket;
3. import java.io.IOException;
4. import java.io.DataInputStream;
5. import java.io.PrintStream;
6. public class TelnetServer extends Thread {
7. protected ServerSocket server_listening_socket;
8. public static void fail(Exception exception, String msg) {
9. System.err.println(msg + "." + exception);
10. System.exit(1);
11. }
12. public TelnetServer() {
13. try {server_listening_socket = new ServerSocket(23, 5); }
14. catch (IOException ioexception) fail(ioexception,
15. "Could not start Telnet Server");
16. System.out.println("Telnet Server Started");
17. this.start();
18. }
19. public void run() {
20. try {
21. while (true) {
22. Socket client_socket = server_listening_socket.accept();
23. TelnetConnection connection = new TelnetConnection(client_socket);
24. }
25. }
26. catch (IOException e) fail(e, "Listening loop failed.");
27. }
28. public static void main (String[] args) {
29. new TelnetServer();
30. }
}
31. class TelnetConnection extends Thread {
32. protected Socket telnet_client;
33. protected DataInputStream from_client;
34. protected PrintStream to_client;
35. // initialize the stream, start the thread.
36. public TelnetConnection (Socket client_socket) {
37. telnet_client = client_socket;
38. try {
39. from_client = new DataInputStream(telnet_client.getInputStream());
40. to_client = new PrintStream(telnet_client.getOutputStream());
41. }
42. catch (IOException ioexception) {
43. try telnet_client.close(); catch (IOException anIOException);
44. System.err.println("Unable to set up socket streams." +
45. ioexception);
46. return;
47 . }
48. this.start();
49. }
50. public void run() {
51. String login_id;
52. String password;
53. int len;
54. try {
55. for(;;) {
56. //prompt, then read login_id
57. to_client.println("Login: ");
58. login_id = from_client.readLine();
59. if (login_id == null) break;
60. // prompt, then read password
61. to_client.println("Password: ");
62. password = from_client.readLine();
63. if (password == null) break;
64. // check for valid login ID and password. If the user is
65. // authorized, tell the client ...
66. to_client.println("Welcome! You're online! Enter command.");
67. // then continue conversation between client and server
68. // to close conversation, set a boolean to false, and code
69. if (boolean_var == false) break;
70. }
71. }
72. catch (IOException e);
73. finally try telnet_client.close() ; catch (IOException anIOexception);
74. }
75. }
OK, now let's break it down. (The following line numbers refer to listing 28.1.)
From java.net, you use the ServerSocket class (to create a socket where the server listens for remote login requests) and the Socket class (to create the socket through which the Telnet conversation occurs).
From java.io, you use the IOException class (to handle errors). The DataInputStream class handles traffic from the client to the server (i.e., input to the server). The PrintStream class handles traffic from the server to the client ("printing" to the client).
Note that our Telnet server is a subclass of Thread. A ServerSocket object (server_listening_object), declared on line 7, will later do the work of listening for client Telnet requests
An error handling routine called fail(), defined from lines 8 to 11, takes two arguments (an Exception object and a String object), prints an error message if there is any problem starting the server, and exits.
The constructor (lines 12-18) creates and starts a ServerSocket thread. An error message is produced if there's a problem. Note the statement on line 13 that actually constructs the server socket:
server_listening_socket = new ServerSocket(23, 5);
This form of the ServerSocket constructor takes two integer arguments. The first argument, the port number, is 23 because we've defined the Telnet service to be on Port 23. The second argument is a count of the number of concurrent Telnet services that we want to allow. We will allow five Telnet sessions in this example. The actual setting is a server configuration issue. If we allow more sessions, we also allocate more server memory. The potential for overloading the server exists because each session requires additional memory.
The server's run() method (lines 19-27), as with all threads that implement the Runnable interface, is where the work is done. In this case, the server goes into an infinite loop and "listens" for client requests. When the server "hears" the client, the server calls the ServerSocket's accept() method, which accepts the connection. Then the server creates a TelnetConnection thread, passing it a Socket object where the Telnet conversation actually occurs.
The main() method (lines 28-31) is very simple. Just create an instance of TelnetServer, print a message to the console that the server has started, and it can figure everything else out.
The TelnetConnection thread (lines 32-75) is where the conversation actually takes place. TelnetConnection creates a DataInputStream object (from_client), which retrieves input from the client using the GetInputStream() method, and a PrintStream object (to_client), which enables the server to write output to the client using the GetOutputStream() method. Thus, a two-way conversation can occur. If this happens successfully, the Telnet session starts.
After the server connects, it issues the Login: prompt by printing it to the client using the println() method of the to_client object (line 57). On line 58, the server uses the readLine() method to store the login ID in the string variable, login_id. The server now needs the password, so it uses the println() method of the to_client object to issue the Password: prompt. Then the server issues another readLine(), storing the user's entry in another string variable, password.
From this point, it's up to the program to verify the login ID and password. Perhaps there's a login ID table, which contains the password. If the password is stored in encrypted format, this would be the place to decrypt it. If the user is authorized, the session can begin using the stream objects that have been set up. Typically, the server prompts for a command and uses a case statement to either perform the command or deny access.
When it's time to log off, the server issues a break to exit the loop. This causes the finally statement to execute, closing the client socket. Closing the socket is critical because, otherwise, you'll exhaust server memory before long. The finally clause ensures that. You can't count on Java's garbage collection to close the socket.
Note that the server is multithreaded, as each client that connects gets its own thread in the server. This is quite an impressive result in so few lines of code!
Below is a prototype for a client program that talks to our Telnet server.
Listing 28.2 TelnetClient.java-A Prototype Telnet Client
1. import java.net.Socket;
2. import java.io.IOException;
3. import java.io.DataInputStream;
4. import java.io.PrintStream;
5. public class TelnetClient {
6. public static void main(String[] args) {
7. Socket s = null;
8. try {
9. s = new Socket("krakow.com",23);
10. DataInputStream server_in = new DataInputStream(s.getInputStream());
11. PrintStream server_out = new PrintStream(s.getOutputStream());
12. DataInputStream input = new DataInputStream(System.in);
13. String line;
14. while (true) {
15. line = server_in.readLine();
16. if (line == null) break;
17. System.out.println(line);
18. line = input.readLine();
19. if (line == null) break;
20. server_out.println(line);
21. }
22. }
23. catch (IOException e) System.out.println(e);
24. finally {
25. try if (s != null) s.close() ; catch (IOException e2);
26. }
27. }
28. }
The client program is simpler. Create a Socket object, specifying the host address and port. The client must know both of these before connecting to the server. We'll assume that the host is "krakow.com". The Telnet port we already know is port 23.
After connecting successfully with the server, we create two DataInputStream objects: one to get data from the server and the other to get data from the user (System.in). We also create a PrintStream object so we can "print" to the server. The client goes into a read/write loop until it receives no more input from the server, at which time it closes the socket.
The following line numbers refer to listing 28.2.
The client only needs the Socket class from the java.net package. The client uses the getInputStream() method to receive data from the server and the getOutputStream() methods to send data to the server. These methods support TCP, ensuring reliable data communication across the network.
From the java.io package, the program imports IOException (for I/O error handling), DataInputStream (for reading input from a stream), and DataOutputStream (for writing to a stream).
TelnetClient has only method-main()-which makes it a stand-alone program. On line 9, a Socket object (s) is created. Socket takes two arguments: the Internet address ("krakow.com") and the Telnet port (23). After the Socket object is created, the following three streams are created:
The program then goes into an infinite loop (lines 14-21). The code from lines 15-17 reads input from the server (line 15), exits if no input is received (line 16), and prints the input on the terminal (line 17). After the socket was established, the server printed out Login: using the println() method on its PrintStream object. On line 15, the client reads it. On line 17, the client prints it to the terminal.
Lines 18-20 are the response from the terminal. On line 18, the client uses the readLine() method, getting the login ID from the user. The readLine() method waits for a carriage return before continuing. On line 20, the client uses the println() method on its PrintStream object (attached to the same socket as the server) to print back to the server.
The exchange continues to get the password, announcing that the connection succeeded (or failed). We have established a line-oriented conversation between client and server. What happens after that depends on the particular application's requirements and is beyond the scope of this discussion.
Communicating using datagram sockets is simpler than using the TCP based sockets (Socket and ServerSocket) that we used for our Telnet server. Communications is also faster because there is no connection overhead. There's also no attempt to send packets again if an error occurs or sequencing of multiple packets, as occurs in TCP transmissions.
A datagram packet is simply sent as an array of bytes to a receiving program, presumably listening at a particular IP address and port. If the receiving program gets the datagram and wants to send a reply, it becomes the sender addressing a datagram back to a known IP address and port. The conversation style is a bit like those old movies in which the pilot sends a message, says "over," and waits for ground control to respond.
You might use datagram socket communication if you're writing an interactive game or, as in many UNIX systems, for returning a small piece of information, such as the time, when you don't want the overhead of establishing a connection and/or (in the case of the time server) when the communication takes place locally.
Here's a prototype program for sending a datagram packet. I am going to send a 12-byte message ("Ira says Hi!") to the IP address mapped to "krakow.com" at port number 1000. When you try this, use an IP address and port that you know is available. I purposely left out error handling to make the prototype more readable. You should insert the appropriate try blocks and catch statements to handle errors gracefully.
Listing 28.3 DatagramSend.java-A Prototype Program to Send a Datagram Packet
1. import java.net.DatagramPacket;
2. import java.net.DatagramSocket;
3. import java.net.InetAddress;
4. public class DatagramSend {
5. public static void main (String args[]) throws Exception {
6. byte[] byte_greeting = new byte[12];
7. String string_greeting = "Ira says hi!";
8. int message_length = 12;
9. int port = 1000;
10. InetAddress internet_address =
11. InetAddress.getByName("krakow.com");
12. string_greeting.getBytes(0 , 12 , byte_greeting , 0 );
13. DatagramPacket packet = new DatagramPacket( byte_greeting,
14. message_length, internet_address , port);
15. DatagramSocket socket = new DatagramSocket();
16. socket.send(packet);
17. socket.close();
18. }
19. }
We only need to use one socket: the DatagramSocket. There is no concept of the server listening for client requests. The idea is just to establish a DatagramSocket object and then send and receive messages. The messages are sent in a DatagramPacket object. An additional object-InetAddress-is needed to construct the IP address to send the packet.
The DatagramSend class has only one method-main()-so it's a stand-alone Java program. This demonstration program only sends one message. You can, of course, modify main() to pass any message to any IP address and port. Because main() throws Exception, I have declared that I'm not handling errors in this class.
The DatagramPacket constructor that I use has the following four arguments:
Another form of the constructor requires only the first two arguments. It's designed for local communication when the IP address and port are already known. You'll see it in action later in this chapter, in "Receiving a Datagram Packet".
The following line numbers refer to listing 28.3.
The statement on line 6 creates the byte array form of our greeting message. On line 7 is the declaration and initialization of the greeting. On line 10, the getBytes() instance method of the java.lang.String class converts string into byte array form, storing the converted string in byte_greeting.
The getByName() method of InetAddress (on line 8) converts a string into an Internet address in the form that the DatagramPacket constructor accepts.
On lines 11 and 12, an instance of DatagramPacket is created with the above arguments. Finally, on line 13, the packet is sent using the send() instance method of the DatagramPacket.
The packet is on its way, so it's time to receive it. Here's the receiving program.
Listing 28.4 DatagramReceive.java-A Prototype Program To Receive a Datagram Packet
1. import java.net.DatagramSocket;
2. import java.net.DatagramPacket;
3. public class DatagramReceive {
4. public static void main (String args[]) throws Exception {
5. String greeting;
6. byte[] buffer = new byte[2048];
7. DatagramPacket rcv_packet = new DatagramPacket(buffer, buffer.length);
8. DatagramSocket rcv_socket = new DatagramSocket(1000);
9. rcv_socket.receive( rcv_packet );
10. greeting = new String(buffer ,0 ,0 , rcv_packet.getLength());
11. System.out.println(greeting);
12. rcv_socket.close();
13. }
14. }
The DatagramReceive class, like the DatagramSend class, uses the DatagramSocket and DatagramPacket classes from java.net. First, create a buffer large enough to hold the message. Our buffer (buffer) is a 2K byte array. Your buffer size may very. Just make sure it will hold the largest packet you'll receive.
Then we create a datagram packet. Note that the receive program already knows its IP address and port, and so it can use the two-argument form of the constructor. On line 8, the DatagramSocket is set up to receive data at Port 1000.
The receive() method of Datagram receives the packet as a byte array. The String (greeting) is constructed out of the byte array and the greeting is printed on the terminal. Finally, the socket is closed, freeing memory instead of waiting for Java's garbage collection.
To get the IP address of the network you're running on, call the getLocalHost() and getAddress() methods of the class java.net.InetAddress. First, getLocalHost() returns an iNetAddress object. Then, you use the getAddress() method, which returns a byte array consisting of the four bytes of the IP address, as in the following example:
InetAddress internet_address = InetAddress.getLocalHost(); byte[] ipaddress = internet_address.getAddress();
If the IP address of the network you're running on is 221.111.112.23, then
The Internet does not provide built-in security. The socket-oriented communications methods I've discussed do not verify whether any particular request for reading or writing data is coming from a source that should have such access.
A number of solutions have been proposed. As mentioned at the beginning of this chapter, Netscape has proposed the Secure Sockets Layer (SSL) protocol. SSL is a protocol that resides between the services, such as Telnet, FTP, and http, and the TCP/IP connection sessions that I've illustrated here. SSL would check that the client and server networks are valid, provide data encryption, and ensure that the message does not contain any embedded commands or programs. SSL would thus provide for secure transactions to occur across the Internet.
Another proposal is to write a server that provides security from the start. This is the idea behind Secure HyperText Transfer Protocol (S-HTTP) developed by Enterprise Information Technologies (EIT), RSA Labs, and the National Center for Supercomputer Applications (NCSA).
NCSA is the group that developed Mosaic, the the original Web browser for Microsoft Windows. The Mosaic design team went on to fame and fortune by completely rewriting Mosaic to create a new and original Web browser. The result was Netscape.
You can find the S-HTTP specifications at http://www.commerce.net:80/software/Shttpd
In your organization, you might want to provide a firewall between the public and private areas of your networks, so there are a number of reasons you might need more protection for your network than TCP-IP provides.
Java provides a set of methods for implementing either of these strategies called SocketImpl, which is an abstract class. To use it, you create a subclass and implement its methods, such as connecting to the server, accepting client requests, getting file information, writing to local files, and so on. Even if you never write your own server or create a custom socket class, it's nice to know that it's possible to do it in Java.
Imagine a world in which Java applets on any network can set up client/server communications of the type I've discussed in this chapter. Perhaps an applet on my network can call a method in an applet on your network or run a program on your network remotely. For example, an applet connects to a quote server, determines that the price of a certain stock has reached the target price, and then connects to a user's machine on a network, displaying a message and requesting permission to buy. Or perhaps the applet can run an Excel spreadsheet macro to update the portfolio every 10 minutes. Many powerful applets could be written.
With this power comes potential danger. How can we prevent the applet from deleting files, downloading unauthorized data, or even being aware of the existence of such files? In this world of distributed objects, there's a profound tension between enabling more capabilities for an applet and fear of unwanted use.
This is why the debate on object access is fierce. The main stage is a standard called Common Object Request Broker Architecture
This is a consortium of many computer companies that allow requests and responses to be made securely from distributed objects. Microsoft is, of course, one of the participants. They have a protocol for requesting objects called Object Linking and Embedding (OLE). OLE's main purpose is for one Windows application to access information in another Windows application . OLE is more platform-specific than CORBA. It's worth watching the progress of the debate. Will Java applets be allowed to run Windows DLLs so they can communicate with Windows objects? How open will OLE become?
Currently, applets loaded from a network not only cannot run Windows DLLs on the local machine, they are forbidden to run local commands, such as the DOS dir command, that would find out the names of files on the client. In addition, applets cannot make network connections except to the network they're on.
These limitations apply only to applets loaded from a network. Locally loaded applets are not restricted like this.
The debate between power and security seems to be veering towards the security side. An example is a recent "bug" that Drew Dean, Ed Felten, and Dan Wallach of Princeton University, found in Netscape 2.0 running a Java applet. They were able to trick the Domain Name Service (DNS) (the program that translates addresses, such as www.yahoo.com, into those funny IP addresses) into disguising their origin. They were able to make DNS believe they were actually from another computer, and then they were able to breach security on it. Netscape acknowledged the situation and has provided an update (Version 2.01) that provides more close control over how an IP address is resolved.
This situation caused a real stir. Concerns about Internet security are rampant. Also, concerns about restricting applet access to the point where the usefulness of the applications are diminished greatly are also rampant. It will be interesting to see which side prevails.
Sun has suggested a naming convention for running applets across networks. The convention would be based on the IP address of the network where the applet resides. Perhaps in the future, digital signatures will be attached to applets before they run. Take a look at
(Frequently Asked Questions about Java and applet security) for developments.