Abstract:
A method for client-server interaction in a distributed computing environment. The computing environment may consist of a multiplicity of client computers, at least one server computer and a network connecting server and client computers. The server computer has some resources which the client computers need, alternatively the client computers run an application to request these resources. The client computers send requests for those resources to the server. The server aggregates those requests and dispatches the resource to the clients using a single multicast message. The server may check a threshold to determine if the threshold on server performance is exceeded. If the threshold is exceeded dispatches will be aggregated, however, if the threshold is not exceeded the request for the resource will be serviced immediately.

Description:
BACKGROUND OF THE INVENTION  
         [0001]    1. Field of the Invention  
           [0002]    The invention relates generally to computer software, and in particular to method for distributing resources in client-server system where a group of geographically distributed clients are connected to a common server using a computer network.  
           [0003]    2. Description of Prior Art  
           [0004]    With the popularity of the Internet on the rise, client-server applications are being used by millions of people every day to perform various transactions in cyberspace. Such applications range from collaborative applications to e-commerce applications such as Internet auctions. Many client-server applications such as remote presentation and online auctions are inherently bursty, i.e., a burst of client requests arrive in the server simultaneously. For example, in a remote presentation application with a shared foil viewer, whenever a foil is flipped, all the clients request the server for the next foil at the same time. A similar behavior can be observed in auction applications, when a new item is being shown to the clients. One of the technical challenges in building such applications is performance and scalability of the server, and effective use of network bandwidth in presence of such bursts of client requests.  
         SUMMARY OF THE INVENTION  
         [0005]    The objective of the present invention is to reduce the amount of work performed by a server when a request for an arbitrary server resource is simultaneously initiated from multiple client locations.  
           [0006]    This invention provides support for an efficient and scalable protocol between a client and the server in the presence of bursty requests initiated from multiple client locations in wide-area distributed environments such as the Internet.  
           [0007]    The computing environment for utilizing the present invention, may consist of at least one server computer connected by a network, such as the Internet, to a multitude of client computers. The server computer having some resources which client computers need. Client computers execute an application to request client resources. Those requests for server resources are sent over the network to the server.  
           [0008]    According to the inventive method, an application on a client computer determines what resources will be necessary for that client in the future and initiates a request for that resource by requesting that resource from the server. This application is configurable by defining values of parameters including a cache size, a network bandwidth, a sequence of requests, and an average time between successive requests.  
           [0009]    The server aggregates client requests before dispatching the resource. The aggregation of requests routine of the present invention, makes use of parameters including maximum number of aggregate requests pending at a given time, maximum number of individual clients in any aggregate request, maximum time period before completion of building of an aggregate request. The aggregation of requests can be configured by providing values to these parameters. The aggregation of requests routine also logs data on individual requests received and on aggregate requests. After aggregating requests, the resource is simultaneously sent to all requesting clients using a single multicast message.  
           [0010]    After the requested resource is received by the client computer, an inventive caching routine is used. The caching routine of the present invention has a garbage collection policy for reclaiming storage space used for storing resources that are no longer needed.  
           [0011]    In another embodiment, the aggregation of requests is scalable. The server may check a threshold to determine if the threshold on server performance is exceeded. If the threshold is exceeded dispatches will be aggregated, however, if the threshold is not exceeded the request for the resource will be serviced immediately. The threshold value may be scalably adjusted. 
       
    
    
     BRIEF DESCRIPTION OF DRAWINGS  
       [0012]    The foregoing objects and advantages of the present invention may be more readily understood by one skilled in the art with reference being had to the following detailed description of a preferred embodiment thereof, taken in conjunction with the accompanying drawings wherein like elements are designated by identical reference numerals throughout the several views, and in which:  
         [0013]    [0013]FIG. 1 is an example of a system having features of the present invention;  
         [0014]    [0014]FIG. 2 depicts data structures for a cache and a cache allocation table;  
         [0015]    [0015]FIG. 3 depicts data structure for a resource list;  
         [0016]    [0016]FIGS. 4 and 5 are a flowchart of steps for pre-fetch of resources;  
         [0017]    [0017]FIG. 6 is a flowchart of steps for requesting a resource on a client computer;  
         [0018]    [0018]FIG. 7 is a flowchart of steps for receiving a resource on a client computer;  
         [0019]    [0019]FIG. 8 is a flowchart of steps for aggregating requests from multiple client computers for same resource;  
         [0020]    [0020]FIG. 9 is a flowchart of steps for closing an aggregate request and servicing the request using a multicast message; and  
         [0021]    [0021]FIG. 10 is an example of a scalable embodiment of the present invention using a threshold to aggregate requests. 
     
    
     DETAILED DESCRIPTION OF THE INVENTION  
       [0022]    [0022]FIG. 1 shows the system of the present invention having a local client site  100 , one or more remote client sites  170  and a server  120 , all connected using a network  113 . The network is used to communicate messages between clients and servers using a network specific protocol, e.g., the TCP/IP protocol is used when the Internet is used as the network.  
         [0023]    The server  120  can be either a client machine running the server or a dedicated server machine comprising an aggregation and dispatch module  160 . Module  160  aggregates client requests received during a specific time interval. FIG. 10 shows the process flow diagram of the server  120  (FIG. 1). In a scalable embodiment of the invention, once a request for a resource is received at step  1010 , a check is made at step  1020 , to determine if a threshold on server performance is exceeded. For example, a typical threshold may be defined as the server work load being above ninety percent of server capacity. If the threshold is exceeded, at step  1030  the request is forwarded to the aggregation and dispatch module  160  (FIG. 1). Otherwise, at step  1040  the request is serviced immediately. Aggregated requests are serviced as soon as certain conditions are met. As shown in FIG. 1, each client site,  100 ,  170  includes an operating system layer  101 ,  101 ′, a middleware layer  102 ,  102 ′, and an application layer  103 ,  103 ′. The operating system layer  101 ,  101 ′ can be any available computer operating system such as AIX, Windows 95, Windows NT, SUN OS, Solaris, and MVS. The middleware layer implements domain specific system infrastructures on which applications can be developed. The application layer includes client-server application components  105 ,  105 ′. These applications are programmed using the services provided by a pre-fetching and caching module (PCM)  110 ,  110 ′, and a client request receiver module (CRR)  109 ,  109 ′. Both the PCM  110 ,  110 ′ and the CRR  109 ,  109 ′ can belong to the middleware layer  102 ,  102 ′ or the application layer  103 ,  103 ′. An application  105 ,  105 ′ uses the support of the PCM module  110 ,  110 ′ to initiate a request for a resource to a server before the resource is really needed. The CRR module  109 ,  109 ′ is used to manage a request for a resource to an appropriate server  120 .  
         [0024]    Pre-fetching and Caching  
         [0025]    [0025]FIG. 3 shows a client maintained list of resources called Resource List  300 . The Resource List  300  contains resources in the order they are likely to be needed by an application  105 ,  105 ′ (FIG. 1). Each resource has a unique resource number  301 , a universal resource locator (URL)  302 . Further Resource List  300  has a slot  303  for storing the status of each resource which may be one listed as available, requested, and not in cache.  
         [0026]    [0026]FIG. 2 shows a cache  250 , provided in each client computer  100 ,  170  (FIG. 1), to store resources that are pre-fetched for a later use by an application  105 ,  105 ′ (FIG. 1). A cache allocation table  200  is implemented for each cache  250  that holds a list of resources currently in cache  250 . For each resource  201  in cache  250 , a starting address  202  and a size  203  are stored as well. Steps for computing whether there is enough contiguous space to hold a resource of a given size, may utilize the data provided in the cache allocation table  200 .  
         [0027]    The Server of the present invention aggregates requests received during a time interval, and will not reply to the requests until the end of that time interval. Therefore, it is more likely that the latency seen by the client systems would increase. The PCM module  110  (FIG. 1) alleviates the problem of requesting resources before they are really needed by the application by pre-fetching resources. It is desirable to cache as many resources as possible. However, the amount of memory available for storing these resources is limited. Therefore, the pre-fetch steps initiate a request for a new resource whenever there is enough unused memory in the resource cache.  
         [0028]    [0028]FIGS. 4 and 5 show a flowchart of steps for pre-fetching resources implemented in the PCM module  110 ,  110 ′ (FIG. 1). First, as shown in FIG. 4, the size of the available cache, cacheSize, and a list of resources, resourceList, are read and cacheSize bytes of memory to be used as cache are obtained at step  410 . Application  105 ,  105 ′ (FIG. 1) updates a common currentUsed variable with the resource number currently in use. Working variables currentReq, currentUsed, cacheLow, cacheHigh, cacheAlloc, and sentList are initialized at step  420 . A request for the very first resource is initiated in step  430 .  
         [0029]    [0029]FIG. 5 shows the continuation of the PCM module  110 ,  110 ′ (FIG. 1) flow started in FIG. 4. A loop is initiated at step  510 . At steps  520  a test determines if the cache is full. If it is, the control passes to step  570 . Otherwise, currentReq variable is incremented at step  530  and a test is performed at step  540  to determine if the resource is either in cache or in sentList. If the resource is in cache or in sentList the control is transferred to step  570 . Otherwise, at step  550  the next resource is requested.  
         [0030]    The sentList is traversed at step  560 , and a test is performed at step  570  to determine if there are more elements in sentList. If there are no more elements, the control is passed to step  595  where all resource numbers in cache that are less than currentUsed, are released after which the program is terminated. Otherwise, at step  580  a test is performed to determine if the resource exists in cache. If the resource does not exist, the control returns to step  570  for further processing. Each resource number in the sentList that also exists in cache is removed from the sentList at step  590 , and the control is once again returned to step  570 .  
         [0031]    Client Request-Receive  
         [0032]    [0032]FIG. 6 shows a flowchart for requesting a resource. At step  610 , a message is prepared containing information about the resource requested from a server. The message is then sent, at step  620 , to the appropriate server specified in the URL for the resource. At step  630 , the status of the resource is updated to requested in resourceList  300  (FIG. 3), after which the program is terminated.  
         [0033]    [0033]FIG. 7 shows a flowchart for receiving a resource in CRR module  109 ,  109 ′ (FIG. 1). A resource X from a server Y is received at step  710 . The starting address in cache for storing the resource X is found at step  720  and at step  730  the resource is stored in cache. At step  740 , the status of the resource X is updated to available.  
         [0034]    Server Aggregation and Dispatch  
         [0035]    [0035]FIG. 8 shows a flowchart for aggregation and dispatch module  160  (FIG. 1) for aggregating requests received for same resource. A number of working variables, e.g., maxActiveResources, timeinterval, maxRecipients, ActiveResourceList, and numActiveResources are initialized in step  810 . A loop is initialized in step  820 . After a request for resource X is received from client R at step  830 , a test is performed at step  840  to determine if X is an active resource. If X is an active resource then client R is added to the target list of resource X at step  850  and the control returns to the top of the loop at step  820 . Otherwise, a test is made at step  860  to determine if the number of active resources, numActiveResources is less then the maximum number of active resources, maxActiveResources. If the number of active resources is less then the maximum number of active resources then the resource X is made an active resource at step  870 , and the control returns to the top of the loop at step  820 . However, if the number of active resources is equal to, or exceeds the maximum number of active resources then, at step  880 , resource X is sent to client X immediately, after which the control returns to the top of the loop at step  820 .  
         [0036]    [0036]FIG. 9 shows a flowchart of a routine in an aggregation and dispatch module  160  for dispatching a resource to the list of targets in an aggregate request using a single multicast message. An instance of this routine is running for each active resource X. Initialization of variables and the reading of the ActiveResource is performed at step  910 . A loop at Step  920  will repeat while resource X is active, if the resource is not active the program will terminate. Time elapsed since the time first target client is added, elapsedTime is computed at step  930 . A test at step  940  determines whether the elapsed time is greater than the time-out interval. If it is, at step  960  resource X is sent to each client in the target list and is made not active. At this point the control of the program passes to step  920 , and the loop repeats. If at step  940  the elapsed time is less than or equal to the time-out interval, then a test at step  950  determines whether the number of targets is larger than or equal to maximum limit of targets. If it is not, the control of the program passes to step  920 , and the loop repeats. However, if the number of targets is larger than or equal to maximum limit of targets the control passes to step  960  and the processing as described above is performed.  
         [0037]    While the invention has been particularly shown and described with respect to illustrative and preferred embodiments thereof, it will be understood by those skilled in the art that the foregoing and other changes in form and details may be made therein without departing from the spirit and scope of the invention that should be limited only by the scope of the appended claims.