Error detection/correction and fault detection/recovery – Data processing system error or fault handling – Reliability and availability
Reexamination Certificate
2001-11-13
2004-06-08
Trammell, James P. (Department: 3621)
Error detection/correction and fault detection/recovery
Data processing system error or fault handling
Reliability and availability
C714S011000
Reexamination Certificate
active
06748554
ABSTRACT:
TECHNICAL FIELD
This invention relates to servers for computer network systems. More particularly, this invention relates to a server architecture that implements a dynamic content method for generating client responses.
BACKGROUND
A computer network system has one or more host network servers connected to serve data to one or more client computers over a network.
FIG. 1
shows a simple computer network system
20
with a single host network server
22
connected to serve data to a client
24
via a network
26
. The client
24
sends a request for data and/or services to the server
22
over the network
26
. The server
22
processes the request and returns a response over the network
26
. If the request is for data, the server
22
accesses a database
28
to retrieve the requested data
30
and returns the data
30
as part of the response.
The client-server system
20
is representative of many different environments. One particular environment of interest is the Internet. The server
22
runs a Web server software program that accepts requests from client-based programs (e.g., browsers) and returns data
30
in the form of Web pages or documents to the client
24
. The Web pages are commonly written in HTML (hypertext markup language) and XML (extensible markup language). Web pages are transmitted using conventional network protocols, such as TCP/IP (Transmission Control Protocol/Internet Protocol), HTTP (Hypertext Transfer Protocol) and DCOM (Distributed Component Object Model). The client
24
executes a browser or application to render the Web page into human-perceptible forms. A Web document might include text, images, sound, video, active code, and so forth.
Documents served from a server to client are typically generated using either or both of two methods: a static content method and a dynamic content method. In a static content method, the document is created in advance and stored statically on a server database. When a client requests the document, the server retrieves the document and transmits it over the network to the client.
FIG. 1
is an example in which the server retrieves the static data
30
from database
28
and serves the data to the client
24
. It is further noted that conventional servers, and particularly Web servers, may be configured to push the content to the client without receiving a request. The static content method has an advantage of minimizing the user's perceived response time, meaning the time between requesting the document and seeing it rendered on a computer screen. It has a disadvantage that all users who request the document receive exactly the same content. With static content, the server cannot respond to specific user requests or personalize a document for individual users.
In a dynamic content method, the document is generated dynamically by the server. When a client requests a document, the server invokes one or more agents, feeding the agents relevant parameters from the user's request (such as the user's name). The agent(s) generate the document that satisfies the user's request and the server returns the document over the network to the client. The dynamic content method has the advantage of responding to specific user requests or personalizing content for individual users. It has the disadvantage that the user's perceived response time will generally be longer than with static document requests. This is because the document generation process involves additional time to invoke the appropriate agent(s) and generate the document.
The server generates dynamic content documents by invoking an agent in one of two ways: an “out-of-process” method and an “in-process” method. In an “out-of-process” method, the agent runs in its own process and address space, separate from the server's process and address space. Typically, the out-of-process method uses the industry-standard common gateway interface (CGI) as the communication mechanism between the server and agent. CGI is described in a publicly available document on the Web at http://hoohoo.ncsa.uiuc.edu/cgi. In an “in-process” method, the agent runs within the Web server's process and address space. The in-process method typically uses a vendor-specific application programming interface, like the Internet Server Application Programming Interface (ISAPI) implemented by Internet Information Server (IIS), which is available from Microsoft Corporation. The ISAPI technology is described in more detail in a document at http://www.microsoft.com/iis/Support/iishelp/iis/misc/documentation.asp.
To illustrate the two dynamic content methods and how they can be used in conjunction with the static content method, consider a scenario in which the server
22
runs a Web server for an online retail company. When the client
24
first accesses the Web site, the server
22
might retrieve a pre-existing home page for the company from the database
28
and serve that page to the client
24
. This initial step is an example of a static content method. From the home page, the client might request to view an online catalog of products offered by the company. In response, the Web server might invoke a catalog agent to guide the user through various product offerings. When the user decides to purchase a product, the client submits an order request. In response, the Web server might invoke an order agent to assist the user in ordering the product. The steps involved with actively serving a catalog or taking an order are examples of dynamic content methods. They both involve dynamic generation of documents in response to input received from the client.
FIG. 2
shows an “out-of-process” method under this scenario. The server
22
runs a Web server
40
as process
1
. The Web server
40
handles the incoming requests from the client. When the client first hits the Web site, the Web server
40
retrieves the company's home page
42
from the database
28
and transmits the home page
42
to the client. When the client sends an order request, the Web server
40
initiates an order manager
44
to assist the user with ordering the desired product or service. The order manager
44
is initiated using the CGI technology as a second process
2
, which uses a separate process and address space than process
1
, as represented by the dashed lines.
When the user selects an item, the order manager
44
dynamically generates an order document
46
that contains the user's name, a description of the selected item, the cost of the item, and payment terms. The order manager
44
returns the order document
46
to the Web server
40
, which then serves the document
46
to the client. Afterwards, the order manager
44
is terminated and the second process
2
is halted.
The out-of-process method shown in
FIG. 2
has an advantage in crash prevention and recovery. If the out-of-process order manager
44
is unreliable and ultimately crashes, it will not cause the Web server
40
to crash. However, the out-of-process method has a disadvantage in that a particular agent must be loaded into memory each time a request arrives for it. Using CGI technology, the agent must also be unloaded from memory once it finishes the request. This loading and unloading consumes resources, resulting in a relatively slow response time. Another problem compounding the slowness is that the out-of-process method involves cross-process communication between processes
1
and
2
, including such activities as marshalling, messaging, and the like.
A variation of CGI, known as FastCGI, allows the server to keep the agent loaded, rather than terminating the agent each time it responds to a particular request. FastCGI is an improvement over CGI in that it saves the per-request invocation overhead, thereby improving the response time. However, the FastCGI is still run in a separate process, and hence the drawbacks associated with cross-process communication remain. A more detailed discussion of FastCGI is found at http://www.fastcgi.com/kit/doc/fastcgi-whitepaper/fastcgi.htm.
FIG. 3
shows an “in-proc
Jin Lei
Kaplan David L.
Krishnan Murali R.
Elisca Pierre E.
Lee & Hayes PLLC
Microsoft Corporation
Trammell James P.
LandOfFree
Server architecture with detection and recovery of failed... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Server architecture with detection and recovery of failed..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Server architecture with detection and recovery of failed... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3300640