METHOD AND SYSTEM FOR DELAYED ALLOCATION OF RESOURCES
The present invention allows a server to delay allocating resources to a client's request. When the client requests a feature that requires server resources, the server accepts and acknowledges the client's request, but the client is prohibited from using the requested feature until further notice from the server. For example, during an authorization process, the server allocates only the minimum resources required to maintain the session and to authorize the client. Thereafter, the server allocates the resources necessary to support the client's request only when the resources become available. Until then, the server maintains the communications session without supporting the request. Thus, the server shepherds its resources rather than committing them at the whim of a client. Also, a client need not repeat its request if the server cannot immediately satisfy it; instead, the server accepts the request and then later begins to support it when adequate resources become available.
Latest Microsoft Patents:
- CACHE SERVICE FOR PROVIDING ACCESS TO SECRETS IN CONTAINERIZED CLOUD-COMPUTING ENVIRONMENT
- SELECTIVE JUST-IN-TIME TRANSCODING
- FAN-IN AND FAN-OUT ARCHITECTURE FOR SUPPLY CHAIN TRACEABILITY
- Personalized Branding with Prompt Adaptation in Large Language Models and Visual Language Models
- HIGHLIGHTING EXPRESSIVE PARTICIPANTS IN AN ONLINE MEETING
The present application claims the benefit of U.S. Provisional Patent Application 60/451,151, filed on Feb. 28, 2003, which is incorporated herein in its entirety by reference.
TECHNICAL FIELDThe invention relates generally to network communications and, more particularly, to allocating resources among clients and servers on a network.
BACKGROUND OF THE INVENTIONThe rapid growth of computer networks, both public and private, in recent years has been spurred, in large part, by “client/server computing.” In this model, one computing device, the client, requests that another computing device, the server, provide services or features to it. Note that “client” and “server” are used solely to denote the parties in a request transaction. While some computing devices are implemented as dedicated servers that can serve multiple clients, a client and a server can switch roles from one transaction to another. In a “peer-to-peer” network (common, for example, among devices communicating via short range radio), every computing device has the potential to be both a client and a server, serially or simultaneously.
Servers often have to allocate precious resources to fulfill a request for a feature or for a service. Upon receiving a request from a client, a server checks the availability of its resources. Traditionally, if the server does not have the resources to fulfill the request, then the server rejects the request. If the client can proceed without the requested feature or service, then it does so and resubmits the request later, at which time the server may have the necessary resources available to fulfill the request.
In order to ensure that precious server resources are dedicated only to those clients authorized to use them, servers often check the identity of a client making a request. If the client cannot authenticate itself to the satisfaction of the server, then the server rejects the request.
This protection against unauthorized clients is not perfect, however. Some types of requests are made before the authorization process is complete. Processing these requests, even if they are ultimately rejected, consumes some level of server resources. For example, a nefarious client could bring a “denial of service” (DOS) attack against a server by repeatedly making requests of the server. Although this client will fail to authenticate itself and its requests will ultimately be rejected, the server may in the mean time utilize so many resources attempting to authenticate the client during each request that the server exhausts its resource pool until the server is rendered incapable of fulfilling any requests, even those made by authorized clients.
SUMMARY OF THE INVENTIONIn view of the foregoing, the present invention allows a server to delay allocating resources to a client's request. When the client requests a service or a feature that requires server resources (such as, for example, encryption or compression of the messages between the client and the server), the server accepts and acknowledges the client's request, but the client is prohibited from using the requested feature until further notice from the server. For example, during an authorization process, the server allocates only the minimum resources required to maintain the session and to authorize the client. Thereafter, the server allocates the resources necessary to support the client's request only when the resources become available. Until then, the server maintains the communications session without supporting the request. Thus, the server shepherds its resources rather than committing them at the whim of a potentially malicious, malfunctioning, or misconfigured client. Also, a legitimate client need not repeat its request if the server cannot immediately satisfy it; instead, the server accepts the request and then later begins to support it when adequate resources become available.
According to one embodiment, after receiving a request for data compression from a client, the server accepts and acknowledges the request but delays allocating the resources necessary to compress communications data. Indeed, the server might not even check to see whether resources are available until the client has successfully authenticated itself to the server. Even though the compression request has been accepted, the client and server communicate without compressing their data. This continues until, and if, the resources necessary for compression become available on the server. At that time, the server allocates the necessary resources and indicates to the client that compression is now supported. The server can signal this by, for example, sending compressed data to the client. Upon receiving the signal (e.g., the compressed data), the client realizes that it is now permitted to communicate with compression. The client responds by beginning to transmit compressed data to the server.
Compression is just one example of a communications feature that can be requested by a client. Other examples include the wide range of features commonly called Quality of Service (QOS). QOS features include, generally, bandwidth, response time guarantees, immunity to error, integrity of message sequence and lack of duplication, maximum permissible loss rates, and the like. QOS features provide examples where, in keeping with one embodiment of the present invention, the server can allocate resources level by level rather than all at once. For example, the client requests a great amount of guaranteed bandwidth. The server initially accepts the request but allocates resources sufficient to support only a low amount of guaranteed bandwidth. The client recognizes this and uses only the low amount of bandwidth. Later, the server allocates more bandwidth to this client (in response, for example, to another client releasing bandwidth), and the client begins to use the greater bandwidth amount.
Also in keeping with the invention, a server or a client (or both) maintains information about the requested feature and about the actual level of service being supported. The server monitors this information for each client and allocates additional resources to the clients as resources become available in order to more fully support the clients' requests.
A client can display to its user the status of requests as accepted and supported, accepted but not yet supported, and rejected. The server can provide similar information to an administrator or to a log file.
While the appended claims set forth the features of the present invention with particularity, the invention, together with its objects and advantages, may be best understood from the following detailed description taken in conjunction with the accompanying drawings of which:
Turning to the drawings, wherein like reference numerals refer to like elements, the present invention is illustrated as being implemented in a suitable computing environment. The following description is based on embodiments of the invention and should not be taken as limiting the invention with regard to alternative embodiments that are not explicitly described herein.
In the description that follows, the present invention is described with reference to acts and symbolic representations of operations that are performed by one or more computing devices, unless indicated otherwise. As such, it will be understood that such acts and operations, which are at times referred to as being computer-executed, include the manipulation by the processing unit of the computing device of electrical signals representing data in a structured form. This manipulation transforms the data or maintains them at locations in the memory system of the computing device, which reconfigures or otherwise alters the operation of the device in a manner well understood by those skilled in the art. The data structures, where data are maintained, are physical locations of the memory that have particular properties defined by the format of the data. However, while the invention is being described in the foregoing context, it is not meant to be limiting as those of skill in the art will appreciate that various of the acts and operations described hereinafter may also be implemented in hardware.
The present invention allows a server to accept a client request but to delay allocating the resources necessary to support that request.
In another transaction, the client 104 and the server 102 can switch roles with the “server” 102 requesting a service from the “client” 104. In a peer-to-peer network, every computing device can be both a client and a server, serially or simultaneously. Accordingly, embodiments of the invention can be practiced on clients, servers, peers, or any combinations thereof.
The computing device 110 is another server but one that only directly communicates with the server 102 to provide resources to it. Its presence illustrates that by following the methods of the present invention, the server 102 shepherds not just its own resources but the resources of the networking environment 100 generally.
The computing devices 102 and 104 of
In step 302, the server 102 receives the feature request and decides whether it will support that feature. If not, then the server 102 uses the methods defined in the protocol to reject the request (not shown). If the server 102 will support the requested feature and is ready to do so immediately, then the server 102 allocates the resources needed to support the feature and accepts the request (also not shown). The scenario depicted in
There are numerous ways in which the server 102 can indicate that the requested feature is not yet supported. In SIP, for example, when data compression is allowed on a communications link, “tags” are added to the data fields. (See
In steps 306 and 308, the client 104 and the server 102 communicate without using the requested feature. Depending upon circumstances, these steps can continue for a long time (until, e.g., the server 102 acquires the necessary resources) or can be very short (e.g., only until the client 104 successfully authenticates itself to the server 102).
Steps 310 and 312 of
Finally, in step 314 the server 102 decides to allocate the resources to support the client 104's request. In step 316, the server 102 indicates to the client 104 that the feature is now supported. Just as with the numerous possible indications discussed above with respect to step 302, there are numerous ways in which the server 102 can indicate that the feature is now supported. Using the data compression example, the server 102 can simply send compressed data to the client 104. Upon receiving the indication, whatever it is, the client 104 notes that the feature is now supported in step 318. From that point on, the client 104 and the server 102 can communicate either using or not using the requested feature, as appropriate to the situation.
In some embodiments, there are at least three types of data packets: (1) untagged data indicating that data compression is not available for the current connection; (2) data tagged indicating that compression is possible, but the data in field 408 are flagged as not compressed; and (3) data tagged indicating that compression is possible, and the data in field 408 are compressed. In steps 304 and 318 of
A flowchart illustrating exemplary steps performed by the server 102 is shown in
If the server 102 could, at least theoretically, support the requested feature, then in step 504 it accepts the request but tells the client 104 that the client 104 may not yet use the feature.
There are some features that the server 102 will only provide to authenticated clients. If the client 104 has requested such a feature, then in step 506 an authentication process is carried out. If the client 104 fails the authentication in step 508, then the server 102 can reject the request in step 510, even though it provisionally accepted the request earlier in step 504. Note that an authentication failure does not necessarily imply that the client 104 must terminate its communications session with the server 102. While that is a possible outcome, for the present discussion, the consequence of an authentication failure is the client 104's inability to use the requested feature.
If the client 104 successfully authenticates itself to the server 102 (or if such authentication is not necessary), then the client 104 and the server 102 begin to communicate with each other but without using the requested feature. If necessary, the server 102 checks for the availability of sufficient resources in step 512 and when, in step 514 of
In step 516 of
Throughout this procedure, the server 102 tracks its resource levels and allocations, as indicated in step 518. The server 102 uses this information when deciding whether it has sufficient resources to support a requested feature. System administrators use this information when deciding whether the server 102 is optimally configured.
In step 520 of
Another use of the server 102's resource allocation log 600 is illustrated in step 522. Here, some resources are freed up (probably from another client), and the server 102 checks its resource allocation log 600. It notes, for example, that the client 108 requested 512 kbps of guaranteed bandwidth but was only granted 128 kbps. If the server 102 can and wishes to support the client 108's request at a higher level, it can now do so. For some features, the server 102 can even use this method to reduce its level of support. Other features do not allow for this, and the level of support must be renegotiated.
The client 104's side of a feature request transaction is illustrated in the flowchart of
The above discussion focuses on the expected course of an exchange between the server 102 and the client 104. The following table illustrates some of the unexpected things that can occur and how the client 104 should react.
In view of the many possible embodiments to which the principles of the present invention may be applied, it should be recognized that the embodiments described herein with respect to the drawing figures are meant to be illustrative only and should not be taken as limiting the scope of the invention. For example, those of skill in the art will recognize that the illustrated embodiments can be modified in arrangement and detail without departing from the spirit of the invention. Although the invention is described in terms of software modules or components, those skilled in the art will recognize that such may be equivalently replaced by hardware components. Therefore, the invention as described herein contemplates all such embodiments as may come within the scope of the following claims and equivalents thereof.
Claims
1-43. (canceled)
44. A method performed by a server to delay supporting a feature for a client until the client is authenticated, the method comprising:
- receiving from the client a request to use the feature;
- after receiving the request to use the feature, sending to the client an indication that the feature is not yet supported; and
- after sending to the client the indication that the feature is not yet supported, determining whether the client is authenticated; upon determining that that client is not authenticated, suppressing allocation of resources to support the feature; and upon determining that that client is authenticated, allocating resources to support the feature; and sending to the client an indication that the feature is now supported.
45. The method of claim 44 wherein the sending to the client an indication that the feature is not yet supported includes indicating that the request is granted.
46. The method of claim 44 including upon determining that the client cannot be authenticated, sending to the client an indication that the client is not authenticated.
47. The method of claim 44 including upon determining that the client can be authenticated, sending to the client an indication that the client is authenticated.
48. The method of claim 44 wherein the received request to use the features indicates a first level of support, and wherein the indication sent to the client that the feature is now supported indicates that the feature is supported at a second level of support.
49. The method of claim 48 wherein the second level of support is less than the first level of support.
50. The method of claim 49 further comprising after sending to the client the indication that the feature is supported at the second level of support, sending to the client an indication that the feature is supported at the first level of support.
51. The method of claim 44 wherein the feature is selected from the group consisting of compression, a quality of service, bandwidth, a response time guarantee, immunity to error, integrity of message sequence and lack of duplication, and a maximum permissible loss rate.
52. A computer-readable storage device storing computer-executable instructions for controlling a client to obtain support from a server for a feature, by a method comprising:
- sending to the server authentication information of the client;
- sending to the server a request to use the feature; and
- after sending to the server the request to use the feature, receiving from the server an indication that the feature is not yet supported; and after receiving from the server the indication that the feature is not yet supported, refraining from using the feature until receiving from the server an indication that the feature is now supported.
53. The computer-readable storage device of claim 52 wherein the receiving from the server of the indication that the feature is not yet supported includes receiving an indication that the request is granted.
54. The computer-readable storage device of claim 52 including receiving from the server an indication that the client is not authenticated when the server is unable to authenticate the client based on the authentication information of the client.
55. The computer-readable storage device of claim 52 including receiving from the server an indication that the feature is now supported and after receiving the indication that the feature is now supported, using the feature.
56. The computer-readable storage device of claim 52 wherein the sent request to use the feature indicates a first level of support, and the received indication that the feature is now supported indicates a second level of support of the feature that is less than the first level of support.
57. The computer-readable storage device of claim 56 after receiving the indication that the feature is supported at the second level of support, receiving from the server indication that the feature is supported at the first level of support.
58. The computer-readable storage device of claim 52 wherein the feature is selected from the group consisting of compression, a quality of service, bandwidth, a response time guarantee, immunity to error, integrity of message sequence and lack of duplication, and a maximum permissible loss rate.
59. A server that delays allocating resources for a feature requested by a client until the client is authenticated, the method comprising:
- a memory storing computer-executable instructions of: a component that receives from the client a request to use the feature and authentication information of the client; a component that, after receiving the request to use the feature, sends to the client an indication that the request is granted but that the feature is not yet supported so that the client will refrain from using the feature until the client is sent an indication that the feature is now supported; and a component that, after sending to the client the indication that the feature is not yet supported, when the client cannot be authenticated based on the received authentication information, suppresses allocation of the feature; and when the client is authenticated based on the received authentication information, allocates resources to support the feature; and sends to the client an indication that the feature is now supported; and a processor that executes the computer-readable instructions stored in memory.
60. The server of claim 59 including a component that, when the client cannot be authenticated based on the received authentication information, sends to the client an indication that the client is not authenticated.
61. The server of claim 59 wherein the received request to use the feature indicates a first level of support of the feature, and wherein the indication sent to the client indicating that the feature is not yet supported indicates that the feature is supported at a second level of support.
62. The server of claim 61 further comprising after sending to the client the indication that the feature is supported at the second level of support, sending to the client an indication that the feature is now supported at the first level of support.
63. The server of claim 62 wherein the feature is selected from the group consisting of compression, a quality of service, bandwidth, a response time guarantee, immunity to error, integrity of message sequence and lack of duplication, and a maximum permissible loss rate.
Type: Application
Filed: Dec 1, 2011
Publication Date: Mar 29, 2012
Applicant: Microsoft Corporation (Redmond, WA)
Inventors: Mark Markaryan (Seattle, WA), Dmitry M. Kakurin (Redmond, WA), Sean C. Olson (Kirkland, WA), Srikanth Shoroff (Sammamish, WA), Radu Ionescu (Redmond, WA)
Application Number: 13/309,331