Browse Prior Art Database

Method for Managing Client/Server Relationships in the AIX Operating System

IP.com Disclosure Number: IPCOM000034203D
Original Publication Date: 1989-Jan-01
Included in the Prior Art Database: 2005-Jan-27
Document File: 3 page(s) / 16K

Publishing Venue

IBM

Related People

Johnson, DW: AUTHOR [+3]

Abstract

This article describes a way of handling stateful client/server relationships in a distributed system. The specific implementation discussed is that of the Distributed Services product which runs under the AIX* operating system for the IBM RT PC. In the Distributed System function of the AIX operating system, client nodes make use of the resources of server nodes. For the client to use the remote resource there must be connection between the client and server, and during the use of the resource, the client and server may build up local knowledge of each other and of the state of the resource. There are several trade-offs available in deciding on the nature of this knowledge and on how to use the connection to maintain the knowledge. A typical scenario might flow as follows: Client "opens" a remote resource 1.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 43% of the total text.

Page 1 of 3

Method for Managing Client/Server Relationships in the AIX Operating System

This article describes a way of handling stateful client/server relationships in a distributed system. The specific implementation discussed is that of the Distributed Services product which runs under the AIX* operating system for the IBM RT PC. In the Distributed System function of the AIX operating system, client nodes make use of the resources of server nodes. For the client to use the remote resource there must be connection between the client and server, and during the use of the resource, the client and server may build up local knowledge of each other and of the state of the resource.

There are several trade-offs available in deciding on the nature of this knowledge and on how to use the connection to maintain the knowledge. A typical scenario might flow as follows:

Client "opens" a remote resource

1. client sends the server a request to open a resource with a

particular name

2. server finds resource

3. server does authorization validation to insure that the

requester has the right to use the resource

4. server builds control blocks to provide fast access to the

resource and to record how the client is using the resource

5. server constructs a handle or token for the resource and sends

to client

6. client stores token

Client "uses" the remote resource

1. client sends a request (e.g., read, write, lock, unlock),

using the token to identify the resource

2. server may accumulate information (e.g., locks) about how the

client is using the resource, and use this information to

insure that concurrent use of the resource by several clients

does not lead to unexpected results.

3. client may accumulate cached copies of server data to give

better performance if the same data is requested

frequently

Client "closes" the resource

1. client sends a close request using the token to identify the

resource

2. server releases counts, locks, and control blocks

3. client cache flushed

4. client discards handle The above is a highly "stateful" relationship; the server remembers who is using the resource for what, and the client maintains local cached copies of portions of the remote resource. If the connection between the client and server is lost, then this state information must be cleaned up: - The client cannot be informed of changes to the "master" vers

1

Page 2 of 3

ions of any cached data. The client must, therefore, purge any

cached data.

- The server may have records of locks that the client has placed

on server resources. When the connection is lost,

then the cli ent cannot release these locks.

Therefore, when the server

detects that loss of the connection, it must remove

these locks.

- The server may have control blocks tied up remembering

information about the client. The server must free

these

resources to avoid having them useless forever.

- The token returned from the server to the client may include

information which is only valid while the connection

is...