Search Images Maps Play YouTube News Gmail Drive More »
Sign in
Screen reader users: click this link for accessible mode. Accessible mode has the same essential features but works better with your reader.

Patents

  1. Advanced Patent Search
Publication numberWO2002025463 A1
Publication typeApplication
Application numberPCT/US2001/029524
Publication date28 Mar 2002
Filing date19 Sep 2001
Priority date19 Sep 2000
Also published asEP1327195A1
Publication numberPCT/2001/29524, PCT/US/1/029524, PCT/US/1/29524, PCT/US/2001/029524, PCT/US/2001/29524, PCT/US1/029524, PCT/US1/29524, PCT/US1029524, PCT/US129524, PCT/US2001/029524, PCT/US2001/29524, PCT/US2001029524, PCT/US200129524, WO 0225463 A1, WO 0225463A1, WO 2002/025463 A1, WO 2002025463 A1, WO 2002025463A1, WO-A1-0225463, WO-A1-2002025463, WO0225463 A1, WO0225463A1, WO2002/025463A1, WO2002025463 A1, WO2002025463A1
InventorsAntonio Salerno
ApplicantConxion Corporation
Export CitationBiBTeX, EndNote, RefMan
External Links: Patentscope, Espacenet
Method and apparatus for dynamic determination of optimum connection of a client to content servers
WO 2002025463 A1
Abstract
The method and apparatus of the present invention provide dynamic routing selection of the optimum data server from among many data servers (130, 300) that form a distributed content cache on a communications network (100). A user client (110, 120) enters a request by one of several addressing protocols (112, 120). The method of the invention uses a combination of analytical tools to act upon information contained in the request to determine which of the many distributed content data servers will provide the optimum connection for the user client. Criteria used to make the selection include the type of request, the shortest.
Claims  (OCR text may contain errors)
What is claimed is:
1. A method of providing dynamic determination of an optimal content server to service a request from a remote user terminal, comprising: receiving a request from a remote user teπninal, said request containing request data and protocol data; updating a network status data table using said protocol data; determining a request type based upon said request data; comparing said request type to content server selection criteria contained in a network status data table; choosing an optimal content server based upon said request type and said content server selection criteria; and communicating information defining said optimal content server to said remote user terminal.
2. The method of Claim 1 wherein said determining step comprises the steps of: parsing said request data; characterizing said request data in accordance with request types maintained in an application/configuration table; forming an optimal content server query; and sending said optimal content server query to a content server node decision module.
3. The method of claim 2 wherein said characterizing step includes the step of characterizing said request data in accordance with requests types including Hypertext Transfer Protocol requests, Hypertext Markup Language requests, and Dynamic Name Server requests.
4. The method of claim 1 wherein said updating step includes updating said network status data table with Border Gateway Protocol data.
5. The method of claim 1 wherein said choosing step includes the step of choosing an optimal content server based upon said request type and content server selection criteria including updated network status, updated network communications bandwidth, user geographic data, and content server geographic data.
6. A computer readable memory to direct a digital device to function in a specified manner, comprising: a redirector agent program including a front end processor module, an application/ configuration data table module, and a node decision server interface module, said redirector agent program identifying a user request type and an optimal server query to process a user request; and a connection decision program including a protocol data table module, a protocol Interpreter module, a network status data table module and a redirector agent interface module, said connection decision program producing an optimal content server command corresponding to an optimal content server to process said user request.
7. The computer readable memory of claim 6 wherein said redirector program and said connection decision program are executed at a single geographic location.
8. The computer readable memory of claim 6 wherein said redirector program and said connection decision program are executed at different geographical locations.
9. The computer readable memory of claim 6 wherein said redirector program and said connection decision program are replicated at a plurality of geographic locations.
Description  (OCR text may contain errors)

METHOD AND APPARATUS FOR DYNAMIC DETERMINATION

OF OPTIMUM CONNECTION OF A CLIENT

TO CONTENT SERVERS

BRIEF DESCRIPTION OF THE INVENTION

The subject of this invention relates to the data communications industry. Specifically, this invention describes a method and apparatus for dynamically determining the optimum one of many servers for delivery of content to a user client terminal.

