Electrical computers and digital processing systems: multicomput – Computer-to-computer session/connection establishing
Reexamination Certificate
1997-03-14
2002-10-22
Meky, Moustafa M. (Department: 2153)
Electrical computers and digital processing systems: multicomput
Computer-to-computer session/connection establishing
C709S245000
Reexamination Certificate
active
06470389
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates generally to data communication networks such as the Internet and more particularly to techniques for hosting network services on a cluster of servers used to deliver data over a network in response to client requests, where the cluster of servers can be collectively identified by a client using a single-address image.
BACKGROUND OF THE INVENTION
With the explosive growth of the World Wide Web, many popular Internet web sites are heavily loaded with client requests. For example, it has been reported in S. L. Garfinkel, “The Wizard of Netscape,” Webserver Magazine, July/August 1996, pp. 59-63, that home pages of Netscape Communications receive more than 80 million client requests or “hits” per day. A single server hosting a service is usually not sufficient to handle this type of aggressive growth. As a result, clients may experience slow response times and may be unable to access certain web sites. Upgrading the servers to more powerful machines may not always be cost-effective. Another common approach involves deploying a set of machines, also known as a cluster, and configuring the machines to work together to host a single service. Such a server cluster should preferably publicize only one server name for the entire cluster so that any configuration change inside the cluster does not affect client applications. The World Wide Web and other portions of the Internet utilize an application-level protocol, known as the Hypertext Transfer Protocol (HTTP), which is based on a client/server architecture. The HTTP protocol is described in greater detail in “Hypertext Transfer Protocol—HTTP/1.0,” Network Working Group, May 1996, <http://www.ics.uci.edu/pub/ ietf/http>, which is incorporated by reference herein.
FIG. 1
illustrates an exemplary client/server architecture suitable for implementing HTTP-based network services on the Internet. A client
12
generates an HTTP request for a particular service, such as a request for information associated with a particular web site, and a Transmission Control Protocol/Internet Protocol (TCP/IP) connection is then established between the client
12
and a server
14
hosting the service. The client request is delivered to the server
14
in this example via a TCP/IP connection over a first network
16
, a router
18
and a second network
20
. The first network
16
may be a wide area communication network such as the Internet, while the second network
20
may be an Ethernet or other type of local area network (LAN) interconnecting server
14
with other servers in a server cluster. The router
18
, also referred to as a gateway, performs a relaying function between the first and second networks which is transparent to the client
12
.
The client request is generated by a web browser or other application-layer program operating in an application layer
22
-
1
of the client
12
, and is responded to by a file transfer system or other program in an application layer
22
-
2
of the server
14
. The requested network service may be designated by a Uniform Resource Locator (URL) which includes a domain name identifying the server
14
or a corresponding server cluster hosting the service. The application-level program of the client
12
initiates the TCP/IP connection by requesting a local or remote Domain Name Service (DNS) to map the server domain name to an IP address. The TCP and IP packet routing functions in client
12
and server
14
are provided in respective TCP layers
24
-
1
,
24
-
2
and IP layers
26
-
1
,
26
-
2
. The TCP and IP layers are generally associated with the transport and network layers, respectively, of the well-known Open Systems Interconnection (OSI) model. The TCP layers
24
-
1
,
24
-
2
process TCP packets of the client request and server response. The TCP packets each include a TCP header identifying a port number of the TCP connection between the client
12
and server
14
. The IP layers
26
-
1
,
26
-
2
process IP packets formed from the TCP packets of the TCP layers. The IP packets each include an IP header identifying an IP address of the TCP/IP connection between the client
12
and server
14
.
The IP address for a given network service may be determined, as noted above, by the client accessing a conventional DNS. The IP layer
26
-
1
of the client
12
uses the resulting IP address as a destination address in the IP packet headers of client request packets. The IP address together with the TCP port number provide the complete transport address for the HTTP server process. The client
12
and server
14
also include data link and physical layers
28
-
1
for performing framing and other operations to configure client request or reply packets for transmission over the networks
16
and
20
. The router
18
includes data link and physical layers
28
-
3
for converting client request and server reply packets to IP format, and an IP layer
26
-
3
for performing packet routing based on IP addresses. The server
14
responds to a given client request by supplying the requested information over the established TCP/IP connection in a number of reply packets. The TCP/IP connection is then closed.
There are many known techniques for distributing HTTP client requests to a cluster of servers.
FIGS. 2 and 3
illustrate server-side single-IP-address image approaches which present a single IP address to the clients. An example of this approach is the TCP router approach described in D. M. Dias, W. Kish, R. Mukherjee and R. Tewari, “A Scalable and Highly Available Web Server,” Proceedings of COMPCON '96, pp.85-92,1996, which is incorporated by reference herein.
FIG. 2
illustrates the TCP router approach in which a client
12
establishes a TCP/IP connection over Internet
30
with a server-side router
32
having an IP address RA. The router
32
is connected via a LAN
36
to a server cluster
34
including N servers
14
-i, i =1, 2, . . . N, having respective IP addresses S
1
, S
2
, . . . SN. Each server of the cluster
34
generally provides access to the same set of contents, and the contents may be replicated on a local disk of each server, shared on a network file system, or served by a distributed file system.
The single-address image is achieved by publicizing the address RA of the server-side router
32
to the clients via the DNS. The client
12
therefore uses RA as a destination IP address in its request. The request is directed to the router
32
, which then dispatches the request to a selected server
14
-k of server cluster
34
based on load characteristics, as indicated by the dashed line connecting client
12
to server
14
-k via router
32
. The router
32
performs this dispatching function by changing the destination IP address of each incoming IP packet of a given client request from the router address RA to the address Sk of selected server
14
-k. The selected server
14
-k responds to the client request by sending reply packets over the established TCP/IP connection, as indicated by the dashed line connecting server
14
-k to client
12
. In order to make the TCP/IP connection appear seamless to the client
12
, the selected server
14
-k changes the source IP address in its reply packets from its address Sk to the router address RA. The advantages of this approach are that it does not increase the number of TCP connections, and it is totally transparent to the clients. However, since the above-noted source IP address change is performed at the IP layer in a given server, the kernel code of every server in the cluster has to be modified to implement this mechanism. A proposed hybrid of the DNS approach and the TCP router approach, in which a DNS server selects one of several clusters of servers using a round-robin technique, suffers from the same problem.
FIG. 3
illustrates a server-side single-address image approach known as network address translation, as described in greater detail in E. Anderson, D. Patterson and E. Brewer, “The Magicrouter, an Application of Fast Packet Interposing,” Symposium on Operat
Chung Pi-Yu
Damani Om P.
Huang Yennun
Kintala Chandra M.
Wang Yi-Min
Kupstas Tod
Meky Moustafa M.
Ryan & Mason & Lewis, LLP
LandOfFree
Hosting a network service on a cluster of servers using a... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Hosting a network service on a cluster of servers using a..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Hosting a network service on a cluster of servers using a... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2925665