CZ354197A3 - Method of data capture received from another application and computer program product for making the same - Google Patents

Abstract

A computer program product is provided for caching data received from a first application and to be provided to a second application in response to a request from the second application. A data stream to be received from the first application and to be provided to the second application is stored in a cache to create a client cache entry corresponding to the request from the second application. The time of creation of a client cache entry is also stored to create a client cache entry time record. Requests from the second application are interrogated to determine if a client cache entry exists corresponding to the request. The client cache entry time record for the client cache entry corresponding to the request from the second application is evaluated to determine if the client cache entry corresponding to the request from the second application was created within a predetermined client coherency time interval prior to the second application requesting the information. The client cache entry is supplied to the second application in response to the request if a client cache entry for the request from the second application was created within a predetermined client coherency time interval prior to the second application requesting the information.

Description

A method of capturing data received from a second application, device, and computer program product to execute it

Technical field

The present invention relates to a data capture method that is particularly useful in systems with slow or wireless communications between two computers, one operating with a client application and the other operating with a server application. The invention further relates to a device and a computer program product for carrying it out.

BACKGROUND OF THE INVENTION

Recent publicity and emphasis on informační 'information superhighway' have resulted in increased awareness and acceptance of the Internet as a mass communication medium. This broad-based understanding of the potential of the Internet as a viable medium for communication and interaction between many different networks has also created an extensive user base built on Internet standardization protocols for interaction between computer networks.

Typical for the Internet is that there is a client-server relationship where the Internet client (browser) communicates with the Internet server. In order to achieve better Internet access, communication protocols and languages used by clients and servers are gradually standardized. These protocols include Hyper-Text Transfer Protocol (HTTP), which is the communication protocol used for communication between clients and servers, and Transfer Control Protocol / Internet Protocol (TCP / IP), where part of TCP is a transmission-specific protocol 1 for communication. between computers or applications.

Standardized is also the language in which clients and servers

that is called Hyper-Text Markup

Language (HTML). Because these protocols and language are machine-independent, and because they use a protocol with minimal connection and best performance to send information, each transaction is fully separate. This means, for example, that each report from the client contains information about the capabilities of the browser (s) and is independent from the perspective of the communication to be completed on any other communications. This independence of client-server communication can be referred to as “stateless communication, which increases the amount of data that must be transmitted between the client and server for that communication.

In the context of the World Wide Web applications of the k1 ient / server type, the client can be a web browser that creates a user interface. This web browser sends user requests to the appropriate web server and formats and displays the HTML data returned from the web server. The web browser also evaluates this HTML data to determine if there are many embedded hyper-link commands that would require subsequent browser requests that would then be initiated by the browser. The web server acts as a client server and handles the requests of web browsers and responds to requests in the form of part of the HTML data in the HTTP data stream.

An example of a typical world wide web communication is when a web browser initiates a home page request from a web server, as this illustrates the basic relationship between HTTP, HTML, TCP, and the web browser and server. When a web browser user requests information from a specific web site, the web browser initiates communication with the web server by sending a retrieve request to the web server with the Universal Resource Locator (URL) specification of the desired web site, e.g., the aforementioned home page. The URL represents the site's URL and is

unique across the Internet. The web server would then retrieve and send the web browser HTML data corresponding to the homepage of the specified URL. This operation may include additional communications

on the Internet from the web server's Internet site, or URL can speci ficate server in the local network to which the browser is

connected. The web browser would then evaluate the received HTML data

as data HTTP flow from the web server to see if there do not occur embedded hyper-link links, such as icons and images, and initiates requests, if any

specifying the hyper-link URL to get the data needed. The data thus obtained is then incorporated into the homepage

and displayed users. As this example shows,

a simple user input request from a web browser can result in multiple additional requests that the web browser automatically executes in response to received HTML data corresponding to the user input request.

The popularity of the web browser / web server and its common information and transmission protocols, HTML and HTTP, has led to the rapid adoption of web technology as a universal interface for accessing information on the network. Furthermore, due to standardization of protocols and language for communication between web browsers and web servers, the communication protocols and language will be the same regardless of whether the user is working with the program

Netscape Navigator, NCSA Mosaic, WebExplorer or any other web browser that allows it to access network information. This means that a large installed user base for web browsers combined with an Internet connection and the ease of writing to a defined HTTP interface make web application web servers using the Common Gateway Interface (CGI) a very attractive means for a large class of form-based applications.

At a time when the Internet was growing in popularity and its availability expanded, so was the popularity of mobile computing.

Use of laptops, laptops, resources Staff

Digital 1 / Communicati on Assistants (PDA / PCA) and other portable devices have led to increased wireless communication requirements.

However, long-distance wireless communications networks, cellular communications, and packet radio communications suffer from common limitations when used in the web context. High per-byte conversion costs, slow response time, low bandwidth and unreliability - all hamper the use of wireless technology for stateless communication protocol World

Wide Web. Because the web protocol is stateless, the amount of data per request, as well as the number of requests transmitted over wireless connections, is greater than would be necessary if

the communication was not independent. Thus, a combination of wireless technology or other slow communication technology with this web seems impractical because the power of web technology is in its universal nature, and it exposes the weaknesses of wireless technology.

In addition to the disadvantages of using wireless communication in a web k1 ient / server environment, traditional capture techniques offer limited use. Recovering captured data received from a web server means reliability and knowledge of the difficulties in use in a web environment. For example, the captured data is restored

each time a new instance of the web browser is initiated, more unnecessary browser requests may be generated if this information is not used during a particular instance of the web browser. If the captured data is not recovered, then this data in the cache is not reliable.

SUMMARY OF THE INVENTION

In view of the above limitations, one object of the present invention is to provide a capture system that provides reliable data without the need for unnecessary updates of the captured data.

It is another object of the present invention to provide a capture structure that can be used in a web browser / server environment.

It is also an object of the present invention to maintain compatibility with existing communication protocols and languages for slow or wireless communication systems, without the need to modify web browser or web server applications.

It is another object of the present invention to provide a capture method that reduces the amount of communication required between the web browser and the web server, and thus enhances the performance of the communication system.

In view of these and other objects, the present invention provides a method of capturing data received from a second application, and also provided on a first application, in response to a request from a first application. The method includes storing the data stream to be received from the second application and to be provided to the first application in a first cache memory to create a client cache entry corresponding to the request from the first application. The client write cache time is also stored to create a client write cache time record. Requests from the first application are intercepted to determine whether there is a client write cache matching the request. If there is a client cache entry that corresponds to the request, then the client entry cache time entry for the client application cache entry corresponding to the first application request is evaluated to determine whether a client application cache entry corresponding to the first application request was created during a predefined client coherent the time interval before the first application requested information. The client write cache is passed to the first application in response to a query of whether the client write cache was created during a predefined client coherent time interval before the first application requested information.

In a further embodiment of the present invention, client caches are maintained for multiple instances of the first application.

In an alternative embodiment of the present invention, the first application is resident on the first computer and the second application resident on the second computer, wherein the first and second applications communicate with each other via an external communication link.

In this alternative embodiment, the present invention further comprises storing the data flow from the second application in response to a request from the first application to a second cache memory resident on the second computer so as to create a server request write cache. The request created by the first application is further evaluated to determine whether the write cache of the server request corresponding to that request was previously stored in the second cache memory. The server request write cache corresponding to the request from the first application is then sent to the first application resident on the first computer over an external communication link.

In another alternative embodiment of the present invention, the second computer determines whether the request write cache, the server corresponding to the request from the first application, was created during a predefined client coherent time interval before the second computer received the request. A server request write cache that corresponds to a request from the first application is sent to the first computer if the server request write cache was created during a predefined client coherent time interval.

An alternative embodiment of the present invention may also include determining whether there is a client cache entry corresponding to a request from a first application that is identical to the server cache entry request. The time interval between the second computer receiving the request from the first application and the creation of the server request write cache corresponding to the request from the first application is calculated to provide write age data. The write age data for the server cache write corresponding to the request from the first application is transferred to the first application resident on the first computer, and the time record of the application is taken by the computers.

the cache of the corresponding request from the first updated by subtracting the age of the entry, the computer, from the current time on the first is from the second

In other embodiments, the web browser and the second communicate with the first and the present invention, the first application forms a web server application, and in a further embodiment the second computer over a wireless communication link.

The above-described aspects of the present invention may also be provided in another form as desired, e.g., as a computer program (i.e., a computer-readable file).

BRIEF DESCRIPTION OF THE DRAWINGS

The invention is explained in more detail below with reference to the drawings.

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

Giant. 2 is a block diagram of a web browser / web server system according to an embodiment of the present invention utilizing client capture and server capture.

Fig. 2a shows a block diagram of a web browser / web server system according to an embodiment of the present invention using the client's first cache and the server's second cache.

Giant. 3 shows a flow chart of operations performed by the intercept module on the client side in the preferred mode

an embodiment of the present invention implementing a coherent cache system.

Giant. 4 illustrates a flow chart of operations performed by a client-side intercept module in a preferred embodiment of the present implementing implement

a coherent cache system.

Giant. 5 is a flowchart of operations performed by a server-side intercept module in a preferred embodiment of the present invention implementing a coherent cache system.

Giant. 6 is a flow chart of operations performed by a server-side intercept module in a preferred embodiment of the present invention implementing a coherent cache system.

Giant. 7 illustrates a flow chart of operations performed by a client-side intercept module in a preferred embodiment of the present invention implementing a differential data transmission system.