BACKGROUND OF THE INVENTION As the use of networks increases, more and more users are turning to network service providers for hosted data services. These service providers operate generally over the Internet, and are thus referred to as Internet Service Providers, or ISPs. It should be noted however that the Internet is not the only possible network topology that provides services to multiple users. Thus the discussion below can apply to a wide variety of network architectures including, but not limited to, local area networks [LANs], wide area networks [WANs], intranets and internets. Further, data communications encompasses a variety of data forms including, but not limited to, voice, video, audio, e-mail and software. For purposes of the present invention the discussion will center on the Internet. Common to all network structures is the notion of clients and servers. Generally, a client is the source of a request for some service and a server provides that service. It is possible that the same device that is a server can, in a following transaction, become a client. For example, supposing that a user makes a request for some information through his ISP. The user's terminal is the client and the ISP is the server. But the information that the user has requested resides on a different network, thus the ISP must make a request from a different data terminal at some other network location, thus the ISP becomes the client and the distant terminal the server. Note that for purposes of this discussion, a data terminal is considered to be a device having data processing, display and input/output capability. Thus a data terminal could be any number of physical machines including a desktop PC, a laptop PC, a router, or any other device capable of communicating with other such devices.

In modern network architectures, individual data terminals are dispersed in logical and, in most cases, physical space. Some of these data terminal devices are strictly clients and are used by individual users to process data, access data and applications, and communicate with remote data terminal devices. Other data terminal devices act as communication portals and serve as both the server to an end user and as clients of other network data terminal devices. Still other data terminal devices contain large volumes of data and act only as servers, outputting requested data upon demand from a client device.

Modernly, data terminal devices on one network have the ability to communicate with data terminal devices on another network through the use of common protocols. The result is that many networks containing many data servers can be connected to a very large number of user clients. To identify which network and client are to be served, an address scheme has been adopted. Additionally, the demand for certain data, for example, a video feed of a sporting event, can be so large that more than one data server with identical data may be required to satisfy the demand. Typically, a network hosting service will supply these multiple data servers in different geographical parts of the world. These identical servers are referred to as data mirrors, or mirror sites. Mirror sites are used for a number of reasons, including data redundancy, traffic demand, and cost control, however, for this discussion the use of mirror sites is particularly related to optimizing data transfer to user clients. Given that multiple mirror sites are available to serve a specific user client, a need arises to determine which of the mirror servers will be used to deliver the requested data. Numerous methods exist in the art to make this decision. These methods fall into two major types: fixed and dynamic. Fixed routing includes such methods as selecting a route from preprogrammed tables, calculating least delivery route cost, least delivery route weight, or least delivery route distance. Dynamic routing methods include deriving the optimum route from data supplied by the user clients and data servers, then making a calculation on-the-fly, or using statistical balancing to determine the best delivery route. Centralized fixed routing uses a dedicated routing server to pick the optimum route from a table. Sometimes referred to as the minimum hop method, a table is used to determine the shortest distance from a user client to a data server. Variations of this method include the geographic location method and the preprogrammed logical location method. The fixed routing method ignores effects of local traffic demand on a single site, thus it suffers from delays in delivery and increases in connection time and cost, with an attendant reduction in network efficiency.

Another fixed routing method divides the network topology into low speed local and high speed backbone segments, then parses the available data servers into one or the other of the segments. This so-called network parsing method makes the delivery decision predicated upon a preprogrammed elimination of many of the otherwise available nodes based on which segment the node resides in, thus it suffers from inefficient selection of the least busy server. The result is again a less-than- optimal route selection with a potential increase in cost due to increased connection time. Dynamic route selection methods include the least weight method, the least cost method, and the statistical balancing method. Each of these methods is dynamic since current network topology and traffic data are used to make the routing decision. The least weight method first uses data gathered about the end nodes in a specific communication session to assign a weight to a theoretical connection to all nodes of a network, then, in a second step, uses tabular data about the network topology with corresponding weighted values, and finally, in a third step, chooses the least weight answer from all possible connections formed by the addition of all of the weighted values. This method is slow compared to other methods, and suffers further from an aggregation of communication delays throughout the network. The result is delayed connection from the user client to the desired data server.

The least cost method is based on traffic density and unit cost of data transferred. In this method an arbitrary cost is assigned to a set level of traffic such that when traffic on one data server reaches a predetermined value, the cost per unit of data transferred will become high, forcing the algorithm to direct new traffic to a different data server. This method ignores the effects of geographical location, forcing traffic over a longer, more delay prone route when traffic on the desired data server reaches the predetermined level. Further, the method is centralized, so it is prone to service interruptions if the decision making data terminal device fails.

