Method and apparatus for allocating server access in a distributed computing environment

In a distributed computing environment (DCE), a scheduler process executes on every DCE processor. The schedulers mediate all remote procedure calls (RPCs) made by client processes to server processes using a scheduler and/or namespace accessible by the DCE processor. The scheduler database stores interfaces of single-thread servers, and the namespace stores interfaces of multi-thread servers. The scheduler, in response to receiving an identity of an interface from a client process searching the scheduler database and namespace to locate the interface. Upon locating the interface, the interface is provided to the client process so that client and server processes can be bound.

TABLE OF CONTENTS 
1. BACKGROUND OF THE INVENTION 
1.1 Clients, Servers, and Interfaces, and RPCs in a DCE Environment 
1.2 Multi-Threaded Servers 
1.3 Backward Compatibility Problems of Single-Thread Servers 
1.4 Prior Attempts to Accommodate Single-Thread Servers in the DCE 
2. SUMMARY OF THE INVENTION 
2.1 Basic Operation 
2.2 Transactional Context 
2.3 Cache of Known Servers 
3. BRIEF DESCRIPTION OF THE DRAWINGS 
4. DETAILED DESCRIPTION OF SPECIFIC EMBODIMENTS 
4.1 Primary Elements and Associated Procedures 
4.1 (a) Scheduler Location of an Interface 
4.1 (b) Client Queuing 
4.1 (c) Releasing the Process 
4.1 (d) Transactional Context 
4.2 An Enhanced Scheduler Embodiment 
4.3 Method of Searching for Bindings 
4.4 Data Transform Model 
CLAIMS

