There is an architectural model of networking, known as the ISO seven-layer model. It doesn't exactly match any real network, but it's a good tool for understanding networking. The seven-layer model says that there are seven layers in a network connection. Each layer only talks to the layer immediately above or below it, but its communications are directed to the same layer on the remote computer. Together they form what the marketing droids call an “IP stack” though it's really a FIFO-queue of course. The layers are shown in Table 25-1. Read it from the bottom up.

People use the acronym All People Seem To Need Data Processing to remember the seven layers, but I think it makes more sense to consider the stack from the bottom up, so Please Do Not Teach Students Poor Acronyms.

TCP/IP is actually built from four layers:

4 The application layer (the networking protocols like HTTP, POP3 and IMAP).

3 The transport layer (TCP and UDP),

2 The network layer (packets and IP addresses),

1 The datalink or link layer (frames and MAC addresses),

There are three big protocols built on top of IP. Both ends of the protocol have an OS data structure called a socket. A socket does the same job for an IP connection that a telephone handset does for a phone conversation: it is an object that makes it convenient to send and receive. In the case of a phone handset we send and receive noises. In the case of an IP connection, we send and receive bytes.

IP supports the following protocols, using socket connections:

ICMP is a low-level protocol for message control and error reporting. It uses IP packets, but its messages are directed at the IP software itself and don't come through to the application layer. Java doesn't support ICMP and we won't say anything more about it.

A client socket is different from a server socket. The client socket is good at asking for something, while the server socket is good at listening for requests. In the phone world, a server socket is the equivalent of a call center that only takes calls and never initiates outgoing calls. A client socket is the equivalent of someone who dials into the call center for support. The phone world is a great analogy for understanding many things about networked communication (because the phone world is networked communication, but of a type where everyone is familiar with the end point features).

Note that the number of socket writes is not at all synchronized with the number or timing of socket reads. A packet may be broken into smaller packets as it is sent across the network, so your code should never assume that a read will get the same number of bytes that were just written into the socket.

The most widely used version of IP today is Internet Protocol Version 4 (IPv4). However, IP Version 6 (IPv6 or IPng) is also beginning to enter the market. IPv6 uses 128 bit addresses, not 32 bit, and so allows many more Internet users. IPv6 is fully backward compatible with (can process packets sent using) IPv4, but it will take a long time before IPv4 is displaced by v6. IPv4 is supported with hardware-based routing at wire speed on 2.5Gb links. IPv6 currently uses software routing.

An IPv4 feature called “Network Address Translation” (NAT) has greatly reduced the pressure to move to v6. A few years ago, it looked like we were going to run out of IP addresses. Today NAT lets your big site have just one assigned address, which you use for the computer with the internet connection. You use any IP address you like for the computers on your side of the firewall. You may be duplicating numbers that someone else uses behind their firewall, but the two systems don't interfere with each other. When you access the internet, NAT updates your packets dynamically. It rewrites your internal IP address in packets changing it into the externally visible one, and rewrites IP addresses in incoming packets so they'll go to your host. A NAT server keeps track of who's doing what, so it knows who should get which packets from the outside. From the outside, it looks like all your traffic is coming from your server computer that runs the NAT service.

Here are some common pieces of hardware in the network world. When we talk about “layer 3” etc. in the following definitions, it is with reference to the OSI 7-layer model.

If you browse the network library API, you'll find the following classes. There are a few other classes, but these are the key ones.

The class DatagramSocket supports the use of UDP packets. We don't deal with UDP here because it is less widely used than TCP. Most people want the reliability feature that TCP offers. Ironically, the widespread use of subnets using directly connected switches (instead of shared ethernet segments) has made UDP much more reliable, to the point where people are using it on LANs instead of TCP, and getting performance and reliability.

Let me try that last sentence again. When we started extensive networking in the late 1970s, ethernet was the medium of choice. You strung a single ethernet cable down a corridor and workstations physically attached to the net by tapping into the cable. That meant that all the network traffic was visible to all the workstations that used that cable. It was electronically noisy and slow. Today, nearly everyone uses 10baseT or 100baseT wiring. The number is the speed in Megabits, and the “T” part means “Twisted pair.” There is a twisted pair wire from your workstation directly to the switch that controls your subnet. No other workstation shares your twisted pair wiring. Result: faster performance, less electronic noise, and more reliable subnets, leading to greater confidence using UDP.

