HK1017789B - Method and apparatus for increasing the performance of a web browser and communicating with a web server - Google Patents

Description

Method and apparatus for increasing performance of web browser and communicating with web server

The present invention relates to communications between client server applications, such as web browsers and web servers. In particular, the present invention relates to communicating between two computers, one running a client application and the other running a server application, over a low-speed or wireless communication connection.

Recent publicity and emphasis on "information highways" has made the public increasingly aware of and receptive to the internet as a public communication medium. This broad recognition of the internet as a visual medium for communications and sessions between multiple networks has also formed a broad pre-established user base for conducting conversations between computer networks relying on internet standard protocols.

The paradigm of the internet is a client-server relationship, in which an internet client (browser) communicates with an internet server. To provide more access to the internet, the communication protocols and languages used by clients and servers have been standardized. These protocols include the hypertext transfer protocol (HTTP), which is the communication protocol used for communication between clients and servers, and the transmission control protocol/internet protocol (TCP/IP), which TCP portion is a proprietary transmission protocol used for communication between computers or applications. Also standardized is the language used by the client and server communications, which is called hypertext markup language (HTML). Since these protocols and languages are machine independent and send information using a connectionless best efforts protocol, each is completely autonomous. Thus, for example, each piece of information from the client contains information about the browser's rights and is not relevant to the communication to be completed and any other communication. This autonomous nature of communication between a client and a server may be referred to as "stateless" communication, and increases the amount of data that must be transferred between a client and a server for a given communication.

In the context of a web client/server application, the client may be a web browser as the user interface that sends the user's request to the appropriate web server and formats and displays the HTML data returned from the web server. The web browser also evaluates the HTML data to determine if there are any hyperlinks statements in the HTML data that require subsequent browser requests for web browser activation. The web server, as a server for the client, processes the web browser's request and returns the requested response as an HTML data portion of an HTTP data stream.

As a typical example of a global network communication, the case where a web browser initiates a request for a "home page" from a web server illustrates the basic relationship between HTTP, HTML, TCP and the web browser and web server. When a user of a web browser requests information from a particular web site, the web browser initiates communication with the web server by sending a "get" request to the web server to determine the desired web site, in this case the Uniform Resource Locator (URL) of the "home page". The URL is a website address and is uniform over the internet. The web server then obtains and transmits HTML data corresponding to the home page determined by the URL to the web browser. Such operations include remote communication over the internet by an internet server or a URL may identify a server in a local area network to which the browser is connected. The web browser then evaluates the HTML data received in the HTTP data stream from the web server to see if any hyperlinks are embedded therein, such as an icon or image, and if such a hyperlink is present, initiates a request to determine the URL of the hyperlink to obtain the determined data. These data are then compiled into the home page and displayed to the user. As shown in this simple example, a single user input request sent by a web browser may result in a plurality of additional requests being automatically executed by the web browser in response to receipt of HTML data corresponding to the user input request.

The basic communication structure of an internet-based system is depicted in fig. 1. In FIG. 1, a web browser 10 is communicatively coupled to a web server 20 via a communication link 15. Such a communication link is typically a local area network connection, a wide area network connection, a connection over a telephone line, or a combination of connections. The web browser 10 and web server 20 communicate using TCP/IP. For the majority of internet communications, web browsers and web servers communicate using the generic communication protocol HTTP which is transmitted between the web browser and the web server over the TCP/IP link between the web browser and the web server. The data actually transferred between the web browser 10 and the web server 20 is HTTP data objects (e.g. HTML data) as described above. Web server 20 may be an agent that receives web browser communications from several web browsers and transmits these communications to the appropriate server.

Web browser/web server, their commonThe popularity of information and transfer protocols, HTML and HTTP, has led to the rapid acceptance by the public of networking technology as a general interface for network access to information. In addition, because of the standardization of protocols and languages for communication between web browsers and web servers, users are not aware of using Netscape Navigator^TM，NCSA Mosaic^TM，WebExplorer^TMOr any other web browser, the communication protocol and language are the same as the web browser they access the network information. Thus, the large installed user base of web browsers combined with internet connectivity, the ease of web application authoring, and the use of the Common Gateway Interface (CGI) specified by HTTP by the server make web technology very attractive to most form-factor applications.

While the internet is becoming more popular and is being accepted by more and more people, mobile computing is also becoming more popular. Laptop computers, notebook computers, personal digital/communication assistants (PDAS/PCAS) and other portable devices have made increasing demands for wireless communication. However, wireless wide area networks, cellular communications and radio packet communications are subject to the same limitations if used in the context of a network. The high cost of communicating each byte, slow response time, low bandwidth and unreliability prevent the use of wireless technology in stateless communication protocols for the world wide web. In addition, because of the network protocol's statelessness, the amount of data per request and the number of requests transmitted over a wireless connection will be greater than the amount of data and the number of requests necessary for non-autonomous communication. Thus, it would seem impractical to combine wireless technology or any low speed communication technology with web technology, as factors in the versatility of web technology add to the weakness of wireless technology.

In view of the foregoing limitations, it is an object of the present invention to utilize the installed subscriber base of web technology in low speed communication environments, such as wireless communications.

It is another object of the present invention to use existing communication protocols and languages in low speed or wireless communication systems without having to modify web browser or web server applications.

It is a further object of the present invention to provide a method of communicating over an external communication link that reduces the amount of communications required to enhance the performance of the communication system.

In view of these and other objects, the present invention provides a method of enhancing the performance of a web browser application residing on a first computer and communicating with a web server application residing on a second computer remote from the first computer using the hypertext transfer protocol (HTTP). At least a segment of the communication between the web browser application of the first computer and the web server application of the second computer is conducted using an external communication link. One embodiment of the method of the present invention includes intercepting the HTTP data stream corresponding to the web browser originated communication prior to transmitting the HTTP data stream over the external communication link. The intercepted web browser originated HTTP data stream is converted from the HTTP protocol to a client/server specific communication protocol and the converted web browser originated communication is transmitted to the second computer in the form of a client/server specific data stream over an external communication link. The second computer receives the client/server specific data stream transmitted over the external communication link and regenerates an HTTP data stream corresponding to the web browser originated communication from the client/server specific data stream received over the external communication link by converting the client/server specific data stream received in the client/server specific communication protocol to the HTTP data stream. The web browser originated communication is provided to the web server in the form of an HTTP data stream.

In another embodiment of the invention, the converted web browser originated communication is transmitted over a wireless communication link.

Another aspect of the present invention employing a cache resident in the first computer further includes storing an HTTP data stream received by the web browser in response to the web browser originated communication with the web server in the cache resident in the first computer to generate a client cache entry corresponding to the web browser originated communication with the web server. The web browser originated communication is interrogated to determine if there is a client cache entry corresponding to the web browser originated communication. If a client cache entry exists corresponding to the web browser originated communication, the client cache entry is provided to the web browser in the form of an HTTP data stream in response to the web browser originated communication.

Another aspect of the invention includes storing user-determined information associated with a particular web browser information request to provide the user-determined information residing in the first computer. The web browser originated communication is interrogated to determine whether the information requested by the web browser corresponds to a request for a user defined information to be stored for the user, and if the web browser communication corresponds to a request for a user defined information to be stored for the user, the user defined, stored information is provided to the web browser in the form of an HTTP data stream in response to the web browser originated communication.

Another embodiment of the present invention that employs a time-coherent cache includes storing a generation time of a client cache entry to generate a client cache entry time record, and evaluating the client cache entry time record to determine whether the client cache entry corresponding to the web browser originated communication was generated within a predetermined client coherency time interval prior to the web browser requesting information. If the client cache entry is made in a predetermined client coherency interval before the web browser requests information, the client cache entry is provided to the web browser in response to the web browser originated communication. Client cache entries may also be maintained across multiple instances (instances) of a web browser.

Another embodiment of the invention includes a server cache wherein HTTP data streams received from a web server in response to a web browser originated communication are stored in a cache resident in a second computer to generate a server request cache entry. A web browser originated communication is interrogated to determine if a server request cache entry corresponding to the browser originated communication has been stored in the cache. If a server cache entry exists, the server cache entry associated with the web browser originated communication is converted to a client/server specific communication protocol and transmitted to the first computer in a client/server specific data stream over the external communication link. The first computer obtains a client/server specific data stream transmitted over the external communication link and regenerates an HTTP data stream corresponding to the server requested cache entry from the client/server specific data stream received over the external communication link by converting the client/server specific data stream received in the client/server specific communication protocol to the HTTP data stream. The server request cache entry for information corresponding to the web browser request is provided to the web browser in the form of an HTTP data stream.

Another embodiment of the caching aspect of the present invention includes determining whether to generate a server request cache entry corresponding to the web-browser originated communication in a predetermined client-related time interval before the second computer receives the web-browser originated communication, and if the server request cache entry is generated in the predetermined client-related time interval, converting the server request cache entry corresponding to the web-browser originated communication to a client/server specific communication protocol. Another embodiment includes determining whether a client cache entry corresponding to the web browser originated communication is present that is the same as a server cache entry corresponding to the web browser originated communication. A time interval between the time the second computer receives the web browser originated communication and the generation time of the server request cache entry corresponding to the web browser originated communication is calculated to provide entry period (entry) data. If the two cache entries are the same, a coherent entry response is sent to the first computer over the external communication link containing entry period data corresponding to the server cache entry of the web browser originated communication. The client cache entry time record corresponding to the web browser originated communication is updated by subtracting the entry period data received from the coherent entry response from the current time of the first computer.

In another embodiment of the present invention that includes reducing data on external communication links using differencing, the web browser originated communication corresponds to a Common Gateway Interface (CGI) request. The intercepted CGI request is queried to determine if a client base cache entry corresponding to the intercepted CGI request exists to provide a client CGI base format. The intercepted CGI request is also queried to determine whether a server-based cache entry corresponding to the intercepted CGI request exists to provide a server CGI-based format. HTTP data streams received from the web server in response to browser originated communications, i.e., requests to a Common Gateway Interface (CGI), are stored in a cache resident in the second computer to create a server base cache entry, and HTTP data streams in response to browser originated communications, i.e., requests to a CGI, to be provided to the web browser are stored in a cache resident in the first computer to create a client base cache entry. Intercepting the HTTP data stream corresponding to the CGI request intercepted by the communication response originating from the web server before transmitting the HTTP data stream over the external communication link. The intercepted CGI response is compared to the server's CGI base format to provide CGI differential data corresponding to a difference between the intercepted CGI response and the server CGI base format, and the CGI differential data is sent to the first computer's web browser in a client/server specific data flow over the external communication link. The client/server specific data stream transmitted by the second computer over the external communication link is obtained by the first computer and the HTTP data stream corresponding to communications from the web server is regenerated from the client/server specific data stream received over the external communication link by combining the client CGI base format with CGI differential data received over the external communication link to produce an HTTP data stream corresponding to the intercepted CG I response. The communication originating from the web server is provided to the web browser in the form of an HTTP data stream.

A re-foundational embodiment of the differential aspect of the present invention determines whether the server CGI base format and the client CGI base format are the same and transmits the server CGI base format and the CGI differential data to the web browser in the form of a client/server specific data stream over an external communication link. Combining the server CGI base format with the CGI differential data received over the external communication link generates an HTTP data stream corresponding to the intercepted CGI response, thereby regenerating an HTTP data stream corresponding to communications from the web server from the client/server specific data stream received over the external communication link. The client CGI base format corresponding to the CGI request is updated by storing the received server CGI base format as a client base cache entry corresponding to the CGI request.

