Protocols Metadata Protocols and Metadata

2. It sends a request. In order to do this, both the client and the server must have a shared understanding of what the connection can be used for, and what constitutes a valid request. 3. It receives a response. In order for this to be meaningful e.g., if the client is doing something other than simply displaying the response, the client and server must again have some sort of shared understanding about what the valid range of responses is. The last two steps involve an application-level protocol and application-level metadata.

2.2.2.1 Protocols

A protocol is simply a shared understanding of what the next step in communicating should be. If two programs are part of a distributed application, and one program tries to send data to the other program, the second program should be expecting the data or at least be aware that data may be sent. And, more importantly, the data should be in a format that the second program understands. Similarly, if the second program sends back a response, the first program should be able to receive the response and interpret it correctly. HTTP is a simple protocol. The client sends a request as a formatted stream of ASCII text containing one of the eight possible HTTP messages. [ 4] The server receives the request and returns a response, also as a formatted stream of ASCII text. Both the request and the response are formatted according to an Internet standard. [ 5] [ 4] One of CONNECT, DELETE, PUT, GET, HEAD, OPTIONS, POST, or TRACE. [ 5] Internet RFC 822. Available from w w w .iet f.or g . HTTP is an example of a stateless protocol. After the response is received, the communication between the client and the server is over™the server is not required to maintain any client- specific state, and any future communication between the two should not rely on prior HTTP requests or responses. Stateless protocols are like IP datagrams™they are easy to design, easy to implement in a robust way, and very scalable. On the other hand, they often require more bandwidth than other protocols because every request and every response must be complete in and of itself.

2.2.2.2 Metadata

An interesting thing happens when you click on the Fetch button: you get back a lot more than the web page that would be visible in a web browser such as Netscape Navigator or Internet Explorer. Figur e 2- 2 shows screenshot of the user interface after the button is clicked. Figure 2-2. The WebBrowser application after fetching a web page This is the response associated to the main OReilly web page. Notice that it starts with a great deal of text that isnt normally displayed in a web browser. Before the page contents, or the formatting information for the page contents are sent, the web server first tells the client about the information it is sending. In this case, the server first informs the client that the response is being sent using the HTTP 1.0 protocol, that the client requested succeeded without any problems this is what 200 OK means, that the page being sent hasnt changed in a few hours, and that the page is composed of HTML text. This type of information, which consists entirely of a description of the rest of the response, is usually called metadata. Weve already encountered the metadatadata distinction before in our discussion of datagrams. Each datagram contains a header the metadata and data the data. One of the things that TCP added to IP was extra metadata to headers that allowed datagram recipients to correctly reassemble the data in several datagrams into one coherent unit. Metadata is ubiquitous in distributed applications. Servers and clients have independent lifecycles, both as applications and as codebases. Enabling robust communication between a client and a server means that you cant simply send a message. You have to say what type of message youre sending, what it is composed of, what version of the protocol and specifications are being used to format the message, and so on. Well do this manually in the next chapter, when we build a socket application. RMI, on the other hand, automatically generates descriptions of Java classes. These descriptions, stored in static long s named serialVersionUID one integer for each class, will be more fully discussed in Chapt er 10 .

2.3 ServerSockets

So far, weve focused on how to write a client program using sockets. Our example code assumed that a server application was already running, and the server was accepting connections on a well-known port. The next logical step in our discussion of sockets is to write an application that will accept connections. Fortunately, this isnt much more complicated than creating a client application. The steps are: