Section 18.1. Network Servers

Chapter 18. Network Programming

Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway.

Andrew S. Tanenbaum

When a marketing type says networking, he probably means he wants to give you his business card. But when a programmer says it, he's talking about electronic communication between physically separated machineswhether across the room, across the city, or across the world.

In the programmer's world, networking usually implies TCP/IP, the native tongue in which millions of machines whisper back and forth across the Internet. I'll say a few words about this before diving into some concrete examples.

Network communication is conceptualized at different levels (or layers) of abstraction. The lowest level is the data link layer, or actual hardware-level communication, which we won't discuss here. Immediately above this is the network layer, which is concerned with the actual moving around of packets; this is the realm of IP (Internet Protocol). At a still higher level of abstraction is the transport layer, where we find TCP (Transmission Control Protocol) and UDP (User Datagram Protocol). At the level above this, we find the application layer; at this point we finally enter the world of telnet, FTP, email protocols, and much more.

It's possible to communicate directly in IP, but normally you wouldn't do such a thing. Most of the time we are concerned with TCP or UDP.

TCP provides reliable communication between two hosts; it is concerned with blocking and deblocking of packet data, acknowledgement of receipt, handling timeouts, and so on. Because it is a reliable protocol, the application using it need not worry about whether the remote host receives the data.

UDP is much simpler, merely sending packets (datagrams) to the remote host, like binary postcards. There is no guarantee that these will be received, so the protocol is unreliable (and thus the application has some extra details to worry about).

Ruby supports low-level networking (chiefly in TCP and UDP) as well as coding at higher levels. These higher levels include telnet, FTP, SMTP, and so on.

Figure 18.1 is a class hierarchy showing the highlights of Ruby's networking support. HTTP and certain other high-level items are shown here; some others are omitted for clarity.

Figure 18.1. Partial inheritance hierarchy for networking support in Ruby.

Note that the bulk of these classes derive from the IO class. This means that we can use the methods of IO that are so familiar to us.

Documenting all the features of all these classes would far exceed the space requirements of this book. I'll only present a task-oriented approach to all of this and offer a little explanation. For a comprehensive list of available methods, consult a reference such as ruby-doc.org.

A few significant areas are not covered here at all, so we'll mention these up front. The Net::Telnet class is mentioned only in connection with NTP servers in section 18.2.2, "Contacting an Official Timeserver"; this class is not just for implementing your own telnet client but is potentially useful for automating anything that has a telnet interface.

The Net::FTP library is also not covered here. In general, FTP is easy to automate in its everyday form, so there is less motivation to use this class than there might be for some others.

The Net::Protocol class, which is the parent of HTTP, POP3, and SMTP, is also not covered in this chapter. It would probably prove useful in the development of other customized networking protocols, but this book does not discuss it.

That ends our broad overview. Let's look at low-level networking in more detail.