In another aspect of the present invention, the server CGI base format may also be updated by determining whether a difference between the server CGI base format and the CGI response is greater than a predetermined difference limit. If the CGI differential data, the server CGI base format corresponding to the CGI request is updated by storing the CGI response received from the web server as the server base cache entry corresponding to the CGI request, and the subsequent comparison also employs the updated server CGI base format that is also sent to the first computer.

In the protocol recovery aspect of the present invention, a persistent connection is established between the first computer and the second computer through an external communication link. The persistent connection is maintained until all web browser originated communications have been completed. While maintaining a persistent connection, a batch of web browser originated communications is intercepted and multiplexed over the external communication link. The client/server specific data streams are then demultiplexed to produce a collection of HTTP data streams, which are provided to the web server.

The title reduction aspect of the present invention includes providing computer specific information corresponding to a predetermined characteristic of a first computer to a second computer via an external communication link and storing the computer specific information corresponding to the predetermined characteristic of the first computer to provide browser title information. The first computer removes computer-specific information from the web browser originated communication and the second computer combines the stored browser title information with the client/server specific data stream to produce an HTTP data stream.

In another aspect of the invention, an HTTP data stream corresponding to a communication originating from a web server is captured and converted from an HTTP protocol to a client/server specific communication protocol before being transmitted over an external communication link. The converted web server originated communication is sent to the web browser in the form of a client/server specific data stream over an external communication link. The first computer obtains a client/server specific data stream transmitted over the external communication link and regenerates an HTTP data stream corresponding to a communication originated from the web server from the client/server specific data stream received over the external communication link by converting the client/server specific data stream received in the client/server specific communication protocol into the HTTP data stream. The communication originating from the web server is provided to the web browser in the form of an HTTP data stream.

Another embodiment of the title reduction aspect of the present invention includes providing computer specific information corresponding to a predetermined characteristic of a second computer to a first computer via an external communication link and storing the computer specific information corresponding to the predetermined characteristic of the second computer to provide server title information. The second computer removes the computer-specific information from the communication originating from the web server, and the first computer combines the server header information with the client/server-specific data stream to produce the HTTP data stream.

In another embodiment of the protocol recovery aspect of the present invention, a persistent connection is established between the first computer and the second computer through an external communication link. The persistent connection is maintained until all communication originating from the web server has been completed. While maintaining a persistent connection, a batch of communications originating at the web server are intercepted and multiplexed over an external communication link. The client/server specific data streams are then demultiplexed to produce a collection of HTTP data streams, which are provided to the web server.

In another embodiment of the present invention, a method is provided for increasing the performance of a client/server system having a client application resident on a first computer and communicating with a server application resident on a second computer remote from the first computer. The client application and the server application communicate between the client and the server using a client/server independent communication protocol (i.e., stateless), and at least a portion of the communication between the client application in the first computer and the server application in the second computer is over an external communication link. The method includes intercepting a communication originating remotely from the client in a client/server independent communication protocol prior to transmitting the communication over the external communication link. The intercepted client originated communication is converted to a second client/server specific communication protocol and transmitted over the external communication link. The second computer receives communications transmitted over the external communication link and converts communications received over the external communication link from the client/server specific communication protocol to the client/server independent communication protocol. Remote client-originated communications are provided to the server in a client/server independent communication protocol. Another aspect of the invention includes intercepting communications under a client/server independent communication protocol originating from a server prior to transmission over an external communication link. The intercepted communication is converted to a second client/server specific pass-through protocol and transmitted over the external communication link. The first computer receives communications over the external communication link and converts them from the client/server specific communication protocol to the client/server independent communication protocol. Server-originated communications are provided to remote clients in the form of client/server independent communication protocols.

As will be appreciated by those skilled in the art, various aspects of the invention described above may also be provided as an apparatus or computer readable program means.

FIG. 1 is a block diagram of a typical web browser/web server system;

FIG. 2 is a block diagram of a web browser/web server utilizing an embodiment of client interception and server interception in accordance with the present invention;

FIG. 3 is a flowchart illustrating the operations performed by the client intercept module in a preferred embodiment of the present invention implementing a coherent cache system;

FIG. 4 is a flowchart illustrating the operations performed by the client intercept module in a preferred embodiment of the present invention implementing a coherent cache system;

FIG. 5 is a flowchart illustrating the operations performed by the server intercept module in a preferred embodiment of the present invention implementing a coherent cache system;

FIG. 6 is a flowchart illustrating the operations performed by the client intercept module in a preferred embodiment of the present invention implementing a coherent cache system;

FIG. 7 is a flowchart describing the operations performed by the client intercept module in a preferred embodiment of the present invention implementing differential data transmission;

FIG. 8 is a flowchart depicting the operations performed by the client intercept module in a preferred embodiment of the present invention implementing differential data transmission;

FIG. 9 is a flowchart describing the operations performed by the server intercept module in a preferred embodiment of the present invention implementing differential data transmission;

FIG. 10 is a flowchart describing the operations performed by the server intercept module in a preferred embodiment of the present invention implementing differential data transmission;

FIG. 11 is a block diagram of one aspect of the present invention employing virtual sockets;

FIG. 12 is a block diagram of a client-side intercept module and a server-side intercept module according to one embodiment of the invention employing virtual sockets;

FIG. 13 is a flowchart describing operations performed by a socket manager of a client-side intercept module or a server-side intercept module according to one embodiment of the present invention employing virtual sockets;

FIG. 14 is a flowchart describing the operation of a client intercept function execution in accordance with one embodiment of the present invention employing a virtual socket;

FIG. 15 is a flowchart describing the operation of a server intercept function execution according to one embodiment of the present invention employing a virtual socket;

FIG. 16-1 is a flow chart describing a virtual generation operation according to one embodiment of the present invention employing a virtual socket;

FIG. 16-2 is a flow chart describing a virtual send operation according to one embodiment of the present invention employing a virtual socket;

FIGS. 16-3 are flow diagrams depicting virtual receive operations according to one embodiment of the present invention employing a virtual jack;

FIGS. 16-4 are flow diagrams depicting a virtual selection operation according to one embodiment of the present invention employing a virtual socket;

FIG. 17-1 is a flow chart describing a virtual refresh operation according to one embodiment of the present invention employing a virtual socket;

FIG. 17-2 is a flow chart describing a virtual shutdown operation according to one embodiment of the present invention employing a virtual socket;

the present invention will be described in detail hereinafter with reference to the accompanying drawings, in which preferred embodiments of the invention are shown. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. Like numbers refer to like elements throughout.

Fig. 3-10 and 13-17-2 are flow diagrams illustrating methods and systems according to the present invention. It will be understood that each block of the flowchart illustrations, and combinations of blocks in the flowchart illustrations, can be implemented by computer program instructions. These computer program instructions may be loaded onto a computer or other programmable apparatus to produce a machine, such that the instructions which execute on the computer or other programmable apparatus create means for implementing the functions specified in the flowchart block or blocks. These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart block or blocks. The computer program instructions may also be loaded onto a computer or other programmable apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented method such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks.

Accordingly, blocks of the flowchart illustrations support combinations of means for performing the specified functions and combinations of steps for performing the specified functions. It will also be understood that each block of the flowchart illustrations, and combinations of blocks in the flowchart illustrations, can be implemented by special purpose hardware-based computer systems which perform the specified functions or steps, or combinations of special purpose hardware and computer instructions.

Fig. 2 illustrates an embodiment of the present invention. As shown in fig. 2, the web browser 10 is connected to a client-side intercept module 30. The web server 20 is connected to a server intercept module 40. The client-side intercept module 30 then communicates with the server-side intercept module 40 via a communication link 35. The web browser 10 and the client-side intercept module 30 may be included in the first computer 5. The server intercept module 40 and the web server 20 may be included in the second computer 6. The first computer 5 and the second computer 6 communicate via an external communication link 35.

Specifically, the web browser 10 is an internet browser that communicates using the hypertext transfer protocol (HTTP) and hypertext markup language (HTML) and an internet server 20 that also uses HTTP and HTML. In operation, the web browser 10 outputs the HTTP data stream intercepted by the client-side intercept module 30. The interception of the HTTP data stream by the client intercept module 30 may be accomplished by using TCP/IP loopback capability, where the client intercept module resides at an IP address of network number 127, such as 127.0.0.1. The client intercept module 30 then converts or transforms the HTTP data stream to a client/server specific protocol and transmits the client/server specific data stream over the external communication link 35. The server intercept module 40 receives the client/server specific data stream and regenerates the original HTTP data stream corresponding to the web browser originated communication. The regenerated HTTP data stream is then transmitted to web server 20. The web server 20 responds to the HTTP data stream in a manner conventional to internet web servers. As will be appreciated by those skilled in the art, web server 20 may also be an agent that allows multiple browsers and Internet connections.

When the web server 20 receives information transmitted to the web browser 10, for example, in response to a browser requesting a specific URL homepage, the web server 20 outputs an HTTP data stream corresponding to a communication to be transmitted to the web browser 10. This web server originated communication is intercepted by the server intercept module 40 and converted to a client/server specific data stream. A client/server specific data stream corresponding to the web server originated communication is then sent from the second computer to the first computer over the external communication link 35. The client-side intercept module 30 receives the client/server specific data stream and regenerates the original HTTP data stream corresponding to the web-server originated communication and provides the HTTP data stream to the web browser 10.

In a particular embodiment of the invention, the external communication link 35 is a wireless communication link. In this case, in order to obtain a system performance that is acceptable to the user, it is necessary to reduce the number of communications on the external communication link 35, both in terms of the frequency of the communications and the amount of information that must be transmitted on the external communication link 35. Thus, the present invention employs caching, differencing and protocol reduction techniques to reduce the amount of communications required over the external communication link 35. These techniques reduce the number and frequency of communications by converting the HTTP stateless or random protocol to utilize a client/server specific protocol that is client and server specific.

Although the invention has been and will be described with respect to a single web browser application and a single web server application, the benefits and advantages of the invention may be realized on multiple web browsers associated with a single web server as will be appreciated by those skilled in the art. Thus, the method, apparatus and program product of the present invention are associated with multiple browsers each of which is connected to a client intercept module and which client intercept module is then in communication with a server intercept module of a web server or web proxy.

In one embodiment of the present invention, both the client-side intercept module 30 and the server-side intercept module 40 have caching capabilities. A client cache resident in the first computer stores HTTP data streams to be received by the web browser in response to the web browser originated communication. A server cache resident on the second computer stores HTTP data streams received from the web server in response to the browser initiated communication.

As will be appreciated by those skilled in the art, the size of the cache resident in the first computer or the second computer is arbitrary, depending on the configuration of the particular hardware of the computer. These caches store information for each communication, including the URL of the communication, a unique identifier based on the content of the communication, such as a Cyclic Redundancy Check (CRC) of the communication data, a Store Data Time (SDT) indicating when a cache entry was generated or flushed, and the data of the communication. This may result in a directory of cache entries for each communication stored in the cache. Furthermore, because of the limited resources available in any given hardware configuration, any technique known to those skilled in the art for maintaining a cache resident in the first computer and the second computer may be utilized. Thus, for example, if a new entry is added that exceeds the size of the cache determined by the user, the cache may invalidate the oldest directory entry and then add the new entry to the location of the invalidated entry. In addition, cache entries may be maintained across multiple instances of a web browser or web server application or even power-up cycles in the first or second computer to create a persistent cache.

The operation of the cache structure according to one aspect of the present invention will be described with reference to the flowcharts of fig. 3 to 6 describing the operation of the client-side intercept module 30 and the server-side intercept module 40.

