Andrew Tanenbaum - Distributed operating systems

Let us now look at the code, as outlined in Fig. 2-9. In (a) we have the server; in (b) we have the client. The server is straightforward. The main loop starts out by calling receive to get a request message. The first parameter identifies the caller by giving its address, and the second parameter points to a message buffer where the incoming message can be stored. The library procedure receive traps to the kernel to suspend the server until a message arrives. When one comes in, the server continues and dispatches on the opcode type. For each opcode, a different procedure is called. The incoming message and a buffer for the outgoing message are given as parameters. The procedure examines the incoming message, ml, and builds the reply in ml. It also returns a function value that is sent back in the result field. After the send has completed, the server goes back to the top of the loop to execute receive and wait for the next incoming message.

In Fig. 2-9(b) we have a procedure that copies a file using the server. Its body consists of a loop that reads one block from the source file and writes it to the destination file. The loop is repeated until the source file has been copied completely, as indicated by a zero or negative return code from the read.

The first part of the loop is concerned with building a message for the READ operation and sending it to the server. After the reply has been received, the second part of the loop is entered, which takes the data just received and sends it back to the server in the form of a WRITE to the destination file. The programs of Fig. 2-9 are just sketches of the code. Many details have been omitted. For example, the do_xxx procedures (the ones that actually do the work) are not shown, and no error checking is done. Still, the general idea of how a client and a server interact should be clear. In the following sections we will look at some of the issues that relate to clients and servers in more detail.

#include

void main(void) {

struct message m1, m2; /* incoming and outgoing messages */

int r; /* result code */

while (1) { /* server runs forever */

receive(FILE_SERVER,&m1); /* block waiting for a message */

switch(m1.opcode) { /* dispatch on type of request */

case CREATE: r = do_create(&m1, &m2); break;

case READ: r = do_read(&m1, &m2); break;

case WRITE: r = do_write(&m1, &m2); break;

case DELETE: r = do_delete(&m1, &m2); break;

default: r = E_BAD_OPCODE;

}

m2.result = r; /* return result to client */

send(m1.source, &m2); /* send reply */

}

}

(a)

#include

int copy(char *src, char *dst) /* procedure to copy file using the server */

{

struct message m1; /* message buffer */

long position; /* current file position */

long client = 110; /* client's address */

initialize(); /* prepare for execution */

position = 0;

do {

/* Get a block of data from the source file. */

m1.opcode = READ; /* operation is a read */

m1.offset = position; /* current position in the file */

m1.count = BUF_SIZE; /* how many bytes to read */

strcpy(&m1.name, src); /* copy name of file to be read to message */

send(FILE_SERVER, &m1); /* send the message to the file server */

receive(client, &m1); /* block waiting for the reply */

/* Write the data just received to the destination file. */

m1.opcode = WRITE; /* operation is a write */

m1.offset = position; /* current position in the file */

m1.count = m1.result; /* how many bytes to write */

strcpy(&m1.name, dst); /* copy name of file to be written to buf */

send(FILE_SERVER, &m1); /* send the message to the file server */

receive(client, &m1); /* block waiting for the reply */

position += m1.result; /* m1.result is number of bytes written •/

} while (m1.result > 0); /* iterate until done */

return(m1.result >= 0 ? OK : m1.result); /* return OK or error code */

}

(b)

Fig. 2-9.(a) A sample server. (b) A client procedure using that server to copy a file.

In order for a client to send a message to a server, it must know the server's address. In the example of the preceding section, the server's address was simply hardwired into header.h as a constant. While this strategy might work in an especially simple system, usually a more sophisticated form of addressing is needed. In this section we will describe some issues concerning addressing.

In our example, the file server has been assigned a numerical address (243), but we have not really specified what this means. In particular, does it refer to a specific machine, or to a specific process? If it refers to a specific machine, the sending kernel can extract it from the message structure and use it as the hardware address for sending the packet to the server. All the sending kernel has to do then is build a frame using the 243 as the data link address and put the frame out on the LAN. The server's interface board will see the frame, recognize 243 as its own address, and accept it.

If there is only one process running on the destination machine, the kernel will know what to do with the incoming message — give it to the one and only process running there. However, what happens if there are several processes running on the destination machine? Which one gets the message? The kernel has no way of knowing. Consequently, a scheme that uses network addresses to identify processes means that only one process can run on each machine. While this limitation is not fatal, it is sometimes a serious restriction.

An alternative addressing system sends messages to processes rather than to machines. Although this method eliminates all ambiguity about who the real recipient is, it does introduce the problem of how processes are identified. One common scheme is to use two part names, specifying both a machine and a process number. Thus 243.4 or 4@243 or something similar designates process 4 on machine 243. The machine number is used by the kernel to get the message correctly delivered to the proper machine, and the process number is used by the kernel on that machine to determine which process the message is intended for. A nice feature of this approach is that every machine can number its processes starting at 0. No global coordination is needed because there is never any ambiguity between process 0 on machine 243 and process 0 on machine 199. The former is 243.0 and the latter is 199.0. This scheme is illustrated in Fig. 2-10(a).

A slight variation on this addressing scheme uses machine.local-id instead of machine.process. The local-id field is normally a randomly chosen 16-bit or 32-bit integer (or the next one in sequence). One process, typically a server, starts up by making a system call to tell the kernel that it wants to listen to local-id. Later, when a message comes in addressed to machine.local_id, the kernel knows which process to give the message to. Most communication in Berkeley UNIX, for example, uses this method, with 32-bit Internet addresses used for specifying machines and 16-bit numbers for the local-id fields.