Sockets

Berkeley Unix introduced the idea of a network socket. This terminology has been adopted as the standard way of describing TCP/IP and UDP connections across most other operating systems so that, at this point, it is pretty much a standard in networking. The Java APIs refer to net communications in terms of sockets, so a basic understanding of them is necessary to understand how Java networking works.

TCP/IP Sockets

A socket is an endpoint for network communications—not the most helpful of definitions. If a TCP/IP connection can be thought of as a virtual wire strung between two computers, then a TCP/IP socket is like the socket into which the wire plugs. There are two ways to use a socket: either as a host or as a client. As a host, a socket sits and waits for connections from clients. A host socket has an identifying number called a port, such that the entire range of sockets can be imagined to be a numbered patch panel.

A client, however, does not have a port. It does not need one because it initiates the connection. Think of this process as making a telephone call. The client dials the host’s number by specifying the host’s address and the host port to which to connect. Once that connection is made, both sides may communicate by “talking” (writing) and “listening” (reading) on their “telephone” (the socket) (see Figure 7.3).

Figure 7.3: Sending data via TCP/IP.

UDP Sockets

A UDP socket is more like a wireless connection. Rather than the socket being dedicated to “talking” with a specific port on a specific partner, it can send data and receive data from any other UDP socket on any other machine. UDP is often called a connectionless protocol.

Every packet sent out from a UDP port must be labeled with the machine and port number of the socket that is going to receive it. A computer can receive and send packets to many different partners on the same UDP socket.

Figure 7.4: Sending data via UDP.

Multicast UDP Sockets

Multicast UDP is like a pair of walkie-talkies. Everyone on the same frequency hears every broadcast on that frequency. This setup is accomplished on the network with a special kind of UDP socket called a multicast socket.

Multicast sockets are created as belonging to a multicast group. Typically this belonging is referred to as subscribing to the group. This group is like the frequency on the walkie-talkie. Every packet sent by a multicast socket can be heard by every other multicast socket subscribed to the same group.

We said can be heard not will be heard for two important reasons. The first has to do with range. Just as your walkie-talkies have a transmission range, so do multicast sockets. On an Ethernet, range is described in numbers of hops. A hop is the moving of a packet from one router¹ to the next. When a multicast socket is created, it is given a maximum number of hops any packet it sends can travel. This value is called the time to live (TTL). If a subscriber to a multicast group is too many hops away from the sender, he will not receive the message.

The second reason why a multicast packet might not be received is that multicast is really a special form of UDP and, as explained previously, UDP packets are not guaranteed as to when or if they arrive at all.

For this reason, various techniques have been developed to do reliable multicasting, which is discussed more in the earlier JRMS section.