Giant. 8 illustrates a flow chart of operations performed by a client-side intercept module in a preferred embodiment of the present invention implementing a differential data transmission system.

Giant. 9 is a flowchart of operations performed by a server-side intercept module in a preferred embodiment of the present invention implementing a differential data transmission system.

Giant. 10 is a flow chart of operations performed by a server-side intercept module in a preferred embodiment of the present invention implementing a differential data transmission system.

Giant. 11 is a block diagram of one embodiment of the present invention using virtual sockets.

Giant. 12 is a block diagram of a client-side intercept module and a server-side intercept module according to an embodiment of the present invention using virtual sockets.

Giant. 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 an embodiment of the present invention;

using virtual sockets.

Giant. 14 is a flowchart describing operations performed by a client-side intercept function in one embodiment of the present invention using virtual sockets.

Giant. 15 is a flowchart describing operations performed by a server-side intercept function in one embodiment of the present invention using virtual sockets.

Giant. 16-1 illustrates a flow chart describing a virtual creation operation according to an embodiment of the present invention using virtual sockets.

Giant. 16-2 is a flowchart describing a virtual send operation according to an embodiment of the present invention using virtual sockets.

Giant. 16-3 is a flowchart describing a virtual receive operation according to an embodiment of the present invention using virtual sockets.

Giant. 16-4 is a flowchart describing a virtual selection operation according to an embodiment of the present invention using virtual sockets.

Giant. 17-1 illustrates a flow chart describing a virtual alignment operation according to an embodiment of the invention using virtual sockets.

Giant. 17-2 is a flowchart describing a virtual close operation according to an embodiment of the present invention using virtual sockets.

DETAILED DESCRIPTION OF THE INVENTION

The present invention will now be described in more detail, namely. with reference to the accompanying drawings, in which preferred descriptions of the invention are shown. However, the present invention may be embodied in many different forms and should not be construed as limited to the embodiments herein. These incorporations are presented to them

9a

the description is complete and complete, and that the present invention is fully presented to those of ordinary skill in the art. Throughout the document, individual elements indicate numbers.

The basic communication structure for the Internet-based system is shown in Fig. 1. In Fig. 1, web browser 10 communicates with web server 20 over communication link 15. This communication link is usually a LAN, WAN link using *

telephone lines or a combination of interconnection methods. The web browser 10 communicates with the web server 20 via TCP / IP. Most Internet communications are with the web server through that the web browser communicates a generic HTTP communication protocol that is transmitted between the web browser and the web server over a TCP / IP link established between the web browser and the web server. The actual data transmitted between the web browser 10 and the web server 20 is made up of HTTP objects (e.g., HTML data) as described above. The web server 20 may also be an intermediary that receives web browser communications from multiple web browsers and routers and forwards them to the appropriate server.

Giant. 3 to 10 and 13 to 17-2 are flow diagrams of the methods and systems of the invention. It should be clear that each block

flowcharts as well as combinations of these blocks can be implemented using a computer program instruction of a computer program. These programs may be loaded onto a computer or may consist of other programmable devices

in order to make the machine such that the instructions that the computer or other programmable device will execute provide means for implementing the functions specified in the block or flowchart blocks. These computer program instructions can be stored in a computer readable memory that can control a computer or other programmable device to operate in a particular way, as instructions stored in a computer readable memory create a production article, including instructions that implement a function

- 9b specified in the flowchart or blocks. Computer program instructions may also be loaded into a computer or other programmable device by causing a series of functional steps performed on a computer or other programmable device to create a computer-implemented process, as well as instructions that perform steps on a computer or other programmable device to implement functions. specified in the block or flowchart blocks.

Similarly, flowchart blocks support combinations of step means to perform specific functions. Each block to illustrate a flowchart or a combination of blocks may also be implemented by a dedicated dedicated hardware-based computer system that performs the specified functions or steps, or by a combination of special purpose hardware and computer instructions.

Figure 2 illustrates one embodiment of the present invention. As shown in Figure 2, the web browser 10 communicates with a client-side intercept module. The web server 20 communicates with the intercept module on the server side 40. The intercept module on the client side 30 then communicates with the intercept module on the server side 40 via the communication link 35. The web browser 10 and the intercept module on the client side 30 may be located in the first computer. The intercept module on the server side 40 and the web server_20 may be located in the second computer 6. The first computer 11 and the second computer 6 communicate with each other via an external communication link 35.

Preferably, the web browser is an internet web browser using hypertext transfer protocol (HTTP) and hypertext markup language (HTML) to communicate with an internet web server 20 that also uses HTTP and HTML. In operation, the web browser 10 would output the HTTP data stream that is captured by the client-side module 30. Capture of the HTTP data locator by the client-side intercept module 30 can be performed using the TCP / IP loopback function, where the client-side intercept module 3 ^ 0 is resident at an IP address and has a network number of 127, eg 127.0.0.1. The client-side intercept module 30 then converts or transforms the HTTP data stream into a specific client / server protocol and sends the specific client / server data stream to an external communication link. The server-side intercept module receives a specific bitrate and reconstructs the original HTTP bitrate corresponding to the communication created by the web browser. This reconstructed HTTP data stream is then sent to the web server 20. The web server 20 responds to the HTTP data stream in the usual manner for an Internet web server. In view of the evaluation of the invention, it should be noted that the web server 20 may also be replaced so as to provide an Internet connection for multiple browsers.

Once the information is received by the web servererrr20 for sending to the web browser 10, for example in response to a browser request for a specific homepage URL, the web server sends an HTTP output stream corresponding to the communication to be sent to the web browser. server-side module JO ^ and transformed to a specific client / server bitrate. This specific client / server bitrate corresponds to the communication being created

RA 995 086

1 is then sent to an external .35 communication link. the second computer to the first computer. The specific client / server data stream is received by the first client-side intercept module 30 which reconstructs the original HTTP data stream corresponding to the communication generated by the web server and provides it to the web browser 10.

In a specific embodiment of the present invention, the external communication link 35 is a wireless communication link. In such a case, in order to achieve user-friendly system performance, it is necessary to reduce the volume of communication over the external communication link 35, both in terms of frequency of communication and in the amount of information that must be transmitted over the communication link 35. employs techniques of balancing, creating, and reducing protocols to minimize communication through an external communications link 35 These techniques are performed by converting stateless or stochastic HTTP protocols to a specific client / server protocol that uses client-specific and server-specific information to minimized the volume and frequency of communication.

While the present invention is and will be described with respect to one web browser application and one web server application, it should be noted to evaluate the present invention that the advantages and advantages of the present invention can also be achieved by multiple web browsers assigned to one web server. Thus, the present invention also relates to methods, devices, and software products in conjunction with multiple browsers, each of which communicates via a client-side intercept module and wherein the client-side intercept module communicates with the server-side intercept module of the web server or other web device.

In one embodiment of the present invention, both the first client-side intercept module and the intercept module

The server-side module 40 utilizes the buffering capability. The client cache is located on the first computer and stores HTTP data streams to be received by the web browser in response to communication generated by the web browser. The server cache is resident on the other computer and stores HTTP data streams that are received from the web server in response to browser-generated communication.

Giant. 2a shows a cache memory storage corresponding to a capture module according to an embodiment of the invention. Klinet's first cache memory 31 on the first client-side intercept module 30 is resident on the first computer 5, and the second server-side memory cache 40 is resident on the second computer 6.

In view of the evaluation of the present invention, the cache memory resident on the first computer or on the second computer may be of any size and of any specific hardware or configuration of the computer. These caches store information for each communication, including URL communication, a unique communication-based identifier including, for example, cyclic redundancy check (CRC), communication data, storage date and time (SDT) indicating the time when the write cache was created or refreshed, and communication give. Thus, a write cache directory can be created for each cached communication. Thereby, the client cache 3.2 is stored in the first client-side cache 31 and the server-side cache 42 is stored in the second server-side cache 42, as shown in FIG. 2a. Further, due to the limited resources available for a given hardware configuration, there may be any number of caching techniques as well as maintaining resident caches on both the first and second computers. All of this is covered by the present invention. This means, for example, that the cache memory can invalidate the oldest write directory if it is user-defined

12a

cache size is exceeded due to the addition of a new listing. Furthermore, cache writes can be maintained through multiple entities of web browser or web server applications or even power-on cycles on the first or second computer to create a permanent cache.

The operation of the alignment structure according to one embodiment of the present invention is described with reference to Figs.

Specifically, in Fig. 3, block 100 indicates that the client-side intercept module has received a request from the web browser 10. This request can be in the form of an HTTP data stream. The client-side 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 the information previously stored in the client cache was resident on the first computer 5 corresponding to the request created by a web browser.

If the information corresponding to the URL has not previously been stored in the client cache, then the client-side intercept module performs the action shown in block 106. The client-side intercept module 30 sends a request over the external communication link 35 to the server-side intercept module 40.

PETR KALENSKÝ

AT7ORNEY AT LAW

However, if, after examining the communication created by the web browser, as shown in block 105, it is found that there is a client cache entry that corresponds to the communication created by the web browser, then in the simplest incorporation this information would be provided to the web browser as an HTTP data stream. However, as shown in Figure 3, the preferred embodiment of the present invention performs what is referred to herein as a coherent interval check on the write cache corresponding to the communication created by the web browser. This operation is illustrated in block 110 of Figure 3.