Referring to FIG. 3, a block 100 indicates that the client-side intercept module has received a request from the web browser 10. The request may take the form of an HTTP data stream. The client intercept module 30 checks the Uniform Resource Locator (URL) of the incoming request, as shown in block 105. The client-side intercept module 30 determines from the URL whether information corresponding to the web browser originated request has been stored in a client cache resident in the first computer.

If the information corresponding to the URL is not stored in the client cache, the client intercept module performs the operations described at block 106. The client-side intercept module 30 transmits a request to the server-side intercept module 40 over the external communication link 35.

However, if the query for a web browser originated communication, as depicted in block 105, there is a client cache entry corresponding to the web browser originated communication, then in the simplest embodiment this information is provided to the web browser in the form of an HTTP data stream. However, as shown in FIG. 3, the preferred embodiment of the present invention implements what is referred to herein as a coherency interval check on the cache entry corresponding to a web browser originated communication. This operation is illustrated in block 110 of fig. 3.

The coherency interval of the client-side intercept module is determined by the user, which is the length of time that exists before a cache entry fails and must be refreshed, if given, by requesting information from the web server corresponding to the web browser originated communication. The coherency interval check reflected by block 110 is accomplished by comparing the current date and time to the sum of the SDT of the cache entry corresponding to the web browser originated communication and the user determined coherency interval. If the current date and time is greater than this sum, then the information stored in the cache corresponding to the web browser originated communication has been invalidated, the "no" branch of box 110 is taken. However, if the current date and time is less than the sum of the SDT plus the user-determined coherence interval, the "YES" branch of block 110 is taken and the cache entry is provided to the browser as an HTTP data stream as shown in block 111 to complete the browser initiated communication received by the client intercept module in block 100 of FIG. 3.

If the coherency interval check, shown at block 110, determines that the cache entry residing in the first computer is invalid, a request is issued to the server intercept module to check the coherency of the cache entry residing in the second computer. This operation is illustrated in block 112 of fig. 3. This is accomplished by providing the server-side intercept module 40 with the coherency interval of the particular client-side intercept module 30, an HTTP request initiated by the web browser 10, and a unique indicia of the contents of the client cache corresponding to the URL of the web browser originated communication via the external communication link 35. In a preferred embodiment, this unique tag is the result of a cyclic redundancy check or CRC of a cache entry.

Referring now to FIG. 5, it reflects the operation of the server intercept module in response to information received from the client intercept module 30 via the external communication link 35. When the server-side intercept module 40 receives a request from the client-side intercept module, the server-side intercept module 40 receives a predetermined client coherence interval, a CRC of the client cache entry, and a web browser originated HTTP request, the receipt of which is shown in box 120 of FIG. 5.

Upon receiving such information from the client-side intercept module 30, the server-side intercept module 40 checks its server cache residing in the second computer to determine if there is a server cache entry corresponding to the URL of the web browser originated HTTP request. After interrogating the web browser originated communication, as shown in block 125, if the server-intercept module 40 determines that there is a cache entry for information corresponding to the web browser originated communication request, the "yes" branch of box 125 is selected. The server-side intercept module 40 then compares the current date and time of the server-side intercept module 40 with the sum of the SDT of the server cache entry corresponding to the information of the web-browser originated communication request and the predetermined client coherence interval received from the client-side intercept module.

If the current date and time is less than the sum of the SDT and the coherency interval of the server cache entry, the YES path of block 130 of FIG. 5 is taken. The server intercept module 40 then compares the CRC of the server cache entry to the CRC of the client cache entry to determine if the two cache entries are the same. If the two cache entries are the same, the "YES" path of block 135 is taken, as shown in block 136, and a "coherency" response is sent to the client intercept module 30.

If the condition of block 135 determines that the CRCs are not the same, then the information contained in the client cache and the server cache is not the same, as indicated by block 137, and the server intercept module sends the server cache entry to the first computer via an external communication link. When the server cache entry is sent to the client intercept module 30, the server intercept module converts the entry to a client specific communication protocol containing the CRC of the server cache entry, the server cache entry data and the age of the server cache entry. The server cache entry's age is calculated by subtracting the SDT of the cache entry from the current date and time.

Finally, with respect to FIG. 5, if the sum of the SDT and the predetermined client coherence interval is less than the current date and time or there is no cache entry corresponding to the URL of the web browser originated communication, then the "No" branch of box 130 or box 125, respectively, is taken. In this way, the operations of box 126 will be performed and the server intercept module 40 will send the web browser originated communication to the server in an HTTP data stream. If the server-side intercept module 40 must send a web browser originated communication to the server in an HTTP data stream, the server-side intercept module 40 will perform the operations of FIG. 6.

In response to a web browser originated communication, the server intercept module will receive an HTTP data stream from the web server, as shown in fig. 6 block 140. Upon receiving the HTTP data stream, the server intercept module 40 will calculate a CRC for the HTTP data stream and temporarily store the HTTP data stream. The server intercept module then interrogates the HTTP data stream and determines if there is a server cache entry corresponding to the URL of the HTTP data stream, as shown in block 145. If such an entry does exist, the "YES" branch of block 145 is performed. The server intercept module 40 then compares the newly calculated CRC of the HTTP data stream received from the web server 20 with the CRC of the server cache entry corresponding to the URL of the communication response communication originating from the web server, as shown in block 150. If the two CRCs are the same, the "YES" branch of block 150 is performed. The server intercept module 40 updates the SDT for the server cache entry as shown in block 151 and flushes the temporarily stored HTTP data stream received from the web server 20 as shown in block 152.

If the result of the CRC comparison indicates that the server cache entry is different from the HTTP data stream received from web server 20, the "No" branch of block 150 is performed. The server intercept module 40 removes the existing data from the server cache, as shown at block 153, and updates the server cache with the new information, as shown at block 154. Such updating includes storing the CRC of the web server communication in the server cache, storing the current date and time as part of the cache entry as the SDT of the cache entry, and storing the HTTP data stream, as indicated at block 154. In either case, whether the server cache entry is updated or the server cache entry is found to be the same as the HTTP data stream received from the web server 20, then the server intercept module determines whether the server cache entry is the same as the client cache entry corresponding to the web browser originated communication. This operation is shown as block 155.

If the server intercept module 40 determines that a cache entry corresponding to the response received from the web server 20 does not exist, the "no" branch of block 145 is taken. A server cache entry is generated by storing the URL of the response from the web server, by storing the CRC of the response from the web server, by storing the HTTP data stream, and by storing the current date and time as an SDT, as shown in block 146. After a cache entry corresponding to the web browser originated communication is generated, the server intercept module 40 again compares the CRC of this server cache entry to the CRC of the corresponding client cache entry, as shown in block 155.

If the result of the comparison of the server cache entry and the client cache entry indicates that the two cache entries are the same, the YES branch of block 155 is taken and the operations of block 156 are performed. As seen in block 156, the server intercept module 40 sends a coherent response to the client intercept module 30. The server intercept module 40 converts the server request cache entry into a client/server specific data stream by sending a coherent response and sending a zero epoch to the client intercept module.

If the server intercept module 40 determines that the client cache entry is different from the server cache entry corresponding to the web browser originated communication, the "no" branch of block 155 is taken and the operations of block 157 are performed. The server intercept module 40 converts or transforms the server cache entry into a client/server specific data stream as shown in block 157. The data stream includes the CRC of the server cache entry, the HTTP data stream of the server cache entry and the age of the cache entry set to zero. This client/server specific communication is then transmitted to the client intercept module 30 via the external communication link 35.

The function of the client-side intercept module 30 in receiving communications from the server-side intercept module will now be described with reference to figure 4. The client-side intercept module 30 receives or obtains a client/server specific data stream transmitted over the external communication link 35, as shown in block 160. The client-side intercept module then determines the type of response received from the server-side intercept module 40, as shown in block 165. If the server intercept module 40 indicates that the client cache entry is coherent, i.e., the server cache entry and the client cache entry are the same, then the operations indicated by block 166 are performed. As shown at block 166, the client-side intercept module 30 updates the SDT of the client cache entry corresponding to the web browser originated communication with the difference between the current date and time and the time period received from the server-side intercept module 40. Thus, without synchronizing the clocks of the first computer 5 and the second computer 6, the present invention has corrected the coherence time of the cache entry of the first computer to reflect the new data of the second computer. After updating the SDT corresponding to the client cache entry for the web browser originated communication, the client intercept module 30 streams the client cache entry to the web browser 10 as HTTP data. This operation is shown in block 174.

However, if client intercept module 30 determines that the response type is a data or data stream response, then the "stream" path of block 165 is taken and the operations of block 167 are performed. The client intercept module 30 receives the HTTP data stream and temporarily stores this data. Subsequently, as shown in FIG. 4 at block 170, the client-side intercept module 30 determines whether a cache entry corresponding to the web browser originated communication exists. If a cache entry exists, the YES path of block 170 is taken and the existing cache entry is flushed, as shown in block 171. The client-side intercept module then updates the client cache entry corresponding to the web browser originated communication by storing the CRC of the HTTP data stream received from the server-side intercept module 40, by storing the difference between the current date and time as an SDT and the time period received from the server-side intercept module 40, and by storing the HTTP data stream. This operation is shown in block 172.

If there is no cache entry corresponding to a web browser originated communication, then the "NO" path of the box 170 is taken. A client cache entry is created by performing the operations shown in block 173. The client-side intercept module 30 generates a client cache entry by storing the URL of the HTTP data stream received from the server-side intercept module 40, by storing the CRC of the HTTP data stream received from the server-side intercept module 40, and by storing the HTTP data stream, as shown in block 173. The client-side intercept module 30 also updates or stores the SDT by subtracting the time period received from the server-side intercept module 40 via the external communication link 35 from the current date and time.

However, whether operated via blocks 166, 172 or 173, a client cache entry is created and the client intercept module transmits or provides the client cache entry to the web browser 10 in the form of an HTTP data stream. These operations are illustrated in block 174 of fig. 4.

As will be appreciated by those skilled in the art, client cache and server cache may be implemented using memory or using mass storage, such as hard disks, read/write CD-ROMS, optical disks or other storage technologies. Further, the client-side intercept module and the server-side intercept module may be implemented by software, hardware, or a combination thereof, as will be appreciated by those skilled in the art.

While reference is made to a cache memory residing in a particular first or second computer, as will be appreciated by those skilled in the art, the advantages of the present invention are realized even if the cache memory does not reside in the first computer, but is only on the same side of an external communication link as the computer. In this way, a hardware cache external to the first computer may be implemented which acts as a client cache and is communicatively coupled to the first computer, and the advantages of the present invention may be realized so long as the cache and the first computer are on the same side of the external communication link.

In an alternative embodiment of the present invention, the server intercept module 40 does not maintain a backup of the HTTP data stream received from the web server 20, but rather maintains a directory entry for the communication. The directory entry includes the URL of the communication, the CRC of the computed HTTP data stream, the time the HTTP data stream was received from the web server, and the SDT of the communication which may be set to the time when the CRC was computed. In this case, when the client-side intercept module 30 sends a communication request corresponding to a URL for which the server-side intercept module has maintained a CRC and SDT to the server-side intercept module 40, the server-side intercept module then checks the CRC received from the client-side intercept module 30 to determine whether it corresponds to the CRC of the last HTTP data stream for the particular URL. If the two match, a coherent response is sent to the client intercept module. If the two do not match, the server intercept module sends the HTTP data stream received from the client intercept module to the web server 20 and returns a response received from the web server 20 to the client intercept module 30.

