Socket is a Unix-derived concept for an active data connection between two processes. Terms like "socket" and "port" were chosen to give this construct a very physical and simple sense. But it is neither physical nor simple. It is a complicated software abstraction that encapsulates layers of even more complicated networking protocols and the artifacts of transmission hardware.
The simple promise of a socket is that information pushed into the socket by some application will appear in another application that is attached to that socket. In a two-directional socket stream, like the one we will develop here, the data flows in both directions.
The two programs that are linked together like this might be on the same computer, they might be joined on a LAN, or they might be linked by the Internet anywhere on Earth. Except during the initial step of establishing a connection, these differences are invisible to the socket user .
Our previous work on sockets led us to implement a web client in PHP. Client-side programming ” especially creating a little browser or robot for the web ”does not demand much control over the socket.We used the fsockopen() function to create a socket connection with the well- understood behavior of an open file. It seemed pretty easy, because some other programmer did the hard work of building the socket functionality on the server side.
Server-side sockets use full-duplex bidirectional connections (meaning that both client and server sides can talk and both can listen simultaneously ). But they are not symmetrical: The server side has host responsibilities to observe. Since the client initiates the contact, the server has the more difficult job of waiting. The host is always listening for service requests .
An even more dramatic asymmetry is the fact that a client attaches to a single server, but the server is managing requests from many clients . An actual socket can connect to only a single client, but a server often needs to respond to hundreds of simultaneous requests.
One socket, identified by IP address and port number, is the published location for a given service. All requests address this socket. This means that the server must manage a system of many active virtual sockets, each behaving as if it were the single public socket known to the clients.
Actual server connections are made to IP addresses. These are represented usually in the form 220.127.116.11. A 32-bit address (4 bytes) is displayed as four decimal values (0 “255) divided by dots. This full number is used to address a single machine somewhere in the universe. The IP address of a web server, like most hardware that is publicly connected to the Internet, is a static IP address: Its 4-byte address will be the same tomorrow as it is today.
In the case of a dial-up Internet connection, the ISP (Internet service provider ”the company providing the connection) generally lends the user an IP number from a pool of numbers that the ISP owns. Even in always-on connections, such as DSL or cable modems, the user is given a dynamic IP address. This technique means that a user's actual address changes frequently. It is roughly equivalent to the phone company giving you a new phone number every time you make a call. It is easy for you to make a call, but it is extremely hard for anyone to call you, since you have no number to publish or even give to your friends .
A dynamic IP address makes it difficult to implement a server at a network node intended for surfing with a browser. Inventive minds still find ways to do it (like peer-to-peer music sharing), but it is tricky and it presents interesting business, political, and cultural issues as well as the simply technical ones.
It is rare to know a server by its numeric address. We know its domain name instead. We look for awl.com, not 18.104.22.168, though they both resolve to the same machine. The domain name is a handy abstraction both for mnemonic reasons and for the freedom to dereference: Someone who is looking for Addison-Wesley content looks for the Addison-Wesley domain and doesn't worry about where the content is actually served from. Easier for them to remember, easier for AWL to change to another server.
To open a socket, we need the IP number, not the domain name. The tables that translate between the two are distributed throughout the Internet. The domain name server ( DNS ) is a process that delivers the IP address for a given name.
To use the domain name service from within PHP, we need to know not where it is located or how it works but just the PHP function call:
<? $address = gethostbyname ( "awl.com" ); echo $address; ?>
In ActionScript the task is even easier. The XML.Socket object has a connect() method that will accept either a numeric address or a named domain. It alternatively accepts the keyword null , which specifies a connection to the server from which this movie was downloaded. Because of the security restrictions on all Web-delivered Flash applications, this is the only domain they can in fact connect to, so the null parameter is by far the most common.
myXMLSocket.connect( null, 12353 );
The server side is similar. The server we build uses a port on its own machine. This derives not from any arbitrary security restriction but from the most fundamental definition of the client/server model.
PHP reserves a name that identifies the server on which we are running:
$address = gethostbyname ($SERVER_NAME);
It gives us a usable numeric reference to the current server.
A port number is an arbitrary number that functions like the extension portion of a business phone number. A PBX phone system allows all the telephone users in an organization to share one public number by routing each incoming call to the proper extension. The port number allows the many processes on a modern computer to share the single IP address; incoming messages are routed to the proper process.
In practice, a publicly known port number is usually identified with a service, not the process that performs a service. To continue the phone analogy, it is as if job applicants were told, "Call extension 202 for human resources."
Most of us are familiar with the ports on a personal computer. Serial ports (like COM1:, COM2:, and so on) usually identify actual UART chips, Even printer ports (LPT1:, LPT2:), which are somewhat more abstracted, still resolve quickly to a specific hardware connection. Forget all this. The Socket port has no relation to installed hardware. Its limit is simply the mathematic range of a 16-bit integer.
Unlike the domain name situation, port numbers are not controlled by a global authority. This makes sense since port numbers are within the domain of a single machine. Within a machine, the assignment of port numbers is typically controlled by the system administrator.
To implement the example projects in this chapter, you will need your own dedicated port number. Generally this requires you to request the assignment of a fixed number from your system administrator. Our examples assume a Unix server, although Windows also has robust Socket support.
By convention, Unix port assignments follow this pattern:
P RIVILEGED P ROCESSES
These classic services of a web host have port numbers that are validated by decades of history. Most are odd numbers, since they date back to an era when a pair of ports (conventionally consecutive) were required for bidirectional communication. Some of the well-known services with dedicated ports are the following:
The privileged processes are given port assignments from 0 to 1024. To bar collision between user-built code and these privileged services, Macromedia has installed yet another security restriction into XML.connect() . It does not accept a port number below 1024. (Most systems would not allow anyone without root privileges to create a service with such a port number.)
But why restrict the client? It might prevent a sloppy programmer from accidentally stepping on the ftp service, for example, but it also prevents an ambitious one from building (for example) a Flash-based telnet client or a mail program that uses Flash graphics and interfaces directly to an SMTP server. Neither of these applications seems easy, but they would both be interesting.
E PHEMERAL P ORT A SSIGNMENTS
A TCP communication that requires its own dedicated port generally must be assigned this port temporarily by the operating system. We will soon be building such a system and we will be asking the OS to assign us ephemeral ports, in addition to the dedicated port assignment we request from the system administrator.
Assignment of an ephemeral port to a requesting process is fleeting, and the port can be swiftly and safely reassigned to another process. A band of addresses from 1024 through 5000 is reserved for these ephemeral ports. In Linux systems, this convention seems to have been violated and the band of ephemeral ports runs from 1024 through 32767. This may reflect the growth in importance of TCP which results in a huge appetite for ephemeral ports in the sort of large-scale web servers that Linux is used for.
U SER P ROCESSES
All the remaining numbers (even in Linux they are plentiful) are available for individual processes. The port number alone suffices to invoke the special process. For example, at one time we used bigfun.net:8383 to invoke the semipublic mail service at Big Fun. The requested port number appears at the end of the formal URL, separated by a colon . A default port number (in the privileged process range), such as http: (80), ftp: (21) and smtp: (25), is assumed for many protocols.