Statistical balancing of user clients is another dynamic route selection method, hi this method all of the possible routes are monitored for traffic levels, and the traffic loads balanced on a per server basis. This method, like the cost method above, ignores any geographical advantages, thus possibly choosing a sub-optimal route due to the distance the data must travel.

As can be seen, the existing methods suffer from one or more disadvantages. What would be desirable is a method for choosing an optimum connection from a user client to a data server dynamically and in such a way as to mitigate the disadvantages of the existing methods. Advantageously, the method should simultaneously provide the most efficient and cost effective routing decision.

SUMMARY OF THE INVENTION

The method and apparatus of the present invention provide dynamic routing selection of the optimum data server from among many data servers that form a distributed content cache on a communications network. A user client enters a request by one of several addressing protocols. The method of the invention uses a combination of analytical tools to act upon information contained in the request to determine which of the many distributed content data servers will provide the optimum connection for the user client. Criteria used to make the selection include the type of request, the shortest path, and, when needed, other factors such as route weighting and best bandwidth. The method of the present invention combines a number of protocols and test methods to make the optimum routing decision. The protocols include, but are not limited to, HyperText Transfer Protocol [HTTP], HyperText Markup Language [HTML] and Dynamic Name Sever [DNS] addressing using Border Gateway Protocol [BGP] data. A significant advantage over the prior art is that the method of the present invention is platform independent, allowing it to be used for both internal networks, or externally across other networks of different types.

Operation of the present invention is accomplished through use of fully mirrored content data servers, or Content Delivery Nodes [CDN] containing an embedded Redirector Agent, and multiple redundant Node Decision Servers [NDS] located at strategic data hubs within the ISP hosting service. The CDNs may contain a variety of data types, for example live multi-cast, audio, video, standard web pages or simple data libraries. A user client issues a request, for example by entering a Universal Resource Locator [URL] address, which is received and analyzed by the Redirector Agent embedded in the CDN. Having identified the type of protocol to be used, the Redirector Agent queries the NDS for the optimum route decision. The NDS then reviews the status of the network based upon the most current BGP data, including peer outages and geographic location of the CDN closest to the requestor, and makes an optimum connection determination. Once the decision is made, the NDS returns the optimum path data to the Redirector Agent. Based on the received optimum route data from the NDS plus the application of other administrative factors, the Redirector Agent formulates and returns the optimum path data to the user client.

Because the method of the present invention is platform independent, user client requests can vary. For example, the Redirector Agent can receive and react to HTTP tasks submitted by the requestor's web browser and return to the user client the URL of the optimum CDN. Alternatively the method of the present invention can receive DNS lookup data from the requestor and, using a DNS lookup table, return the DNS address of the optimum CDN. A third alternative method delivers embedded HTML instructions containing the appropriate target CDN data. The array of redundant NDSs receives constant updates as to the status of the network via BGP data which is fresh with each new communications session. Thus if one of a plurality of mirrored CDNs goes offline, the redundant NDS array factors this peer outage into the decision criteria. In this way the optimum connection decision is dynamic, and always represents the best decision for any given communications session connection in real time. Once the off-line CDN returns to service, the network status is again updated and the optimum route decision is made accordingly. Thus a significant advantage of the present invention is the ability to provide the optimum connection from a requestor to a content data server in real time. This and other advantages of the present invention are discussed in detail below in conjunction with the figures attached.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 illustrates a high level block diagram of a system that can make use of a first embodiment of the method of the present invention.

Figure 2 presents a top level state diagram of an embodiment of the method of the present invention. Figure 3 is a detailed block diagram of a data content server that can make use of the method of the present invention.

Figure 4 is a detailed block diagram of a node decision server that can make use of the method of the present invention.

Figure 5 presents a state diagram of a typical HTTP communications session using the method of the present invention.

Figure 6 presents a state diagram of a typical HTML communications session using the method of the present invention.

Figure 7 presents a state diagram of a typical DNS communications session using the method of the present invention.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

As described briefly above, there are a number of disadvantages with the current methods for optimizing the distribution of content from remotely located data servers including delays, sub optimum efficiency, and service interruptions among others. The method of the present invention overcomes these disadvantages by providing a method and associated apparatus that allows dynamic determination of the most optimal target data server for content delivery without insertion of undesirable delays.

The method of the present invention will be more clearly understood through a brief discussion of the environment in which the invention operates. Note that for the detailed discussion that follows the terms "client" and "server" are used in their technical sense. That is, where a device is the source of a request, it is referred to as a client, whereas the same device responding to a request is referred to as a server.