Fig. 7, 8, 9 and 10 reflect operations performed by the client-side intercept module 30 and the server-side intercept module 40 in another aspect of the present invention that utilizes differentiation to reduce data transmitted over the external communication link 35. As shown in fig. 7, block 200 illustrates the case where the client-side intercept module 30 receives an HTTP request from the web browser 10. The client-side intercept module 30 interrogates the HTTP request intercepted from the web browser 10 to determine if the request is directed to a Common Gateway Interface (CGI), as shown in block 205. If the request is not directed to the public gateway interface, the client intercept module 30 passes the request to the server intercept module, as shown in FIGS. 3 through 6, and illustrated by block 206 of FIG. 7.

However, if the web browser originated communication corresponds to a CGI request, then the "YES" path of the marquee 205. As shown in diagram 210, client/server intercept module 30 determines whether a client base cache entry exists corresponding to an HTTP data stream previously provided to the web browser in response to the corresponding CGI request. This query of the CGI request can be accomplished by comparing the URL of the web browser originated communication with the URL stored in the client base cache.

The client base cache may be initialized by storing the first HTTP data stream received by the client intercept module 30, which is provided to the web browser 10 for a given URL. Such a base cache entry may be maintained in multiple instances or sessions of the web browser 10. The client base cache entry may be updated as shown in figures 7, 8, 9 and 10. If a client base cache entry corresponding to the URL of the web browser originated communication exists, the CRC to be sent to the server-side intercept module 40 over the external communication link 35 is set to the same CRC as the client base cache entry, as shown in block 211 of fig. 7. If no client base cache entry exists, the "no" path of block 210 of FIG. 7 is taken and the CRC of the request to be sent to the server intercept module 40 over the external communication link 35 is set to zero. This operation is illustrated in block 212 of fig. 7.

Block 213 illustrates sending a CGI request to the server intercept module 40 over an external communication link. The client intercept module 30 transmits the HTTP request and the CRC of the request, as shown in block 213. The CRC has been set to zero either if no client cache entry exists for the URL of the CGI request or to the CRC of the client base cache entry if an entry does exist. The client-side intercept module thus converts the CGI request to a client/server specific protocol and transmits the client/server specific communication to be received by the server-side intercept module 40 over the external communication link.

The actions taken by the server intercept module when a CGI request is received are shown in fig. 9. The case where the server intercept module 40 receives a CGI request is shown in block 220. When the server intercept module 40 receives a CGI request, it saves a copy of the HTTP request and the CRC value. The server intercept module 40 passes the HTTP request to the web server 20 as shown in block 221.

When the server-intercept module 40 receives a response corresponding to an HTTP request or CGI request originated from a web browser-originated communication, the server-intercept module 40 receives this response in the form of an HTTP data stream, as shown in block 230 of fig. 10. The server intercept module 40 saves the HTTP data stream and calculates a CRC value for the HTTP data stream received from the web server 20, as shown in block 230. Also, the server-side intercept module 40 sets the differential value to zero to initialize the differential data. The server intercept module then determines whether the response received with the communication originating from the web server is a response to the CGI request, as shown in block 235. If the result is no, the "no" path of block 235 of FIG. 10 is taken and the operations of block 236 are performed to send the HTTP data stream to the client-side intercept module. This operation includes the caching operations described in fig. 3-6, as indicated by block 236. If the response received in block 230 is a response to a CGI request, the YES path of block 235 is taken and the server intercept module then determines if a server base cache entry exists for the CGI response, as shown in block 240.

The server base cache entry may be generated the first time the server intercept module 40 receives a response to the CGI request. In this example, the result of the condition in block 240 will result in the no path of block 240 being taken. The server intercept module 40 will then generate a server base cache entry corresponding to the CGI request by storing the URL of the CGI, the HTTP data stream responsive to the CGI request, and the CRC of the HTTP data stream. This operation is shown in block 241. For compatibility with the coherent cache system described in FIGS. 3 through 6, the server base cache entry also includes SDT. As used herein, the term server CGI base format refers to a server base cache entry corresponding to a CGI request received from a web browser 10.

The "yes" path of box 240 is picked if the server base cache entry corresponding to the CGI request exists. The server intercept module compares the server base cache entry with the CRC of the response received from web server 20. These operations are illustrated in block 245 of fig. 10. If the two CRCs are the same, then the server intercept module determines if the CRC of the server base cache entry corresponds to the CRC of the client base cache entry. If the CRC values are the same, then the client base cache entry, the server base cache entry, and the response received from the web server 20 all contain the same HTTP data stream. A comparison of the server base cache entry and the client base cache entry is shown in block 250.

If the two base cache entries are the same, then the server intercept module does not have to send the base cache entry to the client intercept module 30 and leaves the HTTP data stream data to be transmitted to the client intercept module 30 empty, as shown at block 251. The server intercept module 40 then converts the HTTP data stream received from the web server 20 to the client/server specific communication protocol by transmitting the CRC of the HTTP data stream stored in the server base cache corresponding to the CGI request, the null HTTP data stream data, and the null difference data to indicate that the response to the CGI request is the same as the client base cache entry, as shown in block 252.

Returning to block 245, if the CRC of the server base cache entry corresponding to the CGI request is different from the CRC of the response received from the web server in response to the web browser originated CGI request, the "NO" path of block 245 is taken. Server intercept module 40 then performs the operations shown at block 246. The server intercept module 40 compares the intercepted CGI response to the server base cache entry or server CGI base format corresponding to the intercepted CGI request. The comparison of the intercepted CGI response and the server CGI base format provides CGI differential data corresponding to a difference between the intercepted CGI response and the server CGI base format.

The differentiation may be accomplished using any method known to those skilled in the art to determine the difference between the base format and the correction format. One suitable differential method for use in the present invention is described in "aCross-Platform Binary Diff", Coppeters, Dr. Dobb's Journal, 5 months 1995, pages 32-36, the disclosure of which is incorporated herein by reference. Other methods that may be used to determine differential data include those described in IBM Technical disclosure bulletin, Vol.22, No.8A, which is also incorporated herein by reference. The server intercept module 40 then determines whether the server CGI base format needs to be updated, as shown at block 247. This determination may be made by determining whether the average differential data between the intercepted CGI response and the serving CGI base format exceeds a predetermined limit. Other methods of determining whether the server base cache entry corresponding to the CGI request needs to be updated include temporal coherency, such as that described in FIGS. 3-6 or other methods known to those skilled in the art of determining whether differential data has been increased to such an extent that rebalancing to produce a new base cache entry will improve system performance.

If server re-grounding is not required, then the "NO" path of block 247 is taken and the server intercept module 40 performs the operations of block 250 to determine if the CRC of the client base cache entry is the same as the CRC of the server base cache entry or if the server CGI base format is the same as the client CGI base format, which are the server and client base cache entries that correspond to a particular CGI request originating from a web browser's communication. If the base formats are the same, then the client does not have to be re-based and the HTTP data stream information is empty, as shown in block 251. The server intercept module 40 then sends the differential response to the client intercept module 30 by sending the CRC of the server base cache entry corresponding to the CGI request (i.e., the CRC in the server CGI base format), by sending an empty HTTP data stream corresponding to the base data, and by sending the differential data as determined in block 246. These operations are again illustrated in block 252 of fig. 10.

If server intercept module 40 determines that the CRC of the client CGI base format and the server CGI base format are not the same, then the client needs to be re-basified. The client re-grounding operation includes sending the server CGI base format to the client intercept module 30. To accomplish this, the server intercept module sets the HTTP data stream data to be sent to the client intercept module 30 to be equivalent to the server CGI base format. This operation is shown in block 253. The server intercept module 40 then converts the HTTP data received from the web server into a client/server specific protocol by sending a CRC of the server CGI base format, HTTP data stream data corresponding to the server CGI base format, and differential data between the sending CGI base format and the response received from the web server, as shown in block 252. This information is then transmitted to the client intercept module 30 via the external communication link 35.

Returning to block 247, if server re-grounding is required, the "YES" path of block 247 is taken. The server intercept module updates the server base cache entry corresponding to the browser initiated communication with the HTTP data stream received from the web server, as shown in block 248. The CRC of the response is also updated and the CGI differential data is set to zero. The server intercept module then compares the CRC of the new server cache entry as shown in block 250 and completes the transfer as described above.

The operation of the client-side intercept module in receiving a response from the server-side intercept module 40 is shown in figure 8. The case where the client-side intercept module 30 receives a response from the server-side intercept module 40 is shown at block 260. Client intercept module 30 determines whether the response is a response to the CGI request, as shown at block 265. If the response is not to a CGI request, the client intercept module performs the operations of block 267, which include the caching operations shown in FIGS. 3-6. However, if the response is to a CGI request, then the yes path of block 265 is taken. The client intercept module 30 stores HTTP data stream data, differential data, and CRC obtained from the client/server specific data stream transmitted over the external communication link. These operations are illustrated in block 266 of FIG. 8.

Client intercept module 30 then determines whether a client base cache entry corresponding to the intercepted CGI request containing the client CGI base format exists. This query is shown at block 270 and is accomplished by examining the URL of the HTTP request or HTTP response. If the client CGI base format exists, then the YES path of box 270 is selected. Client intercept module 30 then compares the CRC received over the external communication link with the CRC of the client CGI base format, as shown in block 275. If they are different, the "no" path of box 275 is taken and the client is reinitialized by updating the CGI base format by replacing the client base cache entry corresponding to the URL of the CGI request of the web browser originated communication with HTTP data flow data received from server intercept module 40 through external communication link 35. The client base cache entry for the CRC against the HTTP data stream is also updated. These operations are illustrated in block 276 of fig. 8.

If the CRC received over external communication link 35 is the same as the CRC of the CGI base format, then the server-intercept module server CGI base format is the same as the client-intercept module client CGI base format, the no path of block 275 is taken.

The operations shown in block 277 are performed by the client intercept module 30 whether the base format is the same or the client is re-based. Block 277 reflects the client intercept module 30 regenerating an HTTP data stream corresponding to the communications initiated by web server 20 from the client/server specific data stream received via external communication link 35 by combining the client CGI base format with the CGI differential data received via external communication link 35 to produce an HTTP data stream corresponding to the intercepted CGI response. This response is then provided to the web browser 10 in the form of an HTTP data stream, as shown at block 278.

If the CGI base format corresponding to the URL of the CGI request does not exist in the client, the NO path of block 270 of FIG. 8 is taken. The client-side intercept module 30 generates a client base cache entry corresponding to the URL of the CGI request by storing the URL, the CRC of the HTTP data stream received from the server-side intercept module 40 over the external communication link, and the actual HTTP data stream data, as shown in block 271. Storing this information generates a client base cache entry corresponding to the intercepted CGI request and thus generates a client CGI base format. The client intercept module then regenerates the HTTP data stream by combining or merging the client CGI base format with the CGI differential data that has been set to zero, completing the operations of block 277.

The differential techniques of the present invention can also be used for non-CGI data. In such an example, the server-side intercept module 40 would need to maintain more than one generation of server base cache entries to enable the web browser's client-side intercept module connected to the web server to have different base formats. The server intercept module may then compare the CRC received from the client intercept module with the CRCs of each of the previous generations of the server base format until a match is obtained. The server intercept module 40 may then optionally re-basify the client intercept module 30 or simply provide the client intercept module 30 with the differential data. Thus, the differential approach described herein with respect to CGI requests is equally applicable to any HTTP request and response.

While the above-described system, which maintains multiple generations of the underlying format, makes differencing available for non-CGI requests, this technique requires more memory or storage strength and does not take full advantage of the above-described caching capabilities. To reduce the memory or storage strength required and to take advantage of the caching method described above, the following optimal method of using differentiation for non-CGI requests can be used. In this preferred implementation, the server intercept module calculates the difference between the HTTP data streams corresponding to the server base format of the request and the response from the web server. The server intercept module then saves this difference data. The server base format is then updated by replacing the base format with a new response from the web server, including updating the CRC of the base format. However, the old CRC is not discarded, but the CRC of the previous base format is saved as differential data. The differential data and the previous generation of CRC are then selectively transmitted to a client intercept module based on a CRC corresponding to the client base format of the non-CGI request.

