HyperText Transfer Protocol--HTTP

A second data delivery mechanism that is, on the surface, very different from RPCs is the HyperText Transfer Protocol³. This transport mechanism is primarily intended to move hypertext documents (text, images, ...) over a network. Its basic unit of transfer is a file. The protocol is closely coupled with existing HTTP servers from World Widw Web Consortium, National Center for Supercomputing Applications and commercial providers. These servers support an extension mechanism called the Common Gateway Interface which can be used to transform information on the server computer to a hypertext document. Once the hypertext document has been prepared, it is passed back to the HTTP server which then sends it to the client.

A crucial difference between RPC technology and HTTP is that RPC is used to build an application-level communication protocol while HTTP is an application level protocol. While RPC can be used to build either stateless of stateful distributed systems, HTTP can only be used to build stateless systems. Because HTTP's extensions typically take the form of filter programs combined (using the CGI mechanism) with a server, HTTP is a poor choice for supporting `fat' interfaces. In other words, HTTP/CGI is a good choice for interfaces that are stateless and have a small number of entry points, but a poor choice for stateful or large interfaces.

The widespread use of HTTP and the competition between various providers of HTTP daemons has focused the attention of those server providers on important considerations like system security and accounting. Thus, while providers of HTTP software need to make high quality implementations of the HTTP protocol available, there is also considerable effort expended towards additional features which improve the overall function of any networked system. Because using RPCs virtually necessitates rebuilding support features like access control and logging, using HTTP can translate into significant savings during the design, implementation and management phases of a project.

The widespread use of HTTP means that server programs for HTTP are likely to exist on many of the would-be data-provider machines. Thus using HTTP will remove one impediment from a user becoming a data provider, that is, to become a data provider users will not necessarily have to install a data server. The nature of RPC technology is such that data server installation is typically considered complex by users and removing that hurdle improves the accessibility of the system (since the system depends on, to a large extent, the willingness of people to become data providers).

Figure: HTTP can be used to construct servers architecturally similar to those built with RPCs. (Figure ). To do so the RPC server stub portion of the server is implemented using HTTPD and one or more Common Gateway Interfaces as shown in this figure.

While there are fundamental differences between RPC and HTTP, Figure  shows how the RPC server stubs layer in Figure  can be constructed using one implementation of HTTP and some additional software. One crucial difference between systems built with RPC and those built using HTTP is that the RPC-based server can maintain state information while the HTTP-based server cannot. Thus, while servers based on RPC can use any convenient set of functions as the server interface, the HTTP interface must be more carefully chosen so as to insure that the system can function efficiently without state information retained in the server.