Referring to Fig. 1, a high level block diagram of a system 100 that can make use of the present invention is shown. A Hosting Service 140 provides data services for numerous users, hi this configuration, the Hosting Service 140 is located geographically in Santa Clara. The Hosting Service 140 maintains a number of Routers 141 and Switches 143 that interface to data content servers such as Content Server #1 300. As is known to those of skill in the art, this is not the only possible host services configuration and is shown here as an example only. Other configurations could be used without departing from the spirit of the invention, for example, the Switches 143 could be eliminated for smaller host configurations. The Content Server #1 300 contains, among other data and programs, a Content Delivery Node #1 310 and a Redirector Agent 350. As will be discussed in greater detail below, the Content Delivery Node #1 310 contains the information that a remote user is seeking and is one of several mirrored content sites. The Redirector Agent 350, also discussed in detail below, is a program that receives users' requests, processes user address data, and interfaces with a Node Decision Server [NDS] 400, also located at the Hosting Service 140. The NDS 400 uses the Border Gateway Protocol [BGP] Data Table 410 to make a decision as to which of a plurality of mirrored data content servers will be the best for a particular user and communications session.

The BGP Data Table 410 is updated with current network status with each new communications session. These data are contained in the incoming message and are sent to the NDS 400 by the Router 141 as part of its normal operation. The NDS 400 then interprets the BGP data sent and updates the BGP Data Table 410. Each time a new communications session is started, regardless of the specific user, updated BGP data are sent to the BGP Data Table 410. In this way the method of the present invention maintains a detailed status of the current network conditions, including peer outages and active routes, advantageously allowing for a more accurate determination of an optimum content delivery path.

An example of a mirrored data content server is Content Server #2 130 in Atlanta. Content Server #2 130 contains the identical data content as Content Server #1 300 as well as Content Delivery Node #2 135. As will be discussed below, this fully mirrored configuration has several nontrivial advantages over the prior art including more rapid determination of the optimum data content server for a particular user and communications session. Shown in Fig. 1 are two typical remote users, User 1 110 in Chicago and User

2 120 in Seattle. These users each have an Internet Service Provider [ISP] (User 1 ISP 112 and User 2 ISP 122 respectively) connecting them to the Internet 150. The function of an ISP is well understood by those of skill in the art and is thus not treated in detail as part of this discussion. These users have a need to connect to a content provider's information and do so by requesting the establishment of a communications session with a target data content server.

Fig. 2 presents a high level state diagram 200 of the method of the present invention. While there are numerous specific instances of the use of BGP data by the method of the present invention, each discussed in detail below, Fig. 2 is appropriate for describing the method at a high level of granularity. The process begins when the User 210 requests a communications session. Note that the User 210 in Fig. 2 is equivalent to User 1 110 in Fig. 1 but is labeled differently here for clarity. Note further that Router 230, Redirector Agent 280, and NDS 250 all are equivalent to their counterparts in Fig. 1 but are labeled differently for clarity in Fig. 2. The User Request 215 is sent to a Router 230. The Router 230 sends the incoming message to the NDS 250 in the Send BGP data step 234. The NDS 250 interprets the BGP data contained in the incoming message in the Interpret BGP Data step 252 and then updates the BGP table at the Update BGP Data Table step 254. At this point in time the NDS 250 has a real time status of the entire network to use in its decision making process. The Router 230 also delivers the request to the Redirector Agent 280 at the Deliver Request step 236. Once the Redirector Agent 280 has received the request, the Determine Request Type step 282 is executed in order for the method of the present invention to understand what type of communication protocol is being used by the user's client device. After making this determination the Redirector Agent 280 forms a query and sends it to the NDS 250 via the Query NDS for Best Server step 284. Using the very recently updated network status the NDS executes a Look-up Best Server step 265 and returns the results of the decision process to the Redirector Agent 280 in the Best Server Response step 258.

Having received the best data content server decision from the NDS 250, the Redirector Agent 280 executes the Apply Other Admin Factors step 286 prior to sending the optimum route decision via the Return Best Server step 288. Other administrative factors may include such information as customer status, current traffic conditions and content status among others. The Router 230 receives the optimum data content server path information from the Redirector Agent 280 and passes it back to the User 210 via the Best Choice step 238.