As an example of a non-CGI differencing method, if the server-intercept module receives a non-CGI request, accompanying the non-CGI request is a CRC of the underlying format residing in the client-intercept module corresponding to the URL of the non-CGI request. When the server intercept module receives a response from the web server, the server intercept module will calculate the CRC of the response. The server intercept module then computes the difference between the response and the server base format of the URL and saves this difference data. The server intercept module will update the server base format with the response data and archive the CRC of the previous base format and the differential data between the response and the old base format. The server intercept module then compares the client base format CRC with the server base format CRC and the stored or documented stored CRC to determine if a match is found. If no match is found, the response is simply sent to the client intercept module.

If a match is found, the differential data corresponding to the CRC match and any subsequent differential data that arrives and includes the current differential data are sent to a client intercept module. The client intercept module then applies the difference data to the client base format to regenerate the response. Thus, if a CRC match occurs on a CRC in the base format before three generations, three sets of differential data are sent to the client intercept module and the construction of a response is completed by applying the three consecutive sets of differential data to the client base format. However, if the number of differential data sets required to regenerate a response, or the size of the differential data sets, is too large such that less data transmission is required to send the actual response, the response itself is sent through the server intercept module. In any event, upon regenerating or receiving the response, the client intercept module will update the client base format of the URL of the request with the response data and the CRC with the response. Since the client base format is updated each time a response to a particular URL is received, the aforementioned client cache can be used as a cache for the client base format, thereby eliminating the need for a separate cache for the client base format if differentiation is applied to non-CGI requests.

In another aspect of the invention, additional communication savings can be obtained based on redundancy of stateless communication protocols, such as HTTP. In such a protocol, the client transmits information about itself to the server at the beginning of each communication. Also, the server transmits specific information about itself to the client at the beginning of each response.

In an alternative embodiment of the present invention, the first computer 5 transmits computer specific information corresponding to a predetermined characteristic of the first computer to the second computer 6. The second computer stores this computer specific information. The first computer then removes the computer specific information from the subsequent web browser originated communication before transmission over the external communication link 35. The second computer then recreates the original web browser originated communication by combining the saved computer specific information with subsequent communications received via the external communication link 35 to create an HTTP data stream.

In addition to removing computer-specific information from web browser originated communications, this computer-specific information is also removed from web server originated communications. As such, the second computer 6 of FIG. 2 provides computer-specific information corresponding to the predetermined characteristics of the second computer 6 to the first computer 5 via the external communication link 35. The first computer 5 stores this computer specific information to provide server title information. In subsequent communications, the second computer 6 removes the computer-specific information from the web server originated communications and transmits the remainder of the web server originated communications over the external communication link 35. The first computer 5 receives the communication over the external communication link and recreates the original web server originated communication by combining the server header information with the client/server specific data stream received over the external communication link to produce an HTTP data stream. In both instances, the operations of removing computer-specific information and saving that information to generate server header information or client header information are performed by either the client-side intercept module 30 or the server-side intercept module 40, depending on whether such an operation occurs at the first computer 5 or the second computer 6.

In one embodiment of the invention, the web browser 10 employs the Transmission control protocol/Internet protocol (TCP/IP) to communicate with the client intercept module 30. TCP may be used for communication between the client-side intercept module 30 and the server-side intercept module 40 over the external communication link 35. Finally, TCP may also be used for communication between server intercept module 40 and web server 20. Since TCP may be used to facilitate communications between the various components that make up the system of the present invention, the HTTP protocol does not provide the most efficient method for communicating over an external communication link. To increase the performance of the external communication link 35, one embodiment of the present invention creates what is referred to herein as a "virtual socket" that is applied to the communication connection between the web browser and the client-side intercept module 30 and the communication connection between the server-side intercept module 40 and the web server 20. The operation of these virtual sockets is described below with reference to fig. 11 to 17.

Fig. 11 is a block diagram of one possible implementation of the present invention utilizing the virtual socket concept. As shown in fig. 11, the first computer 5 and the second computer 6 are connected by an external communication link 35. The web browser 10 has a collection of real slots that connect the web browser to the client-side intercept module 30. As shown in FIG. 11, the first real socket on the web browser 10 is labeled 65a and the corresponding socket on the client-side intercept module 30 is 65 b. This first real socket is the TCP socket through which the web browser 10 requests further connections from the client-side intercept module 30.

When the web browser 10 requests a new TCP connection, a communication is generated through the real socket 65a and received at the real socket 65 b. The client-side intercept module 30 then creates another real socket to communicate with the web browser 10. As shown in fig. 11, a collection of real sockets is generated on the web browser 10, while a corresponding collection of real sockets is generated on the client-side intercept module 30. These real sockets on the web browser 10 are labeled 60a through 64a and the real sockets on the client-side intercept module 30 are labeled 60b through 64 b. The real world wide web browser 10 and the client-side intercept module 30 are communicatively coupled via these. After the real sockets 60a to 64a and 60b to 64b are created, communications are multiplexed through these sockets to the real socket 36a, the real socket 36a providing the client intercept module 30 access to the external communications link 35. The real sockets 36a and 36b are generated when a request is sent to the real socket 37b of the computer 6 through the real socket 37a of the computer 5. When the real socket 37b receives a connection request, the real sockets 36a and 36b are generated. The sockets 37a and 37b serve as the first real sockets for communication between the client-side intercept module and the server-side intercept module and are used only to establish a connection between the two modules reflected by the sockets 36a and 36 b. Each of these real sockets operates under the standard TCP/IP protocol. When a communication is received by second computer 6 over external communication link 35, the communication is received at real socket 36 b. Server intercept module 40 then demultiplexes the communications received at socket 36b and provides them to the appropriate socket for transmission to web server 20. Thus, for example, communications from socket 60a to socket 60b requesting information from a particular URL are multiplexed to socket 36a, received by socket 36b, demultiplexed by server intercept module 40, and transmitted from socket 60c to socket 60d on web server 20. Likewise, communications occurring through the jack 61a are received by the jack 61b, multiplexed by the client-side intercept module 30, and transmitted from the jack 36a to the jack 36b, where the server-side intercept module 40 demultiplexes the communications and transmits to the jack 61d through the jack 61 c. Thus, communications through the sockets 60a and 60b, 61a and 61b, 62a and 62b, 63a and 63b, and 64a and 64b are transmitted through the respective corresponding sockets 60c and 60d, sockets 61c and 61d, sockets 62c and 62d, sockets 63c and 63d, and sockets 64c and 64d between the server intercept module 40 and the web server 20.

Likewise, responses from the web server 20 to requests from the web browser 10 are also transmitted to the client-side intercept module 30 via the jack connecting the web server 20 and the server-side intercept module 40 and via the external communication link 35, and subsequently to the web browser 10. Thus, for example, a response initiated by web server 20 may be sent through socket 60d to socket 60c and multiplexed by server intercept module 40 to socket 36b, where the response is transmitted over external communication link 35 to socket 36 a. The client-side intercept module 30 then de-signals the communication and provides it to the socket 60b for transmission to the socket 60a on the web browser 10. Similar communication paths are established for each socket being used by the web browser 10 or web server 20. As will be appreciated by those skilled in the art, while the invention has been described with respect to a 4-socket connection between the web browser 10 and the web server 20, any number of sockets may be used to provide a communication path between the web browser 10 and the web server 20.

Fig. 12 is a block diagram illustrating the implementation of the virtual socket system in the client-side intercept module 30 and the server-side intercept module 40. The real sockets between the client-side intercept module 30 and the web browser 10 and between the server-side intercept module 40 and the web server 20, outside of these modules, function as normal TCP/IP sockets. Thus, the benefits of the virtual socket are clear to the web browser 10 and web server 20.

A particular embodiment of the invention is illustrated below with reference to block diagram 12 and flowcharts 13 to 17. Fig. 13 is a flow chart of the socket manager labeled block 68 in fig. 12. Referring to FIG. 13, block 300 represents the generation of the real socket manager 68 of the client intercept module 30. After the real socket manager 68 is generated, the real socket manager generates a first real socket, shown as socket 65b in fig. 12. The creation of the first real socket is shown in block 301 of fig. 13. After the first real socket 65b is created, the socket manager 68 residing on the client-side intercept module 30, also referred to herein as the client socket manager, waits for an event on the first real socket 65b, as shown in block 302 of FIG. 13. When an event is received at the first real socket, the real socket manager 68 examines the event and selects one of the five paths based on the examination, as shown in block 305 of FIG. 13.

If a real socket is generated in response to a communication request received on the first real socket 65b, the real socket manager 68 adds the generated real socket to the real event list as indicated by the path between blocks 305 to 306 of fig. 13. The real socket manager then generates a simplex virtual socket, as shown in block 307. In the case of the client-side intercept module, the real socket manager initiates an application function that performs the functions of the client-side intercept module for the generated virtual socket, as shown in block 308 of FIG. 13.

As used herein, a "simplex socket" or "simplex virtual socket" refers to a socket that is directly connected to a single socket or a single application. As used herein, "multiplex outlet" refers to an outlet that connects with a collection of other outlets. Thus, the multiplexing jack performs multiplexing or demultiplexing functions, and the simplex jack performs one-to-one connection. Thus, for example, in performing the functions of blocks 306 through 308 of FIG. 13, the client socket manager 68 generates the real socket 60b, the simplex virtual socket 70, and initiates the client intercept function at the application 80 in response to the first connection request received by the first real socket 65 b. Similar to the case of a subsequent event that is generated at one of the real sockets. The real socket manager will generate real sockets 61b, 62b, 63b or 64b and simplex virtual sockets 71, 72, 73 or 74 and initiate the CSI functions, labeled blocks 81, 82, 83 or 84 in fig. 12, corresponding to the generated real and virtual sockets.

The operation of the client intercept function will now be described with reference to the real socket 60b, the simplex virtual socket 70 and the client intercept function 80 shown in figure 12. Block 325 of fig. 14 reflects the generation of the client intercept function. When it is generated, the client intercept function 80 waits for an event on the simplex virtual socket 70, as shown at block 326. This waiting operation is accomplished by implementing the virtual selection function described in FIGS. 16-4. When an event is received, the event is checked, as shown in block 330. If the event is a virtual socket shutdown, the client intercept function 80 deletes the simplex virtual socket 70, as shown in block 349, and terminates, as shown in block 350 of FIG. 14.

If the event is data reception, then the path is taken from block 330 to block 331 and the client intercept function 80 receives browser initiated communications from the simplex virtual socket 70 by performing the virtual receive operation described in FIGS. 16-3. The client intercept function then executes the client intercept module as described above (see, e.g., fig. 3 and 7), as indicated at block 332. The client intercept function 80 then generates a multiplexed virtual socket that connects to the real socket 36a in the client intercept module 30. The real socket 36a is connected to the real socket 36b on the server intercept module 40. The generation of the multiplexed virtual socket is shown at block 333 of FIG. 14 and is accomplished by performing the virtual generation operation described in FIG. 16-1. Box 334 reflects the operation of sending information received from the web browser through real socket 60b and simplex virtual socket 70 after the client-side intercept function 80 is performed on the web browser originated communication. This communication is queued to the multiplexed virtual socket 90 by performing the virtual transmit operation described in fig. 16-2. After queuing the request to the multiplexed virtual socket 90, the client intercept function 80 flushes the data queued in the multiplexed virtual socket 90, as shown in block 335 of FIG. 14, and then waits for an event on the multiplexed virtual socket, as shown in block 336. The virtual refresh function is accomplished by performing the virtual refresh operation described in fig. 17-1, which is the fetching of data from the multi-work virtual socket queue and the provision of data to real socket 36 a. The wait operation may be performed by completing the virtual select function described in fig. 16-4. At this point, the client-side intercept module has intercepted the web browser originated communication and transmitted the communication to the server-side intercept module via the external communication link 35.

