This problem requires a design decision. Should the client stubs be opaque, isolating the user from the record formats described in Figure 10.5 or should the stubs be as transparent as possible? If the client stubs have the same calling sequence as the server routines in Figure 10.5, the answer is that they will be moderately transparent. That is the direction we take in the answer given here:
do_create(m1,m2)
(struct message)* m1, m2;
{
m1->source = client;
m1->dest = FILE_SERVER; /* don't know if this is needed */
m1->opcode = CREATE;
send( FILE_SERVER, m1);
receive( client, m2 );
return( m2->result );
}
The other procedures, do_read, do_write and
do_delete are identical, except that they use different opcodes.
why not!
Part B: Is the above code sensitive to variations in communications primitives?
The above code certainly relies on the receive primitive being a blocking primitive. The code works using conventional (buffered) communication, and it also works with an unbuffered blocking send primitive where the transfer of a message from sender to receiver is accomplished by a rendezvous between sender and receiver.
Presumably, the server must have a published network address (a public socket) to which any client may connect. If client and server need to conduct a prolonged dialog during which other clients must also contact the same server, one solution is to use the initial connection with the server to communicate in order to set up a private channel.
For example, the client could create two sockets, connecting one to the server's public socket and using that connection to send the server the identity of the client's private socket. The server could then create a new private socket and connect that to the client's private socket before breaking the initial connection with the client. At this point, the client and server have a private connection with each other while the server's public socket is open, available for dialogues with other clients.
An alternative would be for the server to respond to the initial inquiry from a client by creating a new private socket and sending its identity back to the client. On receipt of this reply, the client would then close the link to the server's public socket and connect to the private socket the server provided. The result is the same, only the direction of the flow of information differs between these two solutions.
Part B: Describe a top-level design for a web server suitable for use on a large system where multiple clients make concurrent demands for different files, and where the underlying disk subsystem can overlap seeks on one disk drive with I/O transfers to another.
The server could, on receipt of an initial inquiry, use the fork primitive to create a new thread to serve each client. Each such thread could communicate with its client over a private channel, distinct from the public channel used to initiate the conversation. Of course, there may be reasons to limit the number of server threads at any given time. If this is needed, the server can maintain a record of the number of threads currently active, and it can refuse to respond to new clients until old clients have been served.
Part C: Discuss alternatives to the HTTP protocol, with an emphasis on protocols that are supported by the UNIX network interface that you believe could offer a performance improvement.
The biggest problem apparent with HTTP is that, when user displays a web page containing multiple illustrations (for example, embedded GIF images), a new client-server connection appears to be opened for each subsidiary file that must be displayed. Frequently, all of the subsidiary files reside on the same server, and frequently, the time taken to open the connections is greater than the time taken to transfer the data. As a result, it would be a good idea to allow multiple file requests to be sent over a single client-server connection, with all files returned to the client before that connection is broken.