Fig. 3 provides the relevant detail of a typical Content Server 300, such as Content Server #1 in Fig. 1. The server contains, among other things, a Content Delivery Node #1 310, in this case having a Universal Resource Locator [URL] of www-west.demo.com. Also contained in Content Server 300 is a Redirector Agent 350. The redirector agent is a software program containing a Front End Processor module 352, Application/Configuration Table 355 and NDS Interface module 358. As will be obvious to those of skill in the art, a typical content server will contain many other components, both hardware and software, that are not relevant to the method of the present invention and are thus not addressed in this discussion. While each of the modules contained in the Redirector Agent 350 will be discussed in greater detail in conjunction with Figs. 5 through 7 below, in general, the Front End Processor module 352 is responsible of accepting a user's request, parsing the incoming data, analyzing the data and formulating a decision query to be sent to the NDS. The query is based upon what type of application has been sent by the user, thus the Application/Configuration Table 355, containing pre-configured data related to types of applications expected from users, is checked by the Front End Processor module 352 and the proper data is fetched for use in formulating the query to the NDS. The NDS Interface module 358 is used to send queries and receive responses from the NDS.

Fig. 4 is a detailed block diagram of the NDS 400 in Fig. 1. The NDS 400 contains, among other things, the BGP Data Table 410, the BGP Interpreter module 420, The Network Status Data Table 430 and the Redirector Agent Interface module 440. Note that the NDS 400 may contain other hardware and software that are not relevant to the method of the present invention and are thus not addressed in this discussion.

BGP Interpreter module 420 interprets the incoming message and extracts BGP data. These fresh data are then sent to the BGP Data Table 410, and, in combination with the geographic location data from the Network Status Data Table 430, form the decision data to be used in determining the optimum data content server location for the particular user request. The exact method for selection of the best possible data content server varies with the type of user request thus is not discussed in detail here; however, each method is covered in detail in conjunction with Fig.s 5 through 7 below. Redirector Agent Interface module 440 receives queries from and sends responses to the NDS Interface module, 358 of Fig. 3.

Recall that the precise best route selection method depends upon what application was used by the user to establish the communication session. Figs. 5 through 7 provide the process details for three types of communication sessions.

These application types are exemplary in nature, and do not represent a limitation on the scope of the present invention. For Figs. 5 through 7 state diagrams have been used for clarity of understanding. It will be recognized by those of skill in the art that within each of the states shown various smaller steps are executed which do not add to the understanding of the method of the present invention and have been aggregated for clarity.

Fig. 5 presents a detailed state diagram 500 of the present invention using the HTTP redirect method. With this method the process starts with the User 510, whose IP address happens to be 192.168J.43, issuing a request to connect to www.demo.com at User Request 515. The request takes the form of an HTTP GET/file.exe command. The Router 530 receives the command and then delivers the request via the Deliver Request step 536 to a Redirector Agent 580 embedded in a content server, for example, Content Server #1 300 in Fig. 1. Note that the Router 530 accomplishes other tasks as explained in conjunction with Fig. 2 above, for example, delivering the request message to the NDS 550 to accomplish the BGP data update. The Redirector Agent 580 uses the data contained in the Application/Configuration Table, 355 of Fig. 3, to determine which type of communications protocol is being used at the Determine Request Type step 582. Once determined, a query is formed and sent to the NDS 550 at the Best Server for 192.168.7.43 step 584. Within the NDS 550 the Look-up Best Server step 556 determines the closest geographic data content server to the user from among a plurality of data content servers. Once the optimum geographical data content server has been determined, the NDS 550 responds to the Redirector Agent 580 with the location data at the Best Server = Content Server #2 step 558.

The decision in the NDS 550 is based upon the current BGP data, the geographic locations of all possible relevant data content servers, which of the relevant data content servers have active routes, and which are administratively up or down. Where multiple geographic locations with active routes exist that are otherwise equal, a random distribution method of route assignment is used, i the example shown in Fig. 5, the optimum data content server selected by the NDS 550 happens to be Content Server #2 (130 of Fig. 1) located in Atlanta. This comports with the geographic location of the User 510 who is located in Chicago. Were the incoming request from User 2, 120 in Fig 1., located in Seattle, the NDS 550 would respond with Content Server #1 (300 of Fig. 1) instead, since it is located in Santa Clara.

