Browse Prior Art Database

Efficient Scheduling Mechanism for Distributed Computing Environment

IP.com Disclosure Number: IPCOM000113214D
Original Publication Date: 1994-Jul-01
Included in the Prior Art Database: 2005-Mar-27
Document File: 4 page(s) / 178K

Publishing Venue

IBM

Related People

Lin, DH: AUTHOR

Abstract

In the current OSF/DCE implementation, there is no scheduling mechanism to efficiently schedule incoming service requests among machines in a configured cell. The only policy that applied in current OSF/DCE is randomization: when a client requests the service from a set of servers, the RPC runtime will return one compatible server binding handle selected at random from the name service database. This is an inefficient way of sharing the resources in a distributed environment. This provides a simple mechanism to efficiently schedule all the incoming requests from the clients to proper server machines that can provide the best services to the clients. As a result, the application's performance can be improved. Additionally, the entire distributed system environment's throughput can be increased.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 31% of the total text.

Efficient Scheduling Mechanism for Distributed Computing Environment

      In the current OSF/DCE implementation, there is no scheduling
mechanism to efficiently schedule incoming service requests among
machines in a configured cell.  The only policy that applied in
current OSF/DCE is randomization: when a client requests the service
from a set of servers, the RPC runtime will return one compatible
server binding handle selected at random from the name service
database.  This is an inefficient way of sharing the resources in a
distributed environment.  This provides a simple mechanism to
efficiently schedule all the incoming requests from the clients to
proper server machines that can provide the best services to the
clients.  As a result, the application's performance can be improved.
Additionally, the entire distributed system environment's throughput
can be increased.

      One of the advantages of distributed computing is efficient
sharing various resources among different machines configured in a
networking environment (e.g., A cell in the OSF/DCE term).  A typical
way of resource sharing is through the help of the scheduling
mechanism in the system.  Based on certain criteria of the systems,
the scheduling mechanims can literally arrange all system resources
(in the network) to achieve the best processing capacity (e.g.,
performance, throughput, response time, resource utilization, etc.).
In the current OSF/DCE environment, when client requests a service
from the name space database (i.e., the Cell Directory Service
Clearinghouse), in the case of multiple compatible servers, the RPC
runtime will randomly return a compatible server binding to the
client.

      In a single cell environment, if all of the application server
machines have the same configuration (i.e., same CPU power, same
amount of RAM, same DASD, etc.), the current randomly returned server
binding will not cause any inefficient dresources sharing.  However,
if the application server machines are different (some machines are
much faster than others), the way that current DCE/RPC handles this
will not be efficient enough to best utilize all resources in this
environment.  In the real world, DCE is designed to be used in global
distributed computing environment (using GDS and DNS/X.500).  Chances
for all the application servers to run on the same configuration
machines are almost zero.  Therefore, this is trying to provide a
simple and efficient mechanism to resolve this problem which exists
in the current OSF/DCE.

      In the DCE/RPC runtime implementation, the APIs that an
application uses to get the server binding information are called
Name Service Independent Interface (NSI).  Among them, the most
frequently used NSI calls are those related to import and lookup
operations.

      The NSI calls for applications to find a compatible server are
rpc_ns_binding_import_begin, rpc_ns_binding_import_next, and
rpc_ns_binding_import_done.  The ...