Turning now to fig. 13, this figure is a flow chart showing a socket manager in the server-side intercept module 40 or the client-side intercept module 30. The real socket manager or server socket manager in the server intercept module, represented as block 69 in figure 12, performs the same functions as the client socket manager, represented as block 68. In generating the first real socket, the server-side intercept module 40 (30 in text, error) generates a "well-known port" 37b for receiving requests for each socket from the client-side intercept module 30 in contact with the server-side intercept module 40, as shown in block 301. When a real event occurs on the real socket 36b of the server intercept module 40, the event is checked, as shown in block 305. In the present case, the event is the receipt of data from real socket 36a, thus taking the path from block 305 to block 320 of fig. 13. The data received on the real socket 36b is verified and in this example a new virtual socket must be created in the server-side intercept module 40 since the data is a web browser originated communication transmitted by the client-side intercept module. This takes the path of blocks 320 to 321 in figure 13. The server socket manager 69 then performs the operations shown in blocks 321, 322, 323, and 324 of FIG. 13. The server socket management 69 generates a multiplex virtual socket 95 as shown in block 321, removes the multiplex socket activity timer as shown in block 322, and starts the application of the server intercept function as shown in block 323 of fig. 13, which is shown as block 85 in fig. 12. Data received at real socket 36b is then queued to multiplex virtual sockets 95 and virtual events are signaled.

The generation of the server intercept function, shown at block 323, is represented in fig. 15 as block 360. After the server-side intercept function 85 is generated, it receives data corresponding to the web browser originated communication sent from the client-side intercept module 30 from the multiplexed virtual socket 95. This operation is shown in block 361 of fig. 15. Upon receiving the data from the client-side intercept module, the server-side intercept function 85 processes the data for the server-side intercept module as previously described. Execution of the server intercept function is shown at block 362 (see, e.g., fig. 5 and 9). After processing this information, the server intercept function 85 generates the simplex virtual socket 75 by performing the virtual generation operation described in FIG. 16-1. This operation is illustrated in block 363 of fig. 15. The server intercept function 85 then sends the web browser originated communication to the simplex virtual socket 75 by performing the virtual send operation described in fig. 16-2. Subsequently, the server intercept function 85 performs a virtual refresh to flush data queued in the simplex virtual socket 75 to the real socket 60c and waits for an event on the simplex virtual socket 75. The virtual refresh operation described herein is described with reference to fig. 17-1. The send and refresh operations operate blocks 364 and 365 of fig. 15. The wait operation is performed by completing the virtual select function described in fig. 16-4. When the server intercept function 85 generates a simplex virtual socket 75, a corresponding real socket 60c will also be generated. The server intercept function 85 transmits the web browser originated communication to the web server by sending the web browser originated communication to the simplex virtual socket 75.

When server intercept module 40 receives a response from the web server at real socket 60c, a real event occurs, server socket manager 69 exits block 302 of FIG. 13 and checks for an event occurring at real socket 60c, as shown at block 305. In the present case, the event is data of the virtual socket that is currently present, and the path from block 320 to block 324 of fig. 13 will be taken. Data received at real socket 60c is queued for virtual socket 75 and a virtual event is signaled. When the virtual event is signaled, the server intercept function 85 (original text as the virtual intercept function) exits block 366 of FIG. 15 and checks for the event, as shown at block 370. If the event is a socket closure, an error condition results and an error message is generated in response, as shown at block 375 of FIG. 15. However, if the event is data reception, then the path from block 370 to block 371 is taken and the server intercept function 85 performs the virtual receive operation described in FIGS. 16-3 to obtain a server response from the simplex virtual socket 75, as shown in block 371. The server intercept function 85 then performs a virtual shutdown operation of the simplex virtual socket, as shown at block 372, and with reference to fig. 17-2, and processes data for the server intercept module as previously described, and is shown at block 373. (see, e.g., fig. 6 and 10).

Regardless of whether the exit path of block 370 of fig. 15 is the wrong path to block 375 or the data path to block 371, the simplex virtual socket will be deleted at block 374. The server intercept function then performs a virtual send operation on the multiplexed virtual socket 95 to transmit the web server originated communication to the client intercept module 30, as shown in block 376. Server intercept function 85 then performs a virtual refresh operation to refresh the data queued in multiplexed virtual socket 95. These operations are shown in block 377. The server intercept function 85 then performs a virtual shutdown operation to shutdown the multiplexed virtual outlet 95, as shown in block 378 of fig. 15. Finally, the server intercept function 85 deletes the multiplex virtual socket and terminates, as shown in blocks 379 and 380.

The server intercept function performs virtual send and refresh operations on multiplexed virtual sockets 95. These triggering events are on the real socket 36a and the client socket manager 68 exits block 302 and checks for the event, as shown in block 305. As data is received on real socket 36a, the path from block 305 to block 320 of fig. 13 is taken and the data is queued to multiplex virtual socket 90. Thus, when real socket 36a receives a web server response from real socket 36b over external communication link 35, this response information is demultiplexed and provided to the appropriate multiplexed virtual socket. Receipt of the data causes a virtual event to occur, as shown in block 324 of FIG. 13, and exits block 336 of FIG. 14, which is checked by the client intercept function 80, as shown in block 340 of FIG. 14.

If the event is a socket close response, then the path from block 340 to block 345 of FIG. 14 is taken and the client intercept function 80 generates an error message response and passes to block 344 of FIG. 14. If the event is data reception, in this example, the event is data reception, the path from block 340 to block 341 of fig. 14 is taken, and the client-intercepting function 80 performs a virtual reception operation to receive a response from the multiplexed virtual socket 90. This receiving operation is illustrated in block 341 of fig. 14. Upon receiving data from the multiplexed virtual socket 90, the client intercept function 80 performs a virtual shutdown operation to shutdown the multiplexed virtual socket 90, as shown in block 342. The client intercept function 80 then processes the response for the client intercept module as previously described (see fig. 4 and 8).

The operations of block 344 are performed subsequently regardless of which path was taken to exit block 340. The client intercept function 80 removes the multiplex virtual socket, as shown at block 344, and then performs a virtual send operation to send a response to the browser through the simplex virtual socket 70, as shown at block 346. When the virtual send operation is complete, the client intercept function 80 performs a virtual flush operation to flush the data queued in the simplex virtual socket to the real socket 60b, as shown in block 347, and then performs a virtual close operation to close the simplex virtual socket, as shown in block 348. After closing the simplex virtual socket to the client-side intercept function, the simplex virtual socket is removed and the client-side intercept function terminates, as shown in blocks 349 and 350 of FIG. 14.

As will be appreciated by those skilled in the art, while the present invention illustrates one particular example of the generation of simplex and multiplex virtual sockets and client-side and server-side intercept functions, a collection of such functions may be generated in either the client-side intercept module or the server-side intercept module. Thus, a client-side intercept module and a server-side intercept module according to the present invention may create a TCP/IP connection between the client-side intercept module 30 and the server-side intercept module 40 and multiplex a batch of web browser or web server originated communications over TCP/IP while maintaining the TCP/IP connection.

The remaining functions of the client socket manager and the server socket manager are best understood with reference to fig. 16-1 through 16-4 and fig. 17-1 and 17-2. These figures illustrate the operations performed by the client-side intercept module and the server-side intercept module during a virtual generate, virtual send, virtual receive, virtual select, virtual refresh, or virtual close operation as reflected in the flows of fig. 14 and 15. The operations of fig. 16-1 beginning at block 400 are performed when a virtual production operation is performed as shown at block 333 of fig. 14 and block 363 of fig. 15. The socket manager then determines whether a real socket is needed, as shown in block 405. If a real socket already exists, such as when a multiplexed virtual socket is generated that will connect to an existing real socket, the "no" path of block 405 is taken and the virtual socket is connected to the real socket, as shown in block 409. However, if a real socket is required, then the "yes" path of block 405 is taken. As shown in block 406, a real socket is generated. The resulting real socket is then added to the event list, as shown in block 408, for monitoring, as shown in block 302 of FIG. 13. After a real socket is created and a connection is established, the virtual socket is connected to the real socket, as shown in block 409, and the creation operation is complete, as shown in block 410.

To perform the virtual send operation shown in blocks 334 and 346 of fig. 14, or shown in blocks 364 and 376 of fig. 15, the operations of fig. 16-2 beginning at block 420 are performed. Data is added to the virtual socket queue as shown in block 427 and when completed, the send operation terminates as shown in block 428.

The virtual receive operation shown in blocks 331 and 341 of fig. 14, and blocks 361 and 371 of fig. 15 is completed by performing the operations of fig. 16-3 starting from block 430. The virtual socket queue is evaluated to determine if there is any data in the virtual socket queue, as shown in block 435. If there is data in the virtual socket queue, the "YES" path of block 435 is taken and the data is returned to the function that called the receive operation, as shown at block 436. If the virtual socket queue has no data and the socket is not marked as closed, the "no" path of decision block 440 is taken and returns to empty, as shown at block 441. However, if the queue has no data and the socket is marked as closed, the "yes" path of block 440 is taken and the socket is marked as closed, as shown at block 442, and a close socket response is returned to the operation requesting receipt, as shown at block 443.

The virtual selection operation in blocks 326 and 336 of fig. 14 is accomplished by performing the operations of fig. 16-4 beginning at block 445. As shown in block 446, a determination is first made as to whether data or a pending virtual shutdown operation is pending for the selected virtual socket. If there is no data or a pending virtual shutdown, the "no" path of block 446 is taken and the process waits for a virtual event on the selected virtual outlet, as shown at block 447, and terminates upon receipt of such an event, as shown at block 448. If a virtual event has occurred for the selected virtual socket data or pending virtual shutdown, the "yes" path of block 446 is taken and the process terminates, as indicated at block 448.

The virtual refresh operations of blocks 335 and 347 of FIG. 14 and blocks 365 and 377 of FIG. 15 are completed by performing the operations of FIG. 17-1 beginning at block 450. When invoked, the virtual refresh operation determines whether there is data in the virtual socket queue to be refreshed, as shown at decision block 455. If there is no data in the virtual socket queue, the refresh operation terminates and returns to the calling function, as indicated by the "NO" path of block 455. However, if there is data in the queue, then the "yes" path of block 455 is taken and a determination is made as to whether the virtual socket queue is for a multiplex socket, as shown in block 460. In the case of a multiplexed socket, a socket header consisting of three bytes reflecting the socket unique identifier and the amount of data in the transmission is added to the real socket buffer as shown in block 461. In either case, if it is a multiplex or simplex socket, the data for the real socket is transferred to the real socket buffer, as shown in block 462. If the real socket buffer is full, the "YES" path of block 465 is taken and data is sent from the real socket buffer at the real socket, as shown at block 466. If the fruit socket is not full, the "no" path of block 465 is taken. The virtual flush function then tests to determine if there is any other data in any other multiplexed virtual socket queue to be sent to the real socket. If the answer is yes, then the "YES" path of block 470 is taken and the data in the real socket buffer is not sent until the virtual flush operation is invoked again to flush one of the other virtual socket queues. If there is no more data or data to join from other multiplexed virtual sockets, then the operations of block 466 are performed and the data in the real socket buffer is sent at the real socket. After all data in the virtual socket queue corresponding to the invoked virtual refresh operation is sent to the real socket, the virtual refresh operation terminates, as shown in block 467.