Once the Redirector Agent 580 has received the response from the NDS 550, other relevant data are applied to the decision at the Apply Other Admin Factors step 586. Here, such factors as data content server loading, availability and data status are used to ensure that the proper content server has been selected. At step 588, Return Best Server, the Redirector Agent 580 passes the decision to the Router 530, which in turn sends the optimum route to the User 510 via the Best Choice = step 538. Thus in this instance, a 302 HTTP ://www-east.demo.com/file.exe redirect command is passed back to the user. The user's device then executes the command and connects the user to the appropriate data content sever via the optimum path. Fig. 6 presents a detailed state diagram 600 of the present invention using the embedded HTML command method. With this method the process again starts with the User 610, whose IP address again happens to be 192.168.7.43, issuing a request to connect to www.demo.com at User Request 615. The request takes the form of an HTTP GET/index.html command. The Router 630 receives the command and then delivers the request via the Deliver Request step 636 to a Redirector Agent 680 embedded in a content server, for example, Content Server #1 300 in Fig. 1. Note that the Router 630 accomplishes other tasks as explained in conjunction with Fig. 2 above, for example, delivering the request message to the NDS 650 to accomplish the BGP data update.

The Redirector Agent 680 uses the data contained in the Application/Configuration Table, 355 of Fig. 3, to determine which type of communications protocol is being used at the Determine Request Type step 682. In this instance, the determination is made that an embedded HTML protocol has been received from the user. Steps 684 through 686 perform the same functions in the same manner as their counterparts in Fig. 5 and therefore are not detailed here. At step 688, Return Best Server, the Redirector Agent 680 passes the decision to the Router 630, which in turn sends the optimum route to the User 610 via the Best Choice = step 638. Thus in this instance, an HTTP://www-east.demo.com/index.html redirect command is passed back to the user. The user's device then executes the command and connects the user to the appropriate data content sever via the optimum path.

Fig. 7 presents a detailed state diagram 700 of the present invention using the DNS lookup method. With this method the process again starts with the User 710, whose IP address again happens to be 192.168.7.43, issuing a request to connect to www.demo.com at User Request 715. The request takes the form of a DNS lookup www.demo.com command. The Router 730 receives the command and then delivers the request via the Deliver Request step 736 to a Redirector Agent 780 embedded in a content server, for example, Content Server #1 300 in Fig. 1. Note that the Router 730 accomplishes other tasks as explained in conjunction with Fig. 2 above, for example, delivering the request message to the NDS 750 to accomplish the BGP data update. The Redirector Agent 780 uses the data contained in the Application/Configuration Table, 355 of Fig. 3, to determine which type of communications protocol is being used at the Determine Request Type step 782. In this instance, the determination is made that a DNS lookup protocol has been received from the user. Steps 784 through 786 perform the same functions in the same manner as their counterparts in Fig. 5 and therefore are not detailed. At step 788, Return Best Server, the Redirector Agent 780 passes the decision to the Router 730, which in turn sends the optimum route to the User 710 via the Best Choice = step 738. Thus in this instance, a DNS address of 206.224.221.254 is passed back to the user. The user's device then executes the connection to the appropriate data content sever via the optimum path in the normal manner. A first advantage of the present invention is the ability to make an optimal route decision based on current network status. This is accomplished by reading and storing network conditions gained from fresh BGP data contained in each new session.

A second advantage of the present invention is the speed of the optimum route decision process. Rapid route selection reduces the user delays in connecting to the best content server thereby reducing overall network traffic and increasing efficiency.

A third advantage of the present invention is that it is platform independent. The Redirector Agent can be embedded in various communications environments making it broadly available to networks of all sizes and configurations.

A fourth advantage of the present invention is that it is application independent. Since the Redirector Agent is pre-configured based upon client protocol preferences, a variety of communication applications may be served from the same network hosting environment.

A fifth advantage of the present invention is that it is expandable. As new protocols and or communications applications become available, the Redirector Agent can be programmed to recognize, analyze and react in an appropriate manner.

A sixth advantage of the present invention is that it is configurable on a client- by-client basis. This advantage allows the present invention to be changed as a client's needs change with little effort and expense.

A seventh advantage of the present invention is that it is mirrored. This redundancy of both data and process greatly increases the dependability of the method of the present invention and significantly reduces the deterioration in performance related to network outages. An eighth advantage of the present invention is that it is economical since makes the optimum route selection based on best performance at the specific point in time when the user makes the content request. This is done through use of a many network factors including bandwidth, equipment status, geographic considerations, and session type, as well as others.

