EP1236329A1 - Acheminement de demande optimal par exploitation d'informations topologiques de routeurs de paquets - Google Patents

Acheminement de demande optimal par exploitation d'informations topologiques de routeurs de paquets

Info

Publication number
EP1236329A1
EP1236329A1 EP00980633A EP00980633A EP1236329A1 EP 1236329 A1 EP1236329 A1 EP 1236329A1 EP 00980633 A EP00980633 A EP 00980633A EP 00980633 A EP00980633 A EP 00980633A EP 1236329 A1 EP1236329 A1 EP 1236329A1
Authority
EP
European Patent Office
Prior art keywords
server
content
name
address
anycast
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP00980633A
Other languages
German (de)
English (en)
Inventor
Stephen Glines
John R. Loverso
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
InfoLibria Inc
Original Assignee
InfoLibria Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by InfoLibria Inc filed Critical InfoLibria Inc
Publication of EP1236329A1 publication Critical patent/EP1236329A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/101—Server selection for load balancing based on network conditions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1038—Load balancing arrangements to avoid a single path through a load balancer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/163—In-band adaptation of TCP data exchange; In-band control procedures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/164—Adaptation or special uses of UDP protocol
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1017—Server selection for load balancing based on a round robin mechanism

Definitions

  • IP Internet Protocol
  • DNS Domain Name Service
  • a caching server replicates the services and content of an original or primary server.
  • the introduction of caching can therefore markedly increase the apparent bandwidth of the original server, and provide redundancy for the original server. If the cache is topologically close to the client, then overall amount of network traffic is reduced as well.
  • the user of a client computer may demand delivery of a content file associated with a particular URL.
  • the speed of delivery is determined by the ability of the remote host system to deliver the data and the ability of the network to transmit it.
  • Internet Service Providers ISPs
  • client computers can therefore improve client response by placing caching servers behind their routers. By caching the most popularly requested web sites (such as yahoo.com), an ISP can therefore significantly reduce its need for external network traffic.
  • the Guyton paper also recognizes that a messaging technique known as anycast might be useful in locating cache copies.
  • anycast message service is useful in situations where it is necessary to locate a host which supports a particular service, and where several servers may support the service.
  • IP Internet Protocol
  • Unicasting is the most common form of addressing. In the unicast address space, every interface to the Internet has a separate IP layer address. Most machines have only one interface, although other machines such as routers may have many such addresses.
  • Multicast messaging allows a single message to be addressed to a group of systems. It is a form of broadcast messaging in which a user may send a message to all listening recipients. Anycast messaging assumes there are multiple systems providing an identical service. Since all the machines in the anycast address space are identical, they can have the same IP address. Routing policies within the Internet Protocol can be depended upon to automatically route packets to the nearest anycast system, namely the one with the best distance metric (e.g. the least number of hops) from the client (at the current time or via the current routing topology).
  • the best distance metric e.g. the least number of hops
  • an anycast messaging construct can be used to locate one of several DNS resolvers in a network.
  • standard network protocols only guarantee that the route which an anycast message takes from its source to its destination is the best one at a given instant in time.
  • two packets sent to the same anycast IP address even if sent in sequence, one immediately after the other, may end up at two physically different anycast servers. If an anycast message comprises more than one packet, its component parts may thus actually take entirely different routes between a sender and receiver.
  • a client issues an anycast request to a service that returns a reply which requires two packets at the TCP layer.
  • the request was served by a first server and that the client's TCP stack has sent two acknowledgment packets. Because the acknowledgments are sent to an anycast address, routers may actually deliver them to different servers, causing the first server to constantly retransmit the second packet.
  • the technique should have minimal impact on existing network infrastructure and require as little reprogramming and rearranging of infrastructure such as routers and gateways as possible. In addition, the technique should not require alteration of standard network communication protocols.
  • content distribution is provided as a service where client requests are automatically routed to the closest available content server.
  • the performance of the system as a whole may be increased by simply adding more server resources to the parts of the network that need it, with minimal change or no change to the network existing infrastructure.
  • name servers are located throughout the network.
  • the name servers are addressable via a common anycast address, as well as being individually addressable via a unicast address unique to each such name server.
  • Each name server is peered with a nearby content server, cache server, or other file server that contains (or can serve) desired content file replicas via unicast addressing.
  • Each name server also advertises itself as being authoritative for the domains associated with the content files stored (or to be served from) the associated content server.
  • IP Internet Protocol
  • a user indicates the location of a content file such as by specifying a Uniform Resource Locator (URL) to a browser program, or by clicking on a hyperlink in a displayed document which has an embedded URL.
  • a URL may, for example, be "http://www.example.com/homepage.htmr'.
  • the browser then makes a request to a DNS service to resolve the IP address of the domain name (e.g. "example.com") specified by the URL.
  • This request is typically formulated as a message sent to a local address resolver.
  • example.com domain is not located in a local domain
  • the local resolver will then proceed to consult public name servers that have been defined as being authoritative for the "example.com” domain.
  • the root domain name servers defined, for example, by the Internic may be programmed to return the common address of the group of name server/content server peers that share a common anycast address.
  • the browser or local resolver Having now resolved an IP address for an authoritative name server (e.g., the previously defined server group address returned) for the "example.com" domain, the browser or local resolver then sends out a DNS request as a UDP datagram to an anycast message to the group. This will now resolve the IP address of www.example.com.
  • an authoritative name server e.g., the previously defined server group address returned
  • the UDP packet will find its way first to the server pair which is located along the shortest path from the requester.
  • the server pair that receives the request then responds by reporting the unique (unicast) address of the associated content replica server (or cluster address if the systems are arranged in a round robin fashion).
  • the user's browser then now make subsequent HTTP level requests to the IP address just received, to obtain the "homepage.html” file from the content server.
  • This content server should represent the “nearest” such server, according to whatever metric the network uses to resolve the anycast address.
  • each physical system which shares the anycast address must perform certain functions, such as a standard but customized name server function, as well as a content server, such as a cache server.
  • a name server is programmed to respond to the common anycast address of the peer content server.
  • the content server will typically never directly respond to the common anycast address (actually, it will never receive an anycast request because it does not have an anycast address).
  • the invention provides a solution to the problem of route discovery by avoiding it altogether. This is accomplished by using an anycast datagram to locate name servers placed on or placed logically near replicated content files.
  • the invention exploits the fact that implicit in the Internet routing mechanism is a concept of "nearness.” In this instance, nearness in the case of an anycast message, may be whatever system the Internet routing scheme first delivers a packet to.
  • Each name server returns the IP address of one or many (such as through round robin or other mechanisms) closely bound and topologically nearby content servers. As a result, a relatively nearby content server, from the perspective or the original requesting client is always located.
  • Fig. 1 is a block diagram of a computer network environment in which the invention may be implemented.
  • Fig. 2 is a flow diagram of a process which makes use of the invention.
  • a computer network 10 in which a mechanism is used to redirect client computer requests for content files to the closest replica of the requested content, by using anycast messaging to a name service provided by a group of name servers distributed in the network.
  • the network 10 may be a typical client-server distributed system, such as is now popularly implemented using personal computer platforms and web based file servers connected via an internetwork 30 such as the Internet.
  • a client computer 12 runs a web browser program that enables a user to submit requests for content files that are nominally located at an origin file server 40. For example, as the user types a Uniform Resource Locator (URL) into a web browser and or uses a pointing device, such as a mouse, to click on a hyperlink embedded in a previously viewed web page, the URL for a particular web site is specified to the browser 12.
  • URL Uniform Resource Locator
  • the URL In the standard scenario, which is well known in the prior art, if the URL is fully qualified, it will typically contain a domain name, a file name for the content file, and an access method.
  • the client browser 12 then makes a request to discover the correct Internet Protocol (IP) address of the origin server 40 that contains the requested content file.
  • IP Internet Protocol
  • DNS Domain Name Service
  • the browser program When the DNS returns an IP address for the origin server 40, the browser program then attempts to open a connection to the origin server 40. If all goes according to design, the origin server 40 complies with the request and delivers the requested content file.
  • replica content servers 50 may contain replicas of one or more content files that originate at the origin server 40.
  • These content servers 50 which may typically include so called cache servers, can eliminate the need for the origin server 40 to deal with traffic demands.
  • Prior art schemes may typically require the reprogramming of name services to allow the browsers 12 to locate the content servers 50, such as by reprogramming one or more Domain Name Service (DNS).
  • DNS Domain Name Service
  • the present invention uses a particular addressing scheme to advertise the availability of alternative or replica name servers 53-1, 53-2, 53-3 for the domain located at the origin server 40.
  • the name servers 53-1, 53-2, 53-3 are peered with content file servers 51-1, 51-2, 51-3 that contain replica copies of files stored at the origin server 40.
  • the name servers 53 advertise themselves as reachable at an anycast address.
  • the internetwork 30 then itself becomes responsible for delivery of a domain name request message to a closest possible name server 53.
  • the closest name server 53 then responds to the anycast message by returning a unique IP address for its associated content server 51.
  • This scheme permits the browser to subsequently establish the higher level protocol access method, such as a Hyper Text Transfer Protocol (HTTP) request, to open a connection and deliver the content file.
  • HTTP Hyper Text Transfer Protocol
  • the browser is then subsequently redirected to the associated nearest cache server 50-1, 50-2, 50-3 that can honor the remaining expected HTTP request message sequence, without adding any unnecessary traffic to the associated domain name server 53 and/or paths in the internetwork 30 to the origin server 40.
  • the environment 10 consists of a client computing device, such as a computer 12, that is running a data file retrieval program such as a web browser.
  • the personal computer 12 is connected through an internetwork device 16-1 to a first network segment 14.
  • the internetwork device 16-1 may be any or any combination of modem, network interface card, router, switch, bridge, gateway, or the like.
  • the internetwork devices 16 provide the ability for connections to be made between various computing system elements using network infrastructure such as the internetwork structure 30, which may be a corporate intranet or the Internet.
  • the client computer 12 is connected to a local area network (LAN) 14 that consists of internetwork devices 16-3 and 16-4, which in this instance are routers.
  • LAN local area network
  • a local name service such as Domain Name Service (DNS) resolver 18, a local content host 21, and local content storage device 22 also form part of the LAN 14.
  • DNS Domain Name Service
  • the local content server 21 may be any type of well known host computer that is adapted for efficiently storing content files on a mass storage device 22. These content files may include web pages, multimedia files, graphics, pictures, other computer files that are suitable for network transmission using well know protocols such as the HyperText Transfer Protocol (HTTP).
  • HTTP HyperText Transfer Protocol
  • the client computer 12 may also make connections through the local area network 14 and router 16-3 to the Internet 30 to access files located at various other computing systems.
  • One of these computer systems may provide a service such as a root domain name service 38.
  • Other systems serve as the origin web server 40.
  • the origin server 40 is similar to the local host 20, in that it consists of a file server 41 and content storage 42 as well as an internetwork device 16-40.
  • the replica content servers 50-1, 50-2, 50-3 store replicas of one or more of the content files that originate at the origin server 40.
  • Each content server 50 consists therefore also of a file server 5 land associated mass storage device 52.
  • replicas of content files that originate at the origin server 40 are distributed and stored in the replica content servers 50.
  • Content files may be propagated through any number of schemes to push content out to various locations in the network 10 and/or move content closer to requesting client computers 12 upon demand. The connections to accomplish this are indicated by the dashed lines shown in Fig. 1. It should be understood that these are typical network connections between the origin server 40, and replica content servers 51-1, 51-2, 51-3; however, these connections are only shown here as logical connections from the perspective of the browser user client computer 12.
  • the name servers 53-1, 53-2, 53-3 are addressable via both a common anycast address as well as a unique or unicast address.
  • a DNS request may be sent to the name servers 53 as an anycast datagram.
  • the internetwork 30 is then responsible for providing best effort delivery of the datagram to at least one, and preferably the closest one, of the machines that accept messages for the anycast address.
  • the replica name servers 53 have received appropriate information from an authoritative DNS 45 for the domains in server 40.
  • Each name server 53 and file server 51 associated with particular content server 50 are considered to be connected in a peering arrangement. That is, they operate quite closely together and, in fact, are preferably located physically near one another, such as on a common local area network segment sharing the same internetwork device 16-50-1.
  • Each replica name server 53 therefore actually has two IP addresses, a common anycast address which is common to all of the replica name servers 53, as well as a unique unicast address which is specific to each name server 53.
  • Each name server 53 is considered to be an authoritative DNS resolver for domain names associated with the replica content files stored in its associated replica content server 51.
  • Fig. 2 in connection with Fig. 1.
  • users specify a Uniform Resource Locator (URL) to a browser program running on the client computer 12.
  • URL Uniform Resource Locator
  • the user may specify the URL http://www.example/homepage.html.
  • the browser program makes an initial attempt to resolve an address for the specified domain "example.com.” For example, the browser program issues a DNS request message as a UDP datagram to a name server. In the case where the user is associated with an Internet Service Provider (ISP) operating the local area network 20, this first name request is made to a local DNS resolver 18, to determine the location of the domain "example.com".
  • the DNS resolver 18 determines whether or not the requested content file is available locally. For example, it determines if "example.com" is located in the local web server 20. In other configurations, the resolver 18 may even reside at the client 12.
  • step 104 if the content is available locally, then the local IP address is returned to the browser program in step 106.
  • step 104 If however, in step 104, the domain "example.com" is not available locally, then the process proceeds to step 108.
  • a request to resolve the location ofexample.com is then sent to a root DNS server 38 in step 108.
  • the request to the root DNS server 38 will be recursively worked through multiple root servers associated with the Internet 30 (not shown in Fig. 1) to resolve the IP address for a DNS server authoritative for the requested domain name.
  • the root DNS name server 38 would then return the IP address of the DNS server that is authoritative for "example.com". In the illustrated embodiment, this may take the form for example, of the four-digit address 62.104.11.12 associated with a particular origin server 40.
  • the root DNS name server 38 has been programmed to instead return the anycast address 50.100.20.1.
  • the name servers 53-1, 53-2, 53-3 have been designated as being the authoritative name servers for "example.com" through previous network management level configuration information. This can be done, for example, by having the parent name server (i.e. the root name server) configured to list which name servers are configured as being authoritative for the "example.com” domain. This may also be intiated at certain times, such as when the content servers 51-1, 51- 2, 51-3 are populated with content file replicas from origin server 40.
  • the primary name service listed by organizations responsible for maintaining the state of internetwork 30, such as the Internic will point to this common address 50.100.20.1 of the caching servers 50, instead of the origin server 40.
  • step 112 now thinking that it has resolved the IP address for the single authoritative name server for "example.com", the browser then sends out a DNS request for the IP address of "www.example.com".
  • This request message is formulated as a UDP datagram specifying the common anycast address 50.100.20.1 returned in the previous step.
  • the domain name request is then sent as a UDP datagram to the anycast address.
  • the anycast datagram will reach one of the name servers 53-1, 53-2, and 53-3 in the group associated with IP address 50.100.20.1, the one reached first being the one closest to the requesting client 12 or DNS resolver 18.
  • the number of hops and hence the distance between the client 12 or DNS resolver 18 (in the case where the client 12 has a local resolver) and each particular one of the content servers 50 will be different.
  • the name server 53-1 may appear to be five hops away
  • the name server 53-2 may appear to be only one hop away
  • the name server 53-3 may appear to be twelve hops away.
  • the specific server 50 that will first return with a response will be the name server 53-3, as it is the closest in terms of network hops. This result is guaranteed, since every router 16 that is connected to a respective one of the content serves 50, and participates in the standard Internet routing protocols.
  • the name server 53 associated with this closest rate will then respond by reporting the unique EP address of its associated replica content server 51. This address is reported as a unicast address rather than an anycast address.
  • the browser program may now make an HTTP level request for the file "homepage.html" using the standard TCP TP and HTTP network protocols.
  • This final request message is sent using the unicast address for the content server 51.
  • the requested file is then returned from the content server 51-2 that is peered with the name server 53-2 that responded as being closest to the particular client 12 at the time the anycast message was sent.
  • the name servers 53 be machines that are physically separate from the content servers 51. Indeed, in a preferred embodiment, they are running typically on the same machine with the name server 53 being of one of the processes running on the content replica server 51.
  • an anycast message service can be built into the internetwork 30 any of a number of known ways.
  • An anycast message service is provided for by certain types of network protocols, such as IPv6. More commonly deployed protocols, such as IPv4, do not technically have direct support for anycast. However, such protocols can be used to create a network of service groups that each act autonomously to advertise themselves as "the" gateway into a group.
  • routing protocol may have profound effects on the propogation and convergence of group membership changes. "Membership" in the group is contigent upon distributed routing state. In the case of deployment within a single provider, where the anycast routing is internal to that network (and transparent to the outside - the Internet), and an internal routing protocol like iBGP or OSPF is used, progation of changes should be fast. In the case of deployment across multiple providers, full fledged external BGP ("eBGP”) preferably would be used.
  • eBGP full fledged external BGP
  • a network anycast service be provided in some way that at least permits datagrams to be sent to defined groups of machines, over the best advertised route to a destination address.
  • the anycast service however also preferably provides functionalities such as join, withdraw, failover/fallback, and overload. Each such function should perform as follows.
  • join routing advertisement Once a join (“begin routing advertisement”) happens, the service group begins to see requests. No convergence is needed, and as the route propagates, work can be directed at the service group.
  • the local routing neighbor would need to depend upon the timeout facilities of the routing protocol in order to discover the outage and force the route to be removed. During this time, clients attempting to contact the anycast address would not get a response ("black-hole").
  • Solutions to this problem include: a. provide redundancy in the service group, such that a name lookup to the anycast address returns two or more IP address in the service group. This gives the client another address to try if the content server fails. b. provide a shorter than normal TTL on the name ->local IP address mapping, such that the client is not able to cache the local IP address of a content server for an extended period of time.
  • Requests get delivered to the DNS server at the anycast address purely by the topological closeness of the requesting clients.
  • standard load balancing and replication techniques can also apply, such as multiple content servers (returning multiple local IP addresses to a name lookup), layer 4 switches, etc.
  • Multiple DNS servers within the group all listening to the anycast address would also be possible.
  • Load balancing across service groups requires an additional mechanism.
  • the DNS server in the service group can advertise a load metric to other service groups, and it can measure the load of the local content servers.
  • the routers 16-50 actually advertise the fact to the routers in 30 that they know how to locate the content at "example.com” in one hop. Although they are not actually networked in this way, they advertise the availability of such content, and therefore can be considered to fool the browser into believing that a network connection is available in one hop from each of the content servers 51 to "example.com", when in fact the distance may be many hops.
  • the initial anycast datagram may actually return two IP addresses for the group of content servers 50. These two addresses point to the same anycast group.
  • the content replicas stored by the replica content servers 51 need not have all of the particular objects for the web site that they replicate.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Information Transfer Between Computers (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

La présente invention concerne une technique permettant de réacheminer les demandes de données client pour des fichiers de contenus à la réplique la plus proche du contenu demandé, en utilisant la messagerie Anycast. La demande de résoudre un nom de domaine est acheminée comme un message Anycast à un service de nom assuré par un groupe de serveurs de nom répartis dans le réseau. Le serveur de nom le plus proche répond au message Anycast en renvoyant une adresse réseau unique à un serveur de contenu associé contenant une réplique du fichier de contenu demandé. Ce schéma permet à un ordinateur client d'établir ultérieurement un procédé d'accès à protocole à niveau plus élevé, notamment une demande de protocole de transfert hypertexte (HTTP), pour ouvrir une connexion et présenter la réplique du fichier de contenu, à partir d'un serveur de contenu proche du client du point de vue topologique, uniquement par des protocoles de réseaux standards.
EP00980633A 1999-11-23 2000-11-21 Acheminement de demande optimal par exploitation d'informations topologiques de routeurs de paquets Withdrawn EP1236329A1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US16712399P 1999-11-23 1999-11-23
US167123P 1999-11-23
PCT/US2000/031990 WO2001039470A1 (fr) 1999-11-23 2000-11-21 Acheminement de demande optimal par exploitation d'informations topologiques de routeurs de paquets

Publications (1)

Publication Number Publication Date
EP1236329A1 true EP1236329A1 (fr) 2002-09-04

Family

ID=22606032

Family Applications (1)

Application Number Title Priority Date Filing Date
EP00980633A Withdrawn EP1236329A1 (fr) 1999-11-23 2000-11-21 Acheminement de demande optimal par exploitation d'informations topologiques de routeurs de paquets

Country Status (3)

Country Link
EP (1) EP1236329A1 (fr)
AU (1) AU1786501A (fr)
WO (1) WO2001039470A1 (fr)

Families Citing this family (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7440994B2 (en) 2001-07-06 2008-10-21 Intel Corporation Method and apparatus for peer-to-peer services to shift network traffic to allow for an efficient transfer of information between devices via prioritized list
US7546363B2 (en) 2001-07-06 2009-06-09 Intel Corporation Adaptive route determination for peer-to-peer services
US7562112B2 (en) 2001-07-06 2009-07-14 Intel Corporation Method and apparatus for peer-to-peer services for efficient transfer of information between networks
FI20011651A (fi) * 2001-08-15 2003-02-16 Nokia Corp Palveluklusterin kuormituksen tasapainoittaminen
US8782654B2 (en) 2004-03-13 2014-07-15 Adaptive Computing Enterprises, Inc. Co-allocating a reservation spanning different compute resources types
EP2341431A1 (fr) 2004-03-13 2011-07-06 Adaptive Computing Enterprises, Inc. Système et procédé pour auto-optimiser la réservation du temps de ressources informatiques
US20070266388A1 (en) 2004-06-18 2007-11-15 Cluster Resources, Inc. System and method for providing advanced reservations in a compute environment
US8176490B1 (en) 2004-08-20 2012-05-08 Adaptive Computing Enterprises, Inc. System and method of interfacing a workload manager and scheduler with an identity manager
WO2006053093A2 (fr) 2004-11-08 2006-05-18 Cluster Resources, Inc. Systeme et procede fournissant des executions de systeme au sein d'un environnement informatique
US8863143B2 (en) 2006-03-16 2014-10-14 Adaptive Computing Enterprises, Inc. System and method for managing a hybrid compute environment
CA2601384A1 (fr) 2005-03-16 2006-10-26 Cluster Resources, Inc. Transfert automatique de charge a un centre sur demande
US9015324B2 (en) 2005-03-16 2015-04-21 Adaptive Computing Enterprises, Inc. System and method of brokering cloud computing resources
US9231886B2 (en) 2005-03-16 2016-01-05 Adaptive Computing Enterprises, Inc. Simple integration of an on-demand compute environment
EP3203374B1 (fr) 2005-04-07 2021-11-24 III Holdings 12, LLC Accès sur demande à des ressources informatiques
US8041773B2 (en) 2007-09-24 2011-10-18 The Research Foundation Of State University Of New York Automatic clustering for self-organizing grids
US8214524B2 (en) 2007-12-21 2012-07-03 Hostway Corporation System and method for selecting an optimal authoritative name server
US20090172192A1 (en) 2007-12-28 2009-07-02 Christian Michael F Mapless Global Traffic Load Balancing Via Anycast
US11720290B2 (en) 2009-10-30 2023-08-08 Iii Holdings 2, Llc Memcached server functionality in a cluster of data processing nodes
US10877695B2 (en) 2009-10-30 2020-12-29 Iii Holdings 2, Llc Memcached server functionality in a cluster of data processing nodes
US9467506B2 (en) 2014-01-27 2016-10-11 Google Inc. Anycast based, wide area distributed mapping and load balancing system
CN115883513A (zh) * 2022-11-24 2023-03-31 中国科学院信息工程研究所 一种基于dns水印技术的解析器探测方法及其分类方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO0139470A1 *

Also Published As

Publication number Publication date
WO2001039470A1 (fr) 2001-05-31
AU1786501A (en) 2001-06-04

Similar Documents

Publication Publication Date Title
US10476984B2 (en) Content request routing and load balancing for content distribution networks
WO2001039470A1 (fr) Acheminement de demande optimal par exploitation d'informations topologiques de routeurs de paquets
US6901445B2 (en) Proximity-based redirection system for robust and scalable service-node location in an internetwork
Ballani et al. Towards a global IP anycast service
Stoica et al. Internet indirection infrastructure
US7908337B2 (en) System and method for using network layer uniform resource locator routing to locate the closest server carrying specific content
US7725596B2 (en) System and method for resolving network layer anycast addresses to network layer unicast addresses
US6182224B1 (en) Enhanced network services using a subnetwork of communicating processors
Pan et al. An overview of DNS-based server selections in content distribution networks
US9154571B2 (en) Publish/subscribe networks
EP1433077B1 (fr) Systeme et procede d'orientation de clients vers des serveurs optimaux dans des reseaux informatiques
EP2708011B1 (fr) Système et procédé d'interconnexion de réseaux de distribution de contenus
EP1277327B1 (fr) Systeme et procede d'utilisation d'un localisateur de ressources universel dans des couches de reseau pour localiser le serveur le plus proche renfermant un contenu specifique
Ferreira et al. An IP address based caching scheme for peer-to-peer networks
Cojocar BBUFs: A new lookup mechanism based on IPV6
Qiu et al. A new Content Distribution Network architecture-Plenty-Cast
Garcia-Luna-Aceves System and Method forInformation Object Routing in Computer Networks
Garcia-Luna-Aceves System and Method for Discovering Information Objects and Information Object Repositories in Computer Networks
Peruru CHOReLLA±A Reliable and Scalable Addressing Scheme for Data Distribution
Cao A new Content Distribution Network architecture-PlentyCast
Gupta et al. Large-scale reliable multicast of small messages
WO2001084803A2 (fr) Systeme et procede pour la transformation d'adresses anycast de couche reseau en adresses unicast
Szymaniak et al. NetAirt: A Flexible Redirection System for Apache
Dao et al. Using Anycast for Improving Peer-to-Peer Overlay Networks

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20020624

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

AX Request for extension of the european patent

Free format text: AL;LT;LV;MK;RO;SI

RBV Designated contracting states (corrected)

Designated state(s): DE FR GB

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20040602