The virtual close operation illustrated by blocks 342 and 348 of fig. 14 and blocks 372 and 378 of fig. 15 is completed by performing the operations of fig. 17-2 beginning at block 480. When the virtual shutdown operation is invoked, the operation first tests to determine if the virtual shutdown is a shutdown of a multiplexed virtual socket, as shown in block 485. If it is a multiplexed virtual socket, the "yes" path of block 485 is taken and a "close" operation indicator is added to the virtual socket queue. Regardless of whether the virtual shutdown is a shutdown of a multiplexed virtual socket, the virtual shutdown operation invokes a virtual refresh operation, as shown at block 487, followed by a disconnection from the real socket, as shown at block 488. The shutdown operation then tests to see if the virtual shutdown is that of a simplex virtual socket, as shown in block 490, and if not, the "no" path is taken which branches to block 495. Since the shutdown is of a multiplexed virtual socket, block 495 tests to determine if the multiplexed virtual socket is the last multiplexed virtual socket, and if so, sets a multiplexed activity timer, as shown in block 496. If not, block 496 is skipped.

Returning now to block 490, if the virtual closure is a simplex virtual socket closure, then the corresponding real socket is removed from the event list, as shown at block 491, and the real socket is closed and deleted, as shown at block 492. Whether the socket is a simplex or multiplex virtual socket, the virtual socket is marked as closed in block 497 and the close operation is terminated in block 498.

FIG. 13 will now be described in relation to FIGS. 13 and 16-1 through 16-4 and 17-1 and 17-2. When an event occurs, block 302 of FIG. 13 is exited and the socket manager checks for events that the event was generated. If the event chronologically exceeds the multiplexed socket activity timer set in block 496 of fig. 17-2, then the path from block 305 to block 312 of fig. 13 is taken. As shown in fig. 13, the socket manager then performs the operations of blocks 312 and 313 to shut down the multiplexed real sockets and delete the multiplexed real sockets corresponding to the sockets connecting the client-side intercept module and the server-side intercept module. The socket manager then waits for the next real event. The muxing event timer is reset by the generation of the muxing virtual socket, as shown in block 322.

If the event occurring at the real socket is a real socket shutdown, e.g., the web server performs a shutdown operation on the socket connection between the server and the server intercept module, then the path of blocks 305 through 309 of FIG. 13 is taken. The socket manager removes the real socket from the real event list, as shown in block 309, and detaches the virtual socket or sockets in the case of multiple, multiplexed sockets from the real socket or sockets, as shown in block 310. The socket manager then marks the virtual socket as closed and signals the virtual event. This operation is shown in block 311, and the virtual socket will be closed when all data is purged from the virtual socket queue. After marking the virtual socket as closed, the socket manager determines whether the real socket to be closed is a simplex socket, as shown in decision block 315. If the real socket being closed is a simplex socket, then the real socket is closed and deleted, as shown in block 316. The socket manager then waits for the next real event, as shown in block 302.

If it is not a simplex real socket that is being shut down, the "no" path of block 315 is taken, and then the socket manager waits for the next real event. Thus, a multiplex real socket or a socket connecting a client-side intercept module and a server-side intercept module can only be shut down by the time overflow of the multiplex socket activity timer. This maintains communication between the client-side intercept module and the server-side intercept module even after the last communication between the modules occurred after a predetermined time specified by the user. In the event of a subsequent communication request issued by the browser prior to timing exceeding the multiplex socket activity timer, communication can be performed without having to reestablish the connection between the client-side intercept module and the server-side intercept module, thereby eliminating the overhead requirement to reestablish such a connection.

The last path to be described in fig. 13 represents the case when an actual event occurs and the event is the receipt of data on a multiplex actual socket or sockets 36a or 36b in fig. 12. When data is received on a multi-tasked real socket, the data is examined, the data in the event includes a close operation identifier, such as the close operation identifier added to the virtual queue in block 486 of fig. 17-2, then a virtual close operation is performed and the path from block 320 to block 310 is taken. The socket manager disengages from the real socket, the multiplexed virtual sockets identified in the data received by the real socket, then marks the virtual sockets as "off" and signals the virtual event, as shown in block 311. Since the shutdown is a multiplexed virtual socket shutdown, the "no" path of block 315 is taken and the socket manager waits for another real event, as shown in block 320.

By performing the operations described in fig. 13 through 17, a particular embodiment of the present invention establishes a persistent connection between a first computer and a second computer over an external communication link. The persistent connection is maintained until all web browser originated communications are completed, and while the persistent connection is maintained, a batch of web browser originated communications are intercepted and multiplexed on the external communication link. The client/server specific data stream is then demultiplexed to generate a batch of HTTP data streams and the batch of HTTP data streams is provided to the web server. The persistent connection is also maintained until all communications originating from the web server are completed. And a batch of communications originating from the web server are intercepted and multiplexed over the external communication link while the persistent connection is maintained. In addition, the client/server specific data streams are demultiplexed to generate a batch of HTTP data streams and to provide the batch of HTTP data streams to the server.

In the drawings and specification, there have been disclosed typical preferred embodiments of the invention and, although specific terms are employed, they are used in a generic and descriptive sense only and not for purposes of limitation, the scope of the invention being set forth in the following claims.

Claims (42)

1. A method of increasing the performance of a web browser application resident on a first computer and communicating using the hypertext transfer protocol (HTTP) with a web server application resident on a second computer remote from said first computer, wherein at least a portion of the communication between the web browser application on the first computer and the web server application on the second computer is via an external communication link, the method comprising the steps of:

intercepting the HTTP data stream corresponding to the web browser originated communication before transmitting the HTTP data stream over the external communication link;

converting the HTTP data stream from the web browser from HTTP protocol to client/server specific communication protocol;

the converted web browser originated communication is transmitted to the web server via the external communication link as a client/server specific data stream.

2. A method as claimed in claim 1, wherein said step of transmitting comprises the steps of:

transferring the converted web browser originated communication to a second computer via an external communication link in a client/server specific data stream;

receiving a client/server specific data stream transmitted over an external communication link;

regenerating an HTTP data stream corresponding to the web browser originated communication from the client/server specific data stream received over the external communication link by converting the client/server specific data stream received in the client/server specific communication protocol to the HTTP data stream;

the web browser originated communication is provided to the web server as an HTTP data stream.

3. The method of claim 1, wherein said step of transmitting further comprises the step of transmitting the converted web browser originated communication over a wireless communication link.

4. A method as claimed in claim 1, further comprising the steps of:

storing an HTTP data stream received by the web browser in response to the web browser originated communication with the web server in a cache resident in the first computer to generate a client cache entry corresponding to the web browser originated communication with the web server;

interrogating the web browser originated communication to determine whether a client cache entry corresponding to the web browser originated communication exists; and is

Wherein if a client cache entry corresponding to a web browser originated communication exists, said converting and said transferring steps are replaced with the steps of;

the client cache entry is provided to the web browser in the form of an HTTP data stream in response to the web browser originated communication.

5. A method as claimed in claim 1, further comprising the steps of:

storing user-determined information associated with a particular web browser information request to provide the user-determined information residing in the first computer;

interrogating the web browser originated communication to determine whether the web browser requested information corresponds to a request for stored user-determined information;

if said querying step determines that the web browser communication corresponds to a request for a user-determined information to be stored, then providing the user-determined stored information to the web browser in the form of an HTTP data stream in response to the web browser originated communication; and is

Wherein said step of transmitting is replaced with said step of querying and said step of providing if the user determines that the stored information is provided to the web browser.

6. A method as claimed in claim 5, further comprising the step of receiving user-determined information from the first computer via the communications link.

7. A method as claimed in claim 4 wherein said storing step further comprises the step of storing the time at which the client cache entry was made to generate a client cache entry time record;

wherein said querying step further comprises evaluating the client cache entry time record to determine whether a client cache entry corresponding to a web browser originated communication was made in a predetermined client coherency time interval prior to the web browser requesting the information; and is

Wherein said providing step further comprises providing the client cache entry to the web browser in the form of an HTTP data stream in response to the web browser originated communication if said determining step determines that the client cache entry was made within a predetermined client coherency time interval before the web browser requested the information.

8. The method of claim 7, further comprising maintaining client cache entries in multiple instances of the web browser.

9. The method of claim 1, wherein said web browser originated communication corresponds to a Common Gateway Interface (CGI) request, said method further comprising the steps of:

interrogating the intercepted CGI request to determine whether a client base cache entry corresponding to the intercepted CGI request exists to provide a client CGI base format;

storing an HTTP data stream to be provided to a web browser in response to a browser initiated communication, the communication being a request to a common gateway interface, in a cache resident in a first computer to create a client base cache entry;

regenerating an HTTP data stream corresponding to a communication originating from the web server from the client/server specific data stream received via the external communication link by combining the client CGI base format and CGI differential data received via the external communication link to generate the HTTP data stream; and is

The web browser is provided with a communication originating from the web server in the form of an HTTP data stream.

10. The method of claim 9, further comprising the steps of:

wherein said regenerating step comprises regenerating an HTTP data stream corresponding to a communication originating from the Web server from a client/server-specific data stream received via the external communication link by combining the server CGI base format with CGI differential data received via the external communication link to produce an HTTP data stream corresponding to the intercepted CGI response; and is

The client CGI base format corresponding to the CGI request is updated by storing the received server CGI base format as the client base cache entry corresponding to the CGI request.

11. The method of claim 1, further comprising the steps of:

establishing a persistent connection between the first computer and the second computer through the external communication link;

maintaining the persistent connection until all web browser originated communications are completed; and is

Wherein said intercepting step comprises intercepting a batch of web browser originated communications and multiplexing them on an external communication link while maintaining a persistent connection.

12. The method of claim 11, further comprising the steps of:

receiving a client/server specific data stream from a second computer over an external communication link;

splitting the client/server specific data stream signal to provide a batch of HTTP data streams to the web browser; and is

And providing the batch of HTTP data streams to a web browser.

13. The method of claim 1, further comprising the steps of:

providing computer specific information corresponding to the predetermined characteristic of the first computer to the second computer through the external communication link; and is

Wherein the converting step comprises the step of removing computer specific information from the web browser originated communication.

14. A method of increasing the performance of a web browser application resident on a first computer and communicating using the hypertext transfer protocol (HTTP) with a web server application resident on a second computer remote from said first computer, wherein at least a portion of the communication between the web browser application on the first computer and the web server application on the second computer is via an external communication link, the method comprising the steps of:

intercepting the HTTP data stream corresponding to the communication originating from the web server before transmitting the HTTP data stream on the external communication link;

converting the HTTP data stream from the web server from HTTP protocol to client/server specific communication protocol;

the converted web server originated communication is streamed to the web browser over the external communication link as client/server specific data.

15. The method of claim 14, further comprising the steps of:

storing the HTTP data stream received from the web server in response to the web browser originated communication in a cache resident in the second computer to generate a server request cache entry;

interrogating a web browser originated communication to determine whether a server request cache entry corresponding to the browser originated communication has been previously stored in the cache; and is

Wherein said converting step comprises converting a server request cache entry associated with a browser initiated communication to a client/server specific communication protocol;

wherein the transmitting step comprises transmitting the converted server request cache entry to the first computer in a client/server private data stream over an external communication link.

16. The method of claim 15, further comprising the steps of:

