WO1999060459A2 - Procede et appareil de localisation efficace du trafic circulant a travers un systeme de nom par domaine - Google Patents

Procede et appareil de localisation efficace du trafic circulant a travers un systeme de nom par domaine Download PDF

Info

Publication number
WO1999060459A2
WO1999060459A2 PCT/US1999/010942 US9910942W WO9960459A2 WO 1999060459 A2 WO1999060459 A2 WO 1999060459A2 US 9910942 W US9910942 W US 9910942W WO 9960459 A2 WO9960459 A2 WO 9960459A2
Authority
WO
WIPO (PCT)
Prior art keywords
server
client
addresses
information
address
Prior art date
Application number
PCT/US1999/010942
Other languages
English (en)
Inventor
Amit Gupta
Geoffrey A. Baehr
Raphael Rom
Christoph Schuba
Original Assignee
Sun Microsystems, 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 Sun Microsystems, Inc. filed Critical Sun Microsystems, Inc.
Priority to AU40836/99A priority Critical patent/AU4083699A/en
Publication of WO1999060459A2 publication Critical patent/WO1999060459A2/fr

Links

Classifications

    • 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

Definitions

  • This invention relates to the field of managing communication on the internet.
  • Computer systems sometimes rely on a server computer system to provide information to requesting computers on a network. When there are a large number of requesting computers, it may be necessary to have more than one server computer system to handle the requests. In prior art systems, there is a problem in efficiently directing requests to the correct server in a multiple server system. One area where this has been a problem is on the internet. The problem can be better understood by reviewing the structure and operation of the internet below.
  • the Internet is a worldwide network of interconnected computers.
  • Internet client accesses a computer on the network via an Internet provider.
  • An Internet provider is an organization that provides a client (e.g., an individual or other organization) with access to the Internet (via analog telephone line or Integrated Services Digital Network line, for example).
  • a client can, for example, read information from, download a file from or send an electronic mail message to another computer /client using the Internet.
  • WWW World Wide Web
  • the components of the WWW include browser software, network links, servers, and WWW protocols.
  • the browser software, or browser is a user-friendly interface (i.e., front-end) that simplifies access to the Internet.
  • a browser allows a client to communicate a request without having to learn a complicated command syntax, for example.
  • a browser typically provides a graphical user interface (GUI) for displaying information and receiving input. Examples of browsers currently available include Mosaic, Netscape Navigator and Communicator, Microsoft Internet Explorer, and Cello.
  • Information servers maintain the information on the WWW and are capable of processing a client request.
  • Hypertext Transport Protocol (HTTP) is the standard protocol for communication with an information server on the WWW. HTTP has communication methods that allow clients to request data from a server and send information to the server.
  • the client contacts the HTTP server and transmits the request to the HTTP server.
  • the request contains the communication method requested for the transaction (e.g., GET an object from the server or POST data to an object on the server).
  • the HTTP server responds to the client by sending a status of the request and the requested information. The connection is then terminated between the client and the HTTP server.
  • a client request therefore, consists of establishing a connection between the client and the HTTP server, performing the request, and terminating the connection.
  • the HTTP server does not retain any information about the request after the connection has been terminated.
  • HTTP is, therefore, a stateless protocol. That is, a client can make several requests of an HTTP server, but each individual request is treated independent of any other request. The server has no recollection of any previous request.
  • An addressing scheme is employed to identify Internet resources (e.g.,
  • a URL contains the protocol to use when accessing the server (e.g., HTTP), the Internet domain name of the site on which the server is running, the port number of the server, and the location of the resource in the file structure of the server.
  • the WWW uses a concept known as hypertext. Hypertext provides the ability to create links within a document to move directly to other information. To activate the link, it is only necessary to click on the hypertext link (e.g., a word or phrase). The hypertext link can be to information stored on a different site than the one that supplied the current information.
  • a URL is associated with the link to identify the location of the additional information. When the link is activated, the client's browser uses the link to access the data at the site specified in the URL.
  • the HTTP server locates the file and sends it to the client.
  • An HTTP server also has the ability to delegate work to gateway programs.
  • CGI Common Gateway Interface
  • a gateway program is referenced using a URL.
  • the HTTP server activates the program specified in the URL and uses CGI mechanisms to pass program data sent by the client to the gateway program.
  • Data is passed from the server to the gateway program via command-line arguments, standard input, or environment variables.
  • the gateway program processes the data and returns its response to the server using CGI (via standard input, for example).
  • the server forwards the data to the client using the HTTP.
  • a browser displays information to a client/user as pages or documents
  • HTML Hypertext Markup Language
  • a WWW page is transmitted to a client as an HTML document.
  • the browser executing at the client parses the document and displays a page based on the information in the HTML document.
  • HTML is a structural language that is comprised of HTML elements that are nested within each other.
  • An HTML document is a text file in which certain strings of characters, called tags, mark regions of the document and assign special meaning to them. These regions are called HTML elements.
  • Each element has a name, or tag.
  • An element can have attributes that specify properties of the element.
  • Blocks or components include unordered list, text boxes, check boxes, radio buttons, for example. Each block has properties such as name, type, and value. The following provides an example of the structure of an HTML document: ⁇ HTML>
  • Each HTML element is delimited by the pair of characters " ⁇ " and ">".
  • the name of the HTML element is contained within the delimiting characters.
  • the combination of the name and delimiting characters is referred to as a marker, or tag.
  • Each element is identified by its marker. In most cases, each element has a start and ending marker. The ending marker is identified by the inclusion of an another character, "/" that follows the " ⁇ " character.
  • HTML is a hierarchical language. With the exception of the HTML element, all other elements are contained within another element.
  • the HTML element encompasses the entire document. It identifies the enclosed text as an HTML document.
  • the HEAD element is contained within the HTML element and includes information about the HTML document.
  • the BODY element is contained within the HTML. The BODY element contains all of the text and other information to be displayed. Other HTML elements are described in HTML reference manuals.
  • a computer user navigates the internet or web from a browser on a computer system.
  • the user enters the host name of the web site into the browser. This can be accomplished by clicking on a link, by activating a tool bar button, or by manually entering a name or address into a location field and pressing "enter".
  • the names that a browser client uses are known as host names, such as www.sun.com for example.
  • the name that is entered is not the actual Internet Protocol (IP) address of the intended web server.
  • IP address Internet Protocol
  • the actual IP address is a string of numbers that uniquely locate the web server that provides the web site data.
  • a worldwide distributed database system called the "Domain Name System (DNS)" provides the mapping between server names and the associated IP addresses.
  • DNS Domain Name System
  • DNS resolver a local library
  • IP address a predetermined local DNS server
  • DNS servers can maintain caches of previously resolved names. More specifically, name resolution processes typically require two hosts on the client side.
  • the client browser will talk with a local resolver (a library attached to the browser process itself, in the current example running on asha.eng.sun.com).
  • the local resolver will go to one of a relatively small number of local name servers, e.g. "ns.sun.com”.
  • ns.sun.com is called the client side name server.
  • the client side name server will communicate with the outside world to determine the IP address of whitehouse.com, and forward this information to the resolver that is part of the browser process.
  • DNS is a global network of servers that translate host names into numerical addresses (known as Internet Protocol, or IP addresses) and provides IP address to name mapping as well.
  • a DNS server consists of a name server and a resolver. The name server provides responses to resolver requests when it can by supplying the correct address for the host name supplied by the resolver. When the DNS server is unable to provide the correct address, it invokes its resolver to provide a solution. The resolver passes the unknown host name to another name server on the internet network and waits for a reply. If the next name server can provide the address for the host name, it does. Otherwise, the host name is forwarded to another name server, and this repeats until a name server is found that can translate the host name, or until it is determined that no translation exists.
  • the server with the correct translation then forwards it to the server that requested it, and that server returns it to the server that requested it from the second server, and so on until it is returned to the original name server, who can then return it to the client's resolver, who returns it to the browser.
  • the originally contacted name server then stores the translation in a local cache so that the next time it sees the host name, it can supply a translation without asking another name server.
  • the browser communicates with the web server at that address to retrieve the requested web page or other information.
  • An internet server is typically limited IN the number of clients it can efficiently service at any one time. However, the owners of an internet site do not want users to be denied access to their internet site. If the site is popular, internet site owners desire all attempted accesses to be successful.
  • the schemes involve the manner in which requests to the internet site address are routed to the multiple server.
  • One such scheme is called a DNS shuffle address or "round-robin".
  • the servers that respond are rotated in some order. If there are three servers in the distributed system, then any one of the servers handles every third request.
  • This scheme has a disadvantage of ignoring load balancing considerations and traffic localization considerations.
  • Another scheme uses a freely available script called "lbnamed" that provides a DNS server with the ability to return a different IP address for every client request received for a internet site host address.
  • the returned IP address can be made to depend on server load as well as availability of local internet servers, but ignores the relative distance between clients and the available servers.
  • a product by Cisco Systems known as "DistributedDirector” is a scheme that relies on internet routing tables to provide locality information.
  • the Cisco scheme imposes extra latency during servicing of DNS requests. It also suppresses DNS caching mechanisms, adding traffic to the internet. It also reacts to each change in the internet routing, which changes very frequently.
  • IBM has developed an "Interactive Network Dispatcher (IND) load balancing product. It consists of Interactive Session Support (ISS) and a Network Dispatcher (ND). For TCP/IP client requests, IND chooses a server cluster (via ISS) and then directs the client request to the appropriate server (via ND). ND routes the request to the chosen server transparently.
  • the ISS can generate load information on servers, can perform ping triangulation initiated at servers to determine the "nearest" server (cluster) to a client, and influence client routing of requests by supplying the necessary DNS replies. Load information is collected through load monitoring agents (advisors) near the servers. Multiple metrics are supported (e.g., CPU, DASD, I/O).
  • ISS provides its own DNS server implementation to generate the necessary DNS replies.
  • This scheme has the disadvantage of requiring modification of the existing DNS system.
  • Another approach is known as "smart clients" from U. C. Berkeley Research.
  • the smart client approach is an architecture for web traffic client- server communication that allows for a dynamic server choice based on load and availability.
  • the approach allows for the use of multiple server machines to achieve scalable performance, for load balancing, for fault transparency, and backwards compatibility with the existing addressing scheme (URLs).
  • the architecture requires client web browsers to execute downloadable, service specific code. This code is divided into a GUI thread and director thread. Server choice, load balancing, and fault transparency are encapsulated by the director thread.
  • a disadvantage of this scheme is that it requires cooperation of requesting clients. It imposes extensive overhead on single web page retrieval and surfing
  • the present invention uses a client-side computation to efficiently provide translation of a domain name to the address of a "good" (i.e. close, available, nearby) server of a distributed server system.
  • the invention uses an application client's resolver to perform some computation to determine the IP address of a preferred server for that client.
  • the DNS service returns data, or a small applet that runs at the browser's local resolver to generate the desired IP address.
  • the present invention is processed by the DNS server (in the resolver portion) and at the client.
  • the web server does not need to participate.
  • the invention does not require any changes to the current DNS infrastructure.
  • the invention also can direct clients to more local servers and avoid expensive "long-haul" links.
  • the invention also preserves the critical caching property of the current DNS system, has reduced latency than other schemes, less traffic for the network and DNS servers, and supports the use of secondary DNS servers.
  • Figure 1 is a block diagram of an example computer system that can be used with the present invention.
  • Figure 2 is a diagram illustrating an embodiment of the present invention.
  • Figure 3A is a diagram illustrating the operation of an embodiment of the present invention.
  • Figure 3B is a flow diagram illustrating the operation of an embodiment of the present invention.
  • the invention is a method and apparatus for providing effective traffic localization through the Domain Name System.
  • numerous specific details are set forth to provide a more thorough description of embodiments of the invention. It will be apparent, however, to one skilled in the art, that the invention may be practiced without these specific details. In other instances, well known features have not been described in detail so as not to obscure the invention.
  • the invention provides a system for providing IP addresses of servers in a distributed server system in a manner that provides efficient traffic localization.
  • the invention takes advantage of the existing DNS infrastructure and uses some client processing for server selection.
  • the server responds, when appropriate, with data, a table of data, or a thin client applet to the client browser.
  • the client's local resolver uses the data, table or applet to generate the IP address of a server that is a "best" server for the client.
  • the selected server may not be the optimal server for the client, but it may be one that promotes efficient use of network resources.
  • the invention has equal application when the DNS server provides either data, a table of data, or an applet.
  • the information will generally be referred to here as "table /applet”. Where appropriate, specific discussion of one of the possible forms of the information will be made. While the ensuing discussion uses the web service as a canonical example of an Internet service, the invention described herein applies equally well to all other internet services, including, but not limited to, the telnet service and the ftp service.
  • the invention is implemented via agents, servers, and clients.
  • the agents collect the network topology/load information at a particular web server farm, and provide it to the DNS server for this service. (Here, a web server farm refers to a set of nearby servers that work together).
  • the servers obtain the load /topology information from many agents, and use the information to generate a single applet/table.
  • the clients employ the applet/table to choose from the available IP addresses for the given server name.
  • FIG. 2 A diagram of the present invention is illustrated in Figure 2.
  • a distributed server system serves the web site
  • the Sun Primary DNS server 205 includes a resolver library 206 and is coupled to a DNS database 203 and cache 204.
  • the Sun primary DNS server 205 handles requests from other resolvers such as request 207. This request can come from a client browser resolver, or from other DNS servers.
  • the DNS server 205 handles the request and sends reply 208.
  • DNS server 205 When DNS server 205 receives a request to resolve the host name sun.com into an IP address, it provides a table /applet as a reply 208 to the requesting resolver.
  • the distance /metric tables are created by agents collecting network topology and load information. This is done at a particular web server farm and the information is provided to the DNS server that serves the web site.
  • the agent is a process that is used by any distributed server system that desires to take advantage of the present invention.
  • the agents could use any of a number of processes to obtain the necessary information.
  • IBM uses ping triangulation to obtain approximate delay information.
  • One description of collecting information from ping requests and incorporated herein by reference is described at http://www.internetweather.com based on 45 packet (one packet/second) ping tests with 210 byte packets between a central site and the primary domain server for a number of networks.
  • Cisco uses BGP information from its own routers to get this information.
  • Another way is to get the picture from routing tables at major exchange points (for example, the web site www.merit.edu provides routing table snapshots). Links to information regarding these methods may be found at the Cooperative Association for Internet Data Analysis (CAIDA) at http://www.caida.org and incorporated herein by reference.
  • CAIDA Cooperative Association for Internet Data Analysis
  • the information does not have to be precise. It may be possible to define ranges of IP addresses that define groups of servers. Consider where servers are defined in groups A, B, and C. Information that shows that server cluster hosts in group A are served by same ISP, hosts in group B have to go through one major exchange, and those in group C have to go through expensive, under-provisioned international routes are usable in the present invention.
  • the machine load average may be used.
  • it may be suitable to measure the weighted tail average of connection set up rate, or the disk I/O rate, and normalize this by the machine capacity.
  • Another option would be to periodically connect to the server process from a nearby client (or same machine), and use the time-to- connect as an estimate of the machine load. This can also be used to calibrate the server when using other metrics (connection set-up average, disk I/O etc.)
  • the servers are responsible for collating the topology/load information that the agents provide and to use this information to generate the table /applet.
  • the agents could provide a table for each server as shown in Tables 1 and 2 below.
  • the server could merge together this information by going through all the client tables in parallel and working through the different address blocks. For each block, the server could choose the best server of the distributed servers through a combination of locality and load information. This information can be placed in a generated table which is returned in a new DNS record type.
  • Table 3 One example of such a merged table is illustrated below in Table 3.
  • One option would be to restrict the generated table to provide only one choice to each client, depending on the client IP address. For example, if the client IP address is within a certain range, one server in the server farm would be identified as the appropriate server for the web site. Another option is to allow clients a small number of choices. The client can choose nearness or locality in "hard” cases. Letting a client choose among several choices may provide a degree of randomization that leads to improved balancing among several nearby servers. An alternate and more dynamic option would have the applet periodically query a "load-server" to refresh the table information. (Note that in these cases, the server should manage the TTL information that it returns to the resolver).
  • the client-side code resides in the resolver. It is responsible for sending the DNS lookup request to the DNS server, accepting the returned applet /table from the DNS server, to run the applet /table code to choose the IP address that the server name maps to, and to return this IP address to the requesting application.
  • This component should be the simplest part of this system - all it depends on is the language used for shipping the condensed server load/locality information in the applet/table. If the applet is a JavaTM applet, this component just executes the JavaTM programming language bytecode. If the returned information is a simple table, this component looks up the table to find the entry that corresponds to the client IP address.
  • the information distributed by the DNS is limited to the full set of server IP addresses.
  • Clients make the choice of which server to contact after the DNS resolution step, before the actual request is made. There are at several options to how clients can make this choice, including, but not limited to, client initiated ping triangulation, client initiated timing service request, random choice, cost-based choice, or no choice (where the system provides only one address, or the client always chooses just one).
  • the client initiated ping triangulation may suffer from measurement problems.
  • the client initiated timing approach is to send a minimal service request to all servers listed in the table and measure the response time. For example, in absence of a standard timing service request, a Web client could request the retrieval of a file that would not be served (e.g.,/dev/null) and measure the arrival of the corresponding HTTP error message.
  • This approach suffers from some of the ping triangulation problems, but has no firewall filtering problems, for example. This approach gains in attractiveness if the availability of HTTP over hybrid TCP-UDP is assumed.
  • the fake request would be intercepted by the network dispatcher and its reply could be artificially delayed based on the load characteristics present at the network dispatcher.
  • FIG. 3A illustrates the relationship between the client browser and the DNS server in an embodiment of the present invention.
  • the client browser 390 has an associated DNS resolver 391.
  • the DNS resolver 391 initiates a request to a DNS server 392 for translation.
  • the DNS server 392 replies to the DNS resolver 391 with an IP address or with a table/applet.
  • a browser user or application enters a host name into the browser.
  • the browser requests a translation of the host name from its DNS resolver.
  • the argument "Name Cached?" is made. This is to determine if the DNS resolver already has a translation for the requested name. If the argument at decision block 303 is false, meaning the name is not cached, the DNS resolver contacts the DNS server at step 304 and initiates a request.
  • the DNS resolver receives an answer (IP address), a table, an applet, or an error message from the DNS server.
  • the DNS server could provide any of several possible responses. If the host name is for a site that does not use a distributed web server system, the DNS server returns an answer that is an IP address. Even when the host name is for a site that uses a distributed web server system, the DNS server could return an IP address in one embodiment of the invention, if it is desired to have processing and choices made at the DNS server. In another embodiment of the invention, the DNS server returns a table or an applet for a host name that is for a web site using a distributed web server system. After step 305, the system proceeds to step 306.
  • the system proceeds to decision block 306. Note that if the name is cached, it could be translated to either an IP address (answer) or a table /applet. At decision block 306 the argument "Answer or Table/Applet?" is made. If the DNS response (or cached translation) is an answer, the DNS resolver provides the answer (IP address) to the browser at step 307.
  • the system proceeds to decision block 308.
  • decision block 308 it is determined whether an applet executable or a table has been returned. If it is a table, the client finds its own client IP address in the provided table at step 309 (this may involve finding a specific entry for its IP address, or a range of IP addresses that contain its own IP address).
  • the client links to the web server IP address returned based on its own client IP address.
  • the client determines it has received an applet
  • the client executes the applet bytecode at step 311 to retrieve a server IP address.
  • the client then links to the retrieved web server IP address at step 312.
  • the client can identify an appropriate server based on a number of factors. For example, the client may be presented with several servers to choose from, with better service available at higher cost (at a fee based web site for example).
  • the client can predetermine criteria for selecting an appropriate server.
  • a client may define connection speed as the most important factor in choosing a server, irrespective of cost. Alternately, a client could define a minimum connection speed that might be met by servers of different costs at certain times of day. In other cases, the client could preclude servers that have any extra cost associated and therefore only choose from no-cost servers.
  • Clients can also choose a server based on geographical proximity to the client, or on network proximity to the client.
  • the steps of finding the web server IP address may be accomplished by a simple look up, or by choosing from several possible IP addresses based on the lookup, or after a locality determination as outlined above.
  • An embodiment of the invention can be implemented as computer software in the form of computer readable code executed on a general purpose computer such as computer 100 illustrated in Figure 1, or in the form of bytecode class files executable within a JavaTM runtime environment running on such a computer.
  • a keyboard 110 and mouse 111 are coupled to a bi-directional system bus 118. The keyboard and mouse are for introducing user input to the computer system and communicating that user input to processor 113. Other suitable input devices may be used in addition to, or in place of, the mouse 111 and keyboard 110.
  • I/O (input /output) unit 119 coupled to bi-directional system bus 118 represents such I/O elements as a printer, A/V (audio/video) I/O, etc.
  • Computer 100 includes a video memory 114, main memory 115 and mass storage 112, all coupled to bi-directional system bus 118 along with keyboard 110, mouse 111 and processor 113.
  • the mass storage 112 may include both fixed and removable media, such as magnetic, optical or magnetic optical storage systems or any other available mass storage technology.
  • Bus 118 may contain, for example, thirty-two address lines for addressing video memory 114 or main memory 115.
  • the system bus 118 also includes, for example, a 32-bit data bus for transferring data between and among the components, such as processor 113, main memory 115, video memory 114 and mass storage 112. Alternatively, multiplex data/address lines may be used instead of separate data and address lines.
  • the processor 113 is a microprocessor manufactured by Motorola, such as the 680X0 processor or a microprocessor manufactured by Intel, such as the 80X86, or Pentium processor, or a SPARCTM microprocessor from Sun MicrosystemsTM, Inc.
  • Main memory 115 is comprised of dynamic random access memory (DRAM).
  • Video memory 114 is a dual-ported video random access memory. One port of the video memory 114 is coupled to video amplifier 116. The video amplifier 116 is used to drive the cathode ray tube (CRT) raster monitor 117. Alternatively, the video memory could be used to drive a flat panel or liquid crystal display (LCD), or any other suitable data presentation device.
  • DRAM dynamic random access memory
  • Video memory 114 is a dual-ported video random access memory. One port of the video memory 114 is coupled to video amplifier 116. The video amplifier 116 is used to drive the cathode ray tube (CRT) raster monitor 117. Alternatively, the video memory could be used to drive
  • Video amplifier 116 is well known in the art and may be implemented by any suitable apparatus. This circuitry converts pixel data stored in video memory 114 to a raster signal suitable for use by monitor 117. Monitor 117 is a type of monitor suitable for displaying graphic images.
  • Computer 100 may also include a communication interface 120 coupled to bus 118.
  • Communication interface 120 provides a two-way data communication coupling via a network link 121 to a local network 122.
  • a network link 121 For example, if communication interface 120 is an integrated services digital network (ISDN) card or a modem, communication interface 120 provides a data communication connection to the corresponding type of telephone line, which comprises part of network link 121.
  • ISDN integrated services digital network
  • LAN local area network
  • communication interface 120 sends and receives electrical, electromagnetic or optical signals which carry digital data streams representing various types of information.
  • Network link 121 typically provides data communication through one or more networks to other data devices.
  • network link 121 may provide a connection through local network 122 to local server computer 123 or to data equipment operated by an Internet Service Provider (ISP) 124.
  • ISP 124 in turn provides data communication services through the world wide packet data communication network now commonly referred to as the "Internet" 125.
  • Internet 125 uses electrical, electromagnetic or optical signals which carry digital data streams.
  • the signals through the various networks and the signals on network link 121 and through communication interface 120, which carry the digital data to and from computer 100, are exemplary forms of carrier waves transporting the information.
  • Computer 100 can send messages and receive data, including program code, through the network(s), network link 121, and communication interface 120.
  • remote server computer 126 might transmit a requested code for an application program through Internet 125, ISP 124, local network 122 and communication interface 120.
  • the received code may be executed by processor 113 as it is received, and /or stored in mass storage 112, or other non-volatile storage for later execution. In this manner, computer 100 may obtain application code in the form of a carrier wave.
  • Application code may be embodied in any form of computer program product.
  • a computer program product comprises a medium configured to store or transport computer readable code, or in which computer readable code may be embedded.
  • Some examples of computer program products are CD-ROM disks, ROM cards, floppy disks, magnetic tapes, computer hard drives, servers on a network, and carrier waves.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)