Patent Citations
Cited PatentFiling datePublication dateApplicantTitle
US5418967 *6 Jan 199323 May 1995Digital Equipment CorporationFast arbiter having easy scaling for large numbers of requesters, large numbers of resource types with multiple instances of each type, and selectable queuing disciplines
US6016520 *14 Jul 199518 Jan 2000Microsoft CorporationMethod of viewing at a client viewing station a multiple media title stored at a server and containing a plurality of topics utilizing anticipatory caching
US6108706 *9 Jun 199722 Aug 2000Microsoft CorporationTransmission announcement system and method for announcing upcoming data transmissions over a broadcast network
US6173322 *5 Jun 19979 Jan 2001Silicon Graphics, Inc.Network request distribution based on static rules and dynamic performance data
US6182122 *26 Mar 199730 Jan 2001International Business Machines CorporationPrecaching data at an intermediate server based on historical data requests by users of the intermediate server
US6233607 *1 Apr 199915 May 2001Diva Systems Corp.Modular storage server architecture with dynamic data management
US6286029 *28 Apr 19974 Sep 2001Sabre Inc.Kiosk controller that retrieves content from servers and then pushes the retrieved content to a kiosk in the order specified in a run list
Referenced by
Citing PatentFiling datePublication dateApplicantTitle
WO2004063946A2 *6 Jan 200429 Jul 2004Gatelinx CorporationCommunication system facilitating real time data over the internet using global load balancing
WO2004063946A3 *6 Jan 200424 Feb 2005Gatelinx CorpCommunication system facilitating real time data over the internet using global load balancing
WO2011073707A1 *14 Dec 200923 Jun 2011Telefonaktiebolaget L M Ericsson (Publ)Dynamic cache selection method and system
WO2014093717A1 *12 Dec 201319 Jun 2014Level 3 Communications, LlcContent delivery framework
CN102640472B *14 Dec 200914 Sep 2016瑞典爱立信有限公司动态缓存选择方法和系统
CN105339921A *19 Feb 201417 Feb 2016泰瑞迪科技有限公司Increased data transfer rate method and system for regular internet user
EP2997486A4 *19 Feb 201426 Oct 2016Teridion Technologies LtdIncreased data transfer rate method and system for regular internet user
US7634490 *11 Jul 200315 Dec 2009Youramigo LimitedLink generation system to allow indexing of dynamically generated server site content
US791283212 Aug 200922 Mar 2011Youramigo LimitedLink generation system to allow indexing of dynamically generated server site content
US882583015 Mar 20132 Sep 2014Level 3 Communications, LlcContent delivery framework with dynamic service network topology
US883207112 Aug 20099 Sep 2014Youramigo LimitedLink generation system to allow indexing of dynamically generated server site content
US904919914 Dec 20092 Jun 2015Telefonaktiebolaget L M Ericsson (Publ)Dynamic cache selection method and system
US945104514 Dec 201220 Sep 2016Level 3 Communications, LlcContent delivery network
US945605314 Dec 201227 Sep 2016Level 3 Communications, LlcContent delivery network
US94620518 Apr 20154 Oct 2016Telefonaktiebolaget Lm Ericsson (Publ)Dynamic cache selection method and system
US951613612 Jun 20146 Dec 2016Level 3 Communications, LlcCustomer-specific request-response processing in a content delivery network
US954890114 Dec 201217 Jan 2017Level 3 Communications, LlcFramework supporting content delivery with hybrid content delivery services
US954890214 Dec 201217 Jan 2017Level 3 Communications, LlcDevices and methods supporting content delivery with delivery services having dynamically configurable log information
US954890314 Dec 201217 Jan 2017Level 3 Communications, LlcDevices and methods supporting content delivery with rendezvous services having dynamically configurable log information
US962834214 Dec 201218 Apr 2017Level 3 Communications, LlcContent delivery framework
US962834314 Dec 201218 Apr 2017Level 3 Communications, LlcContent delivery framework with dynamic service network topologies
US962834414 Dec 201218 Apr 2017Level 3 Communications, LlcFramework supporting content delivery with reducer services network
US962834514 Dec 201218 Apr 2017Level 3 Communications, LlcFramework supporting content delivery with collector services network
US962834614 Dec 201218 Apr 2017Level 3 Communications, LlcDevices and methods supporting content delivery with reducer services
US962834713 Mar 201318 Apr 2017Level 3 Communications, LlcLayered request processing in a content delivery network (CDN)
US963490414 Dec 201225 Apr 2017Level 3 Communications, LlcFramework supporting content delivery with hybrid content delivery services
US963490513 Mar 201325 Apr 2017Level 3 Communications, LlcInvalidation systems, methods, and devices
US963490615 Mar 201325 Apr 2017Level 3 Communications, LlcDevices and methods supporting content delivery with adaptation services with feedback
US963490715 Mar 201325 Apr 2017Level 3 Communications, LlcDevices and methods supporting content delivery with adaptation services with feedback
US963491817 Jun 201425 Apr 2017Level 3 Communications, LlcInvalidation sequencing in a content delivery framework
US964140115 Mar 20132 May 2017Level 3 Communications, LlcFramework supporting content delivery with content delivery services
US964140215 Mar 20132 May 2017Level 3 Communications, LlcConfiguring a content delivery network (CDN)
US964789914 Dec 20129 May 2017Level 3 Communications, LlcFramework supporting content delivery with content delivery services
US964790014 Dec 20129 May 2017Level 3 Communications, LlcDevices and methods supporting content delivery with delivery services
US964790115 Mar 20139 May 2017Level 3 Communications, LlcConfiguring a content delivery network (CDN)
US965435314 Dec 201216 May 2017Level 3 Communications, LlcFramework supporting content delivery with rendezvous services network
US965435414 Dec 201216 May 2017Level 3 Communications, LlcFramework supporting content delivery with delivery services network
US965435514 Dec 201216 May 2017Level 3 Communications, LlcFramework supporting content delivery with adaptation services
US965435614 Dec 201216 May 2017Level 3 Communications, LlcDevices and methods supporting content delivery with adaptation services
US966087414 Dec 201223 May 2017Level 3 Communications, LlcDevices and methods supporting content delivery with delivery services having dynamically configurable log information
US966087514 Dec 201223 May 2017Level 3 Communications, LlcDevices and methods supporting content delivery with rendezvous services having dynamically configurable log information
US966087612 Jun 201423 May 2017Level 3 Communications, LlcCollector mechanisms in a content delivery network
US966104614 Dec 201223 May 2017Level 3 Communications, LlcDevices and methods supporting content delivery with adaptation services
US966750622 Dec 201430 May 2017Level 3 Communications, LlcMulti-level peering in a content delivery framework
US968614813 Mar 201320 Jun 2017Level 3 Communications, LlcResponsibility-based cache peering
US972288214 Dec 20121 Aug 2017Level 3 Communications, LlcDevices and methods supporting content delivery with adaptation services with provisioning
US972288313 Mar 20131 Aug 2017Level 3 Communications, LlcResponsibility-based peering
US972288413 Mar 20131 Aug 2017Level 3 Communications, LlcEvent stream collector systems, methods, and devices
US974919013 Mar 201329 Aug 2017Level 3 Communications, LlcMaintaining invalidation information
US974919113 Mar 201329 Aug 2017Level 3 Communications, LlcLayered request processing with redirection and delegation in a content delivery network (CDN)
US97491923 Dec 201329 Aug 2017Level 3 Communications, LlcDynamic topology transitions in a content delivery framework
US975591414 Dec 20125 Sep 2017Level 3 Communications, LlcRequest processing in a content delivery network
US978755113 Mar 201310 Oct 2017Level 3 Communications, LlcResponsibility-based request processing
Classifications
International ClassificationH04L29/08, H04L29/06
Cooperative ClassificationH04L67/1021, H04L67/1014, H04L67/101
European ClassificationH04L29/08N9A1H, H04L29/08N9A1C, H04L29/08N9A1E, H04L29/08N9A
Legal Events
DateCodeEventDescription
28 Mar 2002AKDesignated states
Kind code of ref document: A1
Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PH PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW
28 Mar 2002ALDesignated countries for regional patents
Kind code of ref document: A1
Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG
10 Oct 2002DFPERequest for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
16 Oct 2002121Ep: the epo has been informed by wipo that ep was designated in this application
19 Mar 2003WWEWipo information: entry into national phase
Ref document number: 2001975281
Country of ref document: EP
16 Jul 2003WWPWipo information: published in national office
Ref document number: 2001975281
Country of ref document: EP
31 Jul 2003REGReference to national code
Ref country code: DE
Ref legal event code: 8642
1 Apr 2004WWWWipo information: withdrawn in national office
Ref document number: 2001975281
Country of ref document: EP
13 Sep 2005NENPNon-entry into the national phase in:
Ref country code: JP