The coherent client-side intercept module can be user-defined and is determined by the length of time that the write cache can exist before it becomes obsolete, and must be refreshed by asking for information corresponding to the communication created by the web browser, the web server. The coherent interval check shown in block 110 can be performed by comparing the current date and time with the sum of the SDT write cache corresponding to the communication created by the web browser and the coherent interval specified by the user. If the current date and time is greater than this amount, then the information stored in the cache corresponding to the communication generated by the web browser will become obsolete and the "No" block of block 110 will apply. However, if the current date and time is less than the SDT sum plus a user defined coherent interval , then the "Yes" branch of block 110 applies, and as further shown in block 111, the write cache is passed to the browser as an HTTP data stream. The communication generated by the browser will then be received by the client-side intercept module 30 in block 100, see Figure 3.

If the coherent interval check shown in block 110 determines that the write cache resident on the first computer is obsolete, it generates a request on the server side intercept module to check the coherence of the write cache resident on the second computer. This operation is illustrated by block 112 in Figure 3. It is performed using an external communication link 35 used to pass a coherent interval to the server-side intercept module 40 for a particular client-side intercept module corresponding to the query web browser 10, and provided clear clues about the content of the client's cache, corresponding to the URL communication generated

RA995 086

-14web browserem. In a preferred embodiment, this unambiguous indicia is the result of a cyclic redundancy check or CRC for a given cache write.

Referring now to Figure 5, which illustrates the operation of a server-side intercept module in response to information received via an external communication link 35 from the client-side intercept module 30. When the server-side intercept module 40 receives a request from the client-side intercept module, the sen / eru 40 side module receives a predefined client coherent time interval, a CRC value for the client cache entry, and an HTTP query generated by the web browser. Confirm this

information is shown in block 120 of Figure 5.

Upon receiving information from the client-side intercept module 30, the server-side intercept module 30 checks its server cache resident on the other computer to determine if there is a server cache entry corresponding to the URL of the HTTP request generated by the web browser. If after examining the communication created by the site

by the browser, as indicated in block 125, the server-side intercept module determines that there is a cache entry corresponding to the information requested by the communication generated by the web browser, the "Yes" branch of block 125 is applied. the date and time of the SSI_40 module with the sum of the SDT server cache entry corresponding to the information requested by the communication created by the web browser and with a predefined client coherent time interval received from the client-side intercept module.

If the current date and time is less than the sum of the SDT for the server write cache and the coherent interval, then the Yes branch of block 130 in Figure 5 applies. The server-side intercept module then compares the CRC of the server write cache with the CRC of the client write cache to whether these caches are identical. If the two caches are identical, the "Yes" branch of block 135 is applied and, as shown in block 136, a "coherent response to the intercept module on the key side 30" is sent.

If the condition block 135 determines that the CRCs are not identical, then the information contained in the client cache and the server cache and

RA995 086

As shown in block 137, the server side intercept module sends the server cache write to the first computer over an external communication link. When the server write cache is sent to the intercept module on the client side 30, the server side intercept module converts the write to the client specific communication protocol that contains the CRC, data, and age of the server write cache. The server write cache age is calculated by subtracting the SDT write cache from the current date and time.

And if, as finally shown in Figure 5, either the sum of SDT plus a predetermined client coherent time interval is less than the current date and time, or there is no cache entry corresponding to the URL communication generated by the web browser, then the branch of No block 130 applies. Thus, block 126 operations are performed and server-side intercept module 40 sends a web browser-generated communication as an HTTP data stream to the server. If the server-side intercept module has to send the communication created by the web browser to the server as an HTTP data stream, then the server-side intercept module will perform the operations described in Figure 6.

As can be seen from block 140 in Figure 6, in response to the communication created by the web browser, the server-side intercept module will receive an HTTP stream from the web browser.

server 20, Upon receiving the HTTP data stream, it calculates the server side intercept module 40_CRC for the HTTP data stream and temporarily stores the HTTP data stream. Then, as shown in block 145, the server-side intercept module examines the HTTP data stream and determines whether there is a server cache entry corresponding to the HTTP data stream URL.

