Chapter 9. Sockets for Clients

Data is transmitted across the Internet in packets of finite size called datagrams . Each datagram contains a header and a payload . The header contains the address and port to which the packet is going, the address and port from which the packet came, and various other housekeeping information used to ensure reliable transmission. The payload contains the data itself. However, since datagrams have a finite length, it's often necessary to split the data across multiple packets and reassemble it at the destination. It's also possible that one or more packets may be lost or corrupted in transit and need to be retransmitted or that packets arrive out of order and need to be reordered. Keeping track of thissplitting the data into packets, generating headers, parsing the headers of incoming packets, keeping track of what packets have and haven't been received, and so onis a lot of work and requires a lot of intricate code.

Fortunately, you don't have to do the work yourself. Sockets allow the programmer to treat a network connection as just another stream onto which bytes can be written and from which bytes can be read. Sockets shield the programmer from low-level details of the network, such as error detection, packet sizes, packet retransmission, network addresses, and more.

9.1 Socket Basics

A socket is a connection between two hosts . It can perform seven basic operations:

Connect to a remote machine
Send data
Receive data
Close a connection
Bind to a port
Listen for incoming data
Accept connections from remote machines on the bound port

Java's Socket class, which is used by both clients and servers, has methods that correspond to the first four of these operations. The last three operations are needed only by servers, which wait for clients to connect to them. They are implemented by the ServerSocket class, which is discussed in the next chapter. Java programs normally use client sockets in the following fashion:

The program creates a new socket with a constructor.
The socket attempts to connect to the remote host.
Once the connection is established, the local and remote hosts get input and output streams from the socket and use those streams to send data to each other. This connection is full-duplex ; both hosts can send and receive data simultaneously . What the data means depends on the protocol; different commands are sent to an FTP server than to an HTTP server. There will normally be some agreed-upon hand-shaking followed by the transmission of data from one to the other.
When the transmission of data is complete, one or both sides close the connection. Some protocols, such as HTTP 1.0, require the connection to be closed after each request is serviced. Others, such as FTP, allow multiple requests to be processed in a single connection.

9.2 Investigating Protocols with Telnet

In this chapter, you'll see clients that use sockets to communicate with a number of well-known Internet services such as HTTP, echo, and more. The sockets themselves are simple enough; however, the protocols to communicate with different servers make life complex.

To get a feel for how a protocol operates, you can use Telnet to connect to a server, type different commands to it, and watch its responses. By default, Telnet attempts to connect to port 23. To connect to servers on different ports, specify the port you want to connect to like this:

%

telnet localhost 25

This example assumes that you're using a Unix system. However, Telnet clients are available for all common operating systems, and they are all pretty similar; for example, on Windows, you might have to type the hostname and the port into a dialog box rather than on the command-line, but otherwise , the clients work the same.

This requests a connection to port 25, the SMTP port, on the local machine; SMTP is the protocol used to transfer email between servers or between a mail client and a server. If you know the commands to interact with an SMTP server, you can send email without going through a mail program. This trick can be used to forge email. For example, a few years ago, the summer students at the National Solar Observatory in Sunspot, New Mexico, made it appear that the party one of the scientists was throwing after the annual volleyball match between the staff and the students was in fact a victory party for the students. (Of course, the author of this book had absolutely nothing to do with such despicable behavior. ;-) ) The interaction with the SMTP server went something like this; input the user types is shown in bold (the names have been changed to protect the gullible):

flare%

telnet localhost 25

Trying 127.0.0.1 ...

Connected to localhost.sunspot.noao.edu.

Escape character is '^]'.

220 flare.sunspot.noao.edu Sendmail 4.1/SMI-4.1 ready at 

Fri, 5 Jul 93 13:13:01 MDT

HELO sunspot.noao.edu

250 flare.sunspot.noao.edu Hello localhost [127.0.0.1], pleased to meet you

MAIL FROM: bart

250 bart... Sender ok

RCPT TO: local@sunspot.noao.edu

250 local@sunspot.noao.edu... Recipient ok

DATA

354 Enter mail, end with "." on a line by itself

In a pitiful attempt to reingratiate myself with the students


after their inevitable defeat of the staff on the volleyball


court at 4:00 P.M., July 24, I will be throwing a victory


party for the students at my house that evening at 7:00.


Everyone is invited.


Beer and Ben-Gay will be provided so the staff may drown


their sorrows and assuage their aching muscles after their


public humiliation.


Sincerely,


Bart


.

250 Mail accepted

QUIT

221 flare.sunspot.noao.edu delivering mail

Connection closed by foreign host.

Several members of the staff asked Bart why he, a staff member, was throwing a victory party for the students. The moral of this story is that you should never trust email, especially patently ridiculous email like this, without independent verification. The other moral of this story is that you can use Telnet to simulate a client, see how the client and the server interact, and thus learn what your Java program needs to do. Although this session doesn't demonstrate all the features of the SMTP protocol, it's sufficient to enable you to deduce how a simple email client talks to a server.