Atomic transaction protocols establish something like a connection as they create a transaction ID, so this class of protocols is not outside the domain of the session layer. Some issues of the protocol may properly be described as being at a higher level, perhaps the presentation layer or even the application layer.
Assume a system with a file server and a large number of compute-servers, each with a local disk, where users may freely launch applications on any compute server; the CS department network follows something close to this model!
What files should be stored locally and what files should be stored centrally on the file server?
Files belonging to users must be accessible from any machine, as users may come to any machine at any time expecting access to their files. Such files must therefore be on the server. Temporary files created briefly during the execution of an application should be stored locally so that their use does not generate network traffic. Read-only files (typically system files) may be stored on either the server or on local disks; because they are read-only, their semantics do not depend on where they are stored. Heavily used read-only files should probably be local, to avoid high traffic on the net, while rarely used files can be stored centrally, to avoid the cost of duplicate storage.
b) Consider the possibility of using the local disk on each machine as a cache, storing copies of files from the central server. What criteria would you use to determine what files may be cached and what files must not be cached. Does your caching solution provide most of the solution to the problem in question 7 on page 548?
The answer given to part a) largely answers this. Read-only files may be safely cached, and the cache management policy will determine which reside locally and which reside on the file server. Read-write files other than temporary files must be on the server so that they will have the expected semantics when the user stops a session on one machine and moves to another.Treating the workstation disk as a cache for the file server does not entirely solve the problem of updating the local disk when new system software is released. It does change the problem, however. Now, we must find some way to delete the old copies from the local cache when the workstation is powered up after a new version becomes available.
Optimal algorithms require global information, and global information is expensive to gather.
First, we adopt the convention that the first word of each message must be the box number to which it is addressed. Then, we create, local to each process, an array of queues, one per incoming box (probably implemented as a linked list of queues, where each queue is itself a linked list, because the array of queues is likely to be very sparse).When a user does awaits a message in a particular box, if the queue representing that box is not empty, we just return that message. If the queue is empty, we repeatedly block awaiting messages from the process's incoming queue until we get a message with the correct box number. All messages we receive with the wrong box numbers are placed in the queue used to implement that box.
It is easy to extend this to support something analogous to an untimed UNIX-style select command -- so long as there is no message in any of the boxes in the list given as an argument, await messages and put them in the indicated queues. As soon as any queue in the list is found to be non-empty, return the box number of that queue.