If such an entry exists, the "Yes" path of block 145 is used. The server-side intercept module 40_potom compares the recently calculated CRC of the HTTP data stream received from the web server 20 to the CRC of the server write cache corresponding to the URL communication in the response generated by the web server. block 150. If the CRCs are identical, the "Yes" branch of block 15 is applied (The server-side intercept module 40 updates the SDT entry for the server cache entry, as shown in block 151, and clears the temporarily stored HTTP stream received by the web server 20. as shown by block 152.

RA995 086

-> 1

If the CRC comparison results indicate that the server write cache is different from the HTTP data stream received from the web server 20, then the No block of branch 150 is applied. The server-side intercept module removes existing data from the server cache as shown in 153, and then, as shown in block 154, updates the server cache _Λ newer information. It is further evident from block 154 that this update includes storing the CRC of the web server communication in a server cache, storing the current date, and

Time in the form of SDT as part of the cache write and save HTTP stream. Whenever the server write cache is updated or when the server write cache is found to be identical to the received HTTP data stream from server 20, the server-side intercept module determines whether the server write cache matches the client write cache corresponding to the communication created by the web browser . This operation is illustrated by block 155.

If the intercept module on the server side 40 determines that there is no cache entry corresponding to the response received from the web server 20, the branch "No" of block 145 is applied. The server cache entry is created, as shown by block 146, by storing the URL. responses from a web server, saving a CRC response from a web server, saving an HTTP stream, and saving the current date and time as an SDT. After creating a write cache corresponding to the communication created by the web server, the server-side intercept module 40 again compares the CRC of the server write cache with the CRC corresponding to the client write cache, as shown in block 155.

If the results of a comparison of the server write cache and the client write cache indicate that the write cache is identical, the "Yes" branch of block 155 is applied and block 156 operations are performed. Block 1 ^ 56It is clear that the intercept module on server side 40 sends a coherent response to the client-side intercept module 30. The server-side intercept module transforms the server request cache write to a specific client / server data stream by sending a coherent response as well as zero age to the client-side intercept module.

If the server-side intercept module determines that the client cache entry is not identical to the server cache entry corresponding to the Web site traffic

RA 995 086

By block 17, the "No" branch of block 155 is applied and block 157 operations are performed. As is clear from block 157, the server side intercept module 40 converts or transforms the server cache entry into a specific client / server data stream. This data stream includes the CRC server write cache, the HTTP server write cache, and the write cache age, which is set to zero. This specific client / server communication is then sent via an external communication link 35 to the client-side intercept module 30.

The function of the client-side intercept module 30 upon receipt of communication from the server-side intercept module will be described with respect to Figure 4. As is clear from block 160, the client-side intercept module receives or requires a specific client / server data stream that has been transmitted. via an external communication link 35. The client-side intercept module then determines what type of response was received from the server-side intercept module 40, as shown in block 165. If the server-side intercept module indicates that the client's write cache is coherent, that is, the identical caches are identical. server and client writes, then the operations shown by block J66 are performed. As seen from block 166, the client-side intercept module 30 of the SDT updates the client's write cache corresponding to the communication created by the web browser by the current date and time and age differences received from the server-side intercept module 40. Thus, without synchronizing the clocks of the first computer J 1 and the second computer 6, the present invention revised the coherent write cache time of the first computer to reflect the newer data from the second computer. After updating the SDT of the client write cache corresponding to the communication created by the web browser, the client-side intercept module 30 sends the client cache write to the web browser 10 as well as an * - ----- HTTP data stream. This activity is illustrated by block 174.

However, if the client-side intercept module indicates that the response type is a data or bitrate, the stream branch of block 165 is applied and the block operation 67 is performed. The client-side intercept module 30 receives the HTTP data stream and temporarily stores the data. Then, as shown in block 170 in Figure 4, the client-side intercept module 30 determines whether there is a cache entry corresponding to the communication created by the web browser. If this write cache exists, the "Yes" path of block 170 is used and how it is

RA995 086

-18 indicated in block71 regenerates the existing cache entry. The client-side intercept module then updates the cache entry corresponding to the communication created by the web browser by storing the CRC of the HTTP data stream received from the server side intercept module 45γ by storing as SDT the difference between the current date, time and age received from the server-side intercept module. saving an HTTP stream. This operation is illustrated by block 172.

If there is no cache entry corresponding to the communication created by the web browser, the No path of block 170 is applied. The client cache entry is created, and by performing the operations shown by block 173. As can be seen from block 17, 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 by storing the HTTP data stream. The client-side intercept module 30 also updates the SDT or stores the SDT by subtracting the age from the current date and time received via the external communication link 35 from the server-side intercept module 40.

However, the client write cache is created every time it passes through block operations 166,172 or j73. In this case, the client-side intercept module passes or provides the client's cache entry to the web browser 10 as an HTTP data stream. These operations are illustrated in block 174 of Figure 4.

In view of the evaluation of the present invention, it should be noted that client and server cache memory can be implemented with other memory or mass storage, for example, hard disks, CD-ROMs, optical disks, or other storage technologies. Further, in the context of the present invention, it should be noted that the client-side intercept module and the server-side intercept module can be implemented through software, hardware or combinations thereof.

While references to cache creation are resident on a particular first or second computer, it should be noted from the perspective of the present invention that the advantages resulting therefrom can be obtained even if the cache is not resident on the first

RA 995 086

-19computers, but they are only on the same side of the external communication link as the computer. The hardware cache memory can be implemented externally on the first computer, where it serves as the client's cache memory, and can be connected to the first computer by high speed communication, and even if the cache is on the same side of the communication link as the first computer, the advantages of the present invention will be achieved.

In an alternative embodiment of the present invention, the server-side intercept module 40 does not retain a copy of the HTTP data stream received from the web server 20, but only writes the communication directory. The directory entry then contains the communication URL, the CRC calculated for the HTTP data stream and the time the HTTP data stream was received from the web server, and the SDT for the communication, which can be set to the time the CRC was calculated. In such a case, when the client-side intercept module 30 sends a request to the server-side intercept module for communication corresponding to the URL for which the CRC and SDT server-side intercept module maintains, the server-side intercept module checks the CRC received from the server-side intercept module. client 30 to determine if the CRC corresponds to the latest HTTP data stream for the specified URL. If it responds, then a coherent response is sent to the client-side intercept module. If it does not, it sends a capture mode! on the server side, the HTTP data stream received from the client-side intercept module to the web server 20 and returns to the client-side intercept module 30 the response received from the web server 20.

Figures 7, 8, 9 and 10 illustrate operations performed by client-side intercept module 30 and server-side intercept module 40 in another aspect of the present invention that utilizes differential determination to reduce the amount of data transmitted over an external communication link. . As shown in Figure 7, block 200 illustrates client-side intercept module 30 HTTP request from web browser 10. As shown in block 205, client-side intercept module 30 examines the intercepted HTTP request from web browser 10 to determine whether this requirement is a Common Gateway Interface (CGI). In case this request is a Common Gateway Interface, the client-side intercept module 30 passes it to the server-side intercept module as shown in Figures 3 to 6 and is illustrated by block 206 in Figure 7.

RA 995 086

However, if the communication created by the web browser conforms to the CGI request, the Yes branch of block 205LA is applied as reflected in block 210, the key / server intercept module 30 determines whether there is a client base cache entry corresponding to the HTTP data stream previously provided to the web browser. in response to a corresponding CGI request. This interception of the CGI request can be performed by comparing the URL of the communication created by the web browser to the URL stored in the client base cache.

The client base cache can be initialized by storing the first HTTP data stream received by the client-side intercept module 30, which should be provided to the web browser 10 for a given URL. This base cache entry may be maintained by a number of entities or web browser sessions 10. The client base cache entries may be updated as shown in Figures 7, 8, 9 and 10. If there is a client base cache entry corresponding to the URL for communication created by the web browser, then CRC ,. to be sent to the server-side intercept module

via an external communication link 35, it is set in the same way as the CRC for the client base cache entry, as shown in block 211 in Figure 7. If such a client base cache entry exists, then the No branch of block 210 in Figure 7 and CRC is applied for to be sent via the external communication link 35 to the server-side intercept module 40, is reset. This operation is shown in block 212 of Figure 7.

Block 213 illustrates operations for sending a CGI request to a server-side intercept module 40 over an external communications link. As shown in block 213, the client-side intercept module 30 sends an HTTP request and a CRC request to be either> - = —----- set to zero (if there is no client base cache entry for the CGI request URL), or should be set to the CRC of the client's base write cache (if any). Thus, the client-side intercept module has converted the CGI request to a specific client / server protocol transmitted by the specific client / server communication over an external communication link to be received by the server-side intercept module 40.

RA 995 086

The operations performed by the server-side intercept module while the CGI request is received are shown in Figure 9. Server-side intercept module CGI request acknowledgment is shown in block 220, When the server-side intercept module receives the CGI request, saves a copy of the CRC and the HTTP request. As is clear from block 221, the server-side intercept module forwards the HTTP request to the web server 20.

When a server-side intercept module receives a response to an HTTP request corresponding to a communication created by a web browser or a CGI request, it will be

The server side intercept module response 40 is received as an HTTP data stream as shown in block 230 of Figure 10. As can be seen from block 230. The server side intercept module 40 stores the HTTP data stream and calculates the CRC for the HTTP data stream received from the web server. 20. The server-side intercept module.40 also resets the differential value to the initialization difference data. The server-side intercept module then determines whether the response received as a communication is established

the web server is a response to a CGI request, as shown by block 235. If the answer is no, the No path of block 235 in Figure 10 is applied and block ^ 16 operations are performed. to send an HTTP stream to the client-side intercept module. As seen in block 236, this operation may include the capture operations described in Figures 3-6. If the response received by block 230 is a response to a CGI request, then the Yes path of block 235 is applied and the server-side intercept module further determines whether a server exists a base cache write for the CGI response, as shown in block 240.

The server base write cache can be created when the server-side intercept module first receives a response to a CGI request. In this case, the condition represented by block 240 will result in the execution of the No path of block 240. The server-side intercept module then creates a server base cache entry corresponding to the CGI request by storing the CGI URL, HTTP response flow of the CGI request, and CRC for the data stream. HTTP. This operation is illustrated in block 241. To be compatible with the coherent cache system described in Figures 3 to 6, the server base cache entry may also include an SDT. Similarly, as used herein,

RA995 086

-22 denotes a form of server CGI base server base cache entry corresponding to a CGI request received from a web browser 10,

If a server base cache entry corresponding to a CGI request exists, the Yes path of block 240 is applied. The server side intercept module compares the CRC of the server base cache entry with the CRC responses received from the web server 20, shown in block 245 of Figure 10. If the CRCs are identical, the server-side intercept module determines whether the CRC for the server base cache entry corresponds to the CRC for the client base cache entry. If the two CRC values are the same, then the client base cache write, the server base cache write, and the response received from the web server 20 will contain the same HTTP data stream. A comparison of the server base cache entry with the client base cache entry is shown in block 250.

If the two writes are the same, then the server-side intercept module does not have to send a base cache write to the client-side intercept module 30 and thus, as shown in block 251, the HTTP data stream to be transmitted to the client-side intercept module 30, is reset. The server-side intercept module then converts the HTTP data stream received from the web server 20 to a specific client / server communication protocol by sending the CRC of the HTTP data stream stored in the server base cache corresponding to the CGI request, the zero HTTP data stream, and the differential data. to indicate that the response to the CGI request was identical to the client base write cache, as shown by block 252.

Back to block 245. If the CRC for the server base cache entry corresponding to the CGI request is different from the CRC for the response received from the web server in response to the CGI request generated by the web browser, then the No branch of block 245 is applied. the operation shown by block 246. The server-side intercept module 10 compares the intercepted CGI response with the server base cache entry corresponding to the intercepted CGI request or with the CGI base form. This compares the captured CGI response with the server base

RA 995 086

The CGI form provides differential CGI data that corresponds to the difference between the captured CGI response and the CGI server base form.

The determination of the difference (differentiation) may, in view of the evaluation of the present invention, be carried out by any known method for determining the difference between the base form and the modified form. One method suitable for use in the present invention is described in the Cross-Platform Binary Diff published in Dr. Dobb's Journal, May 1995, pp. 32-36. Its description is incorporated here, as well as a reference for full citation. Other methods that can be used to determine the difference data are those described in the IBM Technical Disclosure Bulletin, Vol. 22, No. 8A, January 1980, which are also incorporated herein by reference. The server-side intercept module determines whether the CGI server base form requires updating as shown in block 247. This determination can be made by determining whether the average difference data between the intercepted CGI response and the CGI server base form exceeds a predetermined threshold. Other methods for determining whether a server base cache entry corresponding to a CGI request should be updated may include time coherence as described in Figures 3-6 _t or may be other known methods suitable for determining whether the difference data has changed to such an extent the need to create a new base cache entry to improve system performance.

If the creation of a new base caching write is not necessary, branch No of block 247 is applied and the server-side intercept module 40 performs the operations described by block 250 to determine whether the CRC of the client base cache is identical to the server base cache identical to the CGI client base form, which are basically server and client base cache entries that correspond to a particular CGI communication request created by a web browser. If these base forms are the same, there is no need to refresh the client and the HTTP data stream information can be reset as shown in block 251. The server-side intercept module then sends a differential response to the client-side intercept module 30 by sending a CRC the server base cache entry corresponding to

CGI request ((/. CRC server base form CGI)), sending a zero HTTP data stream that would correspond to the base data, and sending differential

RA 995 086

These operations are again reflected as block 252 in Figure 10.

If the server-side intercept module determines that the CRCs being compared are not the same (for the client CGI base form and the server CGI base form), then the client must be renewed. The client restore operation involves sending the server-based CGI base form to the client-side intercept module ^. When this operation is performed, the server-side intercept module sets the HTTP stream data to be sent to

the client-side intercept module 30 coincides with the CGI server base form. This operation is shown in block 253. The server-side intercept module then converts the HTTP data stream received from the web server to a specific client / server protocol by sending a CRC server base form of CGI, an HTTP data stream corresponding to the server base form of CGI, and sending a differential The CGI base form data and response received from the web server, as seen from block 252. This information is then passed over an external communication link 35 to the client-side intercept module 30.

Back to block 247. If recovery is required, the Yes path of block 247 is applied. As shown by block 248, the server side intercept module updates the server base cache entry corresponding to the browser-generated communication with the HTTP data stream received from the web server. The CRC response is also updated and the CGI difference data is reset. The server side intercept module then compares the CRC of the new server side write cache as shown in block 250 and completes the transmission as described above.

The client-side intercept module operation after receiving the server-side intercept module response 40 is shown in Figure 8. Receiving a server-side intercept module response 40 by the client-side intercept module 30 is shown in block 260. As shown in block 265, intercept the client-side module ^ 30 determines whether the response is a response to a CGI request. If this is not a response to a CGI request, then the client-side intercept module performs the operations described by ^ 26Z, which may include the cache operations shown in Figures 3-6. However, if the response is a response to a CGI request, the Yes branch of the block

RA995 086

-25265. The client-side intercept module P1 is the HTTP data stream, the difference data, and the CRC requested from a specific client / server data stream transmitted over an external communication link. These operations are reflected in block 266 of Figure 8.

The client-side intercept module determines whether there is a client base cache entry corresponding to the intercepted CGI request that would contain the client's base CGI form. This examination is recorded in block 270 and can be performed by examining the URL of an HTTP request or an HTTP response. If the client's base form

The CGI exists, the Yes branch of block 270 is applied, the client-side intercept module 30 then compares the CRC received over an external communication link with the CRC of the client CGI base form as shown in block 275. If different, the No path of block 275 is used. the client is refreshed by updating the CGI base form by exchanging the client base cache entry corresponding to the CGI communication request URL created by the web browser for HTTP data stream received via the external communication link 35 from the server-side intercept module 40. The client base cache entry is also updated with respect to CRC for HTTP data stream. These operations are reflected in block 276 of Figure 8.

If the CRC received over the external communication link 35 is the same as the CRC of the CGI base form, then the server CGI base form on the server side intercept module is identical to the client CGI base form on the client side intercept module, and the ^M Yes branch of block 275 applies.

If the base forms are the same or the client has been restored, the operations listed in block 277 will be performed by the client-side intercept module 30. Block 277 reflects how the client-side intercept module reconstructs the HTTP data stream corresponding to communication from the web server specific client / server data stream received over external communication link 35 by combining the client base form of CGI with differential (differential) CGI data received over external communication link 35 to form an HTTP data stream corresponding to the intercepted CGI response. As can be seen from block 278, this response will be provided to the web browser 10 as an HTTP data stream.

RA995 086

If there is no CGI base form corresponding to the CGI request URL, then the No ¹ * block of block 270 in Figure 8 is applied. As is clear from block 271, the client-side intercept module creates a client base cache entry corresponding to the CGI request URL. by storing the URL, the CRC of the HTTP data stream received over an external communication link from the server-side intercept module 40, and the actual HTTP data stream. Storing this information creates a client base cache entry corresponding to the intercepted CGI request, and thus creates a client base form of CGI. The client-side intercept module can then perform block 277 operations by reconstructing the HTTP data stream by merging or nesting the client's CGI base form and CGI difference data that may have been reset.

Existing differentiation techniques can also be applied to non-CGI data. In such a case, the server-side intercept module would need to store multiple generations of server base cache entries that would allow the client-side intercept modules from connected web browsers to the web server to take different base forms. The server-side intercept module could then compare the CRC received from the client-side intercept module with the CRCs of each previous generation of the server base forms until a match was found. The server-side intercept module 40 may then optionally recover the client-side intercept module or simply pass the difference (differential) data to the client-side intercept module J30. Thus, the difference (difference) methodologies described herein would then be applied with respect to the CGI request in the same way as any other HTTP request and response.

While the above system of maintaining multiple generations of base forms may allow differentiation to be applied to requirements other than CGI, this methodology is more memory or capacity intensive and does not take full advantage of the capture capabilities described above. In order to reduce memory or capacity requirements and to utilize the capture methods described above, it is preferred to use the following differentiation method for non-CGI requests. In this preferred implementation, the server-side intercept module calculates the difference (difference) between the server base form corresponding to the request and the HTTP data flow of the response from the web server. These difference data are

RA 995 086

-27 then stored by the server-side intercept module. The server base form is then updated by exchanging the base form for a new response from the web server, including updating the CRC of that base form. However, rather than discarding the old CRC, individual CRCs for earlier base forms are stored as differential data. Previous generations of difference (differential) data and individual CRCs are then selectively transmitted to the client-side intercept module, based on the CRC client base form corresponding to a non-CGI request.

An example of a differentiation method for non-CGI requests - if the server-side intercept module receives a request other than CGI, this request would also be accompanied by a CRC base form resident on the client-side intercept module corresponding to the URL of the non-CGI request. If the server-side intercept module received a response from the web server, it would calculate the CRC of the response. The server-side intercept module would then calculate the difference between the response and the server base form for the URL and store the difference data. The server-side intercept module would further update the server base form with response data and archive the CRC of the previous base form as well as the difference (difference) data between the response boundaries and the old base form. The server-side intercept module would then compare the CRC of the client base form with the CRC of the server base form and all stored or archived CRCs to determine if a match is found, if a match is not found, the response will simply be sent to the client-side intercept module.

If a match is found, the difference data corresponding to the same CRC and all subsequent difference (difference) data including current difference data are sent to the client-side intercept module. The client-side intercept module then uses the difference data in the client base form to reconstruct the response. Then, if, for example, a CRC match with a CRC for a base form that was three generations old, three sets of difference data will be sent to the client-side intercept module and the response construction will be performed by applying these three consecutive difference (difference) data sets in client base form. However, if the number of difference data sets or the size of the difference data sets needed to reconstruct a response is significant that sending the actual response would require less data to be transmitted, then the server-side intercept module can send a custom response. In each case

RA 995 086

-28by after reconstructing or receiving the response intercept module client-side update the client base form for the URL request with the response data and update the CRC with the CRC for the response Because the client base form is updated each ^year in receiving a response to a specific URL can be used above described as the client base cache, thus eliminating the need to have a separate client base cache in a situation where differentiation is used for requests other than CGI.

Another aspect of the present invention may be to further reduce communication by reducing redundancy of a stateless communication protocol, such as HTTP. In this protocol, the client sends information about itself to the server each time communication is initiated. Similarly, a server provides specific information about itself whenever it initiates its response to a client.

In one alternative embodiment of the present invention, the first computer 5 communicates with the second computer 6 where it transmits computer-specific information related to predefined characteristics of the first computer. The other computer stores this computer-specific information. The first computer then removes the computer-specific information from subsequent communications created by the web browser prior to sending via the external communications link 35. The second computer 6 then reconstructs the original communications created by the web browser by combining the stored computer-specific information and subsequent communications received via the external communications link 35 to create an HTTP data stream.

In addition to removing computer-specific information from communications created by the web browser, it is also possible to remove such computer-specific information from communications created by the web server. In this case, the second computer 6, see Figure 2, provides the first computer 5 via external communication link 35 with computer-specific information in accordance with predefined characteristics of the second computer 6. The first computer 5 stores this computer-specific information so as to be able to create a server header. In the subsequent communication, the second computer 6 then removes the computer-specific communication information created by the web server and sends the remainder of the communication created by the web server to an external communication link 35. The first computer receives this communication 5 via

RA995 086

The external communication link reconstructs the original communication created by the web server by merging (combining) the server header information and the specific client / server data stream received over the external communication link to create an HTTP data stream. In both cases, operations for deleting computer-specific information and storing this information to create either server header information or client header information are performed by the client-side intercept module 30 or the servertMO intercept module, depending on whether operations are performed on the first computer. 5 or on a second computer 6.

In one embodiment of the present invention, the web browser 10 communicates with a client-side intercept module 30 using a protocol called Transmission Control Protocol / Internet Protocol (TCP / IP). TCP can also be used to communicate between the client-side intercept module 30 and the server-side intercept module 40 via an external communication link 35. Finally, TCP can be used for communication between the server-side intercept module 40 and the web server 20, while TCP can be used. For communications between the various components that make up the system of the present invention, the HTTP protocol does not provide the most efficient means of communication over an external communications link. To enhance the performance of the external communication link 35, one embodiment of the present invention creates what is referred to herein as virtual sockets used in the connection between the web browser and the client-side intercept module 30 and between the server-side intercept module 40 and the web server. 20. The operation of these virtual sockets will now be described with reference to Figures 11 to 17.

Figure 11 is a block diagram of one possible implementation of the present invention using the concept of virtual sockets. As shown in Figure 11, the first computer 5 and the second computer 6 are interconnected via an external communication link 35. The web browser 10 has a plurality of real sockets that connect the web browser 10 to the client-side intercept module 30. In Figure 11, the first real socket shown on the web browser 10 as 65a and its corresponding socket on the client-side intercept module 30 as 65 b. This first real socket is a TCP socket over which the web browser 10 requires an additional connection from the client-side intercept module '30.

RA995 086

When the web browser 10 requires a new TCP connection, communication occurs over real socket 65a, which is received on real socket 65b. The client-side intercept module 30 then creates another real socket for communication with the web browser 10. As shown in Figure 11, a plurality of real sockets is created on the web browser 10 along with the corresponding real socket created on the client-side intercept module 30. These real sockets 60a to 64a are shown in web browser 10 and 60b to 64b on the client-side intercept module. These real sockets constitute the means through which the web browser 10 communicates with the client-side intercept module 30. After real sockets 60a to 64a and 60b to 64b have been created. the communications through these sockets are multiplexed to the real socket 36a, which provides client-side intercept module 30 access to the external communication link 35. Real sockets 36a and 36b are created at the time a real socket 37a of the computer 5 is sent to the real socket 37b computers 6. After confirming the request os bonding with real socket 37b creates real sockets 36a and 36b. Sockets 37a and 37b operate as the first real sockets for communication between the client-side intercept module and the server-side intercept module and can only be used to establish a connection between the two modules shown by sockets 36a and 36b. Each of these real sockets operates under standard TCP / IP protocols. When communications via the external communication link 35 are received by the second computer 66, they are received on the real socket 36b. The server-side intercept module then demultiplexes these communications to sockets 36b and provides them to the appropriate sockets for transmission to the web server 20. For example, communication over socket 60a to 60b may be performed to request information from a specific URL that would be multiplexed to ₂ sockets 36a taken socket 36b, demultiplexed side intercept module _and server 40 and transmitted from socket 60c to soket.60d on a web server, 20th Similarly, communications occurring through socket are received by socket 61b, multiplexed by client-side intercept module 30 ^ and sent from sockets 36a to socket 36b, where server-side intercept module 40, demultiplexes and sends over socket 61c to socket 61 Thus, communications through socket 60a and 60b, 61a and 61b, 62a and 62b, 63a and 63b, and 64a and 64b are transmitted via respective corresponding sockets between the intercept module on the side

RA995 086

-31 server 40 and web server 20 ₄ i.e. socket 60c and socket 60d, socket 61c and 61d, socket 62c and socket 62d, socket 63c and socket 63d, and socket 64c and 64d.

Similarly, answers to questions from the web browser 10 produced by the web server 20 are also transmitted via the web server 20 socket connection to the server-side intercept module 40 and through the external communication link 35 to the client-side intercept module 30 and then further to the web browser. 10. Then, for example, the response generated by the web server 20 would be sent via socket 60d to socket 60c and multiplexed by the server side M0 intercept module to socket 36b, which would be sent via external communication link 35 to socket 36a. The client-side intercept module 30 then demultiplexes the communication and provides it to the socket 60b for transmission to 60a ^ on the web browser 10. A similar communication path is provided for each socket that is used by the web browser 10 or web server 20. In view of the evaluation of this It is to be noted that while the present invention has been described with respect to 4 socket connections between web browser 10 and web server 20, any number of sockets may be opened to provide communication access between web browser 10 and web server 20.

Figure 12 is a block diagram of a virtual socket system implementation in a client-side intercept module 30 and a server-side intercept module 40. Externally to these modules are real sockets between the client-side intercept module 30 and the web browser 10 and the server-side intercept module 40; web server 20 that function as normal TCP / IP sockets. That is, the use of virtual sockets is transparent to both web browser 10 and web server 20.

A particular embodiment of the present invention will be described with respect to the block diagram shown in Figure 12 and the flowcharts of Figures 13 to 17. Figure 13 is a flow chart of a socket manager shown as block 68 of Figure 12. Referring to Figure 13, block 300 reflects the creation of a manager. After the real socket manager 68 has been created, the first real socket shown in Figure 12 is created as a socket 65b. The formation of this first real socket is reflected by block 301 in Figure 13, Po

RA 995 086

Creating the first real sockets 65b will wait for the client $ 3068 resident on the client-side intercept module 30, also referred to as the client sockets manager, in this material, for the event on the first real sockets 65b as shown in block 302 in FIG. on the first real sockets 65b, the real sockets manager 68 examines it and chooses one of five possible paths, as shown in block 305 of Figure 13, in view of the result of this examination.

In the case of creating real sockets in response to a communication request received on the first real socket 65b, as indicated in the path from block 305 to block 306 in Figure 13, the real socket manager 68 adds the real socket to the real event list. The real socket manager then creates a simplex virtual socket, as outlined in block 307. In the client-side capture module, the real socket manager will indicate the application function that will perform the client-side capture module functions for the created virtual socket, as shown in block. 308 in Figure 13.

As used herein, the term "simplex socket or" simplex virtual socket "refers to a socket that connects either a simple socket or a simple application directly. Here, a "multiplex socket" is also used to denote a socket for connection to a plurality of other sockets. Thus, the multiplex socket performs a multiplex or demultiplex function, and the simplex socket performs an individual connection. This means for example in carrying out the functions of blocks 306 to 308 in Figure 13, the socket manager client 68, in response to the first R ^{1 - 'J} - connection received by the first real socket 65b, create real socket 60b, simplex virtual socket 70, and initiate engagement Similarly, for subsequent events where a real socket is being created, the real socket manager creates real sockets 61 bj_6gb, 63b or 64b and simplex virtual sockets 71, 72 _L 73 or 74 and determines the CSI function corresponding to the created real and virtual sockets. sockets, shown as blocks 81, 82, 83, or 84 in Figure 12.

The operation of the client-side intercept function will now be described with reference to the real socket 60b, the simplex virtual socket 70, and the client-side intercept function 80 shown in Figure 12. Block 325 in Figure 14 reflects the creation of the client-side intercept function 80. client-side intercept function 80 • RA 995 086

An event on simplex virtual sockets 70 as indicated in block 326. This wait operation is performed by performing a virtual selection function as described in Figure 16-4. After the event is acknowledged, the event is examined as indicated in block ^ 330. If the event is closing virtual sockets, then the client-side intercept function deletes the simplex virtual socket 70, as indicated in block 349, and terminates, as indicated in block 350 in Figure 14.

If the event is data reception, then a path from block 330 to block 331 takes place and the client-side intercept function 80 receives the browser-generated communication from

simplex virtual sockets 70 by performing the virtual receive operation described in this material with reference to Figure 16-3. The client-side intercept function then performs the client-side intercept function described above (e.g.

3 and 7), which is shown in block 32. Client-side intercept function 80 then creates a multiplex virtual socket 90 that is connected to real client-side intercept socket 36a. Real socket 36a is connected to real socket 36b of the server-side intercept module 40. The multiplex virtual socket creation is shown in block 333 of Figure 14 and is performed by performing the virtual creation operation described in this material with reference to Figure 16-1. Block 334 illustrates the operation of sending information received from a web browser over a real socket 60b and a simplex virtual socket 70 after executing a client-side intercept function 80 for communication created by the web browser. This communication is queued to multiplex virtual socket 90 by performing the virtual send operation described in this material with reference to Figure 16-2. Client-side intercept function 80, after queuing for the multiplex virtual socket request 90, aligns the data in the queue on the multiplex virtual socket 90 as shown in block 335 in Figure 14, and then waits for an event on the multiplex virtual socket as indicated by the block 336. _f The virtual alignment function is performed by performing the virtual alignment function described in this material with respect to Figure 17-1, which takes the data from the multiplexed virtual socket queue and forwards it to the real socket 36a. The wait operation can be performed by performing the virtual selection function described in Figure 16-4. At this point he caught the client-side intercept module

RA 995 086

-34 the communication created by the web browser and transmitted this communication to the server-side intercept module via an external communication link 35.

Back to Figure 13, which depicts a flow diagram of the socket manager function at either

the server side intercept module or client side intercept module,. The real socket manager in the server-side intercept module or the server socket manager, shown as block 69 in Figure 12, performs the same function as the client socket manager, shown as block 68. When creating the first real socket shown in block 301, the intercept module! server side 40 creates a "well known port 37b to receive socket requests from the client-side intercept module 30 connected to the server-side intercept module 40. If a real event occurs on a real socket 16B at the server-side intercept module 40, this event is examined As indicated in block 305, in this case, the event is receiving data from real socket 36a, therefore the path from block 305 to block 320 shown in Figure 13 is applied. The data received on real socket 36b is examined and in this particular case, since this is the data created by the web browser sent by the client-side intercept module, a new virtual socket must be created in the server-side intercept module 40. That is, the path from block 320 to block 321 in Figure 13 is applied. it then performs the operations outlined in blocks 321, 322, 323 and 324 in Figure 13 r of server sockets 69 creates a multiplex virtual socket 95 as outlined in block 321, cancels the multiplex socket activity timer as outlined in block 322, and initiates the application of a server-side intercept function as outlined in block 322 in Figure 13 and shown as block 85 in Figure 12. Data received on real socket 36 is then queued to multiplex virtual socket 95 and a virtual event is signaled.

Creating a server-side intercept function, as shown in block 323, is referred to as block 360 in Figure 15. After creating a server-side intercept function 85, the function receives data from the multiplex virtual socket 15 that has been sent from the client-side intercept module. 30 and correspond to the communication created by the web browser. This operation is referred to as block 361 in Figure 15

RA995 086

The client-side intercept module processes the server-side intercept function 85 as described above for the server-side intercept module. The execution of server-side functions is indicated in block 362 (see the example in Figures 5 and 9). After processing the information, the server-side intercept function 85 creates a simplex virtual socket 75 by performing a virtual creation, i.e., the operation described in this material with respect to Figure 16-1. This operation is indicated by block 363 in Figure 15. The server-side intercept function then sends the web browser communication to the simplex virtual socket 75, as indicated in block 364, by performing a virtual send, i.e., the operation described in this material with referring to Figure 16-2. The server-side intercept function 85 then performs virtual alignment of data on the simplex virtual socket 75 for real socket 60c and waits for the event on the simplex virtual socket 75 _L The virtual alignment operation is described in this material with respect to Figure 17-1. The send and align operations are shown in blocks 364 and 365 of Figure 15. The wait operation can be performed by performing the virtual selection function described in Figure 16-4. If the server-side intercept function created a simplex virtual socket 75, a corresponding real socket 60c was also created. By sending the communication created by the web browser to the simplex virtual socket 75, the server-side intercept function transfers the communication created by the web browser to the web server.

When the server-side intercept module receives a response from the web server to the real socket 60c, a real event occurs and the server socket manager 69 terminates block 302 in Figure 13 and examines the event that occurred on real socket 60c, as indicated by block 305L. For example, the data is for an existing virtual socket and the path from block 320 to block 324 in Figure 13. Data received on real socket 60c is queued on virtual socket 75 and a virtual event is signaled. When a virtual event is signaled, server-side intercept function 85 terminates block 366 in Figure 15 and examines the event as indicated by block 370. If the event is a socket closure, an error condition occurs and an error message is constructed as a response as indicated in However, if the event is a data receive, the path from block 370 to block 371 is applied and the server-side intercept function performs virtual reception, as described herein with reference to

RA995 086

Figure 36-3 to retrieve the server response from the simplex virtual socket 75 as shown in block 371. The server-side intercept function then performs a virtual closure of the simplex virtual socket 75, as indicated by block 372 and described herein with Referring to Figure 17-2, and processes the response as described above for the server side intercept module and as shown in block 373 (see, for example, Figures 6 and 10).

If block termination path 370 in Figure 15 is an error path to block 375 or data path to block 371, the simplex virtual socket 75 is deleted at block 374. The server-side intercept function then performs a virtual send operation to the multiplex virtual socket 95 to send The server-side intercept function then performs a virtual queue data alignment operation in the multiplex virtual socket 95. These operations are shown in block 377. The intercept functions on the server side server 85 then performs a virtual close operation when ^r which closes the multiplex virtual socket 95 as shown in block 378 of Figure 15. the side intercept function server 85 deletes the last multiplex virtual socket and terminates, as reflected in blocks 379 and 380.

The server-side intercept function performs virtual send and align operations on the multiplex virtual socket ^ 95. This triggers events on real socket 36a, whereby the client socket manager 68 terminates block 302 and examines the event as shown in block 305, and since data has been received on real socket 36a, the path from block 305 to block 320 in Figure 13 will be used. and the data will be queued to multiplex virtual socket J90. Thus, when real socket 36a receives a web server response from real socket 36b via external communication link 35, this data is demultiplexed and provided to the respective multiplex virtual socket. Receiving the data will result in a virtual event that should be terminated as shown in window 324 in Figure 13 and block 336 in Figure 14 and the client-side intercept function 80 should examine the event as shown in block 340 in Figure 14.

RA995 086

If the event is a closed socket response, the path from block_34J0L kb! Oku_345 in Figure 14 is applied and the client-side intercept function 80 generates an error message response and passes it to block £ 44 in Figure 14. If the event is received data, For example, the path from block 340 to block 341 in Fig. 14 is applied, and the client-side intercept function 80 performs a virtual receive operation to receive a response from the multi-sided virtual socket 90. This receive operation is illustrated by block_341 in Fig. socket 90 performs a client-side intercept function 80 and closes the multiplex virtual socket 90 as indicated by block 342. Client-side intercept function 80 then processes the response as described above for the client-side intercept module as shown in block 343 ( see, eg, Figures 4 and 8).

Block 344 operations are then performed using any path to terminate block 340. Client-side intercept function deletes the multiplex virtual socket, as indicated by block 344, and then performs a virtual send operation to send. response to the browser via the simplex virtual socket 70 as indicated by block 346. Upon completion of the virtual send operation, the client-side intercept function 80 performs a virtual alignment operation to align the data in the simplex virtual socket queue as shown by block 347 for real socket 60b , and then performs a virtual close operation to close the simplex virtual socket, as shown in block 348. After closing the simplex virtual socket for the client-side intercept function, the simplex virtual socket is deleted and the client-side intercept function terminates, as shown in block 348. blocks 349 and 350 in Figure 14.

In view of the evaluation of the present invention, this is described with respect to one particular example of creating a simplex and multi-plex virtual socket and client-side and server-side intercept functions, but a plurality of these functions can be created within a single client-side intercept module. server-side module. Similarly, a client-side intercept module and a server-side intercept module, according to the present invention, can establish a TCP / IP connection between a client-side intercept module 30a and a

RA995 086

38 of the server 40 and then perform multiplexing on the plurality of TCP / IP connections by web browser or web server communications while maintaining the TCP / IP connection.

The remaining functions of the client socket manager and server socket manager can best be understood using Figures 16-1 to 16-4 and Figures 17-1 and 17-2, which describe the operations performed by the client-side intercept module and the server-side intercept module when performing operations virtual creation, virtual send, virtual receive, virtual selection, virtual alignment, or virtual close, as shown in the flowcharts of Figures 14 and 15. When the virtual creation operation is performed, as is known from block 333 of Figure 14 and block 363 of Figure 15, starting from block 400 in FIG. 16-1. The socket manager then determines whether a real socket is required, as shown in block 405. If a real socket already exists, or when creating a multiplex virtual socket to be connected to an existing real socket, the "No" path of block 405 and virtual the socket is merged with the real socket as shown in block 409. However, if a real socket is needed, then the "Yes" path of block 405 is used. As shown in block 406, a real socket is created. The real socket is then added to the event list, as indicated in block 408, for monitoring purposes, as reflected in block 302 in Figure 13. After real sockets are created and the connection is established, the virtual socket is connected to real sockets as shown in block 409, and the create operation is completed as shown in block 410.

When performing the virtual send operation outlined in blocks 334 and 346 in Figure 14 or blocks 364 and 376 in Figure 15, operations from block 420 in Figure 16-2 begin. Data is added to the virtual socket queue, as seen from block 427, and then the send operation is terminated, as seen from block 428.

The virtual receive operations shown in blocks 331 and 341 of Figure 14 and blocks

361 and 371 in Fig. 15 are performed by performing operations starting from block 430 in Fig. 16-3. As seen in block 435, the virtual socket queue is evaluated to determine if there is any data in the virtual socket queue. If data is present in the virtual socket queue, the "Yes" path of block 435 ^ is applied and this data is returned to a function called the receive operation, as seen from block 436. If

RA995 086

There is no data in the socket queue, but the socket is not marked for closing, the "No" path of decision block 440 is applied, and nothing returns as is clear from block _441_. However, if there is no data in the queue and the socket is marked to close, then the "Yes" path of block 440 is valid and the socket is marked as closed, as shown in block 442, and the receiving operation is returned with information that the socket is closed. is evident from block 443.

The virtual selection operation performed at blocks 326 and 336 in Figure 14 and at block 366 in Figure 15 is performed by performing operations that begin at block 445 in Figure 16-4. As is clear from block 446, it is first determined whether the data or virtual close operation is not yet pending on the selected virtual socket. If there is no pending or virtual close pending, the No path of block 446 is applied and the process waits for a virtual event on the selected virtual socket, as shown in block 447-4, and terminates as shown in block 448 However, if the data and virtual closures are pending and are pending, are waiting on the selected virtual socket, the virtual event has already occurred, and therefore the Yes path of block 446 is applied, the process ends as shown in block 448.

The virtual alignment operation as seen from blocks SSS and 347 in Figure 14 and blocks 365 and 377 in Figure 15 is performed by performing operations that begin with block 450 in Figure 17-1. When the virtual alignment operation is started, it determines whether there is any data in the virtual socket queue to be aligned, as indicated in decision block £ 55. If there is no data in the virtual socket queue, then the alignment operation simply ends and returns to the function that triggered it, as shown in the “No” branch of block ^ £ 55. However, if there is data in the queue, then the "Yes" path of block 455 is used and it is determined whether the virtual socket queue is for the multiplex socket, as seen from block 46Q. If it is a multiplex socket, then the socket header, which consists of three bytes of data reflecting the unique identifier for the socket and the amount of data to be transferred, is added to the real socket buffer as shown in block 461. In both cases, if it is a multiplex socket or simplex socket, the real socket data is then moved to the real socket buffer as indicated in block 462. If the real socket buffer is full, the <z ~ - Yes branch of block 465 is applied and the data is extracted from the real socket buffer send to

RA 995 086

-40this real socket, as indicated in block 466. However, if the buffer for the real socket is not full, the “No” path of block £ ¢ 5 applies. The virtual alignment function then performs a test to determine if there is any additional data on any additional multiplex virtual socket queue that should be sent to the real socket. If the answer is yes, the Yes path of the ^ ZQ block is applied and the data in the real socket buffer is not sent until the virtual alignment operation is resumed

invoked to align one of the other virtual socket queues. However, if there is no more data or after adding data from other multiplex virtual sockets, block 466 operation is performed and the data in the real socket buffer is sent to the real socket. After all, the data in the virtual socket queue corresponding to the function that called the virtual alignment operation is sent to the real socket, and the virtual alignment operation terminates as shown in block 467.

The virtual close operation shown in blocks 342 and 348 in Figure 14 and blocks 372 · and 378 in Figure 15 is performed by performing operations that begin with block 480 in Figure 17-2. When a virtual close operation is called, it first performs tests to determine whether virtual close relates to a multiplex virtual socket, as shown in block 485. If it is a multiplex virtual socket, then the “Yes” path of block 485 is applied and to the virtual a close operation indicator is added to the socket queue. Whether or not a virtual close of the multiplex virtual socket is performed, the virtual close operation calls the virtual alignment operation as shown in block 487 and then disconnects from the real socket as shown in block 488, then the operation performs tests to determine whether virtual close refers to the simplex virtual socket, as shown in block 490; and if this is not the case, the “No” path of block 495 is used. Because the closure concerns a multiplex virtual socket, block 495 tests are performed to determine if this is the last multiplex virtual socket and, if so, set the multiplex activity timer as shown in block 496. However, if this is not the last multiplex virtual socket, then block 496 is skipped.

Back to block 490. If virtual close refers to a simplex virtual socket, then the corresponding real socket is removed from the event list, as shown in block 491, and the real socket is closed and deleted, as seen in block 492, whether the socket is simplex

RA 995 086

-41 or a multiplex virtual socket is marked as closed, see block 497, and the close operation is terminated, see block 498.

Figure 13 will now be described with reference to Figures 16-1 to 16-4 and Figures 17-1a

17-2. When a real event occurs, block 302 in Figure 13 closes and the socket manager examines the event based on how the event was generated. If the event has exceeded the timing for the multiplex socket activity timer set in block.496 in Figure 17-2, then the path from block 305 to block 312 in Figure 13 is applied. As can be seen from Figure 13, the socket manager performs operations on block 312 and block 313 to close the multiplex real socket and clears the multiplex real socket that corresponds to the socket that connects the client-side intercept module to the server-side intercept module. The socket manager then waits for the next real event. This multiplex event timer is reset to zero by creating a multiplex virtual socket, as seen in block 322.

If the event occurring on the real socket is closing a real socket, such as a web server performing a close operation on the socket connections between the web server and the server-side intercept module, then the path from block 305 to block 309 in Figure 13 is applied. the real event socket as shown in block 309 and disconnects the virtual socket or sockets, in the case of multiple multiplex sockets, from the real socket or sockets as seen from block 310. The socket manager then marks the virtual socket for closure and signals (signals) ) a virtual event. This operation is reflected in block 31J, as soon as all data is deleted from the virtual socket queue, the virtual socket will be closed. After the virtual socket is closed for closing, the socket manager then determines whether or not the real socket to be closed is a simplex socket, as indicated in decision block 315. If the closing of the real socket is related to the simplex socket, that real socket is closed and deleted as shown in block 316, the socket manager then waits for the next real event, as seen from block 302.