Before we look at actual Java code, a diagram is in order showing how a client and server typically communicate over a TCP/IP network connection. Figure 25-3 shows the way processes contact each other by using IP address and a port number. The IP address identifies a unique computer on the Internet. The port number is a simple data structure that the OS maintains to direct an incoming network connection to a specific process.

Figure 25-3. Client and server communication using a TCP/IP connection

An IP address is like a telephone number, and a port number is like an extension at that number. Together they specify a computer and a service request. The combination of an IP address plus a port number is the definition of a socket. To talk to each other, the client and server must open a dialog using the same port number.

For simplicity, in Java network socket connections are made to look like I/O streams. You simply read and write data using the usual stream methods (all socket communication is in 8-bit bytes), and it automagically appears at the other end. Unlike a stream, a socket supports two-way communication. There is a method to get the input stream of a socket, and another method to get the output stream. This allows the client and server to talk back and forth.

Almost all Internet programs work as client/server pairs. The server is on a host system somewhere in cyberspace, and the client is a program running on your local system. When the client wants an Internet service (such as retrieving a web page from an HTTP server), it issues a request, usually to a symbolic address such as www.sun.com rather than to an IP address (though that works just fine, too).

The bits forming the request are assembled into a packet and routed to the server. The server reads the incoming packet, notes what the request is, where it came from, and then tries to respond to it. It does so by providing either the service (web page, shell account, file contents, etc.) or a sensible error message. The response is sent back across the Internet to the client.

All the standard Internet utilities (telnet, rdist, FTP, ping, rcp, NFS, and so on) operate in client/server mode connected by a TCP or UDP socket. Programs that send mail don't really know how to send mail—they just know how to take it to the Post Office port. In this case, mail has a socket connection and talks to a demon at the other end with a fairly simple protocol. The standard mail demon knows how to accept text and addresses from clients and transmit it for delivery. If you can talk to the mail demon, you can send mail. There is little else to it.

Many of the Internet services are actually quite simple. But often considerable frustration comes in doing the socket programming in C and in learning the correct protocol. The socket programming API presented to C is quite low level and all too easy to screw up. Errors are poorly handled and diagnosed. As a result, many programmers naturally conclude that sockets are brittle and hard to use. Sockets aren't hard to use. The C socket API is hard to use.

Don't believe me? Take a look. The C code to establish a socket connection is:

By way of contrast, the equivalent Java code is:

That's it! Just one line of Java code to do all the things the C code does.

Java handles all that socket complexity “under the covers” for you. It doesn't expose the full range of socket possibilities, so Java avoids the novice socketeer choosing contradictory options. On the other hand, a few obscure sockety things cannot be done in Java. You cannot create a raw socket in Java, and hence cannot write a ping program that relies on raw sockets (you can do something just as good, though). The benefit is overwhelming: You can open sockets and start writing to another system just as easily as you open a file and start writing to hard disk.

A “ping program,” in case you're wondering, is a program that sends ICMP control packets over to another machine anywhere on the Internet. This action is called “pinging” the remote system, rather like the sonar in a ship “pings” for submarines or schools of fish. The control packets aren't passed up to the application layer, but tell the TCP/IP library at the remote end to send back a reply. The reply lets the pinger calculate how quickly data can pass between the two systems.

The most-used methods in the API for the client end of a socket are:

The constructor with no arguments creates an unconnected socket which you can later bind() to a host and port you specify. After binding, you will connect() it. It's easier just to do all this by specifying these arguments in the constructor, if you know them at that point.

The setSoTimeout(int ms) will set a timeout on the socket of ms milliseconds. When this is a non-zero amount, a read call on the input stream will block for only this amount of time. Then it will break out of it by throwing a java.net.SocketTimeoutException, but leaving the socket still valid for further use.

The setSocketImplFactory() method is a hook for those sites that want to provide their own implementation of sockets, usually to deal with firewall or proxy issues. If this is done, it will be done on a site-wide basis, and individual programmers won't have to worry about it.

The socket API has one or two dozen other get/set methods for TCP socket options. Most of the time you don't need these and can ignore them.