Electrical computers and digital processing systems: multicomput – Computer-to-computer data addressing
Reexamination Certificate
1999-08-06
2002-09-10
Burgess, Glenton B. (Department: 2153)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data addressing
C709S203000, C705S014270
Reexamination Certificate
active
06449657
ABSTRACT:
FIELD OF THE INVENTION
The field of the present invention generally relates to networking, and more particularly, to methods and techniques for hosting internet services on a network.
BACKGROUND
The Internet has become a very popular global electronic communication network that has brought about a wide variety of on-line services and development of the World Wide Web (WWW). The number of computers and users accessing the Internet continues to increase rapidly.
Computers on the Internet generally exchange information in the form of packets or datagrams with each other using unique addresses, known as host addresses. The most common form of a host address is an Internet Protocol (IP) address, which is presently a four part sequence of numbers that uniquely identify a particular computer on the Internet. An example of a host address is the IP address “206.71.200.33”.
Users commonly access the Internet through one or more clients and servers. Each client and server generally consists of hardware equipment executing one or more software processes that maintain connections to various networked computers. Perhaps the most common tool employed by users for connecting to the Internet is a client or user program called a “browser”. Netscape Corporation's Navigator and Microsoft Corporation's Internet Explorer are two forms of browsers, also known as “web clients”. Other forms of interaction on the Internet include electronic mail (e-mail), wherein one user sends electronic messages addressed to another user, usually through a mail client such as Qualcomm's Eudora Lite mail client.
Users generally do not use host addresses to connect their clients to remote computers or servers on the Internet. Rather, users employ host names, or “domain names” to access a particular computer or server on the Internet. In current Internet parlance, domain names are generally comprised of alphanumeric characters that correspond to a host address on the Internet. An example of a domain name is “yahoo.com”.
Domain names generally comprise multiple parts. A root name or top level domain is the ending suffix on a domain name. Examples of top level domains, or root names, include “edu”, “com”, and “org”. Second level domains immediately follow a top level domain (generally a period, also known as “dot”, separates levels of a domain). Examples of second level domains include “mit”, “yahoo” and “icann”. Multiple additional domain levels can be added to a domain to yield a complete domain name, such as “www.yahoo.com.”
As used in a web client, the domain name might be “http://www.yahoo.com” (the “http://” portion specifying the hypertext transfer protocol (HTTP) proxy), whereas in a mail client, the domain might be in the format of an e-mail address, such as “mailto:alice@smith.com” (the “mailto:” portion specifying the simple mail transfer protocol (SMTP) proxy).
To provide a transparent mapping between host names and host addresses to users, a domain name system is employed. The domain name system, or DNS, in current use on the Internet is generally described in a technical specification known as Internet RFC 1034, entitled “Domain Names—Concepts and Facilities,” and additional features thereof are described in a related technical specification known as Internet RFC 1035, entitled “Domain Names—Implementation and Specification,” both of which are authored by P. Mockepetris.
The domain name system described in RFC 1034 has three major components: (1) domain name space and records, which collectively comprise a tree-type data structure used for the mapping; (2) name servers, which are server programs that hold information about the tree structure and point to other name servers that hold information about the tree structure; and (3) resolvers, which are client programs that extract information from name servers in response to client requests.
One configuration for a domain name system (DNS), and the DNS envisioned by RFCs 1034 and 1035, is depicted as a flow diagram in
FIG. 1. A
shared database holds domain space data for a local name server and a resolver that are associated with a local host.
The contents of the shared database will typically be a mixture of authoritative data maintained by periodic refresh operations from master files by the name server, and non-authoritative cached data from previous resolution requests or maintenance queries that were answered by one or more foreign name servers. The contents of the shared database are generally in the form a flat file comprising a plurality of resource records (RRs). Resource records correlate a particular host name or domain name with its host address and other protocol information on the Internet. As such, resource records generally comprise a number of fields. It should be noted that the name server is responsible for maintaining current resource records for the domain names for which it is the authority and any other non-authoritative domain names specified by the domain name system.
The shared database is generally not a typical database. The shared database is called such because it represents a plurality of resource records distributed among various computer systems (or other domain name systems) throughout the Internet. Although the shared database might have somewhat current resource records for which it is the authority (or in its “zone”), the resource records for which it is not the authority must be periodically updated or “refreshed” from multiple foreign resolvers or from foreign name servers. Theses refresh operations are performed to account for changes in the mappings between host names and host addresses. This process occurs for authoritative resource records too. The shared database is thus a distributed resource record database and is inextricably tied to other authoritative domain name systems on the Internet in order to operate in view of RFC 1034 and 1035. As such, a highly coherent or synchronized view of the database is unlikely, given the highly distributed nature of the Internet and the number of domains therein.
When a user program, such as the browser, requests information from, or attempts to send information to a particular host name, a resolution request is passed in the form of a query to the resolver. The query uses as arguments a proxy, a host name, and other data. The resolver will check the shared database for a corresponding host address to the host name in the shared database or from the name server. If a corresponding resource record exists in the shared database, it will be returned to the resolver and then to the user program. However, if a resource record does not exist, then the resolution request is passed on to a local name server (for authoritative data) or to a foreign name server (for non-authoritative data).
The set of domains for which a particular name server is the authority is commonly referred to as a zone. Data outside the zone is the responsibility of another name server. When a resolution request is made for non-authoritative data—data that is also not present in the shared database—the response is handled as a “zone transfer”. To resolve the resolution request, the request is passed on to a foreign name server, preferably the name server that is the authority for the domain name. Various techniques can be employed to resolve such requests for non-authoritative data.
In particular, it is noted that because a foreign name server will resolve such requests, the latency between the query and the response can be great. The prior domain name system, as described in RFC 1034, envisions that zone transfers should be non-blocking, meaning that zone transfers should be handled immediately—that a second zone transfer should not wait for a first zone transfer to be completed before handling the second zone transfer. Thus, valuable execution processing cycles will not be wasted while the foreign name server performs the work.
However, when authoritative requests are made or requests for non-authoritative data that is contained in the shared database, known domain name systems block concu
Hoffman Daniel G.
Keiser Bruce R.
Stanbach, Jr. Francis J.
Burgess Glenton B.
Edelman Bradley
Irell & Manella LLP
Namezero.com, Inc.
LandOfFree
Internet hosting system does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Internet hosting system, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Internet hosting system will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2841653