If it is not a simplex real socket to close, then the “No” path of block 315 is used and the socket manager waits for the next real event. Multi-socket real socket

RA995 086

or a socket connecting a client-side intercept module and a server-side intercept module can only be closed using the timeout of the multiplex socket activity timer. This allows the connection between the client-side intercept module and the server-side intercept module to be maintained even after the last communication between the modules took place within the user-specified predetermined time. In the situation of a subsequent connection request from the browser before the time interval determined by the multiplex socket activity timer expires, communication could be made without reconnecting the client-side intercept module and the server-side intercept module, thus eliminating the need for additional claims due to the reconnection.

The last branch to be described in Figure 13 is the branch where the real event occurs, and this event is receiving data to the multiplex real socket or real sockets 36a or 36b in Figure 12. If the data is received on multiplex real sockets, this is the data is examined, and if they include a close operation indicator, similar to the virtual queue at block 486 in Figure 17-2, then a virtual close operation is performed, thus using the path from block 320 to block 310. The socket manager disconnects from real socket multiplex virtual socket labeled in the received data to real socket,

see block 310, and then marks the virtual socket to close and signals the virtual event f ¹ as shown in block 31l Because closing is actually closing the multiplex virtual socket, the path "No" of block 315 is applied and then the socket manager waits for a real event as shown in block 302.