4. DETAILED DESCRIPTION OF SPECIFIC EMBODIMENTS 
A detailed description of the architecture of a method in accordance with 
the invention is set out below. In the interest of clarity, not all 
features of an actual implementation are described in this specification. 
It will of course be appreciated that in the development of any such 
actual implementation (as in any software development project), numerous 
programming decisions must be made to achieve the developers' particular 
goals and sub-goals (e.g., compliance with system- and business-related 
constraints), which will vary from one implementation to another. 
Moreover, attention will necessarily be paid to, e.g., proper 
serialization to handle concurrent events. It will be appreciated that 
such a development effort might be complex and time-consuming, but would 
nevertheless be a routine undertaking of program development for those of 
ordinary skill having the benefit of this disclosure. 
4.1 Primary Elements and Associated Procedures 
4.1 (a) Scheduler Location of an Interface 
FIG. 1 shows the conceptual elements of one embodiment of the current 
invention. Upon RPC initialization, a single-thread, multi-process server 
114 registers itself in a scheduler database 105. Also upon 
initialization, a multi-thread, single-process server 113 registers itself 
in namespace 107 by providing an interface identifier and binding 
information. If there were other servers present, all multi-process types 
would register in the scheduler database 105 and all multi-thread types 
would register in the namespace. 
At some future point, client 101 decides to access a server. Toward that 
end, client 101 requests a binding for a specific server interface by 
providing an interface ID. The request is received by the scheduler 103 
which in turn initiates a search for an appropriate interface. 
The scheduler 103 searches two data structures, one after the other: 1) The 
scheduler database 105; and 2) the namespace 107. First, the scheduler 103 
calls the scheduler database 105 to check if any multi-process server 114 
offers an appropriate interface. If an appropriate interface is found in 
the scheduler DB 105 then the search is terminated and the binding of the 
found interface is transferred to the requesting client 101. If an 
appropriate interface is not found in scheduler DB 105, then the scheduler 
103 continues its search calling the namespace 107. If an appropriate 
interface is found in namespace 107, then the corresponding binding is 
transferred to the requesting client 101. If an appropriate interface is 
not found in the namespace 107, then the scheduler 103 generates an error 
message. 
4.1(b) Client Queuing 
When an appropriate interface is found in the scheduler DB 105, the 
scheduler 103 transfers to the client 101 a binding for a multi-process 
server 114. The binding enables the client 101 to locate and access the 
desired server 114. 
Sometimes, the scheduler 103 finds an appropriate yet unavailable interface 
in the scheduler DB 105. Since multi-process servers 114 are single 
threaded, the scheduler cannot assign multiple clients to a single server. 
Therefore, if no appropriate interfaces are available, the scheduler 103 
places the client 101 in its queue. 
When an appropriate interface is found in the namespace 107, the scheduler 
103 transfers to the client 101, a binding to a multi-threaded server 113. 
If no threads are available, the standard RPC queuing mechanism activates. 
4.1(c) Releasing the Process 
In a DCE, by definition, a client 101 only accesses a server for a limited 
period of time. During the period of server access client 101 uses server 
resources to accomplish a limited task. When client 101 completes its task 
on multi-process server 114, then client 101 must relinquish binding 
handle 202. When releasing binding handle 202, client 101 invokes a 
"binding release service." A binding release service notifies the 
scheduler 103 that the server 114 is released thereby allowing 
reallocation of the resource. 
4.1(d) Transactional Context 
The elements of FIG. 1 can operate in an alternate embodiment called the 
transactional context. In the transactional context, the scheduler 103 
slightly changes its procedure in order to accommodate a slightly 
different request from the client 101. FIG. 2 shows the primary elements 
involved in transactional context operation. Transaction manager 201 is 
explained in X/Open documentation, specifically the "X/Open Guide, 
Distributed Transaction Processing Model" distributed by X/Open Co., Ltd., 
ISBN 1 872630 16 2. Briefly, the function of the transaction manager 201 
is to monitor transactions to assure that they are atomic. As a result, 
transaction manager 201 knows when client 101 begins and ends a 
transaction with any server. FIG. 2 illustrates the discrete point in time 
occurring just after the client 101 has acquired a binding handle 202 from 
the scheduler 103. 
When acquiring a binding, the client 101 may notify the scheduler 103 and 
activate transactional context. As a result, the scheduler 103 alters its 
behavior. The scheduler 103 coordinates with the local transaction manager 
201 such that the transaction manager 201 notifies the scheduler 103 when 
the transaction is terminated. Scheduler 103 does not reallocate the same 
binding handle until the transaction is terminated, other than to the same 
client seeking the same interface. For example, suppose client 101 makes a 
subsequent request for the same interface, before the transaction is 
terminated. Scheduler 103 assigns the same binding handle 202. However, if 
during the transaction, other client 203 requests the same interface from 
the scheduler, then scheduler 103 does not assign binding handle 202 even 
if client 101 is not accessing its assigned interface (server 113 or 114) 
at the time. 
Transactional context allows a client to establish and maintain context 
with a server throughout a whole transaction. When the currently executing 
transaction is over the transaction manager 201 notifies scheduler 103 and 
then scheduler 103 makes binding handle 202 available for allocation. 
Since the scheduler 103 is notified by the transaction manager 201, it is 
unnecessary for the client to invoke the binding release service. 
4.2 An Enhanced Scheduler Embodiment 
The embodiment of FIG. 1 may also be implemented with an enhanced scheduler 
301. The enhanced scheduler 301 operates essentially identically to the 
scheduler 103 except the enhanced scheduler 301 incorporates a storage 
unit 302 and uses a more complex method to locate an appropriate binding. 
FIG. 3 shows the elements directly affected by the use of an enhanced 
scheduler 301. 
Storage unit 302 can be any medium for data storage. It can be physically 
located in any memory accessible to the scheduler 301. In one embodiment, 
storage unit 302 holds a record of "contexts" that were created by 
previous binding assignments. For example, after RPC initialization, 
client 101 may invoke a binding resolution service from enhanced scheduler 
301. In response, enhanced scheduler 301 may locate binding 202 and assign 
it to client 101. Enhanced scheduler 301 would then store the connection 
context in storage unit 302. More specifically, the scheduler 301 stores 
binding 202 along with information that keys binding 202 to a specific 
interface. 
The storage unit 302 holds data for any convenient length of time. In the 
transactional context, a very efficient form of binding resolution is 
achieved by using storage unit 302 as a cache type memory storing 
client/server relationship data. In this configuration, the requesting 
client makes a binding request and indicates a transactional context. The 
storage unit 302 may then be required to hold the context data for a 
length of time equal to the transaction length. The schedulers easy access 
to the storage unit results in greater efficiency when the same client 
requests a binding for the same interface. 
4.3 Method of Searching for Bindings 
In one embodiment, the invention uses the method outlined in FIG. 4 to 
retrieve and assign bindings. Referring to FIG. 3, storage unit 302 is 
used to preserve context files containing data which describes the 
relationship between bindings and interfaces. 
Referring to FIG. 4, block 401 shows that the method begins when a client 
requests an interface. Control moves to block 402 where the first task of 
the method is to check in the context files for an appropriate interface. 
Control automatically passes to decision block 403. If an appropriate 
interface was found then decision block 403 passes control to block 404 
and a binding is assigned to the client. From block 404 control passes to 
block 413 which directs control to go to the next client request. 
Moving back to decision block 403, if no appropriate record was found in 
the context files, control is passed to block 405 and the scheduler 
database is searched. Control then automatically passes to decision block 
406. If an appropriate interface was located in the scheduler database 
then control passes to block 410 and the binding is assigned to the 
requesting client. Control then passes to block 411 and the context files 
are updated. Specifically, the server/client relationship is stored as a 
context. Control then passes to block 410 and is directed to the next 
client request. Referring back to decision block 406, if no appropriate 
binding was found control passes to block 407 and the namespace is 
searched for an appropriate binding. Control automatically passes to 
decision block 408. If no binding was found in the namespace then control 
passes to block 409 and an error message is generated. If a binding was 
found in the namespace then control passes to block 410 and proceeds 
through to 412 as outlined above. 
This method can drastically increase the efficiency of locating a binding. 
Efficiency gains are realized if the scheduler can search storage unit 302 
relatively fast as compared to searching the scheduler database 105 or the 
namespace 107. A search of the storage unit 302 is inherently fast 
relative to the other searches because the storage unit 302 typically 
contains fewer entries than the namespace 107 or scheduler database 105. 
The storage unit 302 can achieve an additional and non-inherent speed 
advantage through its location. Conceptually, the storage unit 302 is 
fastest to search if it is located within the scheduler 301. Physically, 
such memory is likely to be located in dedicated cache or in memory space 
allocated solely to the scheduler. 
4.4 Data Transform Model 
The invention can be described as a collection of data transforms and data 
structures. FIG. 5 is a data flow diagram for an implementation of the 
invention described in data-transform terms. The data flow can be 
conceptually divided into two sections: 1) Establish Connection data 
transform 527 which is implemented by the Connection Mapper component that 
resides in the client address space; 2) Schedule Servers data transform 
526 which operates in the targeted operating system environment and 
physical environment. The elements of FIG. 5 are defined as follows: 
Service Requestor 510: This is the user of system services (e.g., a client 
process). 
Binding 508: This indicates that a binding is being transferred from one 
node to another. Recall that a binding is address information sufficient 
for an RPC client to invoke an RPC server. 
Get Binding From Context 501: This is a data transform that retrieves the 
bindings from connection context 502 (connection context 502 is analogous 
to storage unit 302). 
Access Namespace 511: This indicate that the standard DCE RPC namespace is 
invoked to obtain a binding. This is used to obtain bindings for standard 
multi-thread servers. 
Connection Context 502: A data store used by Establish Connection 527 which 
contains zero or more connection context elements, as well as a 
transaction hash table of pointers used to quickly locate connection 
context elements associated with a particular transaction. This is 
analogous to storage unit 302. 
Connection Registration 506: An aggregate data element containing 
information used by Establish Connection 527 to maintain the state of the 
client-to-binding relationship. This information comprises the client for 
which this information is being maintained, the transaction 
identification, the namespace--entryname, the server interface 
specification, the source of the binding information (either Schedule 
Servers 526 or Access Namespace 511), the context semantics specified by 
the client, and the binding. Update CX State 505: This manages information 
in Connection Context 502. Management tasks comprise: 1) adding entries 
that are successfully obtained from the namespace or the scheduler 
database; 2) removing entries when transactions are completed. 
Txn End 504: The Demarcate Transaction data transform calls this routine to 
indicate the specified transaction has completed. The Establish Connection 
data transform uses this indication to terminate the transaction's 
client-server relationship(s) and release any binding information 
maintained for this transaction. This routine accepts one argument, namely 
the transaction identifier (TID). 
Demarcate Transaction 503: Provides services to begin, end, and signal 
completion of a transaction. For example Txn End 504 signals a the end of 
a transaction. 
Get Binding From Namespace 507: Calls Access Namespace 511 to retrieve a 
binding. If a binding is successfully retrieved, it is sent to Service 
Requestor 510 and information is passed to Update CX State 505 so that 
Connection Context 502 may be updated. 
Get Binding From Scheduler 525: Calls Schedule Servers 526 to retrieve a 
binding. If a binding is successfully retrieved, it is sent to Service 
Requestor 510 and information is passed to Update CX State 505 so that 
Connection Context 502 may be updated. 
Request Context 513: This represents a data store that contains the 
transaction identification for the current transaction. 
Server Release 528: Information used by Schedule Servers 526 to de-allocate 
a server process previously allocated by Establish Connection. 
Register Interface 523: This routine calls the DCE RPC runtime to register 
the server's interface(s) and obtain a vector of bindings. The bindings 
for single threaded servers are exported to the scheduler database 517. 
The bindings for multi-threaded servers are exported to the namespace 
using the standard DCE RPC naming export services. 
Unregister Interface 519: This routine is provided to unregister a server 
interface from the scheduler database 517. 
Allocate Server 514: This routine accesses the scheduling database to 
allocate an available server process of a MPST (multi-process, single 
threaded) server identified by the interface ID. 
Deallocate Server 524: This routine changes the status of a previously 
allocated server process to be available and checks if there is any 
waiting client on the waiting list for the particular MPST server. If so, 
it writes to the client process' FIFO to notify the availability of such 
server process. 
Scheduling DB 517: Scheduling DB is the repository for server scheduling 
data. 
Service Entry 518: Service Entries are entries in the Scheduling Database 
representing a MPST server. 
Server State 516: "Server State" represents the state of the specified 
server process within a MPST server (or what the state should be). 
String Binding 515: String Binding contains the character representation of 
a binding handle. 
Process Context data 520: This represents the data that is required for a 
server to register or unregister it interfaces. Specifically, it is the 
identification of the server's interfaces. 
It will be appreciated by those of ordinary skill having the benefit of 
this disclosure that numerous variations from the foregoing illustration 
will be possible without departing from the inventive concept described 
herein. For example, those of ordinary skill having the benefit of this 
disclosure will recognize that logical functions described above as being 
implemented in software can equivalently be implemented in hardware, e.g., 
through the use of discrete logic circuitry, and vice versa; likewise, a 
general-purpose processor operating under program control could 
equivalently be replaced by one or more special-purpose chips designed to 
perform the programmed functions; and so forth. 
Accordingly, it is the claims set forth below, and not merely the foregoing 
illustration, which are intended to define the exclusive rights claimed in 
this application.