Abstract

La présente invention utilise le calcul côté client pour assurer la traduction efficace d'un nom de domaine vers l'adresse d'un 'bon' (c'est-à-dire proche, disponible, voisin) serveur d'un système de serveurs répartis. L'invention utilise un interpréteur du client de l'application pour effectuer quelques calculs afin de déterminer l'adresse IP d'un serveur préféré pour ce client. Lorsque le client fournit à l'interpréteur de DNS le nom du serveur Web (p.ex., www.sun.com), le service DNS retourne des données ou une petite appliquette qui tourne sur l'interpréteur local du navigateur pour générer l'adresse IP désirée. Le traitement de l'objet de la présente invention se fait par le serveur DNS (dans la partie interpréteur) et chez le client. Le serveur Web n'est pas obligé d'y participer. L'invention ne nécessite aucun changement de la structure DNS existante. L'invention peut également diriger les clients vers d'autres serveurs locaux en évitant les coûteuses liaisons 'longue distance'. Elle permet de préserver la propriété tampon critique du système DNS existant, possède une latence réduite par rapport aux autres schémas, représente moins de trafic pour le réseau et les serveurs DNS et prend en charge l'utilisation de serveurs DNS secondaires.
PCT/US1999/010942 1998-05-19 1999-05-18 Procede et appareil de localisation efficace du trafic circulant a travers un systeme de nom par domaine WO1999060459A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU40836/99A AU4083699A (en) 1998-05-19 1999-05-18 Method and apparatus for effective traffic localization through domain name system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US8186098A 1998-05-19 1998-05-19
US09/081,860 1998-05-19

