Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1996-06-26
2001-04-03
Banankhah, Majid A. (Department: 2151)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C709S241000
Reexamination Certificate
active
06212573
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of Invention
The present invention relates to the fields of distributed object computing systems, client-server computing, and object-oriented programming. More particularly, the invention relates to methods and devices for servicing requests received by a server in a distributed object system.
2. Description of Prior Art
A computing environment in which objects located on different computers are linked by a network is typically referred to as a client-server computing environment. Some of the objects act as providers of services or functionality to other objects. Others of the objects or entities act as consumers of services or functionalities. The client-server model may also be generalized to the case where distinct programs running on the same computer communicate with one another through some protected mechanism and act both as providers and consumers of a service or functionality. Thus, distributed objects may exist anywhere in a network, as for example in the address space of the client, in multiple address spaces on the client machine, and in multiple machines across the network.
Attempts to provide such a distributed system have been made using object-oriented methodologies that are based upon a client-server model in which server objects provide interfaces to client objects that make requests of the server objects. Typically, in such a distributed system, the servers are objects consisting of data and associated methods. The client objects obtain access to the functionalities of the server objects by executing calls on them, which calls are mediated by the distributed system through an Object Request Broker (ORB) which is used to locate the various distributed objects and to establish communications between objects. When the server object receives a call, it executes the appropriate method and transmits the result back to the client object.
The software industry has responded to the need for a distributed object technology by forming the Object Management Group (OMG). The goal of the OMG is to define the Object Management Architecture (OMA), which has four major components: the Object Request Broker (ORB), Object Services, Common Facilities, and Application Objects. The Object Request Broker provides basic object communications and management services, thereby forming the basis of a distributed object system. A standard for an Object Request Broker is contained in the Common Object Request Broker Architecture (CORBA) specification.
In a distributed object system, a client may initiate a connection with a server. The connection established is a “line,” i.e. a communications pathway, through which the client and the server may communicate. A line may be established between any pair of processes; however, the number of lines allowed between a client and a server is limited. As such, requests and replies between a client and a server may be multiplexed to enable the use of only one line between a given client-server pair. That is, a single line may be used for multiple requests and replies.
On the server side of a distributed object system which handles multiplexed requests and replies, threads are often used to service requests. Threads may be thought of as “sketch pads” of storage resources. In other words, threads are portions of memory which are allocated to hold execution states. To an operating system, all threads appear to be the same. However, the logic assigned by a programmer, i.e. the responsibilities assigned to a particular thread, for each thread are typically different. For a typical client-server pair which processes multiplexed requests, a single listener, or collector, thread on each end point or port on the server side is assigned the task of “listening” for requests. That is, the “listener” thread monitors the lines between the client-server pair and awaits requests to be made. Once the listener thread collects a request, it passes the request to an appropriate “worker” thread, or non-listener thread which is associated with the same connection as the listener thread, that services the request and returns the results of the service to the client. Each worker thread is assigned a specific task, and the listener thread routes requests to the appropriate worker thread for the request. The passing of a request from the listener thread to a worker thread is known as a “context switch.” A context switch requires the operating system to save the execution state of the thread which is currently running, and to restore the thread which is scheduled to run next. In typical distributed object systems, at least one context switch is required on the server side to route a request for service from the listener thread to the appropriate worker thread for the request.
The configuration of the threads on the client side of a distributed object system is similar to the architecture of the threads on the server side. On the client side, after a request has been sent to the server side, a single listener thread listens for responses, or replies, on the connection to be sent from the server side. Once a response is received by the listener thread, the listener thread passes the response to the appropriate caller thread. The caller thread is the thread that initiated the object invocation or request. It blocks until a reply has been received. As before, the act of a listener thread passing a response to an appropriate caller thread is known as a context switch. In typical distributed object systems, the client side requires at least one context switch.
Neither the listener thread on the client side nor the listener thread on the server side processes any requests or responses. As such, the number of context switches in a client-server pair is at least two when a response is required from the server, i.e. there is one context switch on the server side when a request is received, and there is one context switch on the client side when a response is received. It follows that the minimum number of context switches in a client-server pair is one; this minimum number occurs when a response from the server is not required once a request is received or processed. Due to the fact that the computing overhead associated with context switches is typically high, it would be desirable to develop a method which reduces the minimum number of context switches in a client-server pair to zero. A reduction in the minimum number of context switches would reduce the amount of computing overhead and, more importantly, the latency associated with processing requests, thereby improving the overall efficiency of a distributed object computing system.
SUMMARY OF THE INVENTION
To achieve the foregoing and other objects and in accordance with the purpose of the present invention, data structures, methods and devices for reducing computing overhead by utilizing threads which are effective to both listen for and service requests in a distributed client/server based object oriented operating system are disclosed.
In one aspect of the invention, a method of processing a request for service from a client, involves listening for a request using a first server side thread which is effective for listening for requests for new connections, listening for new requests for services, and processing requests for services on a connection, reading the header of the request using the first server side thread, determining whether the first server side thread is effective for processing the request, and servicing the request. In one embodiment, if it is determined that the first server side thread is ineffective for processing the request, then the request is dispatched to a second server side thread, also with the capability of both listening for requests and servicing requests, which is appropriate for servicing the request when the first server side thread is determined to be ineffective for processing the request.
In another aspect of the invention, a client writes a request for service on a connection between the client and a server using a first client side thread which is eff
Cavanaugh, III Ken M.
Garg Rohit
Lim Swee Boon
Banankhah Majid A.
Beyer Weaver & Thomas LLP
Caldwell P. G.
Sun Microsystems Inc.
LandOfFree
Mechanism for invoking and servicing multiplexed messages... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Mechanism for invoking and servicing multiplexed messages..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Mechanism for invoking and servicing multiplexed messages... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2506572