One of the most prevalent aspects of today's technological environment is the spread of computer communications and, with it, the proliferation of distributed computing. Only rarely are new applications developed that depend solely upon their host computer. Much more often, applications are given the ability to reach out over communications networks to seek assistance from, or to take advantage of services provided by, other computers.
Capitalizing on the benefits offered by computer communications, specialized computers, called “servers,” exist primarily to provide computing services to other computers, called their “clients.” In client/server computing, clients request services from servers. While some services are provided to any client that requests them, other services require that a client authenticate its identity and its permission to use the service.
A server is built with the capacity to accommodate a certain number of simultaneous clients. To accommodate even more clients, and to increase the availability of services in the event that one server becomes unavailable, multiple servers are often configured to provide a common set of services.
With multiple servers providing the same services, the need arises for a mechanism to direct a given client to a particular server. It is administratively impractical for a client to be configured with all of the information it needs to choose an appropriate server. Instead, a client in search of a service provider queries a well known “name service.” Like the telephone yellow pages, the name service directs the client to a server that can provide the service requested by the client. Some name services direct an incoming client request to a server randomly selected from the set of servers that provide the requested service. Other name services select servers in a more deterministic, for example in a round robin, fashion.
These server selection mechanisms, while working well for some services, can prove to be inadequate for popular real-time communications (RTC) services. RTC services, such as audio or video delivery and telephony, usually involve the delivery of large amounts of bandwidth for extended periods of time. An RTC server (often called a “home server”) overloaded with too many clients can fail to deliver the requested bandwidth or can fail to meet delivery timing requirements: A packet of music arriving too late to be played in its proper place is less than worthless. Existing server selection mechanisms tend to overload some home servers while leaving others underutilized. In addition to not intelligently distributing load among the home servers, existing mechanisms, in the face of the failure of one home server, involve lengthy disruptions until the failed home server's clients are “rehomed” onto other servers.
USPTO Backgrounds
USPTO Backgrounds