Publications (1)

Publication Number Publication Date
WO1999060459A2 true WO1999060459A2 (fr) 1999-11-25

Family

ID=22166870

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1999/010942 WO1999060459A2 (fr) 1998-05-19 1999-05-18 Procede et appareil de localisation efficace du trafic circulant a travers un systeme de nom par domaine

Country Status (2)

Country Link
AU (1) AU4083699A (fr)
WO (1) WO1999060459A2 (fr)

Cited By (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001040932A2 (fr) * 1999-11-30 2001-06-07 Elata (Holdings) Limited Systeme et procede pour commander plusieurs serveurs
WO2001086872A2 (fr) * 2000-05-05 2001-11-15 Telefonaktiebolaget Lm Ericsson (Publ) Procede de filtrage de reponses a un message de demande de multi-diffusion
EP1164769A1 (fr) * 2000-06-14 2001-12-19 Alcatel Système de télécommunication, et réseau, et terminal, et générateur, et méthode
WO2002039238A2 (fr) * 2000-11-13 2002-05-16 Schneider Automation Inc. Surveillance a distance d'utilisateurs de systemes d'automatisation d'usines
WO2003009565A1 (fr) * 2001-07-16 2003-01-30 Telefonaktiebolaget Lm Ericsson (Publ) Transfert de donnees police dans des reseaux 3gpp
WO2003026219A1 (fr) * 2001-09-18 2003-03-27 Ericsson Inc. Selection adaptative de noeuds
WO2003048956A1 (fr) * 2001-12-03 2003-06-12 Kent Ridge Digital Labs Systeme d'hebergement d'applications logicielles sur des serveurs distribues, dispositif et procede correspondants
US6728785B1 (en) 2000-06-23 2004-04-27 Cloudshield Technologies, Inc. System and method for dynamic compression of data
US6829654B1 (en) 2000-06-23 2004-12-07 Cloudshield Technologies, Inc. Apparatus and method for virtual edge placement of web sites
US7032031B2 (en) 2000-06-23 2006-04-18 Cloudshield Technologies, Inc. Edge adapter apparatus and method
US7082502B2 (en) 2001-05-15 2006-07-25 Cloudshield Technologies, Inc. Apparatus and method for interfacing with a high speed bi-directional network using a shared memory to store packet data
US7114008B2 (en) 2000-06-23 2006-09-26 Cloudshield Technologies, Inc. Edge adapter architecture apparatus and method
US7210022B2 (en) 2001-05-15 2007-04-24 Cloudshield Technologies, Inc. Apparatus and method for interconnecting a processor to co-processors using a shared memory as the communication interface
US7995504B2 (en) 2008-05-12 2011-08-09 Microsoft Corporation Locality-based routing table generation
US8204082B2 (en) 2000-06-23 2012-06-19 Cloudshield Technologies, Inc. Transparent provisioning of services over a network
US8694610B2 (en) 2000-06-23 2014-04-08 Cloudshield Technologies, Inc. Apparatus and method for domain name resolution
US9444785B2 (en) 2000-06-23 2016-09-13 Cloudshield Technologies, Inc. Transparent provisioning of network access to an application

Cited By (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001040932A2 (fr) * 1999-11-30 2001-06-07 Elata (Holdings) Limited Systeme et procede pour commander plusieurs serveurs
WO2001040932A3 (fr) * 1999-11-30 2001-11-01 Elata Plc Systeme et procede pour commander plusieurs serveurs
WO2001086872A2 (fr) * 2000-05-05 2001-11-15 Telefonaktiebolaget Lm Ericsson (Publ) Procede de filtrage de reponses a un message de demande de multi-diffusion
WO2001086872A3 (fr) * 2000-05-05 2002-02-28 Ericsson Telefon Ab L M Procede de filtrage de reponses a un message de demande de multi-diffusion
EP1164769A1 (fr) * 2000-06-14 2001-12-19 Alcatel Système de télécommunication, et réseau, et terminal, et générateur, et méthode
WO2001097484A1 (fr) * 2000-06-14 2001-12-20 Alcatel Systeme, reseau, terminal, generateur et procede de telecommunication
US8576881B2 (en) 2000-06-23 2013-11-05 Cloudshield Technologies, Inc. Transparent provisioning of services over a network
US7032031B2 (en) 2000-06-23 2006-04-18 Cloudshield Technologies, Inc. Edge adapter apparatus and method
US9444785B2 (en) 2000-06-23 2016-09-13 Cloudshield Technologies, Inc. Transparent provisioning of network access to an application
US9258241B2 (en) 2000-06-23 2016-02-09 Cloudshield Technologies, Inc. Transparent provisioning of services over a network
US7437482B2 (en) 2000-06-23 2008-10-14 Cloudshield Technologies, Inc. Method and apparatus for facilitating client server communications over a network
US6728785B1 (en) 2000-06-23 2004-04-27 Cloudshield Technologies, Inc. System and method for dynamic compression of data
US8694610B2 (en) 2000-06-23 2014-04-08 Cloudshield Technologies, Inc. Apparatus and method for domain name resolution
US6829654B1 (en) 2000-06-23 2004-12-07 Cloudshield Technologies, Inc. Apparatus and method for virtual edge placement of web sites
US7624142B2 (en) 2000-06-23 2009-11-24 Cloudshield Technologies, Inc. System and method for processing packets according to user specified rules governed by a syntax
US9634943B2 (en) 2000-06-23 2017-04-25 Cloudshield Technologies, Inc. Transparent provisioning of services over a network
US7330908B2 (en) 2000-06-23 2008-02-12 Clouldshield Technologies, Inc. System and method for processing packets using location and content addressable memories
US7114008B2 (en) 2000-06-23 2006-09-26 Cloudshield Technologies, Inc. Edge adapter architecture apparatus and method
US7570663B2 (en) 2000-06-23 2009-08-04 Cloudshire Technologies, Inc. System and method for processing packets according to concurrently reconfigurable rules
US8204082B2 (en) 2000-06-23 2012-06-19 Cloudshield Technologies, Inc. Transparent provisioning of services over a network
US7844740B2 (en) 2000-06-23 2010-11-30 Cloudshield Technologies, Inc. System and method for dynamic compression of data
WO2002039238A2 (fr) * 2000-11-13 2002-05-16 Schneider Automation Inc. Surveillance a distance d'utilisateurs de systemes d'automatisation d'usines
US6961633B1 (en) 2000-11-13 2005-11-01 Schneider Automation Inc. Remote monitoring of factory automation users
WO2002039238A3 (fr) * 2000-11-13 2003-07-10 Schneider Automation Surveillance a distance d'utilisateurs de systemes d'automatisation d'usines
US7082502B2 (en) 2001-05-15 2006-07-25 Cloudshield Technologies, Inc. Apparatus and method for interfacing with a high speed bi-directional network using a shared memory to store packet data
US7428618B2 (en) 2001-05-15 2008-09-23 Cloudshield Technologies, Inc. Apparatus and method for interfacing with a high speed bi-directional network
US7318144B2 (en) 2001-05-15 2008-01-08 Cloudshield Teechnologies, Inc. Apparatus and method for interconnecting a processor to co-processors using shared memory
US7210022B2 (en) 2001-05-15 2007-04-24 Cloudshield Technologies, Inc. Apparatus and method for interconnecting a processor to co-processors using a shared memory as the communication interface
US7120156B2 (en) 2001-07-16 2006-10-10 Telefonaktiebolaget Lm Ericsson (Publ) Policy information transfer in 3GPP networks
WO2003009565A1 (fr) * 2001-07-16 2003-01-30 Telefonaktiebolaget Lm Ericsson (Publ) Transfert de donnees police dans des reseaux 3gpp
US6748434B2 (en) 2001-09-18 2004-06-08 Ericsson Inc. Adaptive node selection
WO2003026219A1 (fr) * 2001-09-18 2003-03-27 Ericsson Inc. Selection adaptative de noeuds
WO2003048956A1 (fr) * 2001-12-03 2003-06-12 Kent Ridge Digital Labs Systeme d'hebergement d'applications logicielles sur des serveurs distribues, dispositif et procede correspondants
US7995504B2 (en) 2008-05-12 2011-08-09 Microsoft Corporation Locality-based routing table generation

Also Published As

Publication number Publication date
AU4083699A (en) 1999-12-06

Similar Documents

Publication Publication Date Title
US6724733B1 (en) Method and apparatus for determining approximate network distances using reference locations
EP1110361A2 (fr) Procede et dispositif de traitement en transparence du trafic dns
US6438598B1 (en) System and method for transmitting data from a server application to more than one client node
WO1999060459A2 (fr) Procede et appareil de localisation efficace du trafic circulant a travers un systeme de nom par domaine
US7925713B1 (en) Method for operating an integrated point of presence server network
US6405252B1 (en) Integrated point of presence server network
US6360262B1 (en) Mapping web server objects to TCP/IP ports
US7225254B1 (en) Performance computer network method
US6397253B1 (en) Method and system for providing high performance Web browser and server communications
US7861174B2 (en) Method and system for assembling concurrently-generated content
US7831712B1 (en) System and method for performing application level persistence
EP0889418A2 (fr) Résolution d'adresses URL abstraites par un service de redirection
US6763382B1 (en) Method and apparatus for demand based paging algorithm
US7689430B2 (en) Access to web services
US6970933B1 (en) Enabling application level persistence between a server and another resource over a network
WO2006018713A1 (fr) Systeme, dispositif et procede de transfert de donnees
WO2002080014A1 (fr) Assemblage de contenu de pages web personnalisees realisees parallelement
EP1017202A2 (fr) Système et méthode pour la transmission de données d'une application serveur à des noeuds clients
WO2001039003A1 (fr) Procede d'utilisation d'un point de integre de reseau de presence serveur
US20020065936A1 (en) Multi-platform application
CN1317849C (zh) 一种网络管理系统和方法
WO2002039699A1 (fr) Extensions de systeme de nom de domaine destinees a supporter des operations de mandataires inverses et des reacheminements de couche 7
US20020133572A1 (en) Apparatus and method for providing domain name services to mainframe resource mapping
EP1360598B1 (fr) Assemblage de contenu de pages web personnalisées realisées parallelement

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK 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 MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW SD SL SZ 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 BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: KR

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase