 |
Description  |
|
|
COPYRIGHT NOTIFICATION
Portions of this patent application contain materials that are subject to
copyright protection. The copyright owner has no objection to the
facsimile reproduction by anyone of the patent document, or the patent
disclosure, as it appears in the Patent and Trademark Office.
FIELD OF THE INVENTION
This invention relates generally to improvements in distributed computer
networks and, more specifically, to operating system software for
efficiently implementing client-server systems in distributed service
networks.
BACKGROUND OF THE INVENTION
Computer hardware is becoming increasingly distributed and remote,
resulting in networks of computers for solving problems in concert rather
than as stand-alone systems. Although such distributed "services" networks
generally facilitate problemsolving, they also increase the need for
flexibility and functionality in software programs operating on the
computers.
An example of a distributed services computer network is a "client-server"
system 100 shown in FIG. 1. The system 100 comprises a collection of
client nodes 102, e.g., workstations or personal computers, that
communicate over a network 104 with various server nodes 106. The servers
are typically computers having hardware and software elements that provide
a sophisticated set of services, or operations, for use by the client
nodes 102 to increase the efficiency of their own operations.
Several types of networks, including local area networks (LANs), may be
employed in the client-server system 100. ALAN is a limited area network
that typically consists of a transmission medium, such as a coaxial cable
or twisted pair, for interconnecting the client and server nodes. Each
node is connected to the transmission medium at an address which uniquely
identifies the node and which is used to route data from one node to
another.
Nodes coupled to the network typically communicate by exchanging discrete
"packets" of data according to predefined "protocols". In this context a
protocol consists of a set of rules defining how the nodes interact with
each other. For example, communication in the client-server system 100
typically takes the form of packet exchanges, wherein the clients 102 send
requests to the servers 112, which perform their services and communicate
results back to the clients.
In order to reduce design complexity, most networks are organized as a
series of hardware and software levels or "layers" within each node. These
layers interact to format data for transfer between nodes that are
communicating over the network. Specifically, predetermined services are
performed on the data as it passes through each layer and the layers
communicate with each other by means of the predefined protocols. This
layered design permits each layer to offer selected services to other
layers using a standardized interface that shields those layers from the
details of actual implementation of the services.
In an attempt to standardize network architecture, i.e., the sets of layers
and protocols used within a network, a generalized model has been proposed
by the International Standards Organization (ISO). The model, called the
open systems interconnection (OSI) reference model, addresses the
interconnection of systems that are "open" for communication with other
systems. The proposed OSI model has seven layers which are termed, in
ascending interfacing order, the "physical", "data link", "network",
"transport", "session", "presentation" and "application" layers. These
layers are arranged to form a protocol "stack" in each node of the
network.
FIG. 2 illustrates a block schematic diagram of prior art protocol stacks
225 and 275 used to transmit data between a client node 200 and a server
node 250, respectively. The protocol stacks are structured according to
the international standards organization OSI seven-layer model, which also
standardizes the functions of their constituent layers. Accordingly, only
the protocol stack 225 of the client node will be described.
Broadly stated, the physical layer 214 of the OSI model transmits a raw
data bit stream over a communication channel 220, while the data link
layer 212 manipulates the bit stream and transforms it into a data stream
that appears free of transmission errors. This latter task is accomplished
by dividing the transmitted data into data frames and transmitting the
frames sequentially, accompanied with error correcting mechanisms for
detecting or correcting errors. The network layer 210 routes data packets
from a source node to a destination node by selecting one of many
alternative paths through the physical network. The transport layer 208
accepts the data stream from the session layer 206, apportions it into
smaller units (if necessary), passes the smaller units to the network
layer 212, and provides appropriate mechanisms to ensure that all the
units arrive correctly at the destination.
The session layer 206 establishes "sessions", i.e., connections, between
software processes on the source and destination nodes, and transfers data
over those connections in an orderly fashion. That is, a session not only
allows ordinary data transport between the nodes, but it also provides
enhanced services in some applications, such as dialogue control. The
presentation layer 204 performs frequently-requested functions relating to
the presentation of transmitted data, including encoding of data into
standard formats, while the application layer 202 contains a variety of
protocols that are commonly needed by programs executing on the nodes,
such as remote file access.
As can be seen in FIG. 2, the protocol stacks 225 and 275 are physically
connected through the communications channel 220 at the physical layers
214 and 164. Thus, data transmission over a client-server network consists
of generating data messages in the application layer 202 of the client
node 200 and passing the data messages down through the protocol stack
225, where they are formatted for delivery onto the channel 220 as bits of
packets. Those packet bits are transmitted to the protocol stack 275 of
the server 250, where they are passed up that stack to the application
layer 252. The generation and formation of data are performed by, inter
alia, software programs executing on the nodes. These software programs
may be generally categorized into two broad classes: application programs
and operating systems. Operating systems are usually specific to a type of
computer and consist of a collection of a utility procedures that enable
the computer to perform basic operations, such as storing and retrieving
information on primary and secondary storage devices, displaying
information on an associated video display and, in some cases, performing
network operations.
By itself, the operating system generally provides only very basic
functions and must be accompanied by an "application" program. The
application program interacts with the operating system to provide much
higher level functionality and a direct interface with a user of the node.
During interactions with the operating system, the application program
typically invokes the utility procedures by issuing a series of parameter
requests, via standard local procedure calls, to the operating system
which then performs the request in accordance with the parameters. For
example, the application program may "call" the operating system to store
particular data on a computer disk memory or forward the data over the
network.
As noted, a significant function of each layer in the OSI model is to
provide services to the other layers. Two types of services offered by the
layers are "connection-oriented" and "connectionless" network services. In
a connection-oriented service, a source node establishes a connection with
a destination node and, after sending a message, terminates the
connection. The overhead associated with establishing the connection may
be unattractive for nodes requiring efficient communication performance.
For this latter case, a fully connectionless service is desirable where
each transmitted packet carries the full address of its destination
through the network.
A remote procedure call (RPC) establishes such a "connectionless session"
between a client node and a server node for execution of a specific
service. The RPC is typically embedded in software programs to make the
remote call appear "local" to the nodes. Client-server communication thus
takes the form of procedure calls and the network details are hidden from
the application program by placing them in local procedures called "stub"
procedures.
FIG. 3 illustrates a typical client-server system 300 wherein the client
and server nodes are schematically represented by dotted boxes 305 and
355, respectively. Resident in each node are application programs,
represented by boxes 302 and 352, and operating systems, represented by
boxes 306 and 356. Interactions between the application programs and
operating systems are illustrated schematically by the two-headed arrows
304 and 354. This dual program system is used on many types of computers
ranging from mainframes to personal computers.
In order to provide RPC functions, the application programs interact (as
shown schematically by arrows 308 and 318) with stub procedure software
310 and 360 by exchanging parameter requests. Each stub procedure, which
is generally associated with the operating system, arranges, i.e.,
"flattens", the parameters into a predetermined message format according
to the computer type. An RPC may transfer data or request a server to
perform an operation; accordingly, appropriate stub procedures must be
specifically designed in each node to invoke, or respond to, such actions.
Transport entities 314 and 364, i.e., the software within the transport
layers of the protocol stacks, interact with the stub procedures (as shown
schematically by arrows 312 and 362) to receive the messages, format them
into packets and pass them over the network channel 315 via network
adapters 316 and 366. These adapters incorporate the signal, electrical
and mechanical characteristics, and interchange circuits, needed to
interface with the network channel 315. The transport entities generally
provide reliable, cost-effective data transport between the client and
server, independent of the physical network channel.
To implement an RPC system, the application program 302 of the client 305
calls the stub procedure 310 by, inter alia, passing parameters in a
manner similar to passing parameters for a conventional procedure call.
The client stub procedure 310 flattens the parameters, which are passed to
the transport entity 314 for transmission to the server 355 as a data
packet. Since the RPC is a connectionless system, the transport entity
typically attaches a header to the packet prior to forwarding it to the
adapter 316 and onto the channel. When the packet arrives at the server,
the adapter 366 passes it to transport entity 364 and onto the server stub
procedure 360, which unflattens the parameters. The stub procedure 360
then calls the application program 352 and passes the parameters in a
conventional manner.
After completing its work, the application program 352 "returns" in a
manner that is conventional for local procedure calls, e.g., by returning
a result. The stub procedure 360 flattens the result into a message and
passes it to the transport entity 364, where a reply packet is formed and
transferred to the client 305 over the channel 315. Upon receiving the
reply packet, the transport entity 314 passes it to the client stub
procedure 310 for unflattening. Finally, the stub procedure returns the
reply parameters to the application program 302.
Clearly, the RPC system is a significant vehicle for providing distributed
services in a client-server system. However, as the types of services
available over networks proliferate, additional client-server systems are
needed to distribute those services. This will require development of RPC
software at both the client nodes, where the applications execute, and at
the servers, where the services are provided. In addition, as different
types of media are attached to the network, protocol stack software,
including transport entities, must be developed to enable communication
between the nodes. Previous attempts at implementing client-server systems
have resulted in manual code-writing to provide common RPC and transport
functions. In addition to being error-prone, the manually written code is
typically duplicated at each node, thereby representing costly and
inefficient use of software developer manpower.
The prior art is absent of an efficient way of performing object operations
in a broadcast fashion over a communication network and ensuring the
receipt and execution of the operation by each target of the broadcast.
SUMMARY OF THE INVENTION
Briefly, the invention resides in a novel object-oriented client-server
facility (CSF) interface and a networking service facility (NSF) interface
for implementing communication between application programs residing in
client and server nodes of a distributed services network. The CSF
interface includes remote procedure call (RPC) objects for invoking and
responding to service requests at the nodes, and application programming
interface (API) objects for transporting those requests between the nodes.
However, the API objects only provide communication transports within a
node. Accordingly, the API and RPC objects interact with
dynamically-configurable protocol stacks within the NSF interfaces to
complete the transport mechanism needed by an application program on the
client node when accessing services on a remote server node.
Specifically, the RPC objects comprise master/slave objects which, once
instantiated, provide high-level message delivery services. Each master
object can have any number of slave objects, although each slave object is
uniquely tied to one master object. Each slave object registers itself
with one master, and then receives messages from the master object. The
slave object then processes the message, and can return a reply. This
reply may be a normal or exceptional reply. Normal replies are not
forwarded to the master object, to minimize network usage. Exceptional
replies are returned to the master object for further processing. In this
way, the master object can immediately detect which slaves are
"up-to-date" (i.e., have processed all requests normally) and which have
registered an exception.
Further, a history of messages may be optionally maintained so that new
slaves, when they register, may be promptly brought up to date by the
master. Slave objects which lose their communication with the master can
also be brought up to date by a similar mechanism. A preferred embodiment
also includes networking transports so that messages are known to be
delivered reliably and in order of transmission. The system is suitable
for the delivery of large amounts of continuous data to a wide variety of
clients, such as occurs in multimedia and other dissemination-based
environments that are traditionally poorly served by connection-oriented
point-to-point protocols.
BRIEF DESCRIPTION OF THE DRAWINGS
The above and further advantages of the invention may be better understood
by referring to the following description in conjunction with the
accompanying drawings, in which:
FIG. 1 is a block diagram of a computer network including a collection of
nodes interconnected in a client-server system;
FIG. 2 is a schematic block diagram of prior art protocol stacks structured
according to the international standards organization OSI seven-layer
model and used to transmit data between a client node and a server node of
the system shown in FIG. 1;
FIG. 3 is a schematic illustration of a typical client-server system
showing the relationship between an operating system, an application
program, a stub procedure and transport layer software of the prior art
protocol stack for implementing a remote procedure call between the client
and server nodes;
FIG. 4 is a schematic block diagram of a client node on which a novel,
objected-oriented client-server facility (CSF) interface may be used;
FIG. 5 is a schematic block diagram of a server node on which the novel CSF
interface may be used;
FIG. 6 is a schematic block diagram of client-server system in which the
client and server nodes incorporate the object-oriented CSF interfaces and
NSF interfaces in accordance with the present invention;
FIG. 7 is a schematic block diagram depicting remote procedure call (RPC)
objects and application programming interface (API) objects of the CSF
interfaces which may be referenced by application programs executing on
client and server nodes;
FIG. 8 is a schematic block diagram of a novel, dynamically-configurable
protocol stack of the NSF interface;
FIG. 9 is a schematic block diagram of the illustrative RPC objects used to
interact with the CSF interface in accordance with the invention;
FIG. 10 is a schematic block diagram of the illustrative API objects used
to interact with the CSF interface in accordance with the invention;
FIG. 11 is a simplified class hierarchy diagram illustrating the base,
subclasses and associated classes involved in the construction of the API
objects of FIG. 10;
FIG. 12 is a schematic block diagram of a client node in which the
objectoriented CSF interface and NSF interface are utilized to configure a
data path prior to invoking an RPC service request;
FIG. 13 is an illustrative flow-chart of the sequence of steps involved in
configuring the data path of a client node prior to invoking an RPC
service request;
FIG. 14 is a schematic block diagram of client and server nodes in which
the object-oriented CSF interfaces and NSF interfaces are utilized to
invoke, and respond to, an RPC service request; and
FIGS. 15A & B are illustrative flow-charts of the sequence of steps
involved in invoking, and responding to, an RPC service request at client
and server nodes in accordance with a preferred embodiment.
DETAILED DESCRIPTION O THE ILLUSTRATIVE EMBODIMENTS
FIG. 4 illustrates a typical hardware configuration of a client node 400 in
accordance with the present invention. The client 400 is controlled by a
central processing unit 402, which may be a conventional microprocessor; a
number of other units, all interconnected via a system bus 408, are
provided to accomplish specific tasks. Although a particular client
computer may only have some of the units illustrated in FIG. 4 or may have
additional components not shown, most clients will include at least the
units shown. Specifically, client 400 includes a random access memory
(RAM) 406 for temporary storage of information, a read only memory (ROM)
404 for permanent storage of the computer's configuration and basic
operating commands and a network adapter 410 for connecting the client to
a transmission channel 450. A user interface adapter 416 is also provided
for connecting input devices, such as a keyboard 420, and other known
interface devices including mice, speakers and microphones to the bus 408.
Visual output is provided by a display adapter 418 which connects the bus
408 to a display device 422 such as a video monitor.
FIG. 5 illustrates a typical hardware configuration of a server node 500 in
accordance with the present invention. The server 500 has many of the same
units as employed in the client 400, including a CPU 502, a ROM 504, a RAM
506, a network adapter 510, an interface adapter 516 and a display adapter
518, each of which are interconnected by a system bus 508. In addition,
the server typically includes an input/output (I/O) adapter 550 for
connecting peripheral devices such as a secondary storage unit 513 and a
printer 514 to the bus 508, via cables 512 and 515, respectively.
The invention is preferably practiced in the context of client and server
nodes such as IBM PS/2 or Apple Macintosh computers. Moreover, the client
and server have resident thereon, and are controlled and coordinated by,
operating system software such as the Apple System/7 operating system. In
a preferred embodiment, the invention is implemented in the C++
programming language using object-oriented programming techniques. C++ is
a compiled language, that is, programs are written in a human-readable
script and this script is then provided to another program, called a
compiler, which generates a machine-readable numeric code that can be
loaded into, and directly executed by, a computer. As described below, the
C++ language has certain characteristics which allow a software developer
to easily use programs written by others while still providing a great
deal of control over the reuse of programs to prevent their destruction or
improper use. The C++ language is well-known and many articles and texts
are available which describe the language in detail. In addition, C++
compilers are commercially available from several vendors including
Borland International, Inc. and Microsoft Corporation. Accordingly, for
reasons of clarity, the details of the C++ language and the operation of
the C++ compiler will not be discussed further in detail herein.
As will be understood by those skilled in the art, Object-Oriented
Programming (OOP) techniques involve the definition, creation, use and
destruction of "objects". These objects are software entities comprising
data elements and routines, or functions, which manipulate the data
elements. The data and related functions are treated by the software as an
entity that can be created, used and deleted as if it were a single item.
Together, the data and functions enable objects to model virtually any
real-world entity in terms of its characteristics, which can be
represented by the data elements, and its behavior, which can be
represented by its data manipulation functions. In this way, objects can
model concrete things like people and computers, and they can also model
abstract concepts like numbers or geometrical designs.
Objects are defined by creating "classes" which are not objects themselves,
but which act as templates that instruct the compiler how to construct an
actual object. A class may, for example, specify the number and type of
data variables and the steps involved in the functions which manipulate
the data. An object is actually created in the program by means of a
special function called a "constructor" which uses the corresponding class
definition and additional information, such as arguments provided during
object creation, to construct the object. Likewise objects are destroyed
by a special function called a "destructor". Objects may be used by
manipulating their data and invoking their functions.
The principle benefits of object-oriented programming techniques arise out
of three basic principles; encapsulation, polymorphism and inheritance.
More specifically, objects can be designed to hide, or encapsulate, all,
or a portion of, the internal data structure and the internal functions.
More particularly, during program design, a program developer can define
objects in which all or some of the data variables and all or some of the
related functions are considered "private" or for use only by the object
itself. Other data or functions can be declared "public" or available for
use by other programs. Access to the private variables by other programs
can be controlled by defining public functions for an object which access
the object's private data. The public functions form a controlled and
consistent interface between the private data and the "outside" world. Any
attempt to write program code which directly accesses the private
variables causes the compiler to generate an error during program
compilation which error stops the compilation pro | | |