determining whether a server request cache entry corresponding to the web browser originated communication was made in a predetermined client coherency interval before the second computer receives the web browser originated communication; and is

Wherein said converting step comprises converting the server request cache entry corresponding to the web browser originated communication to the client/server specific communication protocol if said determining step determines that the server request cache entry was made within the predetermined client coherence interval.

17. The method of claim 15, further comprising the steps of:

determining whether a client cache entry corresponding to the web browser originated communication that is the same as a server cache entry corresponding to the web browser originated communication exists; and is

Wherein said converting step comprises calculating a time interval between when the second computer receives the web browser originated communication and when a server request cache entry corresponding to the web browser originated communication is generated to provide entry period data;

wherein the sending step comprises transmitting to the first computer via the external communication link a coherent entry response comprising entry period data corresponding to a server cache entry of the web browser originated communication in a client/server specific protocol.

18. The method of claim 14, wherein said web browser originated communication corresponds to a Common Gateway Interface (CGI) request, said method further comprising the steps of:

interrogating the intercepted CGI request to determine whether a server base cache entry corresponding to the intercepted CGI request exists to provide a server CGI base format;

storing an HTTP data stream received from the web server in response to the browser initiated communication, the communication being a request to the common gateway interface, in a cache resident in the second computer to create a server base cache entry;

wherein said intercepting step comprises intercepting HTTP data corresponding to the CGI request intercepted in response to a communication originating from the web server prior to transmission of the HTTP data stream over the external communication link;

comparing the intercepted CGI response to the server CGI base format to provide CGI difference data corresponding to a difference between the intercepted CGI response and the server CGI base format;

wherein said transmitting step comprises sending the CGI differential data to the web browser in the form of a client/server specific data stream over an external communication link.

19. The method of claim 18, further comprising the steps of:

determining whether the server CGI base format is the same as a client CGI base format corresponding to the CGI request; and is

Wherein said sending step comprises transmitting the server CGI base format in the form of a client/server specific data stream over an external communication link and CGI differential data to the web browser.

20. The method of claim 18, further comprising the steps of:

determining whether a difference between the server CGI base format and the CGI response is greater than a predetermined difference limit;

if the CGI difference data is greater than a predetermined difference limit, updating a server CGI base format corresponding to the CGI request by storing a CGI response received from the web server as the server base cache entry corresponding to the CGI request; and is

Wherein said comparing step and said sending step employ an updated server CGI base format.

21. The method of claim 14, further comprising the steps of:

establishing a persistent connection between the first computer and the second computer through the external communication link;

maintaining the persistent connection until all web browser originated communications are completed; and is

Wherein said intercepting step comprises intercepting a batch of web browser originated communications and multiplexing them on an external communication link while maintaining a persistent connection.

22. An apparatus for enhancing the performance of a web browser application resident on a first computer and communicating using the hypertext transfer protocol (HTTP) with a web server application resident on a second computer remote from said first computer, wherein at least a portion of the communication between the web browser application on the first computer and the web server application on the second computer is via an external communication link, the apparatus comprising:

means for intercepting the HTTP data stream corresponding to the web browser originated communication prior to transmission of the HTTP data stream over the external communication link;

means for converting the web browser originated HTTP data stream from an HTTP protocol to a client/server specific communication protocol;

means for streaming the converted web browser originated communication to a web server via an external communication link in a client/server specific data stream.

23. An apparatus as claimed in claim 22, wherein the transmitting means comprises:

means for transmitting the converted web browser originated communication to a second computer in the form of a client/server specific data stream over an external communication link;

means for receiving a client/server specific data stream transmitted over an external communication link;

means for regenerating an HTTP data stream corresponding to a web browser originated communication from a client/server specific data stream received over an external communication link by converting the client/server specific data stream received in a client/server specific communication protocol to the HTTP data stream;

means for providing the web browser originated communication to the web server as an HTTP data stream.

24. The apparatus of claim 22 wherein said means for transmitting comprises means for transmitting the converted web browser originated communication over a wireless communication link.

25. An apparatus as recited in claim 22, further comprising:

means for storing the HTTP data stream received by the web browser in response to the web browser originated communication with the web server in a cache resident in the first computer to generate a client cache entry corresponding to the web browser originated communication with the web server;

means for interrogating the web browser originated communication to determine whether a client cache entry corresponding to the web browser originated communication exists; and is

Means for providing the client cache entry to the web browser in the form of an HTTP data stream in response to the web browser originated communication.

26. An apparatus as recited in claim 22, further comprising:

means for storing user-determined information associated with a particular web browser information request to provide the user-determined information residing in the first computer;

means for interrogating a web browser originated communication to determine whether the web browser requested information corresponds to a request for stored user-determined information;

if the interrogation means determines that the web browser communication corresponds to a request for a user-determined information to be deposited, then the user-determined deposited information is provided to the web browser in the form of an HTTP data stream in response to the means for a web browser originated communication.

27. The apparatus of claim 26, further comprising means for receiving user-determined information from the first computer via the communication link.

28. An apparatus according to claim 25, wherein said storage means further comprises means for storing the time at which the client cache entry was made to produce a client cache entry time record;

wherein said interrogation means further comprises means for evaluating the client cache entry time record to determine whether a client cache entry corresponding to a web browser originated communication was made in a predetermined client coherency time interval prior to the web browser requesting information; and is

Wherein said providing means further comprises means for providing the client cache entry to the web browser as an HTTP data stream in response to the web browser originated communication if said determining means determines that the client cache entry was made within a predetermined client coherency time interval before the web browser requested the information.

29. The apparatus of claim 28, further comprising means for maintaining client cache entries across multiple web browsers.

30. An apparatus as recited in claim 22, wherein said web browser originated communication corresponds to a Common Gateway Interface (CGI) request, said apparatus further comprising:

means for querying the intercepted CGI request to determine whether a client base cache entry corresponding to the intercepted CGI request exists to provide a client CGI base format;

means for storing the HTTP data stream of the request to the common gateway interface in a cache resident in the first computer to create a client base cache entry;

means for regenerating an HTTP data stream corresponding to communications originating from the Web server from the client/server-specific data stream received over the external communication link by combining the client CGI base format with CGI differential data received over the external communication link to produce the HTTP data stream; and is

A web browser-originated communication is provided to a web browser's device in the form of an HTTP data stream.

31. An apparatus as recited in claim 30, further comprising:

wherein said means for regenerating comprises means for regenerating an HTTP data stream corresponding to a communication originating from the Web server from a client/server-specific data stream received over the external communication link by combining the server CGI base format with CGI differential data received over the external communication link to produce an HTTP data stream corresponding to the intercepted CGI response; and is

Means for updating a client CGI base format corresponding to the CGI request by storing the received server CGI base format as the client base cache entry corresponding to the CGI request.

32. An apparatus as recited in claim 22, further comprising:

means for establishing a persistent connection between the first computer and the second computer through an external communication link;

means for maintaining the persistent connection until all web browser originated communications are completed; and is

Wherein said intercepting means comprises means for intercepting a batch of web browser originated communications and multiplexing them over an external communication link while maintaining a persistent connection.

33. An apparatus as recited in claim 32, further comprising:

means for receiving a client/server specific data stream from a second computer over an external communication link;

means for splitting the client/server specific data stream signal to provide a batch of HTTP data streams to the web browser; and is

Means for providing said plurality of HTTP data streams to a web browser.

34. The apparatus of claim 22, further comprising:

means for providing computer specific information corresponding to a predetermined characteristic of the first computer to the second computer via the external communication link; and is

Wherein said converting means comprises means for removing computer specific information from the web browser originated communication.

35. An apparatus for enhancing the performance of a web browser application resident on a first computer and communicating using the hypertext transfer protocol (HTTP) with a web server application resident on a second computer remote from said first computer, wherein at least a portion of the communication between the web browser application on the first computer and the web server application on the second computer is via an external communication link, the apparatus comprising:

means for intercepting the HTTP data stream corresponding to the communication originating from the web server prior to transmission of the HTTP data stream on the external communication link;

means for converting the HTTP data stream from the web server from the HTTP protocol to a client/server specific communication protocol;

means for streaming the converted web-server originated communication to the web browser via the external communication link as a client/server specific data stream.

36. An apparatus as recited in claim 35, further comprising:

means for storing the HTTP data stream received from the web server in response to the web browser originated communication in a cache resident in the second computer to generate a server request cache entry;

means for interrogating a web browser originated communication to determine whether a server request cache entry corresponding to the browser originated communication has been previously stored in the cache; and is

Wherein said means for translating includes means for translating a server request cache entry associated with a browser initiated communication to a client/server specific communication protocol;

wherein said means for transmitting comprises means for transmitting the converted server request cache entry to the first computer in a client/server private data stream over the external communication link.

37. An apparatus as recited in claim 36, further comprising:

means for determining whether a server request cache entry corresponding to the web browser originated communication was made in a predetermined client coherency interval before the second computer receives the web browser originated communication; and is

Wherein said means for converting comprises means for converting a server request cache entry corresponding to a web browser originated communication to a client/server specific communication protocol if said means for determining determines that a server request cache entry was made within a predetermined client coherence time interval.

38. An apparatus as recited in claim 36, further comprising:

means for determining whether a client cache entry corresponding to the web browser originated communication that is the same as a server cache entry corresponding to the web browser originated communication exists; and is

Wherein said converting means comprises means for calculating a time interval between when the second computer receives the web browser originated communication and when a server request cache entry corresponding to the web browser originated communication is generated to provide entry period data;

wherein said means for sending comprises means for transmitting to the first computer via the external communication link in a client/server specific protocol a coherent entry response containing entry period data corresponding to a server cache entry of the web browser originated communication.

39. An apparatus as recited in claim 35, wherein said web browser originated communication corresponds to a Common Gateway Interface (CGI) request, said apparatus further comprising:

means for querying the intercepted CGI request to determine whether a server base cache entry corresponding to the intercepted CGI request exists to provide a server CGI base format;

means for storing the HTTP data stream received from the web server in response to the browser initiated communication, the HTTP data stream being requested from the common gateway interface, into the cache residing in the second computer to create a server base cache entry;

wherein said intercepting means comprises means for intercepting HTTP data corresponding to the CGI request intercepted in response to a communication originating from the web server, prior to transmission of the HTTP data stream over the external communication link;

means for comparing the intercepted CGI response to the server CGI base format to provide CGI difference data corresponding to a difference between the intercepted CGI response and the server CGI base format;

wherein said transmission means comprises means for transmitting the CGI differential data to the web browser in the form of a client/server specific data stream over an external communication link.

40. An apparatus as recited in claim 39, further comprising:

means for determining whether the server CGI base format is the same as a client CGI base format corresponding to the CGI request; and is

Wherein said means for transmitting comprises means for transmitting the server CGI base format in the form of a client/server specific data stream and for transmitting CGI differential data to the web browser via an external communication link.

41. An apparatus as recited in claim 39, further comprising:

means for determining whether a difference between the server CGI base format and the CGI response is greater than a predetermined difference limit;

means for updating the server CGI base format corresponding to the CGI request by storing the CGI response received from the web server as the server base cache entry corresponding to the CGI request if said determining means determines that the difference between the server CGI base format and the CGI response is greater than a predetermined difference limit; and is

Wherein said comparing means and said sending means use an updated server CGI base format.

42. An apparatus as recited in claim 35, further comprising:

means for establishing a persistent connection between the first computer and the second computer through an external communication link;

means for maintaining the persistent connection until all web browser originated communications are completed; and is

Wherein said intercepting means comprises means for intercepting a batch of web browser originated communications and multiplexing them over an external communication link while maintaining a persistent connection.