By performing the operations described in Figures 13 to 17, a particular aspect of the present invention establishes a permanent connection between the first computer and the second computer via an external communication link. This persistent connection is maintained until all communications created by the web browser are completed and the plurality of communications created by the web browser is captured and then multiplexed to an external communications link while the persistent connection is maintained. The specific client / server data stream can then be demultiplexed to create a plurality of HTTP data streams and this plurality of HTTP data streams is passed to the web server. Permanent connection is also maintained until the completion of all communications created by the web server. The plurality of communications created by the web server is captured and multiplexed to external

RA 995 086

-43 the communication link while the fixed link is maintained. The specific client / server data stream can then be demultiplexed to create a plurality of HTTP data streams, and this plurality of HTTP data streams is passed to the web server.

Typical preferred embodiments of the invention are incorporated in the drawings and specifications, and although specific terms are used, are used in a generic and descriptive sense only and not for the purpose of limitation, the scope of the invention is set forth in the following claims.

Claims (8)

A method of capturing data received from a second application to be provided to a first application in response to a request from a first application, comprising the steps of: storing the data stream to be received from the second application and to be provided to the first application in the first cache memory (31) so as to create a client cache entry (32) corresponding to the request of the first application; write (32) so as to create a client write cache time record (32), intercept the request from the first application, determining whether there is a client write cache (32) corresponding to the request, evaluate the client write cache time record (32) ) for the client cache entry (32) corresponding to the request from the first application, and determining whether a client cache entry (32) corresponding to the request from the first application has been created during a predefined client coherent time interval before requesting the information by the first application cache write (32) to the first application in response to the request, if in said evaluation step ur eno that was created by the client cache entry (32) for the request from the first application within a predetermined time interval coherent client requesting the information before the first application. 2. The method of claim 1, wherein the multiple instances are first 1, further comprising maintaining a client cache of application writes. (32) u The method according to claim 1, claim 1, resident application first and resident application second characterized in that on the first computer (5), on the second computer (6), they communicate with each other through the first second 3. an external communication link (35), the following steps being performed: storing the data flow from the second application in response to the request of the first application in a second cache memory (41) resident on the second computer (6) so as to create a cache write (42) of the request of the server (40); and received by the second application, determining whether a request request server (40) corresponding to the request has been previously stored in the second request cache cache, sending a request request cache (42) to the server (40) corresponding to the first application resident on the first computer (5) via an external communication link (35). A method according to claim 3, characterized in that. That further includes the steps of: determining whether a request write cache (42) of the request server (40) corresponding to the request from the first application has been created during a predefined client coherent time interval before the request is received by the second computer (6); the request write cache (42) of the server (40) generated within a predefined client coherent time interval, upon sending, the write request cache (42) of the request server (40) corresponding to the request from the first application is sent to the first application. The method of claim 3, further comprising the steps of: determining, corresponding identical to whether there is a request from the cache by the client's cache entry (32), the first application that is (42) the request of the server (40) corresponding to the request, the time interval between the second computer ( 6) received the request from the first application, and at the time of writing (42) the request of the server (40), from the second application, providing when the cache corresponding to the write request age is created, sending the first application request data (42) , a server at the first write age for (40), corresponding to the application and resident, and in cache writing a request from the first computer (5), the corresponding current time request on the first write received from the second time record from the first computer (32), the application by subtracting the age data (6) from (5). 6. The method according to the applications is a server (20). Claim 1 web browser characterized in that: (10) and the second application the first is the web 7. Method according to claim 3, characterized that second application is web server (20) , the first app is the web browser (10), wherein the first and second computers (5, 6) communicate with each other via a wireless communication link (35). A device for intercepting data received from a second application to provide a first application in response to a request from a first application, comprising a first intercept module connected between the first application and the second application, wherein the first intercept module is adapted to store a data stream received from the second application and provided by the first application to a first cache memory (31) connected to a first intercept module resident on the first computer (5) to create a client write cache (32) corresponding to the first application request, the first intercept module being further adapted to store a client write cache time (32) for creating a client write cache time record (32), the first intercept module being further adapted to intercept a request from the first client write cache (32) request corresponding to the first intercept module is further modified for evaluating a client write cache time record (32) for a client write cache (32) corresponding to a request from the first application, to determine whether a client write cache (32) corresponding to a request from the first application is created. during a predefined client coherent time interval before requesting information by the first application, the first intercept module is further adapted to supply the client write cache (32) to the first application in response to the request if it is determined to be created for the request from the first application of the client coherent time the client cache write (32) during a predefined interval before requesting information by the first application. Device according to claim 8, characterized in that the second application of the application is resident is resident on the second computer (6) and the first on the first computer (5), the first and second applications being connected via an external communication link (35) , the second intercept module is connected between the first intercept module and the second application, wherein the second intercept module is adapted to store the data flow from the second application in response to the first application request in a second cache memory (41) connected to the second intercept module resident on the second a server (6) for creating a server request cache entry (42), the second intercepting module further adapted to intercept the request from the first application whether it has previously been stored in a second server request cache entry (42) corresponding to said request and the second intercept module is further adapted to send a request write cache (42) to the server, responding to the first application resident on the first computer (5) via an external communication link (35). 10. A computer program product for executing a method according to claim which is stored on a computer readable storage medium, and Embodiment V comprises program computer system code means for and which is computer readable, comprising: computer readable program code means for invoking the first computer (5) to store the data stream to be received from the second application and to be provided to the first application in the first cache memory (31) to create a client write cache (32) corresponding to the first request application, computer readable program code means for retrieving the first computer (5) storing the time of creation of the client write cache (32) such that a time record of the client write cache (32) is generated, computer readable program code means for retrieving the first capture computer (5) a request from the first application to determine whether there is a client cache entry (32) corresponding to the request, computer readable program code means for invoking the first computer (5) to evaluate the client entry cache time record (32) for the client cache entry (32) first app The application to determine whether a client write cache (32) has been created corresponding to the request since the first application. during a predefined k1 of the coherent time interval before requesting information by the first application, computer readable program code means for invoking the first computer (5) to supply the client write cache (32) to the first application in response to the request if it is determined in the evaluation step creating a client cache entry (32) for the request from the first application during a predefined client coherent time interval before requesting the information by the first application.