System and method for synchronizing compression histories

(54) Title: SYSTEMS AND METHODS FOR (57) Summary:

USE OF COMPACTING HISTORICS TO IMPROVE NETWORK PERFORMANCE (30) Unionist Priority: 12/03/2007 us 11 / 685,153,

03/12/2007 US 11 / 685,157, 03/12/2007 US 11 / 685,159, 03/12/2007

US 11 / 685,161,12 / 03/2007 US 11 / 685,165, 12/03/2007 US

11 / 685,170, 12/03/2007 US 11 / 685,172 (73) Owner (s): Citrix Systems, INC.

(72) Inventor (s): Allen Samuels, Dan Decasper, Michael Ovsiannikov, RICHARD JENSEN, Robert Plamondon, Zubin Dittia (74) Attorney (s): Dannemann .Siemsen, Bigler & Ipanema Moreira (86) International Request: pct us2008056681 de 12/03/2008 (87) International Publication: wo 2008 / 112777of 18/09/2008

<img file="BRPI0809005A2_D0001.tif" />

Descriptive Report of the Invention Patent for SYSTEMS AND METHODS FOR THE USE OF COMPACTING HISTORICS TO IMPROVE NETWORK PERFORMANCE.

Related Orders

This order refers to, and claims priority for, the following North American Pending Orders, each of which is hereby incorporated in its entirety by reference: SYSTEMS AND METHODS FOR SHARING COMPRESSION HISTORIES BETWEEN MULTIPLE DEVICES, Order No. 11 / 685,161, deposited on March 12, 2007; SYSTEMS AND METHODS FOR PROVIDING DYNAMIC AD HOC PROXY-CACHE HIERARCHIES, ”Order No. 11 / 685,153, filed on March 12, 2007; SYSTEMS AND METHODS OF CLUSTERED SHARING OF COMPRESSION HISTORIES, Application No. 11 / 685,165, filed March 12, 2007; SYSTEMS AND METHODS OF USING APPLICATION AND PROTOCOL SPECIFIC PARSING FOR COMPRESSION, Application No. 11 / 685,157, filed March 12, 2007; SYSTEMS AND METHODS OF COMPRESSION HISTORY EXPIRATION AND SYNCHRONIZATION, Order No. 11 / 685,172, filed on March 12, 2007; SYSTEMS AND METHODS FOR IDENTIFYING LONG MATCHES OF DATA IN A COMPRESSION HISTORY, Application No. US 11 / 685,170, filed March 12, 2007; and SYSTEMS AND METHODS FOR IDENTIFYING LONG MATCHES OF DATA IN A COMPRESSION HISTORY, Application No. 11 / 685,159, filed March 12, 2007.

Field of the Invention

The present invention relates, in general, to data communication networks. In particular, the present invention relates to systems and methods for compressing data streams and improving the performance of networks using previously stored data. Background of the Invention

The compression of data streams using previously stored data consists of a known technique that serves to reduce the size of the data streams transmitted between two devices. Generally speaking, a typical method of compression links two devices, each of which stores copies of data that are sent between the devices. These stored copies of data can be termed as compression histories, since they represent a history of previously transmitted data that is then used to compress future data flows. When one of the devices is transmitting data to the other device, its compression history is searched for compatibility with the input data, and replaces the compatible portions with references to the data stored in the transmission stream, reducing the size of the transmitted stream. Therefore, the receiving device uses the references in combination with its own compression history in order to reconstruct the flow of uncompressed data. However, this general technique presents a number of challenges.

First, insufficiently long compatibilities between input streams and compression histories can result in poor compression ratios, as well as increasing processing overhead and the number of times a compression history must be accessed. These problems can be exacerbated in cases where a device is simultaneously transmitting multiple data streams, and therefore can have multiple processes that attempt to access a compression history simultaneously. These problems can also be accentuated on devices that use a compression history stored on a medium, such as a disk, with long latencies of potential access. In order to provide a concrete example, a device that sends a 2K file can find forty compatible references spread throughout its compression history, each reference being compatible with 50 different bytes of the file. This may require 40 separate iterations of a potentially complex compatibility algorithm, and 40 separate disk accesses to a compression history. On the other hand, if a device finds a single compatible reference for the entire 2K file, only a single disk access may be required. Therefore, there is a need for systems and methods designed to create long location compatibility between an input stream and a compression history.

Second, when a device is strings in its compression history that are not in a corresponding compression history on another device, inefficiencies can occur. The device can replace portions of data streams with references to the strings, and then be forced to retransmit the data stream as soon as it discovers that the other device has no referring strings. In addition, non-shared strings can take up space in a compression history that could be used for other data. A number of methods can be used to synchronize the compression histories in relation to the data currently being transmitted between the two devices. For example, each device can transmit information corresponding to the total number of bytes transmitted, received, and stored, as well as the location identifiers that identify where the data was stored. However, even if the compression histories are immediately synchronized following the data transmission, a series of events can cause the compression histories to subsequently diverge. For example, a device may perform storage and be forced to overwrite one or more previously stored portions. Or a device may have a disk error or other minor hardware or software flaws that corrupt or remove one or more previously stored portions. Therefore, there is a need for improved systems and methods that serve to efficiently synchronize shared compression histories.

Third, in many implementations, compression histories and caching only provide benefits if the same data is repeatedly sent between the same two devices. This can be particularly problematic in situations where two locations, each having a group of devices, can repeatedly communicate similar information, however, there is no guarantee that information will pass through the same pair of devices. For example, two sites can maintain a group of devices for the purpose of speeding up communications between sites. Group 1 can contain devices A, B and C, and group 2 can contain devices X, Y and Z. For example, devices A and Z can maintain a compression history of a file sent between A and Z, however, the next time the file is requested, the request and response can pass through devices A and Y. Similarly, the next time the file is requested, the request and response can pass through device B and device X. A potential solution is to organize device groups in a hierarchy, so that all requests in a given group, network or region pass through a passing device. However, this solution may involve additional configuration and create network obstructions. Therefore, there is a need to take advantage of data previously transmitted between two devices in order to compress data streams transmitted between devices other than the original transmitters, without necessarily requiring explicit hierarchies.

Brief Summary of the Invention

The present invention relates to systems and methods that serve to store previously transmitted data and use it to reduce bandwidth utilization and accelerate future communications. Using algorithms to identify long compression history compatibility, a network device can effectively improve compression and speed. A network device can also use parsing of a specific application in order to improve the extent and number of compression history compatibilities. In addition, by sharing compression histories, compression history indices, and caches across multiple devices, devices can use data previously transmitted to other devices in order to compress network traffic. Any combination of the systems and methods described in the following paragraphs can be used to effectively discover long compatibility with the stored data, synchronize the storage of previously stored data, and share previously sent data between one or more other devices.

In a first aspect, the present invention relates to systems and methods that serve to determine based on the accomplishment of a disk-based compaction identifying itself in an index maintained in a memory, if an estimated extent of a data compatibility of input to contiguous data stored on disk is above or below a predetermined limit. In one embodiment, a device having a compression history establishes a memory index that corresponds to the fingerprints of a plurality of pieces of data from the compression history to the location identifiers that identify the locations on the disk that have a plurality of pieces of data . The device identifies a series of fingerprints of input data compatible with the fingerprints of a plurality of index entries in memory, and determines, from the series of fingerprints identified in memory, having entries corresponding to a first location identifier that a Estimated compatibility of input data to contiguous data on disk is extensible below a predetermined limit. If the compatibility is extensible below a certain threshold, the device transmits the uncompressed data. If the compatibility is extensible above the specified limit, the device uses the compression history to compress the data.

In a second aspect, the present invention relates to systems and methods that serve to determine a precedence for compatible fingerprints from input data to a fingerprint index that identify a plurality of data cases in a compression history. In one embodiment, a device having a compression history that establishes an index that corresponds to fingerprints of a plurality of pieces of data from the compression history to the location identifiers that identify the locations on the disk that have the plurality of pieces of data. The device identifies a plurality of input data fingerprints compatible with a plurality of entries in the index having at least one location identifier and selects an entry from the plurality of entries having a smaller number of location identifiers. The device can then match a first portion of the input data to the data at a first location in the compression history identified by the selected input.

In a third aspect, the present invention relates to systems and methods that serve to improve compression history compatibility by removing the application layer protocol headers from the compression history data. In one embodiment, these systems and methods include transmitting, between a first device and a second device, an application data stream, the application data stream comprising at least one application layer protocol header between a first sequence application data and a second application data string. The first device identifies the first sequence and the second sequence from the application data stream and stores a combined sequence that comprises the first sequence and the third sequence with a compression history.

In a fourth aspect, the present invention relates to systems and methods that serve to synchronize compression histories shared between two devices. In one embodiment, a first device stores a first compression history, the compression history comprising a plurality of data portions previously transmitted to a second device, each data portion having a location identifier. The first device can then create an ordered list of location identifiers ordered by a moment where the first device last accessed a piece of data at a location corresponding to each identifier. The first device receives, from the second device, information that identifies a number of location identifiers from a corresponding second compression history on the second device: and determine whether the quantity received is less than a number of location identifiers from the first historical compaction by a first quantity. The first device can then select for obsolescence, from the list of location identifiers, the first number of location identifiers at one end of the ordered list corresponding to the most recently accessed portions of data.

In a fifth aspect, the present invention relates to systems and methods that serve to share compression histories among a plurality of devices in order to improve the compression of the data transmitted through a plurality of connections. In one embodiment, a first device transmits a first data stream to a second device, the first data stream being compressed according to a first compression history being shared between the first device and the second device. The first device can receive, from the third device, an indication that a third device is located on the same network as the second device. The first device receives a second data stream destined for the third device. The first device identifies that a portion of the data stream is compatible within a predetermined limit to a portion of the first compression history, and transmits information to the third device that identifies the portion of the first compression history. This can allow communications between the first and third devices so that they are compressed according to a compression history originally shared between the first and second devices.

Another embodiment of the fifth aspect includes transmitting, between a first device and a second device, a first data stream, the first data stream being compressed according to a first compression history being shared between the first device and the second device. The first device receives information that identifies a third device and a portion of the first compression history and transmits, to the third device, the identified portion of the first compression history.

Yet another embodiment includes a first device that receives, through a first device from a second device, a data stream, the data stream being compressed according to a compression history being shared between the first device and a third device. The first device identifies the third device and transmits a request to the third device for a portion of the compression history. The first device receives, from the third device, the requested portion of the compression history. The first device can then unzip the data stream and transmit the unzipped stream to the customer.

A sixth aspect of the present invention relates to systems and methods that serve to share compression indexes between one or more groups of devices in order to improve the compression of data transmitted through a plurality of connections. One embodiment includes receiving, through a first device from a second device, an index of entries for a compression history shared between the second device and a third device; each input index comprising a location identifier of data stored on the second device. The first device receives a data stream destined for a fourth device; and identifies that a portion of the data stream is compatible with an incoming index entry. The first device transmits, to the second device, a location identifier corresponding to the compatible entry. The first device receives, from the second device, a portion of the compression history corresponding to the location identifier; and determines the compression history portion compatible with a portion of the data stream. The first device can then transmit information to the fourth device that identifies the portion of the compression history. This allows communications between the third and fourth devices so that they are compressed according to the compression history originally shared between the first and second devices.

A seventh aspect of the present invention relates to systems and methods that serve to provide an ad-hoc hierarchy of caches to server objects. In one embodiment, a first tool receives from a client a first request for an object from a server. The first device identifies that the object is not located in the tool's first cache and forwards the first request for the object to the server. The tool transmits, before receiving a response to the forwarded request, a second request for the object to a second device. The tool receives, from at least one server or from the second device, the object; and then transmits the object to the customer.

Details of the various embodiments of the invention are presented in the attached drawings and in the description below.

Brief Description of Drawings

These and other objectives, resources and advantages of the invention will become more apparent and will be better understood with reference to the following description taken in conjunction with the attached drawings, where:

figure 1A is a block diagram of a modality of a network environment for a client to access a server through one or more network optimization tools;

figure 1B is a block diagram of another modality of a network environment for a client to access a server through one or more network optimization tools in conjunction with other network tools;

figure 1C is a block diagram of another modality of a network environment for a client to access a server through a single network optimization tool deployed independently or in conjunction with other network tools;

figures 1D and 1E are block diagrams of modalities of a computational device;

figure 2A is a block diagram of a modality of a tool that serves to process communications between a client and a server;

figure 2B is a block diagram of another modality of a client and / or server that implements the network optimization features of the tool;

figure 3 is a block diagram of a modality of a client that serves to communicate with a server using the network optimization feature;

figure 4A is a block diagram of a modality that uses a shared compression history to reduce the size of the transmitted data;

Figure 4B is a block diagram of an embodiment of a data structure used to store data in a compression history;

figure 4C is a block diagram of a modality of a data structure that can be used to locate portions of data in a compaction history;

Figure 5A is a block diagram illustrating a modality that uses a compaction index to find compatibility history of compaction corresponding to the input data;

Figure 5B is a flowchart of a method modality that serves to determine whether the performance of a disk-based compression by identifying in an index maintained in memory an estimated extent of an input data compatibility in contiguous data stored on disk is above or below a predetermined limit;

Figure 6A is a block diagram illustrating a second way of using a compaction index that serves to locate compatibility of compaction history corresponding to the input data;

figure 6B is a flowchart of a method modality that serves to determine a provenance for matching fingerprints in a fingerprint index that identifies a plurality of data cases in a compression history;

Figure 7A is a block diagram illustrating a modality that removes application layer protocol headers from data stored in a compression history;

Figure 7B is a block diagram that illustrates a second modality of a technique that serves to remove application layer protocol headers and from data stored in a compression history;

Figure 7C is a flowchart of a method modality that serves to improve the compatibility of compression history by removing the application layer protocol headers from the compression history data;

figure 7D is a flowchart of a method modality that serves to improve the compatibility of compression history by removing application layer protocol headers from the received data;

figure 8A is a block diagram of a modality of a system that serves to synchronize the compaction histories shared between two devices;

figure 8B is a flow chart of a method used to synchronize the compression histories shared between two devices;

Figure 9A is a block diagram illustrating a method of sharing compaction histories between a plurality of devices;

figure 9B is a flow chart of a modality of a method that serves to share compression histories among a plurality of devices in order to improve the compression of the data transmitted through a plurality of connections;

Figure 9C is a flowchart of a second modality of a method that serves to share compaction histories between a plurality of devices in order to improve the compression of the data transmitted through a plurality of connections;

figure 9D is a flowchart of a third modality of a method that serves to share compaction histories between a plurality of devices in order to improve the compression of the data transmitted through a plurality of connections;

Figure 10A is a block diagram illustrating a modality of a system that serves to share compaction history indexes in order to speed up data transmission between two groups of devices;

figure 10B is a flowchart of a method that serves to share the compression indexes between a plurality of devices in order to improve the compression of the data transmitted through a plurality of connections;

figure 11A is a block diagram illustrating a modality that serves to provide an ad-hoc hierarchy of caches for the purpose of serving objects; and figure 11B is a flow chart illustrating a modality of a method that serves to provide an ad-hoc hierarchy of caches for the purpose of serving objects.

The features and advantages of the present invention will become more apparent from the detailed description presented below when taken in conjunction with the drawings, where similar reference characters identify corresponding elements. In the drawings, similar numerical references generally indicate identical elements, elements of similar functionality and / or structurally similar elements.

Detailed Description of the Invention

For the purposes of reading the later description of the various modalities of the present invention, the following descriptions of the sections of the specification and their respective contents may be useful:

- section A describes a network environment and a computational environment useful for practicing a modality of the present invention;

- section B describes modalities of a system architecture and tool designed to accelerate the distribution of a computing environment to a remote user;

- section C describes modalities for a client agent to accelerate communications between a client and a server;

- section D describes modalities of systems and methods for using a compaction history;

- section E describes system modalities and methods for the efficient identification of compaction history compatibilities;

- section F describes modalities of systems and methods for removing application layer headers from the compression history data;

- section G describes modalities of systems and methods for synchronizing the expiration of shared data of compression history; and

- section H describes modalities of systems and methods designed to take advantage of shared compaction histories on more than two devices.

- section I describes modalities of systems and methods for ad-hoc cache hierarchies.

A. Network and Computational Environment

Before discussing the details of the modalities of the systems and methods of a tool and / or client, it may be useful to discuss the network and computational environments in which these modalities can be implemented. Referring now to figure 1A, a modality of a network environment is described. In a brief overview, the network environment has one or more 102a-102n clients (also commonly referred to as 102 local machine (s), or 102 client (s)) communicating with one or more 106a-106n servers (also generally referred to as server (s) 106, or remote machine (s) 106) over one or more networks 104, 104 'and 104. In some embodiments, a client 102 communicates with a server 106 through one or more network optimization tools 200 and 200 '(generally referred to as a 200 tool). In a modality, the network optimization tool 200 is designed, configured or adapted to optimize WAN traffic. In some embodiments, a first tool 200 works together or in cooperation with a second tool 200 'in order to optimize network traffic. For example, a first tool 200 may be located between a branch and a WAN connection, while the second tool 200 'is located between the WAN and a corporate Local Area Network (LAN). The 200 and 200 'tools can work together to optimize WAN-related network traffic between a client located in a branch and a server located on a corporate LAN.

Although figure 1A shows a network 104, a network 104 'and a network 104 (generally referred to as network (s) 104) between clients 102 and servers 106, clients 102 and servers 106 may be on the same network 104. Networks 104, 104 'and 104 can have the same type of network or different types of networks. Network 104 can be a local area network (LAN), such as a company intranet, a metropolitan area network (MAN), or a wide area network (WAN), such as the Internet or the Range Network Worldwide. Networks 104, 104 'and 104 can be a private network or a public network. In one embodiment, network 104 'or network 104 can be a private network and network 104 can be a public network. In some embodiments, network 104 may be a private network and network 104 'and / or network 104 may be a public network. In another embodiment, networks 104, 104 'and 104 can be private networks. In some embodiments, customers 102 may be located in a branch of an enterprise corporation that communicates over a WAN connection over network 104 to servers 106 located on a corporate LAN in a corporate data center.

Network 104 can have any type and / or form of network and can include any between: a point-to-point network, a broadcasting network, a wide area network, a local area network, a telecommunications network, a data communication network, a computer network, an ATM network (Asynchronous Transfer Mode), a SONET network (Re15 of Synchronous Optics), an SDH network (Digital Synchronous Hierarchy), a wireless network and a wired network. In some embodiments, network 104 may comprise a wireless connection, such as an infrared channel or a satellite band. The topology of network 104 can be a bus, star, or ring topology. The network 104 and the network topology can be any network or network topology known to those skilled in the art capable of supporting the operations described in this document.

As described in figure 1A, a first network optimization tool 200 is shown between networks 104 and 104 'and a second network optimization tool 200' is also shown between networks 104 'and 104. In some embodiments, the tool 200 can be located on network 104. For example, the limited company can deploy a tool 200 at the branch. In other embodiments, tool 200 may be located on network 104 '. In some embodiments, tool 200 'may be located on network 104' or network 104. For example, a tool 200 may be located on a corporate data center. In one embodiment, tools 200 and 200 'are on the same network. In another modality, tools 200 and 200 'are in different networks.

In one embodiment, tool 200 consists of a device that serves to accelerate, optimize or otherwise improve the performance, operation or quality of service of any type or form of network traffic. In some embodiments, Tool 200 consists of a performance-enhancing proxy server. In other embodiments, tool 200 consists of any type and shape of a WAN optimization or acceleration device, sometimes also referred to as a WAN optimization controller. In one embodiment, tool 200 consists of any of the product modalities called WANScaler manufactured by Citrix Systems, Inc. of Ft. Lauderdale, Florida, USA. In other embodiments, Tool 200 includes any of the product modalities referred to as a BIG-IP and WANjet connection controller manufactured by F5 Networks, Inc. of Seattle, Wa16 shington, USA. In another embodiment, Tool 200 includes any of the WX and WXC WAN accelerator device platforms manufactured by Juniper Networks, Inc. of Sunnyvale, California, USA. In some embodiments, Tool 200 includes any steel head line of WAN optimization tools manufactured by Riverbed Technology of San Francisco, California, USA. In other embodiments, Tool 200 includes any of the WAN-related devices manufactured by Expand Networks Inc. of Roseland, New Jersey, USA. In one embodiment, tool 200 includes any of the WAN-related tools manufactured by Packeteer Inc. Cupertino, California, USA, such as the PacketShaper, iShared and SkyX product modalities provided by Packeteer. In yet another modality, Tool 200 includes any WAN-related tools and / or software manufactured by Cisco Systems, Inc. of San Jose, California, USA, such as the WAN Application Services network and software modules. Cisco, and Wide Area Network engine tools.

In some embodiments, Tool 200 provides application services and data acceleration for branch offices or remote offices. In one embodiment, tool 200 includes the optimization of File Services for Wide Area Networks (WAFS). In another modality, tool 200 accelerates the distribution of files, such as through an Internet Common File System (CIFS) protocol. In other embodiments, tool 200 provides for caching in memory and / or storage in order to speed up the distribution of applications and data. In one embodiment, tool 205 provides a compression of network traffic at any level of the network stack or at any network layer. In another modality, tool 200 provides optimizations of the transport layer protocol, flow control, performance improvements or modifications and / or management, in order to accelerate the distribution of applications and data over a WAN connection. For example, in one modality, tool 200 provides optimization of the Transport Control Protocol (TCP). In other modalities, Tool 200 provides optimizations, flow control, performance improvements or modifications and / or management for any application layer section or protocol. Further details of the tool 200's optimization, operations and architecture techniques will be described later in Section B.

Still referring to figure 1A, the network environment can include multiple logically grouped servers 106. In these embodiments, the logical group of servers can be termed as a server farm 38. In some of these modalities, servers 106 can be geographically dispersed. In some cases, a farm 38 can be managed as a single entity. In other embodiments, the server farm 38 comprises a plurality of server farms 38. In one embodiment, the server farm runs one or more applications for the benefit of one or more clients 102.

Servers 106 on each farm 38 can be heterogeneous. One or more 106 servers may operate according to one type of operating system platform (for example, WINDOWS NT, manufactured by Microsoft Corp. of Redmond, Washington, USA), while one or more other 106 servers may operate according to another type of operating system platform (for example, Unix or Linux). Servers 106 from each farm 38 need not be physically close to another server 106 on the same farm 38. Therefore, the group of servers 106 logically grouped as a farm 38 can be interconnected using a wide area network (WAN) connection. or a metropolitan area network connection (MAN). For example, a farm 38 may include servers 106 physically located on different continents or different regions of a continent, country, state, city, field or space. Data transmission speeds between servers 106 on farm 38 can increase if servers 106 are connected using a local area network (LAN) connection or some form of direct connection.

Servers 106 can be file servers, application servers, web servers, proxy servers and / or gateway servers. In some embodiments, a server 106 may have the ability to function as an application server or as a master application server. In one embodiment, a server 106 may include an Active Directory. Clients 102 can also be referred to as client nodes or endpoints. In some embodiments, a client 102 has the ability to function both as a client node that seeks access to applications on a server and an application server that provides access to hosted applications for other 102a-102n clients.

In some embodiments, a client 102 communicates with a server 106. In one embodiment, client 102 communicates directly with or from servers 106 on a farm 38. In another embodiment, client 102 runs a program neighborhood application to communicate with a server 106 on a farm 38. In yet another embodiment, server 106 provides the functionality of a master node. In some embodiments, client 102 communicates with server 106 on farm 38 over a network 104. Along network 104, client 102 can, for example, request the execution of several applications hosted by servers 106a-106n on the farm 38 and receive the results of the application's execution results for display. In some embodiments, only the master node provides the functionality necessary to identify and provide the address information associated with a server 106 'hosting a requested application.

In one embodiment, a server 106 provides the functionality of a web server. In another embodiment, server 106a receives requests from client 102, forwards requests to a second server 106b and responds to the request by client 102 with a response to the request from server 106b. In yet another embodiment, server 106 acquires an enumeration of applications available to client 102 and the address information associated with a server 106 that hosts an application identified by the application enumeration. In yet another modality, server 106 presents the response to the request to client 102 using a web interface. In one embodiment, client 102 communicates directly with server 106 in order to access the identified application. In another embodiment, client 102 receives the output data from the application, such as display data, generated by an execution of the application identified on server 106.

Deployed with Other Applications.

Referring now to figure 1B, another modality of a network environment is described in which the network optimization tool 200 is deployed with one or more other tools 205 and 205 '(generally referred to as tool 205 or second tool 205), such as a gateway, firewall, or acceleration tool. For example, in one embodiment, tool 205 consists of a firewall or security tool, while tool 205 'consists of a LAN acceleration device. In some embodiments, a client 102 can communicate with a server 106 through one or more first tools 200 and one or more second tools 205.

One or more tools 200 and 205 can be located anywhere on the network or network communications path between a client 102 and a server 106. In some embodiments, a second tool 205 can be located on the same network 104 as the first tool 200. In other embodiments, the second tool 205 may be located on a network 104 other than the first tool 200. In yet another embodiment, a first tool 200 and the second tool 205 are in the same network, for example, network 104, while the first tool 200 'and the second tool 205' are in the same network, such as network 104.

In one embodiment, the second tool 205 includes any type and form of transport control protocol or later transport termination device, such as a gateway device or firewall. In one embodiment, tool 205 terminates the transport control protocol by establishing a first transport control protocol connection with the client and a second transport control protocol connection with the second tool or server. In another mode, tool 205 finalizes the transport control protocol by changing, managing or controlling the connection behavior of the transport control protocol between the client and the server or the second tool. For example, tool 205 can alter, queue, forward or transmit network packets in order to effectively terminate the transport control protocol connection or act or simulate the termination of the connection.

In some embodiments, the second tool 205 consists of a performance-enhancing proxy server. In one embodiment, tool 205 provides a virtual private network (VPN) connection. In some embodiments, tool 205 provides a Secure Sockets Layer (SSL VPN) connection. In other modalities, tool 205 provides IPsec (Internet Protocol Security) based on the VPN connection. In some embodiments, tool 205 provides one or more of the following features: compression, acceleration, load balancing, switching / routing, caching, and Transport Control Protocol (TCP) acceleration.

In one embodiment, tool 205 consists of any of the product modalities referred to as Access Port, Firewall Application, Application Port, or NetScaler manufactured by Citrix Systems, Inc. of Ft. Lauderdale, Florida, USA. As such, in some modalities, the 205 tool includes any logic, functions, rules, or operations that serve to perform services or functionality, such as SSL VPN connectivity, SSL offloading, switching / load balancing, Domain Name Service resolution , LAN acceleration and a firewall application.

In some embodiments, tool 205 provides an SSL VPN connection between a client 102 and a server 106. For example, a client 102 on a first network 104 requests to establish a connection to a server 106 on a second network 104 '. In some embodiments, the second network 104 is not routable from the first network 104. In other embodiments, client 102 is on a public network 104 and server 106 is on a private network 104 ', such as a corporate network. In one embodiment, a client agent intercepts client communications 102 on the first network 104, encrypts communications, and transmits communications through a first transport layer connection to tool 205. Tool 205 associates the first transport layer connection on the first network 104 to a second transport layer connection to server 106 on the second network 104. Tool 205 receives the intercepted communication from the client agent, decrypts the communications, and transmits the communication to server 106 on the second network 104 through the second transport layer connection. The second transport layer connection can be a grouped transport layer connection. In one embodiment, tool 205 provides a secure end-to-end transport layer connection for client 102 between the two networks 104 and 104 '

In one embodiment, tool 205 hosts an intranet internet protocol or intranet IP address of client 102 on virtual private network 104. Client 102 has a local network identifier, such as an internet protocol (IP) address and / or name the host on the first network 104. When connected to the second network 104 'through tool 205, tool 205 establishes, assigns or otherwise provides an IntranetiP, which consists of a network identifier, such as an IP address and / or host name, for client 102 on second network 104 '. Tool 205 detects and receives on the second network or private network 104 'for any communications directed towards the client 102 using the client's established IntranetiP. In one embodiment, tool 205 acts as, or on behalf of, client 102 on the second private network 104.

In some embodiments, tool 205 has an encryption mechanism that provides logic, business rules, functions or operations for handling the processing of any security-related protocol, such as SSL or TLS, or any function related to it. For example, the encryption mechanism encrypts and decrypts network packets, or any portions thereof, communicated via the 205 tool. The encryption engine can also configure or establish SSL or TLS connections for the benefit of the 102a-102n client, server 106a-106n, or tool 200, 205. As such, the encryption mechanism provides a download and an acceleration of SSL processing. In one embodiment, the encryption mechanism uses a tunneling protocol in order to provide a virtual private network between a 102a-102n client and a 106a-106n server. In some embodiments, the encryption mechanism uses an encryption processor. In other embodiments, the encryption mechanism includes instructions executable on an encryption processor.

In some embodiments, tool 205 provides one or more of the following acceleration techniques for communications between client 102 and server 106: 1) compression, 2) decompression, 3) Transmission Control Protocol combination Transmission Control Protocol , 4) Transmission Control Protocol multiplexing, 5) Transmission Control Protocol temporary storage, and 6) Cache storage. In one embodiment, tool 200 relieves servers 106 of most of the processing load caused by repeatedly opening and closing transport layer connections to clients 102 by opening one or more transport layer connections with each server 106 and maintaining these connections in order to allow repeated access of data by customers over the Internet. This technique is referred to in this document as a connection combination.

In some embodiments, in order to seamlessly merge communications from a client 102 to a server 106 through a grouped transport layer connection, tool 205 converts or multiplexes communications by changing the sequence number and confirmation numbers at the transport layer protocol level. This is referred to as connection multiplexing. In some embodiments, no application layer protocol interaction is required. For example, in the case of an incoming packet (that is, a packet received from a client 102), the address of the packet's source network is changed to the address of an outbound port of tool 205, and an address destination network is changed to the target server address. In the case of an outgoing packet (that is, a packet received from a server 106), the source network address is changed from the address of server 106 to the address of an outbound port of tool 205 and the destination address is changed from tool address 205 to request client address 102. The sequence numbers and confirmation numbers of the package are also converted into sequence numbers and confirmation numbers expected by the client 102 on the transport layer connection of the tool 205 to client 102. In some embodiments, the checksum of the transport layer protocol is recalculated taking these conversions into account.

In another embodiment, tool 205 provides switching or load balancing functionality for communications between client 102 and server 106. In some embodiments, tool 205 distributes traffic and directs client requests to a server 106 based on layer 4 payload or application layer request data. In one embodiment, although the network layer or layer 2 of the network packet identifies a destination server 106, tool 205 determines server 106 in order to distribute the network packet through application information and data carried as payload of the transport layer package. In one embodiment, a tool 205 health monitoring program monitors the health of the servers in order to determine the server 106 to which a customer request is distributed. In some embodiments, if tool 205 detects that a server 106 is not available or has a load above a predetermined limit, tool 205 may direct or distribute client requests to another server 106.

In some embodiments, tool 205 functions as a Domain Name Service (DNS) resolver or otherwise provides a resolution of a DNS request from clients 102.

In some embodiments, the tool intercepts a DNS request transmitted by client 102. In one embodiment, tool 205 responds to a DNS request from the client with an IP address or hosted by tool 205. In this modality, client 102 transmits a communication from network for domain name to tool 200. In another embodiment, tool 200 responds to a DNS request from the client with an IP address or hosted by a second tool 200 '. In some embodiments, tool 205 responds to a DNS request from the client with an IP address of a server 106 determined by tool 200.

In yet another embodiment, tool 205 provides firewall application functionality for communications between client 102 and server 106. In one embodiment, a policy mechanism 295 'provides rules for detecting and blocking illegitimate requests. In some embodiments, the firewall application protects against denial of service (DoS) attacks. In other ways, the tool analyzes the content of intercepted requests in order to identify and block attacks based on applications. In some embodiments, the policy rules / mechanism include one or more firewall applications or security control policies to provide protection against various classes and types of vulnerabilities based on the web or the Internet, such as one or more of: 1) data overflow, 2) manipulation of CGI-BIN parameters, 3) form / hide field manipulation, 4) forced navigation, 5) cookie or session poisoning, 6) corrupted access control list (ACLs) or weak passwords, 7) cross-site scripting (XSS), 8) command injection, 9) SQL injection, 10) leakage of error sensitive information, 11) insecure use of encryption, 12) erroneous server configuration, 13) rear doors and debugging options, 14) website disfigurement, 15) platform or operating system vulnerabilities, and 16) zero-day exploits. In one embodiment, the tool's firewall application provides HTML field protection in the form of inspection or analysis of network communication for one or more of: 1) required fields are returned, 2) no additional fields allowed, 3) field imposition only for reading and hidden, 4) drop-down list and radio button field conformation, and 5) maximum form field imposition. In some modalities, the 205 application's firewall application ensures that cookies are not modified. In other ways, the 205 tool protects against forced browsing by enforcing legal URLs.

In yet other modalities, the firewall application tool 205 protects any confidential information contained in the network communication. Tool 205 can inspect or analyze any network communication according to the rules or policies of the policy mechanism to identify any confidential information in any field of the network packet. In some modalities, the firewall application identifies in network communication one or more occurrences of a credit card number, password, social security number, name, patient code, contract information, and age. The encrypted portion of the network communication can include these occurrences or confidential information. Based on these occurrences, in a modality, the firewall application can adopt a policy action in the network communication, such as preventing the transmission of the network communication. In another mode, the firewall application can rewrite, remove or otherwise mask this identified occurrence or confidential information.

Although generally referred to as a network optimization or first tool 200 and a second tool 205, the first tool 200 and second tool 205 can be of the same type and shape of tool. In one embodiment, the second tool 205 can perform the same functionality, or portion thereof, as the first tool 200, and vice versa. For example, the first tool 200 and the second tool 205 can provide acceleration techniques. In one embodiment, the first tool can perform LAN acceleration while the second tool can perform WAN acceleration, or vice versa. In another example, the first tool 200 can also be a transport control protocol termination device as well as the second tool 205. In addition, although tools 200 and 205 are shown on separate devices on the network, tools 200 and / or 205 can be a part of any client 102 or server 106.

Referring now to figure 1C, we describe other modalities of a network environment that serve to deploy tool 200. In another mode, as described in the upper part of figure 1C, tool 200 can be deployed as a tool single or single proxy on network 104. For example, tool 200 can be designed, built or adapted to perform WAN optimization techniques discussed in this document without a second cooperation tool 200 '. In other embodiments, as described at the bottom of figure 1C, a single tool 200 with one or more second tools 205 can be deployed. For example, a first WAN 200 acceleration tool, such as a Citrix WANScaler tool, can be deployed with a second LAN acceleration tool or Firewall 205 application, such as a Citrix NetScaler tool.

Computational Device

Client 102, server 106 and tools 200 and 205 can be deployed and / or executed on any type or form of computational device, such as a computer, network device or tool capable of communicating on any type and form of network and perform the operations described in this document. Figures 1C and 1D depict block diagrams of a computational device 100 useful for practicing a modality of client 102, server 106 or tool 200. As shown in figures 1C and 1D, each computing device 100 includes a central processing unit 101, and a main memory unit 122. As shown in figure 1C, a computing device 100 may include a visual display device 124, a keyboard 126 and / or a pointing device 127, such as a mouse. Each computational device 100 may also include additional optional elements, such as one or more input / output devices 130a-130b (commonly referred to as numeric reference 130), and a cache memory 140 in communication with the central processing unit 101.

The central processing unit 101 consists of a logic circuit that responds and processes instructions fetched from the main memory unit 122. In many embodiments, the central processing unit is provided by a microprocessor unit, such as: those manufactured with Intel Corporation of Mountain View, California, USA; those manufactured with Motorola Corporation of Schaumburg, Illinois, USA; those manufactured with Transmeta Corporation of Santa Clara, California, USA; the RS / 6000 processor, those manufactured with the International Business Machines of White Plains, New York, USA; or those manufactured with Advanced Micro Devices in Sunnyvale, California, USA. Computational device 100 can be based on any of the processors, or any other processor capable of operation as described in this document.

Main memory unit 122 can be one or more memory chips capable of storing data and allowing any storage location to be directly accessed by microprocessor 101, such as a Static Random Access Memory (SRAM), Burst SRAM or SynchBurst SRAM (BSRAM), Dynamic Random Access Memory (DRAM), DRAM Quick Paging Mode (FPM DRAM), Enhanced DRAM (EDRAM), Extended RAM Data Output (EDO RAM), Extended DRAM Data Output (EDO DRAM), Accelerated DRAM Extended Data Output (BEDO DRAM), Enhanced DRAM (EDRAM), Synchronous DRAM (SDRAM), JEDEC SRAM, PCI00 SDRAM, Dual Data Rate SDRAM (DDR SDRAM), Enhanced SDRAM (ESDRAM), SyncLink DRAM ( SLDRAM), Direct Rambus DRAM (DRDRAM), or Ferroelectric RAM (FRAM). Main memory 122 can be based on any memory chips described above, or any other available memory chips capable of operating as described in this document. In the embodiment shown in figure 1C, processor 101 communicates with main memory 122 through system bus 150 (described in more detail below). Fig. 1C describes a modality of a computational device 100 in which the processor communicates directly with main memory 122 through a memory port 103. For example, in Fig. 1D, main memory 122 can be DRDRAM.

Fig. 1D describes an embodiment in which the main processor 101 communicates directly with a cache memory 140 through a secondary bus, sometimes referred to as a rear bus. In other embodiments, main processor 101 communicates with cached memory 140 using system bus 150. Cache memory 140 typically has a faster response time than main memory 122 and is typically provided by SRAM, BSRAM or EDRAM. In the embodiment shown in figure 1C, processor 101 communicates with several I / O devices 130 through a local system bus 150. Multiple buses can be used to connect the central processing unit 101 to any of the l / O 130 devices, including a VESA VL bus, an ISA bus, an EISA bus, a MicroChannel (MCA) architecture bus, a PCI bus , a PCI-X bus, a PCIExpress bus, or a NuBus. For modalities in which the L / O device consists of a video screen 124, processor 101 can use an Accelerated Graphics Port (AGP) to communicate with screen 124. Figure 1D describes a mode of a computer 100 in which the main processor 101 communicates directly with the l / O 130 device via HyperTransport, Rapid l / O, or InfiniBand. Figure 1D also describes a modality in which local buses and direct communication are mixed: processor 101 communicates with the I / O device 130 using a local interconnect bus while communicating directly with the I / O device 130 .

Computing device 100 can support any suitable installation device 116, such as a floppy disk drive that serves to receive floppy disks, such as 8.89 cm (3.5 inch), 3.34 cm (5.25) disks inches) or ZIP disks, a CD-ROM drive, a CD-R / RW drive, a DVD-ROM drive, tape drives of various formats, USB devices, hard drives, or any other device suitable for installing software and Software, such as any client agent 120, or portion thereof. The computing device 100 may further comprise a storage device 128, such as one or more hard drives or redundant arrays of independent disks, which serves to store an operating system and other related software, and to store software programs for applications, such as any client agent-related program 120. Optionally, any of the installation devices 116 can also be used as the storage device 128. In addition, the operating system and software can be run from a bootable medium, for example, to a bootable CD, such as KNOPPIX® , a bootable CD for GNU / Linux available as a GNU / Linux distribution from knoppix.net.

In addition, computing device 100 may include a network interface 118 that serves to interface with a Local Area Network (LAN), Wide Area Network (WAN) or the Internet through a variety of connections that include, but are not limited to, are limited to, standard telephone calls, LAN or WAN connections (e.g. 802.11, T1, T3, 56kb, X.25), broadband connections (e.g. ISDN, Frame Relay, ATM), wireless connections, or some combination of any or all of the above. The network interface 118 may comprise a built-in network adapter, network interface card, PCMCIA network card, card bus network adapter, wireless network adapter, USB network adapter, modem or any other device suitable for interface with computational device 100 to any type of network capable of communicating and performing the operations described in this document. A wide variety of 130a-130n l / O devices can be present in computational device 100. Input devices include keyboards, mice, touch sensitive tables (trackpods), stationary mice (trackballs), microphones and digitizing tables. Output devices include video screens, speakers, inkjet printers, laser printers, and color sublimation printers. The I / O devices 130 can be controlled by an I / O controller 123 as shown in figure 1C. The I / O controller can control one or more I / O devices, such as a keyboard 126 and a pointing device 127, for example, a mouse or optical pen. In addition, an I / O device may also provide storage 128 and / or installation means 116 for computing device 100. In yet other embodiments, the computing device 100 can provide USB connections for receiving portable USB storage devices, such as the line of USB flash drives manufactured by Twintech Industry, Inc. of Los Alamitos, California, USA.

In some embodiments, the computing device 100 may comprise or be connected to multiple display devices 124a124n, which may be of the same type or different types and / or shape. As such, any of the l / O 130a-130n devices and / or the l / O controller 123 may comprise any type and / or form of hardware, software, or a combination of appropriate hardware and software that serves to support, permit or providing a connection and use of multiple display devices 124a-124n by computing device 100. For example, computational device 100 may include any type and / or form of video adapter, video card, driver, and / or library that serves to interface, communicate, connect, or otherwise use, the display devices 124a-124n. In one embodiment, a video adapter may comprise multiple connectors that serve to interface with multiple display devices 124a-124n. In other embodiments, the computational device 100 may include multiple video adapters, each video adapter being connected to one or more display devices 124a-124n. In some embodiments, any portion of the operating system of the computing device 100 can be configured to use multiple display devices 124 to 124n. In other embodiments, one or more display devices 124a-124n can be provided by one or more computing devices, such as computing devices 100a and 100b connected to computing device 100, for example, over a network. Such modalities can include any type of software designed and built to use another computer display device as a second display device 124a for computer device 100. A person skilled in the art will recognize and evaluate various forms and modalities in which a computing device 100 can be configured so that it has multiple display devices 124a-124n.

In other embodiments, a 1/0130 device can be a bridge 170 between the system bus 150 and an external communication bus, such as a USB bus, an Apple Desktop bus, an RS-232 serial connection, a SCSI bus, a Fire Wire bus, FireWire 800 bus, Ethernet bus, AppIeTalk bus, Gigabit Ethernet bus, Asynchronous Transfer Mode bus, HIPPI bus, Super HIPPI bus, a SerialPIus bus, a SCI / LAMP bus, a FibreChannel bus, or a Serial Fixed bus with a small computer system interface.

A computational device 100 of the type described in figures 1C and 1D typically operates under the control of operating systems, which control the scheduling of tasks and access to system resources. Computational device 100 can run on any operating system, such as any of the versions of the Windows Microsoft® operating systems, the different releases of the Unix and Linux operating systems, any version of Mac OS® or OS X for Macintosh computers, any system embedded operating system, any real-time operating system, any open source operating system, any proprietary operating system, any operating systems for mobile computing devices, or any other operating system capable of running on the computing device and performing the operations described in this document. Typical operating systems include: WINDOWS 3.x, WINDOWS 95, WINDOWS 98, WINDOWS 2000, WINDOWS NT 3.51, WINDOWS NT 4.0, WINDOWS CE, WINDOWS 2003, WINDOWS XP, and WINDOWS VISTA all manufactured by the Microsoft Corporation of Redmond, Washington, USA; MacOS and OS X, manufactured by Apple Computer of Cupertino, California, USA; OS / 2, manufactured by International Business Machines of Armonk, New York, USA; and Linux, a freely available operating system distributed by Caldera Corp. Salt Lake City, Utah, USA, or any type and / or form of a Unix operating system, (such as Unix versions called Solaris / Sparc, Solaris / x86, AIX IBM, HP UX, and SGI (Silicon Graphics )), among others.

In other embodiments, computational device 100 may have different processors, operating systems, and input devices in line with the device. For example, in one mode, computer 100 is a Treo 180, 270, 1060, 600 or manufactured by Palm, Inc. smart phone. In this mode, the Treo smart phone is operated under the control of the PalmOS operating system and includes a Stylus input, as well as a five-way browser device. In another example, computational device 100 may be a WinCE or PocketPC device with an ARM (Advanced RISC Machine) processor type. In one example, computational device 100 includes a type of Series 80 smart phone (Nokia 9500 or Nokia 9300) manufactured by Nokia of Finland, which can run the Symbian OS or EPOC mobile operating system manufactured by Symbian Software Limited of London, UK . In another example, computing device 100 may include a FOMA M100 branded smart phone manufactured by Motorola, Inc. of Schaumburg, Illinois, USA, and operates the EPOC or Symbian OS operating system. In yet another example, computing device 100 includes a Sony Ericsson mobile phone model P800, P900 or P910 manufactured by Sony Ericsson Mobile Communications (USA) Inc. of Research Triangle Park, North Carolina, USA. In addition, computing device 100 can be any workstation, desktop computer, laptop or notebook computer, server, handheld computer, mobile phone, smart phone, any other computer, or other form of computing or telecommunications device that is capable communicate and has sufficient processor power and memory capacity to perform the operations described in this document.

B. System and Tool Architecture

Referring now to figure 2A, a modality of an environment and system architecture of a tool 200 that serves to distribute and / or operate a computational environment on a client is described. In some embodiments, a server 106 includes an application distribution system 290 that serves to distribute a computing environment in an application and / or data file to one or more clients 102. In a brief overview, a client 102 is communicating with a server 106 over network 104 and tool 200. For example, client 102 can reside in a remote office of a company, for example, a branch, and server 106 can reside in a corporate data center. Client 102 has a client agent 120, and a computing environment 215. Computing environment 215 can run or operate an application that accesses, processes, or uses a data file. The computing environment 215, application and / or data file can be distributed through tool 200 and / or server 106.

In some embodiments, the tool 200 accelerates the distribution of a computing environment 215, or any portion thereof, to a customer 102. In one embodiment, the tool 200 accelerates the distribution of the computing environment 215 by the application distribution system 290. For example, the modalities described in this document can be used to accelerate the distribution of a streaming application and an application-processable data file from a corporate data center to a remote user location, such as a branch office. a company. In another embodiment, tool 200 speeds up transport layer traffic between a client 102 and a server 106. In another modality, tool 200 controls, manages, or adjusts the transport layer protocol in order to accelerate the distribution of the computing environment. In some embodiments, Tool 200 uses caching and / or compression techniques to accelerate the deployment of a computing environment.

In some embodiments, the application distribution management system 290 provides application distribution techniques that serve to distribute a computing environment to a user's desktop, remote or otherwise based on a plurality of application methods. based on any authentication and authorization policies applied through a 295 policy mechanism. With these techniques, a remote user can obtain a computing environment and have access to applications stored on the server and data files from any device connected to a network 100. In one embodiment, the application distribution system 290 can reside or run on a server 106. In another embodiment, application delivery system 290 may reside or run a plurality of servers 106a106n. In some embodiments, the application distribution system 290 may run on a server farm 38. In one embodiment, the server 106 that runs the application distribution system 290 may also store or provide the application and data file. In another embodiment, a first set of one or more servers 106 can run application distribution system 290, and a different server 106n can store or deliver the application and data file. In some embodiments, each application distribution system 290, application and data file can reside or be located on different servers. In yet another embodiment, any portion of the application distribution system 290 may reside, execute, or be stored or distributed to tool 200, or to a plurality of tools.

Client 102 may include a computing environment 215 that serves to run an application that uses or processes a data file. Client 102 through networks 104 and 104 'and tool 200 can request an application and a data file from server 106. In one embodiment, tool 200 can forward a request from client 102 to server 106. For For example, client 102 may not have the application and data file stored or locally accessible. In response to the request, application distribution system 290 and / or server 106 can distribute the application and the data file to client 102. For example, in one embodiment, server 106 can transmit the application as an application stream to operate in a computational environment 215 on client 102.

In some embodiments, the application distribution system 290 comprises any portion of the Citrix Access Suite® available from Citrix Sistemas, Inc., such as MetaFrame or Citrix Presentation Server® and / or any of the Microsoft® Windows Terminal Services manufactured by Microsoft Corporation. In one embodiment, the application delivery system 290 can deliver one or more applications to customers 102 or users via a remote display protocol or otherwise via a remote or server-based computing device. In another embodiment, the application distribution system 290 can distribute one or more applications to customers or users through the continuous flow of the application.

In one embodiment, the application distribution system 290 includes a policy mechanism 295 that serves to control and manage access to applications, selection of application execution methods, and application distribution. In some embodiments, policy mechanism 295 determines one or more applications that a user or client 102 can access. In another embodiment, policy mechanism 295 determines how the application is to be distributed to the user or client 102, for example, the execution method. In some embodiments, the application distribution system 290 provides a plurality of distribution techniques from which to select an application execution method, such as a server-based computing device, streaming or application distribution locally to the client 120 for local execution.

In one embodiment, a client 102 requests the execution of an application program and the application distribution system 290 comprising a server 106 selects a method of executing the application program. In some embodiments, server 106 receives credentials from client 102. In another embodiment, server 106 receives a request for an enumeration of applications available from client 102. In one embodiment, in response to requesting or receiving credentials, application distribution system 290 lists a plurality of application programs available to client 102. Application distribution system 290 receives a request to run an enumerated application. The application distribution system 290 selects a predetermined number of methods for running the listed application, for example, responsive to a policy from a policy engine. The application distribution system 290 can select an application execution method allowing the client 102 to receive the application output data generated by running the application program on a server 106. The application distribution system 290 can select a method of running the application allowing the client or local machine 102 to run the application program locally after restoring a plurality of application files comprising the application. In yet another embodiment, the application distribution system 290 can select a method of executing the application in order to transmit the application over the network 104 to the client 102.

A client 102 may run, operate or otherwise provide an application, which may have any type and / or form of executable software, programs, or instructions, such as any type and / or form of web browser, client based on the web, client-server application, a thin client computational client, an ActiveX control, or a Java applet, or any other type and / or form of executable instructions capable of executing on a 102 client. In some embodiments, the application can be a server-based or remote-based application that runs on behalf of client 102 on a server 106. In one embodiment, server 106 can display output to client 102 using any thin client or remote display protocol, such as the Independent Computing Architecture (ICA) protocol manufactured by Citrix Systems, Inc. of Ft. Lauderdale, Florida, USA or the Remote Desktop Protocol (RDP) manufactured by Microsoft Corporation of Redmond, Washington, USA. The application can use any type of protocol and can be, for example, an HTTP client, an FTP client, an Oscar client, or a Telnet client. In other ways, the application comprises any type of software related to VolP communications, such as a soft IP phone. In other modalities, the application comprises any application related to real-time data communications, such as the applications used to transmit video and / or audio.

In some embodiments, server 106 or a server farm 38 may run on one or more applications, such as an application that provides a thin client computational application or a remote display presentation application. In one embodiment, server 106 or server farm 38 runs, as an application, any portion of the Citrix Access Suite® available from Citrix Systems, Inc., such as MetaFrame or Citrix Presentation Server®, and / or any Services Microsoft® Windows Terminals manufactured by Microsoft Corporation. In one embodiment, the application consists of an ICA client, developed by Citrix Systems, Inc. of Fort Lauderdale, Florida, USA. In other ways, the application includes a Remote Desktop (RDP) client, developed by Microsoft Corporation of Redmond, Washington, USA. Likewise, server 106 can run an application, which can, for example, be an application server that provides e-mail services, such as Microsoft Exchange manufactured by Microsoft Corporation of Redmond, Washington, USA, a web or Internet server , or desktop sharing server, or a collaboration server. In some embodiments, any of the applications may comprise any type of hosted services or products, such as GoToMeeting® provided by Citrix Online Division, Inc. of Santa Barbara, California, USA, WebEx® provided by WebEx, Inc. of Santa Clara, California, USA, or Microsoft Office Live Meeting provided by Microsoft Corpo38 ration of Redmond, Washington, USA.

Exemplifying Tool Architecture

Figure 2A also illustrates an exemplary embodiment of tool 200. The architecture of tool 200 in figure 2A is provided for illustration only and is not intended to be limiting in any way. Tool 200 may include any type and form of computational device 100, such as any element or portion described in accordance with figures 1D and 1E above. In a brief overview, the tool 200 has one or more network ports 266A- 226N and one or more stacks of networks 267A-267N that serve to receive and / or transmit communications over networks 104. The tool 200 also has a mechanism network optimization 250 that serves to optimize, accelerate or otherwise improve the performance, operation, or quality of any network traffic or communications that pass through the tool 200.

Tool 200 includes or is under the control of an operating system. The operating system of tool 200 can be any type and / or form of the Unix operating system, although the invention is not limited to it. As such, Tool 200 can run on any operating system, such as any version of Microsoft® Windows operating systems, the different releases of Unix and Linux operating systems, any version of Mac OS® for Macintosh computers, any operating system any network operating system, any real-time operating system, any open source operating system, any proprietary operating system, any operating systems for mobile computing devices or network devices, or any other operating system capable of running on tool 200 and performing the operations described in this document.

The tool 200's operating system allocates, manages, or otherwise segregates available system memory into what is termed a kernel or system space, and user or application space. The kernel space is typically reserved to run the kernel, including any device drivers, kernel extensions or other kernel-related software. As known to those skilled in the art, the kernel is the core of the operating system, and provides access, control, and management of resources and hardware-related elements of the 200 tool. According to a 200 tool modality, the kernel space also includes a series of network services or processes that work in conjunction with the network optimization engine 250, or any portion thereof. In addition, the kernel mode will depend on the operating system mode installed, configured, or otherwise used by the device 200. In contrast to the kernel space, the user space is the area or portion of the operating system memory used by user mode applications or programs that are otherwise run in user mode. A user-mode application may not access the kernel space directly and use service calls for the purpose of accessing the kernel services. The operating system uses the user or application space to run applications and provide user-level programs, services, processes and / or tasks.

Tool 200 has one or more network ports 266 that serve to transmit and receive data over a network 104. Network port 266 provides a physical and / or logical interface between the computing device and a network 104 or other device 100 which serves to transmit and receive network communications. The type and shape of network port 266 depends on the type and shape of the network and the type of medium used to connect to the network. In addition, any software provided or used by network port 266 and network stack 267 can run in kernel space or user space.

In one embodiment, tool 200 has a network stack 267, such as a TCP / IP based stack, for communication over a network 105, with client 102 and / or with server 106. In one embodiment, the stack of network 267 is used to communicate with a first network, such as network 104, and also with a second network 104 '. In another embodiment, tool 200 has two or more network cells, such as the first network cell 267A and a second network cell 267N. The first network stack 267A can be used in line with a first port 266A to communicate on a first network 104. The second network stack 267N can be used in line with a second port 266N in order to communicate on a second network 104 '. In one embodiment, the network stack (s) 267 has one or more temporary memories that serve to queue one or more network packets destined for transmission by the tool 200.

The network stack 267 includes any type and form of software, or hardware, or any combination thereof, for the purpose of providing connectivity and communications with a network. In one embodiment, the network stack 267 includes a software implementation for a set of network protocols. The network stack 267 may have one or more network layers, such as any network layers of the Open Systems Interconnection (OSI) communications model that persons skilled in the art will recognize and evaluate. As such, network stack 267 can have any type and form of protocols for any of the following layers of the OSI model: 1) physical link layer, 2) data link layer, 3) network layer, 4) transport layer, 5) session layer, 6) presentation layer, and 7) application layer. In one embodiment, network stack 267 includes a transport control protocol (TCP) over the internet protocol (IP) network layer protocol, generally referred to as TCP / IP. In some embodiments, the TCP / IP protocol can be carried over the Ethernet protocol, which can comprise any of the IEEE family of wide area network (WAN) or local area network (LAN) protocols, such as the protocols covered by IEEE 802.3. In some embodiments, the network stack 267 has any type and form of a wireless protocol, such as IEEE 802.11 and / or mobile internet protocol.

Considering a TCP / IP-based network, any protocol based on TCP / IP can be used, including Messaging Application Programming Interface (MAPI) (electronic mail), File Transfer Protocol (FTP), Hypertext Transfer (HTTP), Internet Common File System (CIFS) protocol (file transfer), Independent Computer Architecture Protocol (ICA), Remote Desktop Protocol (RDP), Wireless Application Protocol (WAP), Mobile IP protocol, and Voice over IP (VoIP) protocol. In another embodiment, the network stack 267 comprises any type and form of transport control protocol, such as a modified transport control protocol, for example, a Transaction TCP (T / TCP), TCP with selection confirmations ( TCP-SACK), TCP with large windows (TCPLW), a congestion prediction protocol, such as the TCP-Vegas protocol, and a TCP spoofing protocol. In other embodiments, any type and form of user datagram protocol (UDP), such as UDP over IP, can be used by the network stack 267, such as for voice communications or real-time data communications.

In addition, network stack 267 can include one or more network drivers that support one or more layers, such as a TCP driver or a network layer driver. Network drivers can be included as part of the operating system of the computing device 100 or as part of any network interface cards or other network access components of the computing device 100. In some embodiments, any of the network drivers of the network stack 267 can be standardized, modified or adapted to provide a standard or modified portion of the network stack 267 in support of any of the techniques described in this document.

In one embodiment, tool 200 provides or maintains a transport layer connection between a client 102 and server 106 using a single network stack 267. In some embodiments, tool 200 effectively terminates the network connection. transport layer changing, managing or controlling the behavior of the transport control protocol connection between the client and the server. In these embodiments, tool 200 may use a single network stack 267.

In other embodiments, tool 200 terminates a first transport layer connection, such as a TCP connection from a client 102, and establishes a second transport layer connection to a server 106 for use on behalf of client 102, for example, the second transport layer connection is terminated at tool 200 and server 106. The first and second transport layer connection can be established via a single network stack 267. In other embodiments, tool 200 may use multiple network batteries, for example, 267A and 267N. In these embodiments, the first transport layer connection can be established Pl terminated in a 267A network cell, and the second transport layer connection can be established or terminated in the second network cell 267N. For example, a network stack can serve to receive and transmit network packets on a first network, and another network stack can serve to receive and transmit network packets on a second network.

As shown in figure 2A, network optimization mechanism 250 includes one or more of the following elements, components or modules: network packet processing mechanism 240, LAN / WAN detector 210, flow controller 220, QoS mechanism 236, accelerator protocol 234, compression engine 238, cache manager 232 and policy engine 295 '. The network optimization engine 250, or any portion thereof, may include software, hardware or any combination of software and hardware. In addition, any software provided or used by the network optimization engine 250 can run in kernel space or user space. For example, in one embodiment, the network optimization engine 250 can be run in a kernel space. In another embodiment, the network optimization mechanism 250 can be run in a user space. In yet another embodiment, a first portion of the network optimization engine 250 runs in a kernel space while a second portion of the network optimization engine 250 runs in a user space.

Network Packet Processing Mechanism

The network packet mechanism 240, also commonly referred to as a packet processing mechanism or packet mechanism, is responsible for controlling and managing the processing of packets received and transmitted by the tool 200 through network ports 266 and stack (s) 267. The network packet mechanism 240 can operate at any layer of the network stack 267. In one embodiment, the network packet mechanism 240 operates at layer 2 or layer 3 of the network stack 267. In some embodiments, the packet mechanism 240 intercepts or, otherwise, receives packets at the network layer, such as the IP layer in a TCP / IP mode. In another embodiment, packet mechanism 240 operates at layer 4 of network stack 267. For example, in some embodiments, packet mechanism 240 intercepts or otherwise receives packets at the transport layer, such as intercept packets as the TCP layer in a TCP / IP mode. In other embodiments, the packet mechanism 240 operates on any session or application layer above layer 4. For example, in one embodiment, packet mechanism 240 intercepts or otherwise receives network packets above the protocol layer. transport, such as the payload of a TCP packet in a TCP mode.

The packet mechanism 240 may include a buffer that serves to queue one or more network packets during processing, such as for receiving a network packet or transmitting a network packet. In addition, packet mechanism 240 is communicating with one or more network stacks 267 in order to send and receive network packets through network ports 266. Packet mechanism 240 may include a packet processing timer. In one embodiment, the packet processing timer provides one or more time slots to trigger incoming processing, that is, network packets received, or sent, that is, transmitted. In some embodiments, the packet mechanism 240 processes network packets in response to the timer. The packet processing timer provides any type and form of signal to the packet mechanism 240 in order to notify, trigger, or report an event related to the time, interval or occurrence. In many embodiments, the packet processing timer operates on the order of milliseconds, such as, for example, 100ms, 50ms, 25ms, 10ms, 5ms or 1ms.

During operations, the packet engine 240 can interface, be integrated with or communicate with any portion of the network optimization engine 250, such as the LAN / WAN detector 210, flow controller 220, the QoS engine 236, the protocol accelerator 234, the compression mechanism 238, the cache manager 232 and / or the policy mechanism 295 *. As such, any logic, functions or operations of the LAN / WAN detector 210, flow controller 220, QoS mechanism 236, protocol accelerator 234, compression mechanism 238, cache manager 232 and policy mechanism 295 'can be performed in response the packet processing timer and / or the packet mechanism 240. In some embodiments, any logic, functions or operations of the cryptographic mechanism 234, cache manager 232, policy mechanism 236 and multi-protocol compression logic 238 can be performed in the granularity of time intervals provided through the packet processing timer , for example, in a time interval less than or equal to 10ms. For example, in one embodiment, cache manager 232 can perform an expiration of any cached objects in response to integrated packet mechanism 240 and / or packet processing timer 242. In another embodiment, the expiration or invalidation time of a cached object can be adjusted in the same granular order as the packet processing timer time interval, such as every 10 ms. Cache Manager

The cache manager 232 can include software, hardware or any combination of software and hardware to store data, information and objects in a cache in memory or storage, provide cached access, and control and manage the cache. The data, objects or content processed and stored by the cache manager

232 they can include data in any format, such as a markup language, or any type of data communicated through any protocol. In some embodiments, the cache manager 232 duplicates the original stored data or the data previously computed, generated or transmitted, where the original data may need a longer access time to search, compute or otherwise obtain relation to the reading of a cache memory or storage element. Once the data is stored in the cache, it can be used in the future by accessing the cached copy instead of searching or recomputing the original data, thus reducing access time. In some embodiments, the cache may comprise a data object in the memory of the tool 200. In another embodiment, the cache may comprise any type and form of storage element of the tool 200, such as a portion of a hard disk. In some embodiments, the processing unit of the device may provide a cache memory for use by the cache manager 232. In still other embodiments, the cache manager 232 may use any portion and combination of memory, storage, or the processing unit. for cached data, objects and other content.

In addition, cache manager 232 includes any logic, functions, rules or operations to perform any caching techniques of tool 200. In some embodiments, cache manager 232 can operate as an application, library, program, service, process, execution process or task. In some embodiments, the cache manager 232 may comprise any type of general purpose processor (GPP), or any other type of integrated circuit, such as a Field Programmable Port Array (FPGA), Programmable Logic Device (PLD), or Integrated Circuit for Specific Application (ASIC).

Policy Mechanism

Policy mechanism 295 'includes any logic, function or operations that serve to provide and apply one or more policies or rules to the function, operation or configuration of any portion of tool 200. Policy mechanism 295' may include, for example, an intelligent statistical engine or other programmable application (s). In one embodiment, policy mechanism 295 provides a configuration mechanism that serves to allow a user to identify, specify, define or configure a policy for network optimization mechanism 250, or any portion thereof. For example, policy engine 295 can provide policies for which data is cached, when to cache data, for whom to cache data, when to expire a cached object, or to update the cache. In other modalities, the policy mechanism 236 may include which logic, rules, functions or operations that serve to determine and provide access, control and management of objects, data or content being cached by the tool 200 in addition to accessing, controlling and managing security, network traffic, network access, compression or any other function or operation performed by tool 200.

In some embodiments, policy mechanism 295 'provides and applies one or more policies based on any one or more between: a user, the client ID, the server ID, the type of connection, the connection time, the type of network, or the contents of network traffic. In one embodiment, policy mechanism 295 'proposes and applies a policy based on any field or header in any protocol layer of a network packet. In another embodiment, policy mechanism 295 'provides and applies a policy based on any payload in a network packet. For example, in one embodiment, policy mechanism 295 'enforces a policy based on the identification of a given piece of content from a transported application layer protocol as a payload from a transport layer packet. In another example, policy mechanism 295 'enforces a policy based on any information identified by a client, server or user certificate. In yet another embodiment, policy mechanism 295 'enforces a policy based on any attributes or characteristics obtained on a client 102, such as through any type and form of endpoint detection (see, for example, the agent collection of the client agent discussed below).

In one embodiment, the policy mechanism 295 'works in conjunction or in cooperation with the policy mechanism 295 of the application distribution system 290. In some embodiments, the policy mechanism 295' consists of a distributed portion of the policy mechanism 295 application distribution system 290. In another embodiment, policy mechanism 295 of application distribution system 290 or implemented in tool 200 is implemented. In some embodiments, both policy mechanisms 295 and 295 'operate on tool 200. In yet another embodiment, policy mechanism 295', or a portion thereof, of tool 200 operates on a server 106.

Multiple Protocols or Multiple Layers Compression Mechanism

The compression mechanism 238 includes any logic, business rules, functions or operations that serve to compress one or more protocols of a network packet, such as any protocols used by the network stack 267 of the tool 200. The compression mechanism 238 can also be termed as a multi-protocol compression mechanism 238 where it can be designed, built or capable of compressing a plurality of protocols. In one embodiment, compression mechanism 238 applies context-insensitive compression, and such compression is applied to the data without knowing the data type. In another embodiment, the compression mechanism 238 applies context-sensitive compression. In this modality, the compression mechanism 238 uses the knowledge of the data type to select a specific compression algorithm from a set of suitable algorithms. In some embodiments, knowledge of the specific protocol is used to perform context-sensitive compression. In one embodiment, tool 200 or compaction mechanism 238 can use port numbers (e.g., well-known ports), as well as data from the connection itself to determine the appropriate compaction rate48 that will be used. Some protocols use only a single data type, requiring only a single compression algorithm that can be selected when the connection is established. Other protocols contain different types of data at different times. For example, POP, IMAP, SMTP, and HTTP move files of arbitrary types interspersed with other protocol data.

In one embodiment, compaction mechanism 238 uses a delta-type compaction algorithm. In another embodiment, the compression mechanism 238 uses a first local compression, as well as searching for repeated patterns among the data stored in cache, in memory or disk. In some embodiments, the compression mechanism 238 uses a compression algorithm without data loss. In other embodiments, the compression mechanism uses a data loss compression algorithm. In some cases, knowledge of the data type and, sometimes, the user's permission require the use of a data loss compression algorithm. In some modalities, compression is not limited to the protocol payload. The control fields of the protocol itself can be compacted. In some embodiments, the compaction mechanism 238 uses a different algorithm for control fields than the one used for payload.

In some embodiments, the compaction mechanism 238 compacts in one or more layers of the network stack 267. In one embodiment, the compaction mechanism 238 compacts in a transport layer protocol. In another embodiment, the compression mechanism 238 compresses into an application layer protocol. In some embodiments, the compression mechanism 238 compresses in a layer 2-4 protocol. In other embodiments, the compaction mechanism 238 compacts in a layer 5-7 protocol. In yet another embodiment, the compression mechanism compresses a transport layer protocol and an application layer protocol. In some embodiments, the compression mechanism 238 compresses a layer 2-4 protocol and a layer 5-7 protocol.

In some embodiments, the compression mechanism 238 uses memory-based compression, cache-based compression or disk-based compression or any combination thereof. As such, the compaction mechanism 238 can be termed as a multilayer compaction mechanism. In one embodiment, the compression mechanism 238 uses a history of data stored in memory, such as RAM. In another embodiment, the compression mechanism 238 uses a history of data stored in a cache, such as the processor's L2 cache. In other embodiments, the compression mechanism 238 uses a history of data stored on a disk or storage location. In some embodiments, the compression mechanism 238 uses a hierarchy of historical data based on cache, memory and disk. The compression mechanism 238 can first use the cache-based data to determine one or more data compatibility for compression, and then it can check the memory-based data to determine one or more data compatibility for compression. In another case, the compression mechanism 238 can check disk storage for data compatibility intended for compression after checking the cache and / or memory based data history.

In one embodiment, the multi-protocol compression mechanism 238 compresses, bidirectionally, between clients 102a-102n and servers 106a-106n any protocol based on TCP / IP, including Messaging Application Programming Interface (MAPI) ( email), File Transfer Protocol (FTP), Hypertext Transfer Protocol (HTTP), Internet Common File System (CIFS) protocol (file transfer), Independent Computational Architecture (ICA) protocol, Remote Desktop Protocol (RDP), Wireless Application Protocol (WAP), Mobile IP protocol, and Voice over IP (VolP) protocol. In other modalities, the 238 multi-protocol compression mechanism provides a compression of the

Hypertext Markup (HTML) based on protocols and, in some modalities, provides a compression of any markup languages, such as the Extensible Markup Language (XML). In one embodiment, the multi-protocol compression mechanism 238 provides for compression of any high performance protocol, such as any protocol designed for communications from tool 200 to tool 200. In another embodiment, the 238 multi-protocol compression mechanism compresses any payload or any communication that uses a modified transport control protocol, such as Transaction TCP (T / TCP), TCP with selection confirmations (TCPSACK), TCP with large windows (TCP-LW), a congestion prediction protocol, such as the TCP-Vegas protocol, and a TCP spoofing protocol.

As such, the 238 multi-protocol compression engine can accelerate performance for users accessing applications through desktop clients, for example, Microsoft Outlook and thin clients outside the web, just like any client launched by initiative applications. popular as Oracle, SAP and Siebel, and even mobile customers, such as the Pocket PC. In some embodiments, the multi-protocol compression mechanism, integrating with the packet processing mechanism 240 that accesses network stack 267, is capable of compressing any of the protocols carried by a transport layer protocol, such as any application layer protocol. LAN / WAN detector

The LAN / WAN 238 detector includes any logic, business rules, functions or operations that automatically detect a slow side connection (for example, a wide area network (WAN) connection, such as an intranet) and an associated port 267 , and a fast side connection (for example, a local area network (LAN) connection) and an associated port 267. In some embodiments, the LAN / WAN detector 238 monitors network traffic on network ports 267 of the tool 200 in order to detect a synchronization packet, sometimes referred to as a marked network packet. The synchronization package identifies a type or speed of network traffic. In one embodiment, the synchronization package identifies a WAN speed or WAN connection type. The LAN / WAN detector 238 also identifies the receipt of a confirmation packet to a marked synchronization packet and on which port it is received. Then, tool 200 is configured to operate the identified port on which the marked synchronization packet arrived, in such a way that the speed on this port is adjusted to be the speed associated with the network connected to this port. The other port is then adjusted to the speed associated with the network connected to this port.

For the sake of ease of discussion, reference to the slow side will be made in connection with connecting to a wide area network (WAN), for example, the Internet, and operating at a WAN network speed. Likewise, reference to the quick side will be made in connection with connecting to a local area network (LAN) and operating at a LAN network speed. However, it is noted that the fast and slow sides in a network can change on a per-connection basis and refer to terms of network connection speed or type of network topology. These configurations are useful in complex network topologies, where a network is fast or slow only when compared to adjacent networks and not in any absolute sense.

In one embodiment, the LAN / WAN detector 238 can be used to allow self-discovery by a tool 200 from a network to which it connects. In another embodiment, the LAN / WAN detector 238 can be used to detect the existence or presence of a second tool 200 'implanted in the network 104. For example, a self-discovery mechanism in operation according to figure 1A works as follows; tools 200 and 200 'are placed in line with connection client 102 and server 106. Tools 200 and 200' are at the ends of a low speed connection, for example, Internet, connecting to two LANs. In an exemplary embodiment, tools 200 and 200 'include two ports, one connected to the lower speed connection and the other connected to a higher speed connection, for example, a LAN. Any package that arrives at one port is copied to the other port. Therefore, tools 200 and 200 'are configured to function as a bridge between the two networks 104.

When an endpoint, such as client 102, opens a new TCP connection to another endpoint, such as server 106, client 102 sends a TCP packet with a sync header bit set (SYN), or a SYN packet, to server 106. In the present example, client 102 opens a transport layer connection to server 106. When the SYN packet passes through tool 200, tool 200 inserts, fixes or otherwise provides a characteristic TCP header option to the packet, which announces its presence. If the packet passes through a second tool, in this example tool 200 ', the second tool notes the header option in the SYN packet. Server 106 responds to the SYN packet with a synchronization confirmation packet (SYN-ACK). When the SYN-ACK packet passes through tool 200 ', a TCP header option (for example, pinned, inserted or added) to the SYN-ACK packet is marked in order to announce to tool 200' about the presence of tool 200 When tool 200 receives this packet, both tools 200 and 200 'are now aware and the connection can be accelerated appropriately.

In addition to the operations of the LAN / WAN 238 detector, a method or process is described that serves to detect the fast and slow sides of a network using a SYN packet. During the establishment of a transport layer connection between a client 102 and a server 106, the tool 200 through the LAN / WAN detector 238 determines whether the SYN packet is marked with an acknowledgment (ACK). If checked, tool 200 identifies or configures the port that receives the marked SYN packet (SYN-ACK) as the slow side. In one embodiment, tool 200 optionally removes the ACK mark from the package before copying the package to another port. If the LAN / WAN detector 238 determines that the packet is not marked, the tool 200 identifies or configures the port that receives the unmarked packet as the fast side. Then, tool 200 marks the SYN package with an ACK and copies the package to another port.

In another mode, the LAN / WAN 238 detector detects the fast and slow sides of a network using a SYN-ACK packet. The tool 200 through the LANAVAN 238 detector determines whether the SYNACK packet is marked with an acknowledgment (ACK). If checked, tool 200 identifies or configures the port that receives the marked SYN packet (SYN-ACK) as the slow side. In one embodiment, tool 200 optionally removes the ACK mark from the package before copying the package to another port. If the LAN / WAN detector 238 determines that the packet is not marked, tool 200 identifies and configures the port that receives the unmarked packet as the fast side. The LAN / WAN detector 238 determines whether the SYN packet has been marked. If the SYN package has not been marked, tool 200 copies the package to another port. If the SYN package has been marked, the tool marks the SYN-ACK package before copying it to another port.

The tools 200 and 200 'can add, insert, modify, pin or otherwise provide any information or data in the TCP option header to provide any information, data or characteristics about the network connection, traffic flow, network, or tool 200 configuration or operation. In this way, not only does one tool 200 announce its presence to another tool 200 'or mark a higher or lower speed connection, tool 200 provides additional information and data via the TCP option headers about the tool or connection. The TCP option header information can be useful or used by a tool to control, manage, optimize, accelerate or improve the flow of network traffic that passes through the 200 tool, or otherwise configure or configure the operation of a network port.

Although generally described in conjunction with network connection detection speeds or the presence of tools, the LAN / WAN 238 detector can be used to apply any type of function, logic or operation of tool 200 to a port, connection or network traffic flow. In particular, automated port assignment can occur whenever a device performs different functions on different ports, where assigning a part to a task can be performed during the operation of the unit, and / or the nature of the network segment in each door is discoverable by tool 200.

Flux control

The flow controller 220 includes any logic, business rules, functions or operations that serve to optimize, accelerate or otherwise improve the performance, operation or quality of service of the network packet communication transport layer or the distribution of packets in the transport layer. A flow controller, sometimes referred to as a flow control module, regulates, manages and controls data transfer rates. In some embodiments, the flow controller 220 is deployed or connected to a bandwidth obstacle on network 104. In one embodiment, the flow controller 220 regulates effectively manages and controls the use or utilization of the band. In other modalities, the flow control modules can also be deployed at points in the latency transition network (low latency to high latency) and in connections with media losses (such as wireless or satellite connections).

In some embodiments, a flow controller 220 may include a flow control module on the receiving side that serves to control the rate of receiving network transmissions and a flow control module on the sending side that serves to control the transmission rate network packets. In other embodiments, a first flow controller 220 includes a flow control module on the receiving side and a second flow control module on the sending side. In some embodiments, a first flow controller 220 is implanted in a first tool 200 and a second flow controller 220 'is implanted in a second tool 200'. As such, in some embodiments, a first tool 200 controls the flow of data on the receiving side and a second tool 200 'controls the flow of data from the sending side. In yet another embodiment, a single tool 200 includes flow control for both the receiving side and the sending side of network communications that traverse tool 200.

In one embodiment, a flow control module 220 is configured to allow bandwidth in the obstruction to be more fully utilized, and in some embodiments, not to be overused. In some embodiments, the flow control module 220 temporarily stores (or temporarily restores data already stored, for example, through the sender) the network sessions that pass between the nodes that are associated with the flow control modules 220. When a session passes through two or more flow control modules 220, one or more flow control modules controls a rate of the session (s).

In one embodiment, the flow control module 200 is configured with predetermined data related to bandwidth obstruction. In another embodiment, the flow control module 220 can be configured to detect bandwidth obstruction or the data associated with it. A flow control module on the receiving side 220 can control the data transmission rate. The flow control module on the receiving side 220 controls the flow control module on the sending side, for example, 220, the data transmission rate by passing the transmission rate limits to the flow control module on the sending side. 220. In one embodiment, the flow control module on the receiving side 220 accumulates these transmission rate limits in acknowledgment packets (or signals) (ACK) sent to the sender, for example, client 102, by the receiver, for example, the server 106. The flow control module on the receiving side 220 does this in response to rate control requests that are sent by the flow control module on the sending side 220 '. Requests from the flow control module on the sender side 220 'can be accumulated in data packets sent by the sender 106.

In some embodiments, the flow controller 220 manipulates, adjusts, simulates, changes, improves, or otherwise adapts the behavior of the transport layer protocol to provide improved performance or distribution operations, data rates and / or use of transport layer bandwidth. The flow controller 220 can implement a plurality of data flow control techniques in the transport layer, which include, but are not limited to, 1) pre-confirmations, 2) window virtualization, 3) recongestion techniques, 3 ) local retransmission techniques, 4) wavefront detection and disambiguation, 5) selective transport control protocol confirmations, 6) transaction limit detection techniques and 7) repackaging.

Although a sender can generally be described herein as a client 102 and a receiver as a server 106, a sender can be any endpoint, such as a server 106 or any computing device 100 on network 104. Likewise, a receiver can be a client 102 or any other computing device on the network 104.

Pre-Confirmations

In a brief overview of a pre-confirmation flow control technique, flow controller 220, in some embodiments, manipulates and retransmits to a sender, effectively terminating the sender's connection with the downstream portion of a network connection. Referring to Figure 1B, a possible deployment of a tool 200 in a network architecture to implement this feature is described. In this exemplary environment, a computer or sending client 102 transmits data on the network 104, for example, through a switch, which determines that the data is destined for the VPN tool 205. Due to the chosen network topology, all data destined for the tool VPN 205 traverses tool 200, so tool 200 can apply any necessary algorithms to this data.

Continuing with the example, client 102 transmits a packet, which is received by tool 200. When tool 200 receives the packet, which is transmitted from client 102 to a container via VPN 205 tool, tool 200 retains a copy of the packet and passes the packet downstream to the VPN tool 205. Then tool 200 generates an acknowledgment packet (ACK) and sends the ACK packet back to client 102 or the sending endpoint. This ACK, a pre-confirmation, makes the issuer 102 believe that the package has been successfully distributed, exempting the issuer's resources from subsequent processing. The tool 200 retains the copy of the packet data in the case where a retransmission of the packet is necessary, such that the sender 102 does not have to handle retransmissions of the data. This early generation of confirmations can be called pre-confirmations.

If a retransmission of the packet is required, tool 200 relays the packet to the sender. Tool 200 can determine whether retransmission is necessary, just as an issuer is required in a traditional system, for example, determining that a packet is lost if an acknowledgment has not been received for the packet after a predetermined period of time. In this sense, tool 200 monitors the confirmations generated by the receiving endpoint, for example, server 106 (or any other downstream network entity) in such a way that it can determine whether the packet has been successfully distributed or whether needs to be relayed. If tool 200 determines that the package has been successfully distributed, tool 200 is free to discard saved package data. Tool 200 can also inhibit forwarding of acknowledgments for packets that have already been received by the sending endpoint.

In the embodiment described above, tool 200 through flow controller 220 controls emitter 102 by distributing pre-acknowledgments, also referred to as pre-acknowledgments, as if tool 200 were a receiving endpoint itself. Since tool 200 does not consist of an endpoint and does not actually consume data, tool 200 includes a mechanism that serves to provide overload control at the sending endpoint. Without an overload control, tool 200 may run out of memory because tool 200 stores packets that have been pre-confirmed to the sending endpoint, but have not yet been confirmed as received by the receiving endpoint. Therefore, in a situation where the sender 102 transmits packets to the tool 200 faster than the tool 200 can forward the packets downstream, the memory available in the tool 200 that serves to store unconfirmed packet data can be quickly filled. A mechanism designed to control overload allows tool 200 to control the transmission of packets from emitter 102 in order to avoid this problem.

In one embodiment, tool 200 or flow controller 220 includes an inherently autosynchronized overload control mechanism. This autosynchronization occurs due to the order in which tool 200 can be designed to transmit packets downstream and send ACKs to sender 102 or 106. In some embodiments, tool 200 does not pre-confirm the packet until it transmits the packet downstream . In this way, sender 102 will receive ACKs at the rate at which tool 200 is capable of transmitting packets instead of the rate at which tool 200 receives packets from sender 100. This helps to regulate packet transmission from a sender 102.

Windows Virtualization

Another overload control mechanism that tool 200 can implement is to use the TCP window size parameter, which tells a sender the amount of temporary memory the receiver allows the sender to fill. A non-zero window size (for example, a size of at least a Maximum Segment Size (MSS)) in a pre-commit allows the sending endpoint to continue to distribute data to the tool, while a window size equal to zero inhibits additional data transmission. Consequently, the tool 200 can regulate the flow of packets from the sender, for example, when the buffer 200 of the tool 200 is becoming full, adjusting the window size accordingly.

TCP on each pre-acknowledgment.

Another technique to reduce this additional burden is to apply hysteresis. When tool 200 distributes data to the slower side, the overload control mechanism on tool 200 may require that a minimum amount of space be available before sending a non-zero window advertisement to the sender. In one embodiment, tool 200 waits until there is a minimum of a predetermined number of packages, such as four packages, of available space before sending a non-zero window package, such as a package that indicates a window size of four packages. This can reduce overhead by approximately a factor of four, as only two ACK packets are sent for each group of four data packets, instead of eight ACK packets for four data packets.

Another technique that tool 200 or flow controller 220 can use to control overhead is a delayed TCP ACK mechanism, which omits ACKs in order to reduce network traffic. TCP delayed ACKs automatically delay the sending of an ACK, until two packets are received or until a fixed time interval has occurred. This mechanism alone can result in cutting the overhead in half; in addition, by increasing the number of packages above two, an additional overhead reduction is realized. However, merely slowing down the ACK itself may be insufficient to control the overload, and the tool 200 may also use the window mechanism announced in ACKs in order to control the emitter. When this is done, tool 200 in one mode avoids triggering the transmitter's time slot mechanism by delaying the ACK for a long time.

In one embodiment, flow controller 220 does not pre-confirm the last packet of a packet group. By not confirming the last package, or at least one of the packages in the group, the tool prevents a false confirmation for a group of packages. For example, if the tool does not send a pre-confirmation for a last package and the package is subsequently lost, the sender would be defrauded by assuming that the package is distributed when it is not. Assuming that the package has been distributed, the sender can discard the data. If the tool also loses the package, there may be no more ways to relay the package from the container. If the last package in a package group is not confirmed in advance, the sender will not discard the package until it has been distributed.

In another embodiment, the flow controller 220 may use a window virtualization technique to control the flow rate or bandwidth utilization of a network connection. While it may not be immediately apparent from examining conventional literature, such as RFC 1323, there is an effective send window for transport layer protocols, such as TCP. The sending window is similar to the receiving window, in that it consumes temporary memory space (albeit in the sender). The sending window of the sender consists of all data sent by the application that has not been confirmed by the receiver. This data must be retained in memory in the event that a retransmission is required. Since memory is a shared resource, some TCP stack implementations limit the size of this data. When the upload window is full, an attempt by an application program to send more data results in the application program being blocked until space is available. The subsequent receipt of confirmations will free the sending window memory and unlock the application program. This window size is known as the socket buffer size in some TCP implementations.

In one embodiment, the flow control module 220 is configured to provide access to larger window sizes (or temporary memory). This configuration can also be referred to as window virtualization. In one embodiment, which includes TCP as the transport layer protocol, the TCP header can include a sequence of bits corresponding to a window scale. In one embodiment, the window can be referenced in a context of sending, receiving, or both.

One type of window virtualization is to insert a pre-confirmation tool 200 in a TCP session. In reference to any of the environments of figures 1A or 1B, a data communication session is initiated between a source node, for example, client 102 (for ease of discussion, now called source node 102 ), and a destination node, for example, server 106 (for ease of discussion, now called destination node 106). For TCP communications, source node 102 initially transmits a synchronization signal (SYN) through its local area network 104 to the first flow control module 220. The first flow control module 220 inserts a configuration identifier in the area of TCP header options. The configuration identifier identifies this point in the data path as a flow control module.

The tools 200 through a flow control module 220 provide a window (or temporary memory) to allow increasing temporary data storage capacities in a session despite having endpoints with smaller temporary storage sizes, for example, typically 16k bytes. However, RFC 1323 requires window sizing for any temporary storage sizes larger than 64k bytes, which must be adjusted at the time of the session initialization (SYN, SYN-ACK signals). In addition, window scaling corresponds to the lowest common denominator in the data path, usually an endpoint with a small temporary storage size. This window scale generally consists of a scale of 0 or 1, which corresponds to a temporary storage size of up to 64 k or 128 k bytes. Note that because the window size is defined as the window field in each package moved by the window scale, the window scale establishes an upper limit for temporary storage, however, it does not guarantee that temporary storage is actually so big. Each package indicates the current available temporary storage space at the receiver in the window field.

In a dimensioning modality using a window virtualization technique, during the establishment of the connection (that is, initialization of a session) when the first flow control module 220 receives the SYN signal from the source node 102 ( or package), the flow control module 220 stores the window scale of the source node 102 (which is the previous node) or store a 0 for the window scale if the scale of the previous node is missing. The first flow control module 220 also modifies the scale, for example, increases the scale to 4 from 0 or 1, in the SYN-FCM signal. When the second flow control module 220 receives the SYN signal, it stores the scaled scale from the first flow control signal and resets the scaling on the SYN signal back to the scaling value of the source node 103 for transmission to the target node 106. When the second flow controller 220 receives the SYN-ACK signal from the destination node 106, it stores the scale from the scale of the destination node 106, for example, 0 or 1, and modifies it to an increased scale that is sent next to the SYN-ACK-FCM signal. The first flow control node 220 receives and records the received window scale and reviews the window scale sent back to the source node 102 back to the original scale, for example, 0 or 1. Based on the window change conversation during connection establishment, the window field in all subsequent packets, for example, TCP packet, of the session must be changed according to the window change conversion.

The window scale, as described earlier, expresses temporary storage sizes greater than 64k and may not be necessary for window virtualization. Therefore, changes in the window scale can be used to express the increased temporary storage capacity in each 22G flow control module. This increase in temporary storage capacity can be termed as window virtualization (or temporary storage). The increase in temporary storage size allows for greater packet throughput to and from respective endpoints 102 and

106. It is noted that the temporary storage sizes in TCP are typically expressed in terms of bytes, however, for ease of discussion, packets can be used in the description referring to virtualization.

As an example, a window virtualization (or temporary storage) performed by flow controller 220 is described. In this example, the source node 102 and the destination node 106 are configured similarly to conventional endpoints having a limited 16k bytes temporary storage capacity, which equals approximately 10 data packets. Typically, an endpoint 102, 106 must wait until the packet is transmitted and an acknowledgment is received before a next group of packets can be received. In one embodiment, using an increased temporary storage capacity in the flow control modules 220, when the originating node 103 transmits its data packets, the first flow control module 220 receives the packets, stores them in its storage higher capacity temporary, for example, capacity of 512 packets, and immediately sends back a confirmation signal indicating receipt of the packets (REC-ACK) back to origin node 102. The source node 102 can then empty its current buffer, load the buffer with 10 new data packets, and transmit it to the first flow control module 220. Again, the first flow control module 220 transmits a REC-ACK signal back to source node 102 and source node 102 empties its temporary storage and loads it with 10 more new packets for transmission.

As the first flow control module 220 receives the data packets from the originating nodes, consequently, it loads its temporary storage. When it is ready, the first flow control module 220 can begin transmitting the data packets to the second flow control module 230, which also has an increased size of temporary storage, for example, to receive 512 packets. The second flow control module 220 'receives the data packets and begins transmitting 10 packets at a time to the destination node 106. Each REC-ACK received at the second flow control node 220 from the destination node 106 results 10 more packets being transmitted to destination node 106 until all data packets are transferred. Therefore, the present invention is capable of increasing the data transmission throughput between the source node (sender) 102 and the destination node (receiver) 106 by taking advantage of the larger temporary storage in the flow control modules 220 and 220 'between devices.

It is noted that by confirming the data transmission in advance as previously described, an emitter (or source node 102) is allowed to transmit more data than is possible without the pre-confirmations, thus affecting a larger window size. For example, in one embodiment, this technique is effective when the flow control module 220, 220 'is located close to a node (for example, source node 102 or destination node 106) that is devoid of large windows. Reconquesting

Another technique or algorithm for flow controller 220 is termed recongestion. Standard TCP congestion containment algorithms are known to work poorly under certain network conditions, which include: long RTTs (round trip times), high packet loss rates, and others. When tool 200 detects a congestion condition, such as long round trip times or high packet loss, tool 200 intervenes, replacing a congestion containment algorithm that best suits the particular network condition. In one embodiment, the recongestion algorithm uses pre-confirmations to effectively end the connection between the sender and the receiver. Then, the tool 200 resends the packets from itself to the receiver, using a different congestion containment algorithm. Recongestion algorithms may depend on the characteristics of the TCP connection. Tool 200 monitors each TCP connection, characterizing it in relation to different dimensions, selecting a recongestion algorithm that is appropriate for the current characterization.

In one mode, by detecting a TCP connection that is limited by round trip times (RTT), a recongestion algorithm that behaves like multiple TCP connections is applied. Each TCP connection operates at its own performance threshold, however, the aggregate bandwidth achieves a higher level of performance. A parameter in this mechanism is the number of parallel connections that are applied (N). A very large N value and a packet of connections reach their fair share of bandwidth. A very small value of N and a packet of connections reach less than their fair share of bandwidth. One method of establishing N depends on the tool 200 that monitors the packet loss rate, RTT, and the packet size of the current connection. These numbers are applied to a response curve formula that serves to provide an upper limit on the performance of a single TCP connection in the present configuration. If each connection in the connection pack is achieving substantially the same computer performance as the upper limit, then additional parallel connections apply. If the current packet is achieving a performance lower than the upper limit, the number of parallel connections is reduced. In this way, the general clarity of the system is maintained as long as the individual connection packets do not contain more parallelism than is necessary to eliminate the restrictions imposed by the protocol itself. In addition, each individual connection retains TCP compliance.

Another method of establishing ”N is to use a parallel flow control algorithm, such as the TCP Vegas algorithm or the Stabilized TCP Vegas algorithm. In this method, the network information associated with connections in the connection packet (for example, RTT, loss of rate, average packet size, etc.) is aggregated and applied to the alternate flow control algorithm. The results of this algorithm are successively distributed among the connections of the packet by controlling its number (that is, N). Optionally, each connection in the packet continues to use the standard TCP congestion containment algorithm.

In another embodiment, the individual connections in a parallel packet are virtualized, that is, the current individual TCP connections are not established. In addition, the congestion containment algorithm is modified in order to behave as if there are N parallel connections. This method has the advantage of appearing to transit network nodes as a single connection. Therefore, QOS, security and other monitoring methods are not affected by the recongestion algorithm. In yet another modality, the individual connections in a parallel packet are real, that is, a separate TCP connection is established for each of the parallel connections in a packet. The congestion containment algorithm for each TCP connection does not need to be modified. Relay

In some embodiments, the flow controller 220 may apply a local relay technique. One reason that pre-confirmations are implemented is to prepare to transition over a high loss connection (for example, wireless). In these embodiments, the preconfirmation tool 200 or flow control module 220 is most beneficially located prior to the wireless connection. This allows retransmissions to be carried out closer to the high-loss connection, removing the relay charge from the rest of the network. Tool 200 can provide local retransmission, in which case packets lost due to connection failures are directly retransmitted by tool 200. This is advantageous because it eliminates the burden of retransmission through an endpoint, such as server 106, and infrastructure. any of the networks 104. With tool 200 providing local retransmissions, the lost packet can be retransmitted via the high loss link without the need for retransmission by an endpoint and a corresponding reduction in the data transmission rate from the endpoint.

Another reason for implementing pre-confirmations is to avoid a receipt interval penalty (RTO). In standard TCP, there are many situations that result in an RTO, although a large percentage of packets in flight have been successfully received. With standard TCP algorithms, the loss of more than one packet in an RTT window is likely to result in an interval. In addition, most TCP connections experience an interval if a retransmitted packet is lost. In a network with a high bandwidth delay product, even a relatively small packet loss rate will cause frequent Retransmission intervals (RTOs). In one embodiment, tool 200 uses retransmission and an interval algorithm is avoided before RTOs. Tool 200 or flow controller 220 maintains a count of retransmissions on a per packet basis. Each time a packet is retransmitted, the count is incremented by one and the tool 200 continues to transmit packets. In some embodiments, only if a packet has been retransmitted, a predetermined number of times consists of a declared RTO.

Wavefront Detection and Disambiguation

In some embodiments, tool 200 or flow controller 220 uses wavefront detection and disambiguation techniques to manage and control the flow of network traffic. In this technique, flow controller 220 uses transmission identifiers or numbers to determine whether particular data packets need to be retransmitted. As an example, a sender transmits data packets over a network, where each example of a transmitted data packet is associated with a transmission number. It can be assessed that the transmission number for a packet is not the same as the sequence number of the packet, since a sequence number refers to the data in the packet while the transmission number refers to a case of such transmission Dice. The transmission number can be any information suitable for this purpose, including a time stamp associated with a package or simply an increasing number (similar to a sequence number or a package number). Because a data segment can be retransmitted, different transmission numbers can be associated with a particular sequence number.

As the sender transmits data packets, the sender maintains a data structure for confirmed cases of data packet transmissions. Each case of a packet data transmission is referenced by its sequence number and its transmission number. Keeping a transmission number for each packet, the sender retains the transmission order of the data packets. When the sender receives an ACK or a SACK, the sender determines the highest number of transmissions associated with the packets that the receiver has indicated have arrived (in the confirmation received). Any considerably unconfirmed packets with lower transmission numbers are assumed to be lost.

In some embodiments, the sender is presented with an ambiguous situation when the arrival packet has been retransmitted: a standard ACK / SACK does not contain enough information to allow the sender to determine which transmission of the arrival packet has triggered the conformation. After receiving an ambiguous confirmation, therefore, the sender disambiguates the confirmation in order to associate itself with a transmission number. In several modalities, one technique or a combination of several techniques can be used to resolve this ambiguity.

In one embodiment, the sender includes an identifier with a transmitted data packet, and the receiver returns to the identifier, or a function thereof, an acknowledgment. The identifier can be a timestamp (for example, a TCP timestamp as described in RFC 1323), a sequential number, or any other information that can be used to resolve between two or more transmission cases. a package. In a modality in which the TCP timestamp option is used to disambiguate the confirmation, each packet is marked with up to 32-bits of exclusive information. Upon receipt of the data packet, the receiver reverberates this unique information back to the sender with confirmation. The issuer guarantees that the originally sent package and its version or versions retransmitted contain values ​​for the timestamp option, allowing it to unambiguously eliminate the ACK ambiguity. The sender can keep this unique information, for example, in the data structure in which the status of the sent data packets is stored. This technique is advantageous because it conforms to industry standards and, therefore, it is more likely that small problems or no interoperability problems will be encountered. However, this technique may require ten bytes of TCP header space in some implementations, reducing the effective rate of throughput on the network and reducing the space available for other TCP options.

In another embodiment, another field in the packet, such as the IP ID field, is used to disambiguate in a similar way to the TCP timestamp option described earlier. The sender has the version ID field values ​​or original and retransmitted versions of the packet so that they have different ID fields in the IP header. Upon receipt of the data packet at the receiver, or at a proxy device therein, the receiver sets the ACK packet ID field to a function of the packet ID field that triggers the ACK. This method is advantageous, as it does not require additional data to be sent, preserving the efficiency of the network and the TCP header space. The chosen role must provide a high degree of probability to provide disambiguation. In a preferred mode, the sender selects the IP ID values ​​with the most significant bit set to 0. When the receiver responds, the IP ID value is set to the same IP ID value with the most significant bit set to one.

In another embodiment, the transmission numbers associated with unambiguous confirmations are used to disambiguate an ambiguous confirmation. This technique is based on the principle that confirmations for two packets will tend to be received closer together in time as the packets are transmitted closer together in time. Packets that are not retransmitted will not result in ambiguity, as confirmations received for those packets can be readily associated with a transmission number. Therefore, these known transmission numbers are compared to the possible transmission numbers for an ambiguous acknowledgment received close in time to the known acknowledgment. The sender compares the transmission numbers of the ambiguous confirmation against the last known received transmission number, selecting the number closest to the known received transmission number. For example, if an acknowledgment for a data packet 1 is received and the last acknowledgment received is for data packet 5, the sender resolves the ambiguity by assuming that the third case of data packet 1 induced the acknowledgment.

Selective Confirmations

Another technique of tool 200 or flow controller 220 is to implement a mode of selective confirmation of transport control protocol, or TCP SACK, in order to determine which packets were or were not received. This technique allows the sender to unambiguously determine a list of packets that have been received by the receiver, as well as an accurate list of packets not received. This functionality can be implemented by modifying the emitter and / or receiver, or by inserting flow control modules on the side of the emitter and receiver 220 in the network path between the emitter and receiver. With reference to figure 1A or figure 1B, a sender, for example, client 102, is configured to transmit data packets to the receiver, for example, server 106, over network 104. In response, the receiver returns a Selective TCP Confirmation option, referred to as the SACK packet, to the sender. In one embodiment, communication is bidirectional, although only one direction of communication is discussed in this document for the sake of simplicity. The receiver maintains a list, or other suitable data structure, that contains a group of ranges of sequence numbers for the data packets that the receiver actually received. In some embodiments, the list is ordered by sequence number in ascending or descending order. The receiver also maintains a cursor on the left, which comprises a reference in the list and indicates the cursor on the left from the previously generated SACK packet.

Upon receipt of a data packet, the receiver generates and transmits a SACK packet back to the sender. In some embodiments, the SACK packet includes a series of fields, each of which can maintain a range of sequence numbers to indicate a set of received data packets. The receiver fills the first field of the SACK packet with a range of sequence numbers that includes the arrival packet that triggered the SACK packet. The remaining available SACK fields are filled with ranges of sequence numbers from the list of received packets. Since there are more tracks in the list than can be loaded into the SACK package, the receiver uses the cursor on the left to determine which tracks are loaded into the SACK package. The receiver inserts the SACK ranges consecutively from the ordered list, starting from the range named by the cursor and continuing through the list until the available SACK range space in the TCP header of the SACK packet is consumed. The receiver extends around the beginning of the list if it reaches the end. In some modes, two or three additional SACK tracks can be added to the SACK track information.

Once the receiver generates the SACK packet, the receiver sends the conformation back to the sender. The receiver then advances the cursor on the left through one or more SACK track entries in the list. If the receiver inserts four SACK tracks, for example, the cursor on the left can advance two SACK tracks in the list. When the cursor on the leading left reaches the end of the list, the cursor is reset to the beginning of the list, effectively extending around the list of known received tracks. The act of extending around the list allows the system to function well, even in the presence of large losses of SACK packets, since information that has not been communicated due to a lost SACK packet will communicate effectively, since the list is extended around.

It can therefore be assessed that a SACK package can communicate various details about the condition of the receiver. First, the SACK packet indicates that, upon generation of the SACK packet, the receiver has just received a data packet which is in the first field of the SACK information. Second, the second field and the subsequent field of the SACK information indicate that the receiver has received the data packets in these ranges. The SACK information also implies that the receiver, at the time of generating the SACK packet, did not receive any of the data packets that are between the second field and the subsequent field of the SACK information. In essence, the bands between the second and subsequent tracks in the information are holes in the received data, and the data in them is known to have not been distributed. Using this method, therefore, when a SACK packet has enough space to include more than two SACK tracks, the receiver can indicate to the sender a range of data packets that have not yet been received by the receiver.

In another embodiment, the sender uses the SACK packet described above in combination with the retransmission technique described earlier, which serves to make assumptions about which data packets were distributed to the receiver. For example, when the retransmission algorithm (using transmission numbers) declares a packet loss, the sender considers that the packet is only conditionally lost, as it is possible that the SACK packet that identifies the reception of this packet is lost rather than the data package itself. Therefore, the issuer adds this package to a list of potentially lost packages, called a supposedly lost list. Each time a SACK packet arrives, the known missing data strips from the SACK packet are compared to the packets in the supposedly lost list. Packets containing known data to be missing are currently declared lost and are subsequently retransmitted. In this way, the two schemes are combined in order to provide the sender with better information about which packets have been lost and which need to be retransmitted

Detection of Transaction Limits

In some embodiments, tool 200 or flow controller 220 applies a technique referred to as transaction limit detection. In one embodiment, the technique belongs to the ping-pong behavior connections. In the TCP layer, ping-pong behavior occurs when one communicator - a sender - sends data and then a73 keeps it for a response from the other communicator - the receiver. Examples of ping-pong behavior include remote procedure calls, HTTP and others. The previously described algorithms use a retransmission interval (RTO) to recover from the loss of the last packet or packets associated with the transaction. Since the TCP RTO mechanism is extremely thick in some modalities, for example, requiring at least a second value in all cases), weak application behavior can be observed in these situations.

In one embodiment, the data issuer or a flow control module 220 coupled to the issuer detects a transaction limit in the data being sent. Upon detection of a transaction limit, the sender or a flow control module 220 sends additional packets, the reception of which generates additional ACK or SACK responses from the receiver. The insertion of additional packages is preferably limited in order to balance between the improved response time of the application and the use of network capacity. The number of additional packets that are inserted can be selected according to the current loss rate associated with this connection, with more packets selected for connections having a higher loss rate.

One method of detecting a transaction limit is based on time. If the sender is sending data and stops, then, after a period of time, the sender or flow control module 200 declares a transaction limit. This can be combined with other techniques. For example, the setting of the PSH (TCP Push) bit by the sender in the TCP header may indicate a transaction limit. Consequently, combining the time-based approach with these additional heuristics can provide more accurate detection of a transaction threshold. In another technique, if the issuer or flow control module 220 understands the application protocol, the protocol data flow can be parsed and the transaction limits directly determined. In some embodiments, the latter behavior can be used independently of any time-based mechanisms.

In response to the detection of a transaction boundary, the sender or flow control module 220 transmits additional data packets to the receiver in order to perform confirmations from them. The additional data packets must therefore be such that the receiver generates only one ACK or SACK in response to receiving the data packet. In one embodiment, the last package or packages in the transaction are simply retransmitted. This has the added benefit of relaying the necessary data if the last packet or packets are lost, compared to the mere sending of simulated data packets. In another modality, the fractions of the last package or packages are sent, allowing the sender to disambiguate the arrival of these packages from their original packages. This allows the receiver to avoid falsely confusing any chord adaptation algorithms. In another embodiment, a series of well-known error correction techniques can be used to generate additional data for the inserted packages, allowing a reconstruction of lost or otherwise missing data at the receiver.

In some embodiments, the limit detection technique described in this document helps to avoid an interval when confirmations for the last data packets in a transaction are lost. When the sender or flow control module 220 receives acknowledgments for these additional data packets, the sender can determine from these additional acknowledgments whether the last data packets have been received or whether they need to be retransmitted, thereby avoiding an interval. In one embodiment, if the last packets are received, however, their confirmations are lost, a flow control module 220 generates an acknowledgment for the data packets and sends the acknowledgment to the sender, thereby communicating to the sender that the packets of data were distributed. In another embodiment, if the last packets are not received, a flow control module 200 sends a packet to the sender in order to induce a retransmission of the lost data packets.

Repackaging

In yet another embodiment, tool 200 or flow controller 220 applies a repackaging technique that serves to optimize the flow of network traffic from the transport layer. In some embodiments, TCP performance is proportional to the packet size. Therefore, increasing packet sizes improves performance unless it causes substantially increased packet loss rates or other non-linear effects, such as IP fragmentation. In general, wired media (such as copper or optical fibers) have extremely low bit error rates, so low that they can be ignored. For these media, it is advantageous that the packet size is as much as possible before fragmentation occurs (the maximum packet size is limited by the underlying transmission media protocols). While for transmission media with higher loss rates (for example, wireless technologies, such as WiFi, etc., or high-loss environments, such as power line networks, etc.), the increase in packet size can lead to lower transmission rates, as errors induced by media cause the entire packet to be lost (that is, errors induced by media beyond the capacity of the standard error correction code for such media), increasing the rate packet loss. A sufficiently large increase in the packet loss rate will actually negate any performance benefit from increasing packet sizes. In some cases, it may be difficult for a TCP endpoint to choose an optimal packet size. For example, the optimal packet size may vary along the transmission path, depending on the nature of each connection.

By inserting a tool 200 or flow control module 220 in the transmission path, the flow controller 220 monitors the characteristics of the connection and repackages according to certain connection characteristics. In one embodiment, a tool 200 or flow controller 220 repackages the packets with sequential data into a smaller number of larger packets. In another embodiment, a tool 200 or flow controller 220 repackages the packets by corrupting part of a sequence of large packets into a larger number of smaller packets. In other embodiments, a tool 200 or flow controller 220 monitors connection characteristics and adjusts packet sizes through recombination in order to optimize performance.

QoS

Referring also to figure 2A, the flow controller 220, in some modalities, may include a QoS Mechanism 236, also known as a QoS controller. In another modality, the tool 200 and / or the network optimization mechanism 250 include the QoS mechanism 236, for example, separately, however, in communication with the flow controller 220. The QoS Mechanism 236 includes any logic, business rules, functions or operations that serve to perform one or more Quality of Service (QoS) techniques that improve the performance, operation or quality of service of any network connections. In some embodiments, the QoS 236 engine includes network traffic control and management mechanisms that provide different priorities for different users, applications, data flows or connections. In other modalities, the QoS 236 mechanism controls, maintains or guarantees a certain level of performance to a user, application, data flow or connection. In one embodiment, the QoS 236 engine controls, maintains or guarantees a certain portion of the bandwidth or network capacity for a user, application, data flow or connection. In some modalities, the QoS 236 engine monitors the level of performance or quality of service corresponding to a user, application, data flow or connection, for example, data rate and delay. In response to monitoring the QoS 236 engine, it controls or dynamically adjusts network packet scheduling priorities in order to achieve the desired level of performance or quality of service.

In some modalities, the QoS 236 mechanism prioritizes, schedules and transmits network packets according to one or more classes or service levels. In some modalities, the class or level of service may include: 1) best efforts, 2) controlled load, 3) guaranteed or 4) qualitative. For a class of service with better efforts, the tool

200 makes a reasonable effort to distribute packages (a standard service level). For a load controlled class of service, tool 200 or QoS mechanism 236 approaches the loss of standard packet errors from the transmission medium or approaches best effort service behavior in lightly loaded network conditions. For a guaranteed class of service, tool 200 or QoS mechanism 236 guarantees the ability to transmit data at a certain rate for the duration of the connection. For a qualitative class of service, tool 200 or QoS mechanism 236, the qualitative class of service is used for applications, users, data flows or connections that need or want priority traffic, but cannot quantify resource needs or service level. In such cases, tool 200 or QoS 236 engine determines the class of service or priority based on any logic or configuration of the QoS 236 engine or based on business or political rules. For example, in one embodiment, the QoS 236 mechanism prioritizes, schedules and transmits network packets according to one or more policies as specified by policy mechanism 295, 295 '.

Protocol Acceleration

The 234 protocol accelerator includes any logic, business rules, functions for optimization, acceleration, or otherwise improving the performance, operations or quality of service of one or more protocols. In one embodiment, protocol accelerator 234 accelerates any layer protocol or protocols in layers 5-7 of the network stack. In other embodiments, the protocol accelerator 234 accelerates a transport layer or a layer 4 protocol. In one embodiment, the protocol accelerator 234 accelerates layer 2 or layer 3 protocols. In some embodiments, the protocol accelerator 234 is configured, built or designed to optimize or accelerate one or more protocols according to the type of data, characteristics and / or behavior of the protocol. In another embodiment, the protocol accelerator 234 is configured, built or designed to enhance a user's experience, response times, network or computational load, and / or network usage or bandwidth over a protocol.

In one embodiment, the 234 protocol accelerator is configured, built or designed to minimize the effect of WAN latency on file system access. In some modalities, the 234 protocol accelerator optimizes or accelerates the use of the Internet Common File System (CIFS) protocol in order to improve file system access times or data and file access times. In some modalities, the protocol accelerator 234 optimizes or accelerates the use of the NFS protocol (Network File System). In another modality, the protocol accelerator 234 optimizes the use of the File Transfer (FTP) protocol.

In one embodiment, the protocol accelerator 234 is configured, built or designed to optimize or accelerate a protocol that transports as a payload or uses any type and form of markup language. In other modalities, the protocol accelerator 234 is configured, built or designed to optimize or accelerate a Hypertext Transfer Protocol (HTTP). In another modality, the protocol accelerator 234 is configured, built or designed to optimize or accelerate a protocol that it carries as a payload or, otherwise, uses XML (Extensible Markup Language).

Transparency Settings and Multiple Deployments

In some embodiments, the tool 200 and / or the network optimization mechanism 250 are transparent to any data flowing through a network connection or link, such as a WAN link. In one embodiment, the tool 200 and / or the network optimization mechanism 250 operate in such a way that the data flow across the WAN is recognizable by any network monitoring, QOS management or network analysis tools. In some embodiments, the tool 200 and / or the network optimization mechanism 250 do not create tunnels or flows for data transmission that can hide, hide or otherwise make the network traffic non-transparent. In other modalities, fer79 ramenta 200 operates transparently, where the tool does not change any of the source and / or destination address information or port information of a network packet, such as internet protocol addresses or network numbers. door. In other modalities, the tool 200 and / or the network optimization mechanism 250 is considered to operate or behave, transparently, to the network, an application, client, server or other tools or computational device in the network infrastructure. That is, in some modalities, the tool is transparent where the network-related configuration of any device or tool on the network does not need to be modified in order to support the tool 200.

Tool 200 can be deployed in any of the deployment configurations: 1) in-line traffic, 2) in proxy mode, or 3) in a virtual in-line mode. In some embodiments, the tool 200 may be deployed online in one or more of the following: a router, a client, a server or another device or network tool. In other embodiments, tool 200 may be deployed in parallel on one or more of the following: a router, a client, a server or another device or network tool. In parallel deployments, a client, server, router or other network tool can be configured to pass on, transfer or transition networks to or through the 200 tool.

In an online mode, tool 200 is deployed online with a WAN connection from a router. In this way, all traffic from the WAN passes through the tool before reaching a destination on a LAN.

In the form of a proxy mode, tool 200 is deployed as a proxy device between a client and a server. In some embodiments, Tool 200 allows customers to make indirect connections to a resource on a network. For example, a client connects to a resource through tool 200, and the tool provides the resource by connecting to the resource, a different resource, or by serving the resource from a cache. In some cases, the tool can change the client request or server response for several purposes, such as, for any optimization techniques discussed in this document. In one embodiment, client 102 sends requests assigned to the proxy. In one case, the proxy responds to the client rather than acting as a 106 server. In other modalities, tool 200 behaves like a transparent proxy, intercepting and passing on, in a transparent way, requests and responses to a client and / or server. Without a client-side configuration, the tool 200 can redirect client requests to different servers or networks. In some embodiments, tool 200 can perform any type and form of network address translation, referred to as NAT, or any network traffic that passes through the tool.

In some embodiments, tool 200 is deployed in an online virtual mode configuration. In this modality, a router or a network device with routing or switching functionality is configured in order to forward, re-route or otherwise provide network packets destined for a network to the tool 200. Then, the tool 200 performs any processing network packets, such as any WAN optimization techniques discussed in this document. Upon completion of processing, tool 200 forwards the processed network packet to the router in order to transmit it to the destination on the network. In this way, tool 200 can be coupled to the router in parallel, however, operate as such if tool 200 is in line. This deployment mode also provides transparency where source and destination addresses and port information are preserved as the packet is processed and transmitted over the network.

Endpoint Deployment

Although the network optimization mechanism 250 is, in general, described previously in conjunction with a tool 200, the network optimization mechanism 250, or any portion thereof, can be deployed, distributed or otherwise operated at any time. endpoint, such as a client 102 and / or a server 106. As such, a client or server can provide any of the systems and methods of the network optimization mechanism 250 described herein in conjunction with one or more tools 200 or without a tool 200.

Referring now to Figure 2B, an exemplary modality of the network optimization mechanism 250 deployed on one or more endpoints is described. In a brief overview, client 102 can include a first network optimization engine 250 'and server 106 can include a second network optimization engine 250. Client 102 and server 106 can establish a transport connection layer and exchange communications whether or not they cross a 200 tool.

In one embodiment, the network optimization mechanism 250 'of client 102 performs the techniques described in this document for the purpose of optimizing, accelerating or, otherwise, improving the performance, operation or quality of service of the network traffic communicated with server 106. In another embodiment, the network optimization mechanism 250 of the server 106 performs the techniques described in this document in order to optimize, accelerate or otherwise improve the performance, operation or quality of service of the network traffic communicated with the customer 102. In some embodiments, the network optimization mechanism 250 'of the client 102 and the network optimization mechanism 250 of the server 106 carry out the techniques described in this document for the purpose of optimizing, accelerating or otherwise improving performance, operation or quality of service of the network traffic communicated between client 102 and server 106. In yet another modality, the network optimization mechanism 250 'of client 102 performs the techniques described in this document in line with a tool 200 for the purpose of optimizing, accelerating or, otherwise, improving the performance, operation or quality of network traffic service communicated with the client 102. In yet another modality, the network optimization mechanism 250 of the server 106 performs the techniques described in this document in line with a tool 200 for the purpose of optimizing, accelerating or, otherwise, improving performance, operation or quality of service network traffic communicated with server 106.

C. Client agent

As illustrated in figures 2A and 2B, a client deployed in the system or with a 200 or 205 tool can include a client agent 120. In one embodiment, the client agent 120 is used to facilitate communications with one or more tools 200 or 205. In some embodiments, any of the 200 or 205 tool systems and methods described in this document can be deployed, implemented or incorporated into a client, such as through a client agent 120. In other embodiments, client agent 120 may include applications, programs or agents that provide additional functionality, such as endpoint detection and authorization, virtual private network connectivity and application streaming. Before discussing other modalities of the systems and methods of tool 200, the modalities of client agent 120 will be described.

Referring now to Figure 3, a modality of a client agent 120 is shown. Client 102 has a client agent 120 to establish, exchange, manage or control communications with tool 200, tool 205 and / or server 106 over a network 104. In some embodiments, client agent 120, which can also be referred to as a WAN client, it speeds up WAN network communications and / or be used to communicate through Tool 200 on a network. In a brief overview, client 102 operates on computational device 100 which has an operating system with a kernel mode 302 and a user mode 303 and a network stack 267 with one or more layers 310a-310b. Client 102 may have installed and / or run one or more applications. In some embodiments, one or more applications can communicate over network stack 267 to network 104. One of the applications, such as a web browser, can also include a first 322 program. For example, the first program 322 can be used in some ways to install and / or run client agent 120, or any part thereof. Client agent 120 includes an interception mechanism or interceptor 350, to intercept network communications from network stack 267 of one or more applications.

As with tool 200, the client has a network stack 267 that includes any type and form of software, hardware, or any combination of these, to provide connectivity and communications with a network 104. Client network stack 267 includes any one of the network stack modes described above in conjunction with tool 200. In some embodiments, the client agent 120, or any part thereof, is designed and built to operate or function in conjunction with the network stack 267 installed or otherwise provided by the client's operating system 102.

In additional detail, the client's network stack 267 102 or tool 200 (or 205) may include any type and form of interfaces for receiving, obtaining, providing, or otherwise accessing any information and data related to the client's network communications. client 102. In one embodiment, an interface to the network stack 267 includes an application programming interface (API). The interface can also have any function call, hook or filter mechanism, event or callback, or any type of interface technique. The network stack 267 through the interface can receive or provide any type and form of data structure, such as an object related to the functionality or operation of the network stack 267. For example, the data structure can include information and related data to a network packet or one or more network packets. In some embodiments, the data structure includes references or identifies a portion of the network packet processed in a protocol layer of the network stack 267, such as a transport layer network packet. In some embodiments, data structure 325 is a kernel-level data structure, while in other embodiments, data structure 325 is a user-mode data structure. A kernel-level data structure can have a data structure obtained from or related to a part of the network stack 267 that operates in kernel mode 302, or a network driver or other software that runs in kernel mode 302, or any structure of data obtained or received through a service, process, task, chain, or other executable instructions that execute or operate in the operating system's kernel mode.

In addition, some parts of the network stack 267 may run or operate in kernel mode 302, for example, the data link or network path, while other parts run or operate in user mode 303, such as a layer application network stack 267. For example, a first part 310a of the network stack can provide user mode access to network stack 267 in an application while a second part 310a of network stack 267 provides access to a network. In some embodiments, a first portion 310a of the network stack has one or more upper layers of the network stack 267, such as any of layers 5 through 7. In other embodiments, the second part 310b of the network stack 267 includes a or more lower layers, such as any of layers 1 to 4. Each of the first part 310a and second part 310b of the network stack 267 may include any part of the network stack 267, in any one or more network layers, in user mode 303, kernel mode, 302, or combinations thereof, or anywhere on a network layer or interface point on a network layer or any part or interface point for user mode 302 and kernel mode 203.

The interceptor 350 can include software, hardware, or any combination of software and hardware. In one embodiment, interceptor 350 intercepts or otherwise receives a network communication anywhere on the network stack 267, and redirects or transmits the network communication to a desired destination, managed or controlled by interceptor 350 or client agent 120. For example, interceptor 350 can intercept network communication from a network stack 267 of a first network and transmit network communication to tool 200 for transmission on a second network 104. In some embodiments, interceptor 350 includes or is a driver, just like a network driver built and designed to interface and work with the 267 network stack. In some embodiments, the client agent 120 and / or interceptor 350 operates on one or more layers of the network stack 267, such as the transport layer. In one embodiment, interceptor 350 includes a filter driver, hook mechanism, or any form and type of suitable network driver interface that interfaces with the transport layer of the network stack, such as through the driver interface of transport (TDI). In some embodiments, interceptor 350 interfaces with a first protocol layer, such as the transport layer and another protocol layer, such as any layer above the protocol transport layer, for example, a protocol layer app. In one embodiment, interceptor 350 includes a driver that meets the Network Driver Interface Specification (NDIS), or an NDIS driver. In another embodiment, the interceptor 350 can be a minifilter or miniport driver. In one embodiment, interceptor 350, or part of it, operates in kernel mode 202. In another embodiment, interceptor 350, or part of it, operates in user mode 203. In some embodiments, a part of interceptor 350 operates in kernel mode. 202, while the other part of interceptor 350 operates in user mode 203. In other modalities, client agent 120 operates in user mode 203, however, interfaces through interceptor 350 in a kernel-mode driver, process, service, task or part of the operating system, such as obtaining a data structure kernel level 225. In the additional modalities, interceptor 350 is a user mode application or program, such as an application.

In one embodiment, interceptor 350 intercepts or receives any transport layer connection requests. In these embodiments, interceptor 350 performs transport layer application programming interface (API) calls to configure destination information, such as destination address and / or IP port at a desired location for location. In this way, interceptor 350 intercepts and redirects the transport layer connection to an IP address and port controlled and managed by interceptor 350 or client agent 120. In one embodiment, interceptor 350 configures the destination information for the connection to a client IP address and local port 102 where client agent 120 is listening. For example, client agent 120 may comprise a proxy service that listens on a local IP address and port for redirected transport layer communications. In some modalities, the client agent 120 then communicates the transport layer communication redirected to the tool 200. In some modalities, the interceptor 350 intercepts a Domain Name Service (DNS) request. In one embodiment, client agent 120 and / or interceptor 350 resolves the DNS request. In another embodiment, the interceptor transmits the intercepted DNS request to tool 200 for DNS resolution. In one embodiment, tool 200 resolves the DNS request and communicates the DNS response to client agent 120. In some embodiments, tool 200 resolves the DNS request through another tool 200 'or a DNS server 106.

In yet another embodiment, the client agent 120 may include two agents 120 and 120 '. In one embodiment, a first agent 120 may include an interceptor 350 that operates at the network layer of network stack 267. In some embodiments, the first agent 120 intercepts network layer requests, such as Message Protocol requests Internet Control (ICMP) (for example, ping and traceroute). In other embodiments, the second agent 120 'can operate at the transport layer and intercept the communications transport layer. In some embodiments, the first agent 120 intercepts communications at a layer of the network stack 210 and interfaces or communicates the intercepted communication to the second agent 120 '.

The client agent 120 and / or interceptor 350 can operate or interface with a protocol layer, in a transparent manner, with any other protocol layer of the network stack 267. For example, in one embodiment, interceptor 350 operates or interfaces with the transport layer of network stack 267, transparently, in any protocol layer below the transport layer, such as the network layer, and any protocol layer above the transport layer, such as session, presentation, or application layer protocols. This allows the other protocol layer of the network stack 267 to operate as desired and without modification to use interceptor 350. As such, client agent 120 and / or interceptor 350 interfaces or operates at the transport layer level to maintain , optimize, accelerate, route or load balance any communications provided through any protocol carried by the transport layer, such as any application layer protocol over TCP / IP.

In addition, client agent 120 and / or interceptor 350 can operate or interface with network stack 267 transparently in any application, a client user 102, client 102 and / or any other computing device 100, such as a server or tool 200, 206, in communications with client 102. Client agent 120, or any part thereof, can be installed and / or run on client 102 in a manner without modifying an application. In one embodiment, client agent 120, or any part thereof, is installed and / or executed transparently in any network configuration of client 102, tool 200, 205 or server 106. In some embodiments, client agent 120, or any part thereof, is installed and / or modified with any network configuration of client 102, tool 200, 205 or server 106. In one embodiment, the user of client 102 or a computing device in communications with client 102 is not aware of the existence, execution or operation of client agent 12, or any part thereof. As such, in some embodiments, client agent 120 and / or interceptor 350 is installed, executed and / or operated, transparently, in an application, client user 102, client 102, another computing device, such as a server or tool 200, 2005, or any of the protocol layers above and / or below the protocol layer that interfaces with interceptor 350.

Client agent 120 includes a streaming client 306, a collection agent 304, SSL VPN agent 308, a network optimization mechanism 250, and / or an acceleration program 302. In one embodiment, a88 people client 120 is a Independent Computing Architecture (ICA) client, or any part thereof, developed with Citrix Systems, Inc. of Fort Lauderdale, Florida, and is also referred to as an ICA client. In some embodiments, the client agent 120 has an application streaming client 306 to continuously stream an application from a server 106 to a client 102. In another embodiment, the client agent 120 includes a collection agent 304 to perform detection / endpoint scan and collect endpoint information for tool 200 and / or server 106. In some embodiments, the client agent 120 has one or more network acceleration or optimization programs or agents, such as a network optimization mechanism 250 and an acceleration program 302. In one embodiment, the acceleration program 302 accelerates the communications between client 102 and server 106 through tool 205 '. In some embodiments, the network optimization engine 250 provides WAN optimization techniques, as discussed above.

The 306 streaming client is an executable application, program, process, service, task or set of instructions for receiving and running a streaming application from a 106 server. A 106 server can continuously stream one or more data files application for the streaming client 306 to play, run, or otherwise cause the application to run on client 102. In some embodiments, server 106 transmits a set of compressed or packaged application data files to the streaming client 306. In some embodiments, the plurality of application files is compressed and stored on a file server within a file. dead, such as a CAB, ZIP, SIT, TAR, JAR or other file. In one embodiment, server 106 unzips, unpacks or unarchives the application files and transmits the files to client 102. In another embodiment, client 102 unzips, unpacks or unarchives the application files. The 306 streaming client dynamically installs the application, or part of it, and runs the application. In one embodiment, the streaming client 306 can be an executable program. In some embodiments, the streaming client 306 may be able to start another executable program.

Collection agent 304 is an executable application, program, process, service, task or set of instructions to identify, obtain and / or collect information about the customer 102. In some embodiments, Tool 200 transmits collection agent 304 to the client 102 or client agent 120. Collection agent 304 can be configured according to one or more policies of the tool's 236 policy engine. In other modalities, the collection agent 304 transmits the collected information about the client 102 to the tool 200. In one embodiment, the policy mechanism 236 of the tool 200 uses the collected information to determine and provide access control, authentication and authorization. client connection to a 104 network.

In one embodiment, the collection agent 304 is an endpoint detection and scanning program, which identifies and determines one or more attributes or characteristics of the customer. For example, collection agent 304 can identify and determine any or more of the following client-side attributes: 1) the operating system and / or a version of an operating system, 2) a service system package 3) an execution service, 4) an execution process and 5) a file. Collection Agent 304 can also identify and determine the presence or version of any one or more on the following client: 1) antivirus software, 2) personal firewall software, 3) anti-spam software, and 4) internet security. The policy mechanism 236 can have one or more policies based on any one or more of the attributes or characteristics of the client or attributes of the client side.

The SSL VPN Agent 308 is an executable application, program, process, service, task or instruction set to establish a Secure Socket Layer (SSL) virtual private network (VPN) connection from a first network 104 to a second network 104 ', 104, or an SSL VPN connection from a client 102 to a server 106. In one embodiment, the SSL VPN agent 308 establishes an SSL VPN connection from a public network 104 to a private network 104' or 104. In some embodiments, the SSL VPN agent 308 works in conjunction with the 205 tool to provide the SSL VPN connection. In one embodiment, the SSL VPN agent 308 establishes a first transport layer connection with tool 205. In some embodiments, tool 205 establishes a second transport layer connection with a server 106. In another modality, the SSL VPN 308 agent establishes a first transport layer connection with an application on the client, and a second transport layer connection with the 205 tool. In other modalities, the SSL VPN 308 agent works in conjunction with the 200 WAN optimization tool to provide SSL VPN connectivity. In some embodiments, the 302 acceleration program is a client-side acceleration program to perform one or more acceleration techniques to accelerate, enhance, or otherwise improve, client communications and / or access a server 106, such as like, accessing an application provided by a 106 server. The logical functions and / or operations of the 302 acceleration program executable instructions can perform one or more of the following acceleration techniques: 1) multiprotocol compression, 2) transport control protocol combination, 3) control control protocol multiplexing transport, 4) transport control protocol temporary storage, and 5) cache through the cache manager. In addition, the acceleration program 302 can perform encryption and / or decryption of any communications received and / or transmitted by the client 102. In some embodiments, the acceleration program 302 performs one or more acceleration techniques in an integrated manner. In addition, the acceleration program 302 can compress any of the protocols, or multiple protocols, carried as a payload of a transport layer protocol network packet.

In one embodiment, the acceleration program 302 is designed, built or configured to work with the 205 tool to provide LAN side acceleration or to provide acceleration techniques provided through the 205 tool. For example, in a NetScaler 205 tool embodiment produced by Citrix Systems, Inc., the 302 acceleration program includes a NetScaler client. In some embodiments, the 302 acceleration program provides stand-alone NetScaler acceleration techniques on a remote device, such as a branch office. In other embodiments, the acceleration program 302 works in conjunction with one or more NetScaler 205 tools. In one embodiment, the acceleration program 302 provides LAN-side or LAN-based acceleration or optimization of network traffic.

In some embodiments, the network optimization engine 250 can be designed, built or configured to work with the WAN 200 optimization tool. In other modalities, network optimization engine 250 can be designed, built or configured to provide the techniques 200 WAN optimization tool, with or without a 200 tool. For example, in a modality of a WANScaler 200 tool produced by Citrix Systems, Inc., the network optimization engine 250 includes the WANscaler client. In some embodiments, the network optimization engine 250 provides autonomous WANScaler acceleration techniques at a remote location, such as a branch. In other ways, the network optimization mechanism 250 works in conjunction with one or more WANScaler 200 tools.

In another embodiment, the network optimization mechanism 250 includes the acceleration program 302, or the function, operations and logic of the acceleration program 302. In some embodiments, the acceleration program 302 includes the network optimization mechanism 250 or the function, operations and logic of the network optimization engine 250. In yet another embodiment, the network optimization mechanism 250 is provided or installed as a separate program or set of instructions executable from the acceleration program 302. In other modalities, the network optimization mechanism 250 and the acceleration program 302 are included in the same program or set of executable instructions.

In some embodiments, still referring to figure 3, a first program 322 can be used to install and / or run the client agent 120, or any part of it, automatically, silently, transparently or otherwise. In one embodiment, the first 322 program is a plugin component, such as ActiveX control or Java control or script that is loaded into and executed by an application. For example, the first program comprises an ActiveX control loaded and executed by a web browser application, such as in the application's space or memory context. In another embodiment, the first program 322 comprises a set of executable instructions loaded and executed by the application, such as a browser. In one embodiment, the first program 322 is a program designed and built to install client agent 120. In some embodiments, the first program 322 obtains downloads or receives client agent 120 over the network from the other computational device. In another embodiment, the first program 322 is a plug and play installer or manager program to install programs, such as a network driver and client agent 120, or any part thereof, on the client's operating system 102.

In some embodiments, each or any part of the client agent 120 - a streaming client 306, a collection agent 304, an SSL VPN agent 308, a network optimization mechanism 250, acceleration program 302 and interceptor 350 - they can be installed, run, configured or operated as an application, program, process, service, task or set of separate executable instructions. In other embodiments, each or any of the parts of the client agent 120 can be installed, executed, configured or operated together as a single client agent 120.

D. Systems and methods for using shared compression histories

Referring now to Figure 4A, a block diagram of a modality that uses a shared compression history to reduce the size of the transmitted data is shown. In a brief overview, two clients, 102a and 102b, transmit data using two tools, 200a and 200b, which have compression histories 400a and 400b (usually 400), respectively, and which communicate over a network 104. The compression histories 400a and 400b are used to compress the data transmitted between the tools 200a, 200b, and comprise parts of data previously transmitted between the two tools 200a, 200b. The tool 200a compacts the data transmitted over the network 104 by identifying the pieces of data in a data stream sent by a client 102a that was previously transmitted between the two clients. The tool 200a then replaces those pieces of data with reference to a location in the compression histories 400a, 400b, reducing the volume of data transmitted, while allowing the corresponding tool 200b to precisely reconstruct the original data stream. A 102c client that contains a 250a network optimization engine can also use a 400c compression history to speed up communications with a 200 or second 102d client tool that has a 400d compression history.

Still referring to figure 4A, now, in more detail, a client 102a transmits a data stream to a tool 200a. The data stream can comprise any type of data sent over a network, including any protocol. In some embodiments, the data stream can be transmitted over a transport layer connection, such as a TCP connection. In other embodiments, the data stream can be transmitted using a session layer protocol, such as SSL. In some embodiments, some or all of the data stream can be encrypted.

In some embodiments, one or more tools 200a may operate transparently on one or more clients 102a, 102b. In other embodiments, one or more tools 200a can operate as a transparent proxy for one or more clients 102a, 102b. For example, tools 200a and 200b can intercept and compress network traffic over a TCP connection between clients 102a and 102b, transparently, on one or both clients 102a, 102b. In this example, client 102a can send a TCP stream directed to client 102b which is intercepted by tools 200a. The tool 200a can then compress the data stream and forward it to the client 102b through the tool 200b. The tool 200b, after receiving the flow, can then unzip and forward the data flow to the client 102b. In this way, client 102a and client 102b are able to maintain their use of standard TCP addresses and protocols.

Tools 200a, 200b maintain synchronized compaction histories 400a, 400b, each of which contains data previously transmitted between tools 200b. These synchronized compression histories can also be referred to as shared compression histories. Compaction histories 400a, 400b can be synchronized by any means. In one embodiment, the compaction histories can be synchronized using tools 200a 200b that intercept and store the same data streams in the compaction histories 400a 400b. In another embodiment, tools 200a, 200b can transfer all or part of a compaction history between them. In some embodiments, compaction histories may be only imperfect or partially synchronized. A 400 compression history can be located on any storage medium, which includes, without limitation, RAM and disks. In some embodiments, a compression mechanism 238 that is located on a tool 200 can maintain a compression history 400. A compression history 400 can store any type and form of data, including any previously transmitted data. In some embodiments, a tool can store all data that passes through the tool for compression history. In other embodiments, a tool can select pieces of data from a data stream to be stored in the compression history based on any factor including, without limitation, the data stream source, the data stream destination, protocol transmission rates, application protocols, available disk space, current disk usage, available memory space, current available bandwidth and size of data pieces. In some embodiments, data stored in the compression history can be compressed using the compression algorithm without data loss. In one embodiment, a compression history can store data in blocks, which will be discussed with reference to figure 4B.

In some modalities, a tool can store the payloads, or any parts thereof, of any layer of protocol packets that are transmitted through the tool in the compression history. In one embodiment, a tool can store only the payload of TCP packets transmitted through the tool in a compression history. In one embodiment, the tool stores application data obtained through an application layer protocol in the 1138 compression history. In some embodiments, the tool stores network packet headers, such as the application layer header for a payload. useful HTTP, in a compression history. In other embodiments, the tool does not store network packet headers. In another embodiment, a tool can store only the payload of a UDP packet transmitted through the tool in a compression history. In one embodiment, a tool may decide not to store any encrypted data in the compression history. In another mode, a tool can decrypt encrypted data and store the decrypted data in a compression history. In yet another modality, a tool can store encrypted data in a compression history.

A compression mechanism 238 can store compression history 400 in storage 128, such as, disk, memory, such as, RAM, or a combination of storage and memory. In some embodiments, the compaction mechanism 238 uses an object or data index to reference or identify the corresponding objects or data stored in the compaction history. A specific example of a modality of such an index is provided in figure 4C. In a modality, a compression mechanism 238 uses an object index stored in memory. In other embodiments, a compression mechanism 238 uses an object index stored on the disk. An object index can comprise any type and form of indexing scheme to match an index to an object in a 400 compression history. In one embodiment, an object index is maintained in memory while the corresponding object is stored in a compression history 400. In some embodiments, an object index comprises an entry that references or identifies a location or pointer to the object stored in the compression history 400. In some embodiments, some or all of the compression history or index can be stored in a 232 cache. In other embodiments, some or all of the 232 cache can be stored using a compression history.

In recording a part of the data transmitted for the compaction history, a tool can create a shared identifier to activate the tool and a tool that receives the transmitted data to be referred to the data part in later communications. In one embodiment, this identifier can be a unique identifier between the two tools. In other embodiments, this shared identifier can be a globally unique identifier among a plurality of tools. The shared identifier can be created, for example, by tracking the number of bytes sent through a connection between the tools and assigning successive identifiers to the successive transmitted bytes.

In some embodiments, a single tool 200 can maintain multiple compaction histories. For example, a tool 200a in communication with multiple other tools can maintain a separate compaction history that contains the data transmitted to and from each tool. In one embodiment, these separate compression histories can be physically separated, such as where separate disks are kept for each compression history. In another embodiment, these separate compaction histories can be logically separated, such as, in which multiple compaction histories are mixed on a single disk, with identifiers or indexes that identify which compaction history or compaction histories a given data belongs to.

In the embodiment shown, tool 200a used compaction history 400a to identify parts of data in the data stream from client 102a that were previously transmitted to tool 200b. The tool then replaces those parts of the data stream with identifiers that identify the locations in the compression history that contains those parts before sending the data stream to tool 200b. For example, the tool can replace a 120-byte sequence with reference to a memory location that contains the sequence and an instruction that includes 120 bytes from that location.

Upon receipt of the data stream that contains a reference to a location in the compression history, tool 200b fetches its compression history 400b for the identified piece of data. Tool 200b then replaces the identifier in the data stream with the identified data portion, and sends the reconstructed data stream to client 102b. In these modalities and subsequent modalities discussed below, the history of compression and caching functions performed by tools 200a, 200b can be performed by one or more between a client 102, client agent 120 or server 106. For example, a client agent 120 can maintain a compression history 400 comprising parts of data previously transmitted to a server, the server also maintains a corresponding compression history. Client agent 120 and server 106 can then compress the data sent between the server and a client on which client agent 120 is located when using compression histories.

Referring now to Figure 4B, a block diagram of a modality of a data structure used to store data in a compression history is shown. In a brief overview, a compression history 400 comprises a plurality of storage units referred to as blocks 405a, 405b, 405c, 405d (generally referred to as 405) for storing data from a compression history. Each block 405 comprises a header 455 that has a status identifier 475 and a next pointer pointer 485. Each block also includes a section that contains previously transmitted data 465.

Still referring to figure 4B, now, in more detail, a compaction history 400 comprises numerous 405 blocks. A block can refer to any distinct physical or logical storage element. Examples of a block can include a region on a disk, multiple sequential regions on a disk and a memory location, a series of consecutive memory locations. For example, a 10MB disk can be divided into 1,000 10KB blocks, where each block consists of a logically contiguous 10K region on the disk. Or, for example, two 10MB disks can be divided into 20,000 1KB blocks, with one or more block crossing disks. In other embodiments, a block may comprise non-sequential areas of a disc or disks. For example, a 2K block can be stored in 4 separate 512-byte parts, and a maintainable data structure identifies the locations of the separate parts. In still other embodiments, a block header 455 can be stored in a location other than that of a payload block 465. For example, one or more block headers 455 can be kept in memory, while block data 465 can be kept on a disc.

A block can be any size including, without limitation, 32 bytes, 64 bytes, 100 bytes, 128 bytes, 256 bytes, 512 bytes, 1K, 2K, 3K, 4K, 8K, 10K, 16K, 32K, 64K, and 128K. In some embodiments, some blocks can only be partially filled with data. For example, in a mode in which the blocks have a fixed size of 5K, a block can include only 2K of data in a case where the block kept the last bytes of a given transmission.

In some embodiments, a series of blocks can be sequentially stored on a disk or in memory. In other modes, blocks can be stored in a plurality of locations on a disk or in memory. For example, in one mode, a tool can store blocks that contain data transmitted to another tool in a contiguous section of a disc. In another embodiment, a compression mechanism on a client can store blocks with data transmitted to a first tool interspersed on the disk with blocks that include data transmitted to a second tool.

In some modalities, a tool can create a new block for each new connection that is opened through the tool. For example, in a tool that serves as an intermediary for a plurality of TCP connections, a tool can create a new block each time a new TCP connection is opened, and store data from the TCP connection in the block. In this example, the tool can create additional blocks for a TCP connection if the initial block becomes full. In this mode, the tool can ensure that each block maintains data from only one TCP connection. The tool can store any information regarding the TCP connection, including timestamps, sequential numbers and source and destination addresses in one or more block headers.

In some embodiments, a compression history may contain uniformly sized blocks. In other modalities, a compression history may contain blocks of varying sizes.

The compaction history shown comprises a plurality of blocks 405. Each block contains a block header 455. A block header 405 can comprise any identification, navigation or historical data referring to the block. Examples of data that can be stored in a block header include, without limitation, a block identifier, a pointer to the next block in a sequence, a pointer to a previous block in a sequence, a size for the block, a time the block was created, a time the block was last accessed, a total number of times the block was accessed, and a checksum or other error correction measures.

In the embodiment shown, the block includes a block identifier, which can comprise a unique serial number assigned to the block. In one embodiment, this unique serial number can correspond to a block's memory address, such as a starting address of the block's location in memory or on a disk. In other embodiments, the block identifier can correspond to a location in a stream of transmitted data. For example, in a compression history shared between two devices, a block with a serial number of 4,500,000 can contain the 4,500,000 bytes transmitted between the two tools and some number of subsequent bytes. The block identifier that corresponds to a piece of transmitted data can be shared with the corresponding tool either explicitly or implicitly. For example, two tools can use the above method so that a certain part of the transmitted data has the same block identifier in both tools. In this way, the unique serial number refers to an identical piece of data that is located in two or more tools. In another example, after a first tool transmits a certain number of bytes to a second tool, the first tool can transmit a block identifier that identifies the block in which the first tool stored the transmitted data. The second tool, then, can register the block identifier received in a table that corresponds to the block identifier of the second tool assigned to the same data.

In one embodiment, block identifiers can be globally unique among a plurality of tools. For example, in a set of tools, each with unique serial numbers, a tool can attach the tool's serial number to the beginning or end of a locally unique block identifier to create a globally unique block identifier. In another embodiment, each device that stores the data transmitted to the blocks on a disk can create a block identifier by attaching the disk serial number to a disk.

101 block serial number. If block serial numbers are never reused, this technique can be used to create globally unique block identifiers. A device can then transmit the created block identifier to a recipient of the transmitted data, so that a compatibility table can be maintained on the receiving device.

In some embodiments, some or all of the data included in block header 455 can be stored in a footer after the block. In yet other embodiments, some or all of the data contained in block header 455 can be stored in an external table or other data structure.

Referring now to Figure 4C, a block diagram of a modality of a data structure that can be used to locate the parts of data in a compaction history, a compaction index 410 is shown. In a brief overview, a compaction index 410 contains numerous location identifiers 420 arranged in a table. Each row in the table corresponds to a specific data fingerprint. For example, row 4 of the table contains location identifiers for pieces of data in the compaction history that have a data fingerprint of 4. Each of the location identifiers 420 indicates a location in a compaction history 400 when identifying a location in a given block. In the mode shown, the location identifiers identify a particular block and an offset within the block.

Still referring to figure 4C, now, in more detail, a compaction index 410 includes numerous location identifiers 420 arranged in an index where each line corresponds to a particular data fingerprint. The index can be implemented using any data structure, including matrices, tables, hash tables and linked lists, binary trees, red-black trees and trials. The index can also be implemented using any technique to implement a hash table. For example, in one modality, the index can be

102 implemented as an array of linked lists, where each linked list corresponds to an index row. In another embodiment, the table can be implemented as a single two-dimensional matrix. In this mode, if a line in the matrix becomes full, the less recently used location identifier in the line can be discarded. In still other modalities, the index can be implemented as a single matrix, in which hash collisions are resolved by placing the location identifiers in matrix openings subsequent to an opening of the overloaded hash value. Throughout this specification the word input can also be used to indicate the part of a compaction index that has location identifiers that correspond to a particular fingerprint. Thus, in relation to figure 4C, entry 8 stores the location identifiers C73 + x and C₂ + x (where x represents any displacement).

Location identifiers 420 can comprise any identifier that allows the tool to locate the corresponding data portion in a compression history. In one embodiment, a location identifier can comprise a block identifier 475 and an offset. In another embodiment, a location identifier can comprise a unique address that corresponds to a memory or disk location of the data portion. In yet another embodiment, a location identifier can comprise an address and a size indicator.

After determining a part of a compaction history coincides with a part of an input stream, a tool can then perform a run-lenght extension to determine a total length for the compatible sequence. The length extension of the path can be performed by comparing the successive bytes in the compression history with the successive bytes of the input stream, without the need to compute the fingerprints. In some modalities, a length extension of the path can also compare the previous bytes in the compression history with the an103 bytes in the input stream. For example, if a 600-byte stream of input data was buffered via a 200 tool for later transmission and a match is found in a compression history with respect to 140 to 145 ° bytes, the tool can compare the previous and successive bytes in the compression history with the previous and successive bytes of the input stream to identify the full extent of the compression history compatibility. In some embodiments, an extension of the path length may extend over a plurality of blocks. In these modalities, the next and previous block pointers contained within a given block can be used to identify the successive and preceding areas of the compaction history.

E. Systems and methods for efficiently identifying compaction history compatibilities

Referring now to Figure 5A, a block diagram illustrating a modality of a method of using a compaction index to locate the compaction history compatibilities that correspond to the input data is shown. In a brief overview, a tool can intercept one or more data streams 510, 520. The tool arranges a data stream 510, 520 on a number of cards and then computes a fingerprint for each card. For example, character flow 10 fast is treated as ten overlapping four-byte plates. Each fingerprint, then, serves as an index on a 410a compression index. For example, the plate produces a fingerprint 4, which corresponds to line 4 of the compaction index 410a. This line has numerous location identifiers that indicate the locations in a compression history that includes cards that also have a fingerprint 4.

Still referring to figure 5A, now, in more detail, a tool divides a 510 data stream into numerous cards. In the mode shown, the data flow is a fast chain. The tool breaks the chain on 4-byte plates. In other modalities, the plates can

104 have any other length including, without limitation, 3, 5, 6, 7, 8, 10, 12, 16, 32 or 64 bytes. In the mode shown, the tool creates overlapping 4-byte plates for each successive byte in the data stream. In other embodiments, the plates can be non-overlapping. In still other modalities, a tool can create cards for only a subset of bytes in a data stream. For example, a tool can create a card for each other byte in a data stream, or for each third byte in a data stream. In some modalities, the tool can compute a fingerprint for numerous plates, in order to select the fingerprint that will be consulted in a compression index. This technique and other digital printing techniques are more fully described in US patent 7,098,815, Method and apparatus for efficient compression ”, all the contents of which are expressly incorporated by reference in this document.

In the modality shown, the tool computes a fingerprint value for each plate, which is then used as an index on a compaction index 410a. In some modalities, the tool can then access the data part identified by a location identifier that is located in the index. The tool can then do a byte-by-byte comparison of the data portion in the compression history with the board to ensure that a match has been found. For example, this comparison may be necessary if the fingerprint method does not produce a unique fingerprint for each possible plate, or if multiple fingerprints are consolidated on a given line of the compaction index 410a. In one embodiment, when a plate found matches a certain piece of data in the compression history, a tool can then extend the length of the compatibility path to determine whether the subsequent pieces of data in the compression history match the parts subsequent input stream received.

In one embodiment, a tool can use a verification strategy for a plurality of print compatibility

105 before accessing a compression history to confirm that a match is found. In this mode, the tool compares the location identifiers that correspond to the overlapping plates to verify that the locations indicated are the subsequent sections of a single block. The tool can carry out this strategy to establish some probability that a compatibility of a certain length does exist, and it is not a false positive of the fingerprint algorithm or a compatibility of such a small length that it does not provide significant compression benefit. The strategy can result in performance improvements in cases where a compression history is stored on a disk and thus may have access times slower than the compression index that can be stored in memory. This strategy can also result in performance improvements in cases where a compression history is being heavily used by a plurality of connections, while minimizing the number of times a disk or memory region is accessed.

Still referring to figure 5A, a tool can compute a fingerprint for the first the card in data stream 510. By checking the compression index for entries that correspond to the fingerprint, the tool finds a large number of entries, perhaps, as a result of large numbers of previously transmitted data that contain the byte sequence. The tool can then compute a fingerprint for the next he_q card, and find only a single compatibility, identify block 6 and a specific offset. The tool can then compute a fingerprint for the next e_qu card, and find only a single compatibility, which identifies block 2 and an offset of 6. Since block 2 and block 6 do not represent sequential areas in the compaction history, there is a very low probability that these blocks will contain compatibility for anything other than individual boards. The tool, therefore, can determine not to access each of these pieces of data in the compression history and instead send

106 uncompressed data, or compressed using a compression mechanism other than a compression history. Regarding data flow 520, the tool can determine that the location identifiers associated with consecutive brev revi evit and vity cards identify the consecutive parts of the compression history, that is, they identify bytes 4, 5, 6 and 7 of the block 2. This indicates a substantial probability of a long compatibility for data flow 520 in block 2. The tool can then determine to access this part of the compaction history and perform a length extension of the path to determine a total length for the sequence compatible.

Referring now to figure 5B, a flowchart of a method modality to determine whether to perform disk-based compression by identifying in an index maintained in memory an estimated extent of an input data compatibility to contiguous data stored in the disk is above or below a predetermined limit is shown. In a brief overview, a device that has a compression history establishes an in-memory index that is compatible with the fingerprints of a plurality of pieces of compression history data for location identifiers to identify locations on a storage element which has the plurality of pieces of data (step 501). The device identifies numerous fingerprints of input data compatibility fingerprints from a plurality of index entries in memory (step 503) and determines, from numerous fingerprints identified in memory that it has entries that are compatible with a first identifier location that an estimated compatibility of input data with contiguous data on the disk is extensible below a predetermined limit (step 505). If the compatibility is extensible below a specified limit, the device transmits the uncompressed data (step 507). If the compatibility is extensible above the specified limit, the device uses the compression history to compress the data (step 509). Although the method can be discussed below in the context of being performed by a tool,

107 the device may comprise a client 102, server 106, tool 200, or any other computing device 100.

Still referring to figure 5B, now, in more detail, a device that has a stored compression history establishes an index in memory that corresponds to the fingerprints of a plurality of parts of the compression history data to the location identifiers that identify the locations in a storage element that has the plurality of pieces of data (step 501). In one embodiment, the index can comprise a compaction index 410 as described herein. Location identifiers may also comprise location identifiers 420, as described herein. In one embodiment, the locations on the disk may correspond to blocks 400, as described in this document. The index can be established and maintained at any time. In one embodiment, the index can be updated every time it is stored in a compression history. The storage element can comprise any storage medium, including one or more RAM, disks and fast memory. In some embodiments, the storage element may be located in the device. In other embodiments, the storage element can be connected to the device via a network. In one embodiment, the storage element may have a higher latency than the memory containing the index.

In the embodiment shown, a device identifies numerous fingerprints of input data compatibility fingerprints from a plurality of index entries in memory (step 503). The input data can comprise input data from any source. In one embodiment, the input data may comprise a data stream transmitted to the device from a client 102 or server 106. In one embodiment, the data stream can comprise data from a TCP connection for which the device is serving as a proxy. In another embodiment, the input data may comprise data sent from an application that works on the device.

The device can compute fingerprints of the input data using any fingerprint method that includes, without limitation, a plate method, as described in this document. The number of fingerprints can be any number 2 or greater, including 2, 3, 4, 5, 6, 7, 8, 9 and 10. For example, a tool can compute fingerprints for four successive cards in a given flow Dice. In another mode, a tool can compute fingerprints for five nearby cards not overlapping in the input data. In one embodiment, the number of fingerprints can be predetermined in order to balance the disadvantages of potentially jumping through small compatible segments against the benefits gained by some disk accesses.

In the modality shown, the method then comprises determining, through the device, from the number of fingerprints identified in the memory that has entries that correspond to a first location identifier in which an estimated compatibility of the input data with the contiguous data on the disk is extensible below a predetermined limit (step 505). In one embodiment, this method may comprise identifying that one or more fingerprints correspond to entries in the index that contain null pointers or another indication that there is no compatibility in the compression history for the fingerprint. In another embodiment, this method may comprise identifying that two or more fingerprints correspond to entries that contain location identifiers that point to non-contiguous locations in the compression history. For example, in relation to input stream 510, the device can determine that the locations identified by fingerprints 1 and 9 are not contiguous in the compression history. This indicates that the compatibility in the compression history that corresponds to the beginning of the input stream is not more than 5 characters.

The predetermined limit can comprise any number of bytes. In one embodiment, the predetermined limit can be 8, 12, 16, 32,

109

64, 128, or 256 bytes. In some embodiments, the predetermined limit can be changed in response to the operational characteristics of the device. In one embodiment, the limit can be increased in response to an increase in the number of connections that pass through the device, an increase in the amount of data that passes through the device, or an increase in a connection speed that refers to the data input. In another embodiment, the limit can be reduced in response to a reduction in the number of connections, a reduction in the amount of data that passes through the device, or a reduction in the connection speed that refers to the input data. For example, in a tool that serves as a proxy that compresses numerous TCP connections, the tool can increase the threshold in response to additional TCP connections that are opened, in order to minimize the occurrence of compression routines for two connections that need simultaneously access a disk that contains compression histories.

In the modality shown, the method then comprises transmitting, through the device, the uncompressed data in response to a determination that the compatibility is not extensible above a certain limit (step 507). The device can then continue to compute fingerprints for the subsequently received pieces of input data to identify potential compatibilities in the compression history. Uncompressed data can be transmitted to a tool, a client, or any other device. In some embodiments, the transmitted data can be compressed using a compression method other than the compression history. For example, data can then be compressed using path length compression or LZW compression. In one embodiment, data can be compressed using only parts of the compression history that are available in a faster storage element. For example, a device can keep recently accessed parts of the compression history in a cache. The device can choose to compress the data using only those parts that are available in cache.

110

If the compatibility is extensible above a certain limit, the device can use the compression history to compress the input data. The use of the compression history can include any method of access, reference or, otherwise, use of the compression history to try to compress the input data. For example, the device can access the compression history to determine whether the parts of the fingerprint compression history that match the input data are byte-byte compatibility of the input data. Or the device can, after accessing the compression history to confirm a compatibility, replace one or more parts of the input data with references to the compression history before relaying the input data.

A potential problem with the use of plates as indexes in compression histories is the fact that in some cases a given plate can occur in a large number of transmitted files or data. This can prevent the ability of a compression engine to find long continuous compatibilities in a compression history for a given input stream. These long continuous compatibilities may be desirable to reduce the amount of data transmitted, as well as to reduce the number of disk accesses if a compression history is stored on a disk. For example, the &lt;HTML card must be present on a large number of web pages. If a tool then receives an input stream that begins with &lt;HTML, even if the input stream is the beginning of a file that exists in the tool's compression history, the tool may have difficulty identifying which among the numerous blocks contains the ”&lt;HTML” card will be compatible with the rest of the input stream.

Referring now to Figure 6A, a block diagram illustrating a second way of using a compaction index to locate the compatibility of compaction history that corresponds to the input data is shown. In a brief overview, a Call me Ishmael input stream is processed on a number of boards. An

111 fingerprint is computed for each plate and corresponding line in the index is identified. The tool then counts the number of location identifiers on each line to determine which line to select for the purpose of accessing the disk.

Still referring to figure 6A, a tool (either client agent or server agent) computes fingerprints for countless cards before accessing a compression history. After receiving the Call me Ishmael · 'input string, the tool computes fingerprints for each of the four-byte cards that make up the input string. The first Call card has a fingerprint value of 4, and the corresponding compression index entry 410b has a plurality of location identifiers. This may indicate that numerous blocks on the disk contain the character string Call. Instead of trying to access one of these blocks, the tool then proceeds to compute fingerprints on numerous successive plates in the input chain. In the example shown, the tool computes the fingerprints for the next 4 cards. The tool then counts the number of location identifiers in each index entry. In the example shown, the all ”card has a fingerprint that is compatible with a compression history location, the only II m has a fingerprint that is compatible with three compression history locations, the I plate has a fingerprint which is compatible with two compression history locations, and the me ”card has a fingerprint that is compatible with more than three compression history locations. An observation, then, can be made that any long compression history compatibility that contains the input string must contain compatibility for each of the boards. Thus, if a long chain compatibility exists in the compression history, it must contain a compatibility for the all card, which has only one location identifier in the corresponding entry. The compression mechanism can deduce that this location identifier is more likely to point to an area of ​​the compression history that contains a long compatibility, and access the compression history at the specified location. The compression mechanism can then perform an extension of the compatibility path length to determine a total length of the compatible string.

The compression engine can determine numerous location identifiers in a compression index entry that uses any method. In one embodiment, the compression mechanism can count the location identifiers in a given index entry by iterating over each location identifier. In another embodiment, the compression mechanism can count the location identifiers when determining a total size of the compression index entry. In yet another embodiment, each entry in a compaction index can store a count of the number of location identifiers contained in the entry.

Referring now to figure 6B, a flowchart of a method modality for determining a precedence for compatible fingerprints of input data in a fingerprint index that identifies a plurality of data instances in a compression history is shown. In a brief overview, the method comprises a device that has a compression history that establishes an index that corresponds to the fingerprints of a plurality of pieces of compression history data on location identifiers that identify locations on a storage element that has the plurality of pieces of data (step 601). The device identifies that a plurality of input data fingerprints is compatible with a plurality of entries in the index that have at least one location identifier (step 603) and selects an entry from the plurality of entries that has a smaller number of location identifiers. location (step 605). The device can then be compatible with a first part of the input data in the data at a first location in the compression history identified by the selected input (step 607). The method can be performed by any device that has a compression history including a client, client agent, server, or server agent. In addition, this method can be performed in combination with any of the other compaction history methods and systems, as described in this document. For example, this method can be carried out in combination with the method described together with figure 5B. In this example, a compression engine would compute fingerprints for a number of cards, identify the cards that have minor location identifiers in the index, and then verify that the location identifiers for those plates pointed to the sequential areas of the compression history.

Still referring to figure 6B, now, in more detail, a device establishes any type and form of index for a compression history a (step 601). In one embodiment, the index may comprise a compression index 410. In another embodiment, the device may use a network optimization mechanism 250 and / or compression mechanism 238 to establish the index. The index can use any method of fingerprinting data, and the parts of data can be chosen using any method. In one embodiment, the index can correspond to fingerprints taken from a plurality of plates superimposed on block and offset identifiers. In another embodiment, the index can correspond to fingerprints taken from a plurality of plates overlaid on memory addresses in a compression history. The data in the compression history can be received from any source. In one embodiment, the data in the compression history can comprise the data previously transmitted by the device. The storage element that stores the compression history can comprise any storage medium, including one or more RAM, disks and fast memory. In some embodiments, the storage element may be located in the device. In other embodiments, the storage element can be connected to the device via a network. In one embodiment, the storage element may have a higher latency than the memory containing the index.

114

After establishing the index, the device can identify that a plurality of input data fingerprints are compatible with a plurality of entries in the index that have at least one location identifier (step 603). The device can compute fingerprints for any number and amount of input data. In one embodiment, the device can compute fingerprints for four pieces of input data. In another embodiment, the device can compute fingerprints for two, three, five, six, seven, eight, nine, ten or more pieces of input data. In one embodiment, the device can identify that a plurality of fingerprints, each corresponding to a successive overlapping plate of input data, is compatible with a plurality of inputs.

In some embodiments, the device can compute fingerprints for a plurality of pieces of input data before checking the index for the corresponding location identifiers. In other embodiments, the device can compute a fingerprint for a piece of data, check the index for a corresponding location identifier, and then, if more than one location identifier is found, the device can compute fingerprints for subsequent parts of data before accessing a compression history. For example, the device can continue to compute fingerprints and count the corresponding location identifiers until the device computes a fingerprint where only one location identifier is in the corresponding index entry. The device can then select this entry (step 605) and access the location in the compression history identified by a location identifier and determine a compatibility length.

The device can select an entry from the plurality of entries that have a smaller number of location identifiers (step 605). In some cases, the device may select an entry that has only a location identifier. In other cases, the device may select an entry that has more than one location identifier,

115 however, it has the least number of plurality location identifiers. In these cases, the device can choose a location identifier to access from the input using any method including, without limitation, selecting a location identifier at random, or selecting a location identifier using the method described in figure 5B.

After selecting an entry, the device can be compatible with a first part of the entry data in the data at a first location in the compression history identified by the selected entry (step 607). This first part can be the part whose fingerprint corresponds to the selected entry. Compatibility can be achieved by any method including, without limitation, byte-by-byte comparison, a second fingerprinting process, checksums and path length expansion.

If a match is found, the device can then compress the input data by replacing the compatible data stream with a reference to the compatible compression history part in the subsequent transmission. The device can then repeat any or all of the above steps in relation to subsequent input data.

F. Systems and methods for removing application layer headers from compression history data

As previously discussed, many benefits can be associated with the identification and use of longer compaction history compatibilities as opposed to shorter compatibilities. Potential benefits include less compression history hits, improved compression ratios, and lower processing overhead. Another way to increase the likelihood of generating longer compression history compatibilities is to remove the input data from consideration that is unlikely to be repeated from the compression history. An example of data that can be improbably repeated is the application layer protocol headers,

116 which can include session numbers, timestamps, and other unique data. By removing these application layer headers from the compression history data, longer compression history compatibility can be achieved, and the compression history space can be conserved.

Referring now to Figure 7A, a block diagram illustrating a modality of a technique for removing application layer protocol headers from data stored in a compression history is shown. In a brief overview, an application data stream 700 is transmitted from a client 102 to a tool 200. The application data stream comprises numerous streams of application data 720a, 720b, 720c (usually 720) separated by application layer protocol headers 710a, 710b, 710c (usually 710). Tool 200 stores parts of application data 720 in a contiguous region of a compression history 400.

Still referring to figure 7A, now, in more detail, a tool 200 (in other modalities, this can be a client agent, server agent, client, or server) receives an application data stream 700 through any type and protocol form. An application data stream 700 can comprise any application layer data stream. As used in figures 7A, 7B, 1C, 7D and the attached description, the application layer can refer to the application layer (or layer 7) of the OSI model, or the application layer can refer to any layer above the layer in the OSI model. Examples of application data flows include, without limitation, HTTP communications, Common Internet File System (CIFS) communications, File System (NFS) communications, ICA communications and File Transfer Protocol communications ( FTP). In one embodiment, tool 200 may serve as a proxy or as a transparent proxy for a data stream that contains application data stream 700. For example, tool 200 can serve as a transparent proxy for a TCP connection, with the payloads

117

TCP comprise an application data stream.

An application data stream 700 can comprise a number of application layer protocol headers 710. The application layer protocol headers can comprise any sequence used by an application protocol to format, outline or transport information in relation to application data . Application layer protocol headers can occur anywhere in an application data stream, and anywhere in an application data object. The term application layer protocol header also includes footers, trailers, and intermediate object strings. For example, a file access application, such as CIFS, can transmit parts of files interspersed with headers that indicate the size and location of the file data transmitted with the headers. Application layer protocol headers 710 can be outlined with special characters, formatting and / or specific application conventions. For example, an application layer 710 protocol header can contain a size field that indicates the size of a following piece of application data 720. Next, a sequence of application data 720 of the specified size can be another application layer protocol 710.

Application data 720 can comprise any data other than application layer protocol headers 710 transmitted for use by an application. Examples of 720 application data can include, without limitation, text, documents, files, images, objects, video streams and audio streams. In one case, application data 720 may comprise a file that is being transmitted between the two computing devices using FTP. In another case, application data 720 may comprise parts of a file that are transmitted between the two computing devices using CIFS. In a third case, application data 720 may comprise a file object or data to be used in a virtualized application. For example, a remote user can access a word processing application provided by a central server. The central server can provide access to the application by transmitting numerous data objects that include, without limitation, executable parts of the application, graphic data to be displayed to the user and one or more document files.

After receiving application data flow 700, the tool can analyze application data flow 700 to identify application layer protocol headers 710 and application data 720. In one embodiment, the tool can identify protocol headers application layer layer when using an analysis engine or part of a custom analysis engine for a given application. For example, a tool can be programmed to specifically identify CIFS headers.

Once application data 720 and application layer protocol headers 710 have been identified, tool 200 can then store application data 720 in a sequential area of ​​a compression history. In some embodiments, a sequential area of ​​a compression history may comprise a physically contiguous region of memory. In other embodiments, a sequential area of ​​a compaction history may comprise a sequential area of ​​a single block compaction history. In still other embodiments, a sequential area of ​​a compaction history may comprise parts of a plurality of blocks that are logically sequential. For example, application data 720 can be stored in numerous blocks, with each block containing a pointer to the next block in the sequence. Or, for example, application data 720 can be stored in numerous blocks spread out over a compression history, with an external data structure that indicates the sequence of blocks that includes application data 720.

In one embodiment, the tool may not store the application layer protocol headers 710. In another embodiment, the tool may store the application layer protocol headers 710 in a separate area of ​​the compression history from the

119 720 application data.

By storing application data 720 sequentially in the compression history, the tool may be able to obtain longer compression history compatibility if identical application data is subsequently transmitted through the tool. Many application layer protocols use headers that can be unique for each application data stream. For example, application layer protocol headers can include information specific to a sender or recipient of application data, or specific to a particular session in which application data is transmitted. By storing application data that sequentially and subsequently seeks compression history compatibility only in relation to application data, greater compatibility can be found.

Although, in the modality shown, application data 720 is stored in a sequential region of a compression history, in other modalities, application data 720 can be stored in non-sequential regions of a compression history.

Referring now to Figure 7B, a block diagram illustrating a second mode of removing application layer protocol headers and data stored in a compression history is shown. In a brief overview, a tool receives an application data stream 700 that comprises a plurality of application data objects 720, 721, which have been multiplexed along the application data stream 700 and are separated by protocol headers from application layer 710. The tool analyzes the application data stream 700 to identify the application data objects and store each application data object in a separate block from a compression history 400.

Still referring to figure 7B, now, in more detail, an application data object can comprise any distinct unit of application data. Examples of an application data object

120 include, without limitation, a document, a file, an image, a video stream and an audio stream. For example, an application can transmit a plurality of files over a single transport layer connection. The parts of the plurality of files can be interleaved with each other, and separated by application layer protocol headers that identify the files. In another example, a server can provide an user with access to an application. The server can transmit numerous objects that comprise the application or objects used by the application over a single transport layer connection.

The tool can use any information contained in application data stream 700 to identify application data objects 730, 731. In one embodiment, the tool analyzes one or more application layer protocol headers to identify application data objects. app. In the mode shown, the tool identifies that an application data object 730 has been divided into two parts 730a, 730b for transmission. The tool then stores the two parts 730a, 730b in sequential regions separate from the compaction history. Although figure 7B shows a tool that identifies two interleaved application data objects, in other embodiments, a tool can identify any number of interleaved application data objects. Also, although figure 7B shows a tool that stores the application data objects in separate blocks, in other modalities, the application data objects can be stored in the same block in which the first object is stored in a first contiguous region of the block and the second application data object is stored in a second contiguous region of the block.

Storing the application data objects in contiguous regions of a compression history can allow the largest compression history to be found if the same application data object is passed through the tool again. It may be unlikely that a particular application data object will be merged in the same

121 way, and among them, other application data objects, as previously occurred. In this way, although a given application data object 730 can be transmitted many times through a given tool 200, a search for compatibility of compression history based on the transmitted application data stream can only produce compatibilities as long as fragments application data object types 730a and 730b. by storing and analyzing application data objects as complete units, a tool may be able to optimize the length of subsequent compression history compatibilities.

Referring now to Figure 7C, a flowchart of one method modality for improving compression history compatibility by removing application layer protocol headers from data compression history data is shown. In a brief overview, the method comprises transmitting between a first device and a second device, an application data stream, the application data stream comprising at least one application layer protocol header between a first data stream application and a second application data string (step 701). The first device identifies the first sequence and the second sequence of the application data flow (step 703); and stores a combined sequence comprising the first sequence and the third sequence in a compression history (step 705).

Still referring to figure 7C, now, in more detail, the method shown comprises transmitting, between a first device and a second device, an application data stream 700, the application data stream 700 comprising at least one application layer protocol header 710 between a first application data stream 720 and a second application data stream 720 (step 701). The first and second devices can be any computational device 100. In one embodiment, the first and second devices can be 200 tools. In another embodiment, one or more of the first

122 and second devices can be the client, server, client agent, or server agent. In one embodiment, the first and second devices can be WAN optimization devices. In another embodiment, the first and second devices can serve as transparent proxies for a transport layer connection between a client and a server.

The first and second application data streams 720 can comprise any application data streams. Examples of application data strings include sequential parts of a file, data object, image, text, or document that is transferred. For example, the first application data stream can comprise the first 5,000 bytes of a portion of a file that is transmitted via CIFS. The second application data stream, then, can comprise the next 5,000 bytes of the file, the first and second strings separated by a CIFS header.

In some embodiments, the first device can transmit a plurality of application data streams, with an application layer protocol header between each application data stream. For example, two WAN optimization devices can serve as transparent proxies for the connection between the client and the server. The server can then transmit a 10MB file to a client using NFS, the file being separated into 10MB parts with each part outlined by an NFS header.

The first device identifies the first sequence and the second sequence of the application data flow by any means (step 703). In one embodiment, the first device can analyze one or more application layer protocol headers. In another embodiment, the first device can analyze one or more streams of application data. The first device can identify numerous streams of application data, separated by numerous application layer protocol headers. In some embodiments, the second device can similarly identify the first and second application data streams, so that the second device can synchronize its compression history with that of the first device. In other embodiments, the first device can transmit explicit notifications to the second device that identifies the first and second application data streams.

The first device can then store a combined sequence comprising the first sequence and the second sequence for a compaction history (step 705). The combined sequence can be stored in a logical or physically sequential region of the compaction history. In other embodiments, the combined sequence can comprise numerous streams of application data. The second device can also store a combined sequence that comprises the first sequence and the second sequence in a compression history.

For example, the two WAN optimization devices can serve as transparent proxies for the connection between the client and the server. The server can then transmit a 10MB file to a client using NFS, the file being separated into 10MB parts, with each part outlined by an NFS header. Each WAN optimization device can identify parts of the file when analyzing NFS headers. Each WAN optimization device, then, can store the parts in a sequential region of their respective compression histories. In this way, the file can be represented as a whole in the compression history without intervening in the protocol headers. The tools, then, may be able to obtain longer compression history compatibilities in the event that the file is transmitted again between the two devices.

Referring now to Figure 7D, a flowchart of a second modality of a method for improving compression history compatibility by removing the application layer protocol headers from the received data is shown. In a brief overview, the method comprises receiving, through a first device, an application data stream, with the application data stream comprising at least one application layer protocol header between a first data stream application and a second application data string (step 751). The device identifies the first sequence and the second sequence of the application data stream (step 753); and determines that a combined sequence comprising the first sequence and the second sequence is compatible with part of a compression history (step 755). The device then transmits information to the second device that identifies the part of the compatible compression history (step 757).

Still referring to figure 7D, now, in more detail, the method comprises receiving, through a first device, an application data stream, the application data stream comprising at least one application layer protocol header. between a first application data stream and a second application data stream (step 751). The first device can comprise any of a client, server, client agent, server agent, tool, WAN optimization tool and transparent proxy. The first device can receive the application data stream from anyone between a client, server, client agent, server agent, tool and WAN optimization tool. In one embodiment, the first device can comprise a WAN optimization tool that receives an application data stream from a server. In another embodiment, the first device may comprise a client agent that receives an application data stream from a client. The first device can relay some or all of the application data flow to a second device. In one embodiment, the first device can serve as a transparent proxy for a client or server from which the first device receives data

The first device can then identify the first sequence and the second sequence from the application data stream (step 753). The first device can identify the first and second sequences using any technique described in this document. In some embodiments, the first device may delay the retransmission of the application data stream while the first device identifies the first and second streams. For example, upon receipt of a CIFS stream, a WAN optimization device can wait to retransmit the stream until the tool identifies one or more strings in a file that are transmitted through the stream, so that the tool can verify compatibility. of one or more file strings in a compression history.

The first device, then, can determine that a combined sequence comprising the first sequence and the second sequence is compatible with part of a compression history (step 755). In some embodiments, the first device tool can determine compatibility when using a fingerprint method and / or the compression ratio, as described in this document. In other embodiments, the first device may use a length extension to determine compatibility. For example, when finding a match for an initial part of the first data stream, the first device can perform the byte-by-byte comparison of the received application data stream with the compatible compression history part, but omitting any headers from application-layer protocol of the byte-by-byte comparison. The compatible part of the compaction history may have been stored using the method described in relation to figure 7C.

The first device can then transmit to a second device the information that identifies the compatible part of the compression history (step 757). In one embodiment, the information identifying the compatible part of the compaction history may comprise a block identifier, a block identifier plus an offset and / or a memory address. The second device can then reconstruct the application data stream using a corresponding part of a compression history.

As an example of the above method, the first and second positive devices can be WAN optimization devices that serve as proxies for a transport layer connection between a client and a server, with the first device on the server side, and the second device on the client side. The first WAN optimization device can receive a stream of CIFS that comprises a file spread out over numerous strings separated by CIFS headers. The first device identifies that the file was previously transmitted between the first and second devices by identifying the file strings, and using the path length expansion to be compatible with the file strings in a sequential area of ​​the first device's compression history . The first device can then transmit a block identifier to the second device that identifies the compatible part of the compression history, along with the CIFS headers. The second device can then access the portion of the compression history on the second device that corresponds to the block identifier. The second device can then reconstruct the stream from the server by inserting the appropriate file strings from the second device's compression history between the CIFS headers received from the first tool. The second device can then transmit the uncompressed stream to the customer.

G. Systems and methods for synchronizing the expiration of shared compression history data

This section describes the techniques and devices for synchronizing the compression histories shared between the two devices. By maintaining a prioritized list of pieces of data in a compression history and then passing the number of pieces of data in the list to another device, two devices can maintain at least rough synchronization of compression history content. This can result in the benefit of fewer cases where a device compresses data using a reference to a piece of data not maintained by the recipient's compression history. This can also allow a device to more efficiently delete parts of data that are useless or unlikely to be used.

127 from a compression history.

Referring now to Figures 8A and 8B, a method for synchronizing compression histories shared between two devices is shown. In a brief overview, the method comprises: storing, through a first device, a first compression history, and the compression history comprises a plurality of pieces of data previously transmitted to a second device, each piece of data having a location identifier (step 801). The first device can then create an ordered list of ordered location identifiers at the time the first device last accessed a piece of data at a location that corresponds to each identifier (step 803). The second device can then delete one or more pieces of data and transmit the remaining parts to the first device. The first device receives, from the second device, the information that identifies a number of location identifiers from a corresponding second compression history on the second device (step 805); and determines whether the quantity received is less than the number of location identifiers in the first summarization history using a first quantity (step 807). The first device can then select obsolescence, from the list of location identifiers, the first number of location identifiers at the end of the ordered list that corresponds to the least recently accessed pieces of data (step 809). The first and second devices can comprise any one of a client, server, client agent, server agent, tool, WAN optimization device, and / or transparent proxy.

Still referring to figures 8A and 8B, now, in more detail, the method shown comprises: storing, through a first device, a first compression history, with the compression history comprising a plurality of pieces of data previously transmitted for a second device, each piece of data having a location identifier (step 801). This compaction history can be created and stored by any method, including the entire method described in this document. In one embodiment, the pieces of data may comprise blocks 405, and the location identifiers may comprise block identifiers and / or block and displacement identifiers. The creation of the first compression history can be synchronized with the creation of a second compression history on a second device.

The first device can then create an ordered list of ordered location identifiers at the time the first device last accessed a piece of data at a location that corresponds to each identifier (step 803). The ordered list can comprise any data structure that allows order representation that includes, without limitation, a matrix, tree, heap or linked list. The ordered list can be stored in any way, including on a disk, in memory or in any combination. For example, a long ordered list can be stored on a disk, with the active parts of the list being transferred in RAM.

In one embodiment, the last time accessed for a given part of a compression history can represent the time the part was last used to compress a data stream. In another modality, the last accessed time can represent the time in which the part was created. In yet another modality, the last accessed time can represent the time that the part was last used to compress a stream of data transmitted to a given device. In this embodiment, a device can maintain a separate ordered list for each plurality of devices to which the device transmits compressed data. In some embodiments, a device can also maintain a count of the number of location identifiers in a given ordered list.

In one embodiment, a device can keep the list sorted by moving a location identifier that corresponds to a part of the compaction history in front of the list each time the part of the compaction history is accessed. As the device creates a new part of a compression history, the device can also place the location identifier for the new part at the front of the list. For example, a device can initially create a compression history that comprises data parts A, B, C, D, E, F, G, Η, I, and J. The ordered list can then be J, I, H, G, F, E, D, C, B, A, which reflects the order in which the parts were created, with J being the most recent. If the device then receives and compresses the data that comprises the data from part F, the device can reorder the list to F, J, I, H, G, E, D, C, B, A. if the device then creates a new part, K, the list can be updated again to K, F, J, I, H, G, E, D, C, B, A. if the device then receives and compacts the data from parts C and D, the list can be updated again to D, C, K, F, J, I, H, G, Ε, B, A.

The device can also keep the list sorted by moving a location identifier that matches a piece of data to the bottom of the list if the device receives an indication that the data piece is corrupted. The device can also move a location identifier that matches a piece of data to the bottom of the list if the device receives an indication that the piece of data is no longer stored in a corresponding compression history on the second device. For example, the first device may attempt to compress a data stream by replacing a particular piece of data with a reference to an identical piece of data in the compression history. The first device, then, may receive an error message from the recipient indicating that the recipient does not have the data part in its corresponding compression history, possibly because it has been deleted to make room for the more data pieces. recently transmitted. The first device can then move the location identifier that corresponds to the data part to the end of its ordered list.

The first device can receive information from the second device that identifies a number of location identifiers from a corresponding second compression history on the second device (step 805). This information can be received by any means. In some modalities, information can be received through a control protocol used between the first and second devices. In one mode, information can be received by establishing and / or terminating communications with the second device. For example, by establishing communications between two WAN optimization devices, each can transmit the total number of blocks in a compression history that corresponds to another device. In another modality, the information can be encoded in another data stream transmitted between the two devices.

The first device can then determine whether the quantity received is less than the number of location identifiers in the first compaction history using a first quantity (step 807). For example, the first device may receive an indication that the second device has a total of 1,546 blocks in its compression history that corresponds to the first device. The first device, then, can identify that it has a total of 1613 blocks in its compression history that corresponds to the second device. In this example, the quantity received is less than the local quantity in 67 blocks. A discrepancy in block quantities can be caused by any factor, including differences in available disk space, corruption of one or more pieces of data, or different software versions.

The first device can then select obsolescence from the list of the first number of location identifiers that corresponds to the least recently used pieces of data (step 809). For example, if the ordered list of the first block device was list D, C, K, F, J, I, H, G, Ε, B, A from the example above, and the first device received an indication that the second device had only 8 blocks in its corresponding compression history, the first device can select blocks Ε, B and A for obsolescence.

In some modalities, the first device, then, can

131 disable, delete or otherwise remove the selected location identifiers from the ordered list. In one embodiment, the first device, then, can also disable, delete, or otherwise remove the pieces of data that correspond to the selected location identifiers. In some embodiments, the first device can deactivate a piece of data from a compression history only in relation to a single device, but keep the data piece active in relation to other devices.

The above method can also be coupled with a general policy of always deleting the least recently used pieces of compression history data when the parts need to be deleted. For example, a WAN optimization device located in a central office can be used to accelerate and compress communications with numerous WAN optimization devices located in branch offices. The WAN optimization device in the central office can run out of disk space for compression histories before any branch devices, since the central office device must maintain a compression history that corresponds to each of the branch devices. As the central office device transmits data to a branch A device, the central office device may be forced to delete numerous pieces of data in one of its compression histories to make room for the new pieces of data that are recorded in the compression history. In some cases, the central office device may delete parts of the compression history that correspond to device A. in other cases, the central office device may delete parts of a compression history that correspond to a different branch device. However, the central device can choose to delete the least recently used data pieces from any compression history that it chooses to delete the parts of it. Then, at a later time, the central device can transmit the total number of parts that remain in the compression history from which the parts were deleted. The device that receives the updated total number can then use the method

132 above to delete the least recently used pieces of data, allowing compression histories on the central and branch office devices to be at least approximately synchronized.

H. Systems and methods for leveraging shared compression histories and caches across more than two devices

When transmitting parts of compression history and / or compression history indexes between devices, the benefit of efficient compression of previously transmitted data can be extended beyond the two devices that do the initial transmission. Using a simple example, if device A transfers a compression history corresponding to device C to device B, devices C and B can now communicate with the ability to compress data previously transmitted between C and A. A The following section discusses the systems and method for leveraging compaction histories to provide compaction between devices other than the original transmitters.

Referring now to Figure 9A, a block diagram illustrating a modality of compaction history shared between the plurality of devices is shown. In a brief overview, a tool 200c transmits data to a tool 200a over a low performance network 104b. Tool 200c then receives a request for similar data from another tool 200b. As the tool 200c receives the response to the request, the tool can detect compatibility with the data stored in the compaction history that has been transmitted to the tool 200a. The tool 200c then sends an indication of compatibility with the tool 200b. This indication can take the form of compressing the response according to the compression and use the location identifiers that point to the tool 200a. Tool 200b, then, can request compatible data from a compression history maintained by tool 200a. After tool 200b receives the requested data from tool 200a, tool 200a can then unzip the data received from tool 200a and send it to the customer

133

102b.

Still referring to figure 9A, now, in more detail, numerous tools 200a, 200b, 200c communicate through numerous networks 104a, 104b, 104c. In some embodiments, the tools may be WAN optimization devices, and network 104b may comprise a WAN. In other embodiments, the tools can serve as transparent proxies for communications between numerous clients 102a, 102b and a server 106. The server can be on LAN 104a with the tool 200c. The two tools 200a, 200b can be on a LAN with one or more clients 102a, 102b. In one embodiment, tool 200c and server 106 can be located in a central office, and tools 200a, 200b and clients 102a 102b can be located in one or more branches. Although figure 9A shows the tools, the systems and methods described in relation to figure 9A can apply equally to clients, client agents, servers and server agents. For example, one or more tools 200a or 200b can be replaced in figure 9A by a client agent 120 that runs on a client.

In the embodiment shown, tool 200c transmits data from server 106 to tool 200a. This data can be sent in the course of responding to a request from client 102a for data from server 106. Although figure 9A shows data being sent from a server, data can come from another source , which includes another tool or a cache in the 200c tool. As data is transmitted from tool 200c to tool 200a, the two tools can store copies of the data in their respective compaction history. In one embodiment, the tools can store and record together with the stored data that indicates the tool in which the data was transmitted. For example, data can be stored in a block in tool compaction history 200c, where the block contains an indicator that the data in the block has been transmitted to tool 200a.

The 200c tool can then receive a request from

134 from tool 200b to server 106. The request can originate from a client 102b. In another embodiment, the request can originate from the same client 102a as the previous data. This modality may be applicable where more than one WAN optimization device is used to provide access for a specific branch or set of customers. Tool 200c passes the request to server 106. In other modalities, the tool can pass the request to any other computational device, or the request service uses an internal cache.

As the tool 200c receives the response to the request from server 106, the tool can detect one or more compression history compatibilities that correspond to the received data. The tool can detect these compatibilities using any method, including any fingerprint and index methods described in this document. The tool can then determine that the compatibilities correspond to the data previously transmitted to the tool 200a.

The tool 200c can then begin to transmit the data stream received from the server to the tool 200b compressed according to the compression history shared with the tool 200a. In some embodiments, tool 200c may determine that network 104b has a sufficiently low performance compared to network 104c in which the transmission of the requested data to tool 200b will be faster if they are compressed using the compaction history from the tool 200a. In other embodiments, tool 200c may have no information about the performance of networks 104b, 104c, however, still transmitting the indication to tool 200b in the hope that the transmission will be improved. In each of these modalities, tool 200c can also start transmitting the requested data to tool 200b in uncompressed form in the event that tool 200a is unavailable or no longer has the requested data in its compaction history.

Tool 200b, after receiving the compressed data stream,

135 then, you can request the indicated parts of the compaction history from tool 200a. In some cases, tool 200b may request a number of subsequent compaction history blocks.

After tool 200a receives the request for compatible parts of the compaction history, tool 200a can then transmit the requested data parts to tool 200b. In one embodiment, tool 200b, then, can store parts received in the compaction history used to speed up communications between tool 200b and tool 200c.

In another embodiment, instead of sending a compressed data stream directly to tool 200b, tool 200c can transmit a request to tool 200a to serve as an intermediary for the connection between tool 200c and tool 200b. The 200c tool can then begin transmitting the requested data stream at 200a, which uses the previous compression history to speed up transmission. Tool 200a can then route the data flow to tool 200b.

Referring now to Figure 9B, a flowchart of a modality of a method for sharing compression histories among a plurality of devices to improve data compression transmitted over a plurality of connections is shown. In a brief overview, a first device transmits to a second device a first data stream, the first data stream compressed according to a first compression history shared between the first device and the second device (step 901). The first device can receive from the third device, an indication that a third device is located on the same network as the second device. The first device receives a second data stream designed for the third device (step 903). The first device identifies that a part of the data stream is compatible with a predetermined limit on the part of the first compression history (step 905); and transmits to the third device, the information identifying the part of the first pacing history (step 907). The first, second and third devices can be any one between a client, server, client agent, server agent, tool, WAN optimization device and / or transparent proxy. In one embodiment, this method can reflect the steps performed by tool 200c in figure 9A.

Still referring to figure 9B, now, in more detail, the method comprises transmitting between a first device and a second device a first data stream, the first compressed data stream according to a first compression history shared between the first device and the second device (step 901). In one embodiment, the data stream can be transmitted from the first tool to the second tool. In another embodiment, the data stream can be transmitted from the second tool to the first tool. The data stream is compressed according to a compression history shared with the first and second devices. This compaction can be carried out in any way, including any described in this document, and the compaction history can comprise any compaction history, including any compaction history described in this document. In one embodiment, the shared compression history may already contain one or more pieces of data contained in the first data stream. In some cases, data can be transmitted uncompressed if no compatibility is found for data in the shared compression history. The shared compression history can be updated to include one or more pieces of data contained in the first data stream, not yet in the first compression history.

The first device can receive an indication that a third device is on the same network as the second device anyway (step 902). The first device can receive the indication from any source. In some embodiments, the first device can receive the indication from the second or third device. In other modalities, the first device can receive the indication from

137 from another device. In yet other modalities, the first device can be manually configured with the indication.

In one embodiment, by establishing a connection between two devices, each device can send other information that identifies one or more other devices on the same network. For example, at startup, a tool can automatically discover, using any network techniques, other tools that are located on a LAN or otherwise grouped with the tool. Each tool can, at startup, identify the other tools located in the same group.

In one embodiment, tools in the same group can exchange information that identifies a range of block identifiers that corresponds to the parts of the compression history maintained on each device. In another mode, the tools in a group can exchange information that identifies the disks held in each tool. In this way, each tool has a group and may be able to identify whether a given location identifier or block identifier corresponds to a compaction history located in another tool in the group. For example, in the case where block identifiers are created by appending the serial number to a globally unique disk identifier, each tool can send to the other tools in a group the identifier for each tool disk and a range specifying the numbers serial numbers valid for each disk identifier. In this way, when a tool in a group receives a block identifier, the tool may be able to check the disk identifier contained in the block identifier to determine whether the disk is held by a tool in the group.

After this discovery step, when the tool establishes a connection with any other tool or client agent, the tool can transmit a list of the tools locally grouped with the tool. The tool can also receive, upon establishing the connection, a list of tools or client agents on a LAN or,

138 otherwise, grouped with the connection recipient. In this way, each tool or client agent in communication with another tool or client agent can know the identities of any other local tools or client agents for the other tool or client agent. In other embodiments, any or all discoveries of clustered devices can be performed through manual configuration.

To provide a detailed example, a central office can use a group of WAN optimization tools to communicate with numerous branches, each branch also having a group of WAN optimization devices. When a tool from the central office establishes a connection with a tool in a branch, the central office tool can transmit to the branch tool the information that identifies the other tools located in the central office group. The branch tool can also transmit information that identifies the other tools located in the branch group to the central office tool. Along with this identification information, the tools can exchange any other information that refers to other tools in their respective groups, including IP addresses, capacity, performance, disk identifiers and configuration information.

The method shown then comprises receiving, through a first device, a data stream designed for the third device (step 903). The first device can receive the data stream from any source, including a client 102, server 106 or client agent 120. In one embodiment, the data stream can comprise a response from a server 106 to a client request. . For example, the first device can serve as a transparent proxy for a TCP connection between a client and a server, and the data stream can comprise a response to an HTTP request through the client. Or, for example, the data stream may comprise an ICA stream from an application server to a client agent.

The first device then identifies that a portion of the data stream is compatible with a portion of the first compression history

139 (step 905). The first device can identify compatibility using any technique, including any digital printing and indexing technique, as described in this document. In one embodiment, the first device can identify that one or more cards in the data stream are compatible with the parts of blocks stored in the first compression history. For example, a block comprising the compatible part may have a header that indicates that the data has been sent to the second device. Or, for example, a compression index entry may indicate that the compatible data portion has been transmitted to the second device. After determining that the compatible piece of data is maintained by a compression history not shared with the intended recipient, the first device can determine that the compatible piece of data is maintained by a compression history shared with a tool or other device in a group with the intended recipient.

In one embodiment, the first device can determine that a portion of the data stream is compatible with a predetermined limit portion of the first compression history. The predetermined limit can comprise any amount, percentage or distribution of data. In one embodiment, the predetermined limit can comprise a minimum number of bytes. For example, the first device can identify that at least 64 bytes of the data stream is compatible with part of the first compression history. A minimum number of bytes can be any number of bytes, including 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, and 3072 bytes. In some embodiments, the predetermined limit may require that a minimum number of compatible bytes be sequential. In other modalities, the predetermined limit may require that the minimum number of compatible bytes be found in a given distribution along the data flow. For example, a predetermined limit should require that at least 50 out of three consecutive 100-byte strings be compatible. Or, a predetermined limit should require that at least three compatible strings other than at least 64 bytes be found. In some embodiments, the predetermined limit may require that the compatible parts of the compression history be sequential. For example, the predetermined limit may require that a sequence of at least 128 bytes is compatible with a consecutive sequence of 128 bytes in the first compression history. In some embodiments, the first device may use a technique, such as those described in relation to figures 5B and 6B, to efficiently determine the existence of long sequential compatibilities. In still other modalities, the predetermined limit may require that a certain percentage of the data flow is compatible with the data in the first compression history. For example, the predetermined limit may require that 85% of a first number of bytes in the data stream be compatible with the first compression history.

In one embodiment, the predetermined limit can be automatically adjusted by the first device. In other embodiments, the predetermined limit can be manually configured. In some embodiments, the predetermined threshold can be calibrated to take into account the potential overhead using compression history blocks not maintained by the target device, however, it preferably results in a successful transfer of compression history data . For example, the predetermined threshold may be reduced in response to the slower performance of network 104b. Or, the predetermined threshold may be high, as the performance of the network that connects the first device to the second and third devices becomes faster. In another example, the predetermined threshold may be lower if the bandwidth of the connection between the first and third devices is substantially lower than the bandwidth of the connection between the second and third devices. In some embodiments, the predetermined limit may comprise the same limit for compression that uses a compression history shared with the intended recipient of the data stream. In other embodiments, the predetermined limit may be higher for cases where the compatible part or parts are not maintained by the intended recipient, but are instead maintained by a device grouped with the intended recipient of the data stream.

The first device can then transmit to the third device the information that identifies the compatible part of the first compression history (step 907). In one embodiment, this step may comprise the transmission of the data stream to the third compressed device according to the compatible parts of the first compression history. The first device can perform this compression according to the compatible parts of the first compression history, in any way. In one embodiment, the first device can replace parts of the data stream with location identifiers that identify the compatible parts of the first compression history. In this embodiment, the first device can also compress the data stream using any other techniques including, without further limiting the compression of the data stream according to a second compression history shared between the first device and the third device. In one embodiment, this step may comprise the transmission of one or more block identifiers to the third device. In another embodiment, this step may comprise transmitting one or more location identifiers to the third device. In one embodiment, the first device can also transmit information that identifies the second device.

In one embodiment, the first device may also include location identifiers for one or more parts of the first compression history that are subsequent to the identified compatible parts. The first device may include these parts based on speculation that the subsequent parts will also be compatible with the subsequent parts of the second data stream. In some embodiments, the number of subsequent parts that the first device identifies can be determined by the quality or quantity of the compatibilities found.

After the third device receives the compressed data stream

142 according to the first compression history, the third device can transmit a request to the second device for the identified parts of the first compression history. These parts can then be transmitted from the second device to the third device using any means and any protocol. In some embodiments, the third device can then signal to the first device that it has received one or more parts of the compression history. In other embodiments, the third device can transmit an indication to the first device that the identified parts of the compaction history cannot be obtained, which can occur if the second device is inoperative or busy. In these cases, the first device can then relay the data stream to the third device without compressing it according to the first compression history.

Referring now to figure 9C, a flowchart of a second modality of a method for sharing compression histories between a plurality of devices to improve data compression transmitted over a plurality of connections is shown. In a brief overview, the method comprises transmitting, between a first device and a second device, a first data stream, the first compressed data stream according to a first compression history shared between the first device and the second device ( step 911). The first device receives information that identifies a third device and a part of the first compression history (step 913) and transmits to the third device, the identified part of the first compression history (step 915). The first, second and third devices can be any one between a client, server, client agent, server agent, tool, WAN optimization device and / or transparent proxy. In one embodiment, this method can reflect the steps performed by tool 200a in figure 9A.

Still referring to figure 9C, now, in more detail, the method comprises transmitting, between a first device and a second device, a first data stream, the first compressed data stream

143 according to a first compression history shared between the first device and the second device (step 911). This step can correspond to step 901 of the previous method, and can be carried out according to any of the modalities discussed in this document. The first device can be the sender or recipient of the first data stream.

The first device, then, can receive information from a third device that identifies a part of the first compression history (step 913). In some embodiments, the information received may comprise any information transmitted in accordance with step 907 of the method previously discussed. In one embodiment, the information may also comprise a request to transmit the identified party to the third device. In another embodiment, the information can identify a plurality of parts of the first compression history to be transmitted to the third device. In another embodiment, the first device can receive numerous block identifiers. In yet another embodiment, the first device can receive a location identifier and a byte count that indicates numerous bytes that follow the location identifier to transmit to the third device.

In some embodiments, the first device can receive the plurality of transmissions from the third device with information that identifies a third device and a part of the first compression history. For example, the second device can be transmitted along the data stream to the third device, and continuously identify the parts of the data stream that are compatible with the parts of the first compression history and that, consequently, compress the stream. As the third device receives each location identifier in place of data from the data stream, the third device can request the identified part or parts of the compression history from the first device. The third device can then reconstruct the data stream using the requested parts of the first compression history.

144

The second device can then transmit the identified parts of the first compression history to the third device (step 915). The second device can transmit these parts of the first compression history using any protocol or protocols. In some embodiments, the second device can transmit a plurality of parts identified at once. In other embodiments, the second device can transmit a plurality of parts identified in a sequence.

Referring now to Figure 9D, a flowchart of a third modality of a method for sharing compression histories between a plurality of devices to improve the compression of data transmitted through a plurality of connections is shown. In a brief overview, the method comprises a first device that receives, through a first device from a second device, a data stream, the data stream compressed according to a compression history shared between the first device and a third device (step 921). The first device identifies the third device (step 923) and transmits a request to a part of the compression history to the third device (step 925). The first device receives the requested portion of the compression history from the third device (step 927). The first device can then unzip the data stream (step 929) and transmit the unzipped stream to the client (step 931). The first, second and third devices can be any one between a client, server, client agent, server agent, tool, WAN optimization device and / or transparent proxy. In one embodiment, this method can reflect the steps performed by tool 200b in figure 9A.

Still referring to figure 9D, now, in more detail, a first device receives a data stream from the second device, the data stream compressed according to a compression history shared between the first device and a third device (step 921). This step can be performed according to any modality described in this document. In some modalities, this step

145 it can correspond to the reception of a compressed data stream transmitted according to step 907 of the method in figure 9B. In one embodiment, the first device can receive a data stream that comprises numerous location identifiers, where the location identifiers identify the parts of data to be inserted into the data stream.

The first device can identify the third device in any way (step 923). In one embodiment, the third device can be on a LAN or, otherwise, grouped with the first device. The first device can use any of the discovery techniques and clustering techniques, as described in this document, to identify the third device. In some embodiments, the first device can identify the third device by determining that a disk identifier included in a block identifier in the data stream corresponds to a disk held by the third device. In another embodiment, the first device can determine that a location identifier contained in the data stream is found in a range of location identifiers disclosed by the third device.

The first device can then transmit a request for a portion of the compression history to the third device (step 925). The request can be transmitted using any protocol or protocols. In some embodiments, the request may request a plurality of parts of the compression history. In some embodiments, the first device may transmit a separate request for each of the numerous identifiers received in the data stream. In another embodiment, the first device can include more than one identifier in a single request. In some embodiments, the first device may request one or more parts of the compression history subsequent to the identified parts. For example, if the first device receives a data stream that comprises a block identifier that identifies a block maintained by the third device, the first device can transmit a request for the identified block to the third device, as well as one or more blocks subsequent This can be based on a probability that subsequent compatibilities will occur and include subsequent blocks. Or, for example, if the first device receives a data stream that comprises a location identifier that identifies 212 bytes of a block maintained by the third device, the first device can transmit a request for the identified bytes to the third device, as well as numerous subsequent bytes from the block. Numerous subsequent requested bytes can be determined in any way including, without limitation, based on a number or length of previous compatibilities.

The first device can then receive the requested portion of the compression history from a third device (step 927). The part can be received via any protocol or protocols. In one embodiment, the part may be received as a result of the third device that performs step 915 of the method previously described. In some embodiments, the first device can receive a plurality of parts of the compaction history. In some embodiments, the first device can receive all blocks from the compression history. For example, in response to a request for 514 bytes for a block, the first tool can receive the entire block containing the requested bytes. In other embodiments, the first device can receive a part of a block. The first device can also receive any additional information with the requested portion of the compression history including, without limitation, any information contained in a block header or compression index that corresponds to the requested portion.

In some modalities, after receiving the requested part of the compaction history, the first device can then insert the part of the second compaction history in one or more compaction histories on the first device (step 925). This insertion can be done by any means. In some embodiments, this step may include the incorporation of one or more blocks received from the third device in a compression history shared with the second device. In one mode, insertion can be done temporarily,

147 and blocks can be removed or deactivated after they are finished using. In another modality, insertion can occur, so that the parts are incorporated in the first compaction history as if they had been created in the normal data transmission course or from the second device.

In some embodiments, the first device can transmit an indication to the second device, upon successfully receiving the part from the third device. This indication can serve to notify the second device that it can start or continue to compress the second data stream according to the parts of the second compression. In some embodiments, the first device may transmit an indication to the second device, if the requested parts have not been received from the third device. This indication can be used to instruct the second device not to use the data pieces from the compression history to compress the data flow. The second device can also, in response to the indication, retransmit one or more parts of the data stream.

After receiving the requested portion of the compression history, the first device can unzip the received data stream (step 927). This unpacking can be done in any way. In one embodiment, the first device can replace numerous location identifiers with pieces of data identified by the location identifiers. The first device can use numerous unzipping methods. For example, the first device can first unzip the data stream using the path length unzipping method and then further unzip the data stream by using the parts received from the data compression history data. In some embodiments, the first device can also use the data pieces from a locally stored compression history to decompress the data stream.

After unpacking the data stream, the first device can transmit the data stream to a client (step 929). In other modes, the first device can transmit the data stream to any other device including a client, server or tool.

In some embodiments, the method described can be applied continuously over the course of service of one or more requests. For example, a customer at a branch office can access numerous applications from an application server in a central office that uses ICA. The branch and central office can each have groups of WAN 200 optimization tools. The ICA connection can be proxied through a first central office tool and a first branch tool. As data from the application server is transmitted via the central office WAN tool, the central office tool can determine which parts of the data have previously been sent to a second W AN optimization branch tool in the group with the first affiliate tool. The central office tool can compress data as it traverses using references to the compression history parts shared with the second branch device. As each reference in the compressed data stream is received by the first branch tool, it can send a request for the mentioned data. As each piece of data mentioned is received, the first branch tool can use the received data to reconstruct a part data stream and forward the part of the reconstructed data stream to the customer.

Referring now to Figure 10A, a block diagram of a modality of a system for sharing the compaction history indexes to speed up data transmission between the two groups of devices is shown. In a brief overview, a first data stream is transmitted between tool 200c and tool 200a, with each tool storing parts of the data stream in their respective compression histories. Tool 200a then shares a compression index that contains entries that correspond to the first data stream transmitted with tool 200d. The tool 200d, in the course of transmitting a second data stream to the tool 200b can

149 identify one or more compatibilities that correspond to the index received from tool 200c. The 200d tool can then take steps to take advantage of the compaction histories in the 200c and 200a tool to speed up transmission. In the modality shown, tool 200d requests the corresponding parts of the compaction history from tool 200c, and sends an indication of compatibility to tool 200b when compacting the second data stream using references to the compaction history shared through the tools 200a and 200c. Tool 200b, upon receipt of the compressed flow, can then request the corresponding parts of the compression history from tool 200a to unzip the data flow.

Still referring to figure 10A, now, in more detail, numerous tools 200a, 200b, 200c, 200d communicate over numerous networks 104a, 104b, 104c. In some embodiments, the tools may be WAN optimization devices, and network 104b may comprise a WAN. In other embodiments, the tools can serve as transparent proxies for communications between numerous clients 102a, 102b and a server 106. The server can be on LAN 104a with the tool 200c. The two tools 200a, 200b can be on a LAN with one or more clients 102a, 102b. In one embodiment, tools 200c, 200d and server 106 can be located in a central office, and tools 200a, 200b and clients 102a 102b can be located in one or more branches. Although figure 10A shows the tools, the systems and methods described in relation to figure 10A can apply equally to clients, client agents, servers, and server agents.

In the mode shown, tool 200c sends data from server 106 to tool 200a. In some cases, these can be a file or other data requested from server 106 by client 102a. In these cases, tools 200c, 200a can serve as transparent proxies for communication. As data is transmitted, tools 200a, 200c can store data from the transmission in

150 their respective compression histories, and store information that refers to the data in a compression index.

The 200c tool can then transmit some or all of its compaction index to the 200d tool. The 200d tool can also transmit some or all of its compaction index to the 200c tool. In some embodiments, tools 200c, 200d may be part of a tool group that contains two or more devices, all of which transmit parts of their compaction indexes to each other. Tools can be grouped in any way, and can be discovered using any technique. In this way, any tool in the group may be able to determine whether a data stream that the tool is transmitting contains numerous compatibilities with a data stream previously transmitted by any of the other tools in the group. Devices in a group can exchange compression ratios using any method. In some modalities, devices can periodically transmit updates to their compression history indexes to the other devices in the group. In other modalities, devices can transmit parts of their compression history to the other devices in the group upon initialization, or through a new device in the group. In some embodiments, devices can transmit only a portion of an index compression history to the other device in a group. In other embodiments, devices can only transmit entries from a compression index that correspond to the frequently or recently used parts of a compression history. After receiving the compaction index from tool 200c, tool 200d can integrate the received compaction index with one or more compaction indexes maintained by tool 200d. In some embodiments, tool 200d can mark the entry of indexes received from tool 200c to indicate that the index entries correspond to tool 200c. Sharing the compression history indexes between a group of devices can be useful in situations where a group of tools is providing acceleration for a

151 server, and in those situations where the same tool does not always provide acceleration for the same server in the set. In some ways, the system in figure 10A and the method shown in figure 10B can be a variation of the systems and methods shown in figures 9A-9D. Tool 200d, then, can receive a data stream from a server 106 destined for client 102b through tool 200b. The tool 200d can determine that one or more parts of this data stream are compatible with the parts of the compression index received from the tool 200c. After identifying the compatible parts, the tool 200d can send a request to the compatible parts in the tool 200c. Tool 200c can respond by transmitting the requested parts along with this step to tool 200a which can also have the requested data parts.

After receiving the compatible parts from tool 200c, tool 200d can determine whether the gears are actually compatible with the data flow. This may be necessary in cases where the compression index comprises only data fingerprints and, therefore, a byte-by-byte comparison of the parts received with the data stream may be necessary to confirm compatibility. Once compatibility is confirmed, tool 200d can send an indication of compatibility to tool 200b and replace one or more parts of the data stream with references to the compatible parts of the compaction history. The tool 200b, then, can request compatible pieces of data from tool 200a.

Tool 200b, which has corresponding parts similarly received from the compression history from tool 200a, can then unzip the data stream and transmit the data stream to client 102b.

Referring now to Figure 10B, a flow chart of a method for sharing the compression indexes between a plurality of devices to improve the compression of data transmitted through a plurality of connections is shown. In a brief overview, the

152 method comprises: receiving, through a first device from a second device, an index of entries for a compression history shared between the second device and a third device; each index entry comprising a data location identifier stored on the second device (step 1001). The first device receives an intended data stream for a fourth device (step 1003); and identifies that a part of the data stream is compatible with an index entry received (step 1005). The first device transmits a location identifier to the second device that corresponds to the compatible input (step 1007). The first device receives from the second device a portion of the compression history that corresponds to the location identifier (step 1009); and determines the compression history portion that is compatible with the data flow portion (step 1011). The first device, then, can transmit to the fourth device, this step the information that identifies the part of the compaction history (step 1013). The first, second, third and fourth devices can be any one between a client, server, client agent, server agent, tool, WAN optimization device and / or transparent proxy. In one embodiment, this method can reflect the steps performed by the tools in figure 10A, where the first device is tool 200d, the second device is tool 200c, the third device is tool 200a and the fourth device is tool 200b .

Still referring to figure 1OB, now, in more detail, the method comprises receiving, through a first device from a second device, an index of entries for a compression history shared between the second device and a third device; each index entry comprising a data location identifier stored on the second device (step 1001) The received index can comprise any type of index for the first compression history. In one embodiment, the index can comprise a compaction index 410. The index received can comprise the entire index for the first compaction history, or the index received

153 can comprise only part of the index for the first compaction history. In some embodiments, the index may comprise a specifically selected part of the index for the first compaction history. In other embodiments, the index can comprise entries from a plurality of compaction histories. In some embodiments, the first device can receive the input index after detecting that the second device is in a group with the first device. In other embodiments, the first device can periodically receive numerous index entries from the second device. The first device can also receive any other information from the second device, including a range of valid location identifiers and / or one or more disk identifiers for disks operated by the second device.

In some embodiments, the index entries received can be integrated into an existing compression index on the first device. For example, the received index may have been created using the same fingerprint method used by the third device, and the entry numbers may correspond to the entry numbers in a third party's compression index. In one embodiment, the third device can dial or, otherwise, note the entries that were received from the first device.

In another embodiment, the location identifiers in the received index entries can point to locations known to be on the first device. In some embodiments, each device in a device group can periodically transmit updated compression indexes to the other devices in the group. In this way, a device group can be created, where all essentially or partially share the same compression ratio. This can allow any individual device to take advantage of data transmissions through any of the other devices to speed up future communications. For example, a group of devices can provide WAN optimization services for a central office across numerous branches. Each device

154 at the central office you can periodically transmit some or all of your compression ratio to the other central office devices. In this way, each device in the central office may be able to take advantage of previous transmissions for a branch office to compress future transmissions to the branch office, even if the previous transmission was from a different central office device, and to a different branch device or customer. .

The first device, then, can receive an intended data stream for a fourth device (step 1003). The first device can receive the data stream from any source, including a client 102, server 106 or client agent 120. In one embodiment, the data stream can comprise a response from a server 106 to a client request. . For example, the first device can serve as a transparent proxy for a TCP connection between a client and a server, and the data stream can comprise a response to an HTTP request through the client. Or, for example, the data stream may comprise an ICA stream from an application server to a client agent.

The first device can identify that a part of the data stream is compatible with an index entry received (step 1005). In some embodiments, the first device may identify that a portion of the data stream is compatible with an index entry received before any data is transmitted to the fourth device. In other embodiments, the third device can identify that a part of the data stream is compatible with an index entry received after some data has already been transmitted to the fourth device. The first device can identify compatibility using any technique, including any digital printing and indexing technique as described in this document. In one embodiment, the first device can identify that one or more cards in the data stream have fingerprints that correspond to an entry in the received index.

In some embodiments, the first device may identify that a portion of the second data stream is compatible at a predetermined limit ending with a portion of the received index. The predetermined limit can comprise any amount, percentage or distribution of data. In one embodiment, the predetermined limit can comprise the minimum number of bytes. For example, the third device can identify that at least 64 bytes of the second data stream are compatible with the entries in the received index. The minimum number of bytes can be any number of bytes, including 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048 and 3072 bytes. In some embodiments, the predetermined limit may require that the minimum number of compatible bytes be sequential. In other embodiments, the predetermined limit may require that the minimum number of compatible bytes be found in a given distribution over the second data stream. For example, a predetermined limit should require that at least 50 compatible byte strings be found in at least three different locations in the second data stream. Or the predetermined limit must require that at least three different compatible strings with at least 64 bytes be found. In some embodiments, the predetermined limit may require that compatible index entries have location identifiers that correspond to the sequential parts of the first compression history. For example, the predetermined limit may require that a sequence of at least 128 bytes be compatible with index entries that identify a consecutive sequence of 128 bytes in the first compression history. In some embodiments, the third device may use a technique, such as those described in relation to figures 5B and 6B, which efficiently determine the existence of any long sequential compatibilities. In still other modalities, the predetermined limit may require that a certain percentage of the second data stream is compatible with the received index entries. For example, the predetermined threshold may require that 85% of a first number of bytes in the second data stream be compatible with the received index entries.

The predetermined limit can be adjusted automatically by the first device or configured manually. In some instances, the predetermined threshold can be calibrated to balance contact overhead with the first device and subsequently transfer parts of a compression history against the increased potential in transmission speed, as a result of a successful data transfer from compression history. For example, the predetermined threshold may be reduced in response to slower performance of network 104b. Or the predetermined threshold can be raised as the performance of network 104b becomes faster. In another example, the predetermined threshold may be lower if the bandwidth of the connection between the first and third devices is substantially higher than the bandwidth of the connection between the third and fourth devices.

After identifying a compatibility, the first device can transmit to the second device a location identifier that corresponds to the compatible input (step 1009). In one embodiment, the first device can transmit one or more block identifiers to the second device. In another embodiment, the first device can transmit a plurality of locations and / or block identifiers to the second device. These parts can then be transmitted from the second device to the first device using any means and any protocol. In some embodiments, the first device can then signal to the first device that it has successfully received one or more parts of the requested compression history.

In one embodiment, the first device can transmit a request to the second device to send the identified part of the first compression history to the first device. The request can be transmitted using any protocol or protocols. In some embodiments, the request may request a plurality of parts of the compression history. In some embodiments, the first device may transmit a separate request for each of the numerous identifiers received in the data stream. In another embodiment, the first device can include more than one identifier in a single request. In some embodiments, the first device may request one or more parts of the

157 compaction history subsequent to the identified parties. For example, if the first device receives a data stream that comprises a piece of data that is compatible with an index entry received from the second device, the first device can transmit a request for an identified block to the second device, as well as one or more subsequent blocks. This can be based on a likelihood that subsequent compatibilities will occur and include subsequent blocks. Or, for example, if 212 bytes of a data stream are compatible with an index entry that identifies a block held by the second device, the first device can transmit a request to the second device for the identified bytes, as well as numerous subsequent bytes. from the block. Numerous subsequent requested bytes can be determined, however, without limitation, based on a number or length of previous compatibilities.

The first device can receive from the second device a portion of the compression history that corresponds to the location identifier in any way (step 1011). The part can be received via any protocol or protocols. In some embodiments, the first device can receive a plurality of parts of the compaction history. In some embodiments, the first device can receive all blocks from the compression history. For example, in response to a 514 byte request for a block, the first tool can receive the entire block containing the requested bytes. In other embodiments, the first device can receive a part of a block. The first device can also receive any additional information with the requested portion of the compression history including, without limitation, any information contained in a block header or compression index that corresponds to the requested portion. In some embodiments, the first device may receive information that identifies other devices that may also have the block. In these modalities, the first device, then, can determine whether one of the other devices that has the block is located in a group or, otherwise, local in the fourth device.

158

The first device can then determine the compression history portion that is compatible with a portion of the data stream (step 1011). This step can be used in the modalities where an index compatibility does not guarantee that the data in the compression history is also compatible. For example, if the index is implemented using a non-exclusive fingerprint method, two separate cards can have the same fingerprint. A comparison with the data part referred to in the compaction history may be necessary to verify that a compatibility exists. In other modalities, this step can be omitted.

The first device can then transmit information to the fourth device that identifies the compression history portion (step 1013). In one embodiment, this step may comprise the transmission of the data stream to the fourth compressed device according to the compatible parts of the first compression history. The first device can perform this compression according to the compatible parts of the first compression history in any way. In one embodiment, the first device can replace parts of the data stream with location identifiers that identify the compatible parts of the first compression history. In this embodiment, the first device can also compress the data stream using any other techniques including, without further limiting, the compression of the data stream according to a second compression history shared between the first device and the third device. In one embodiment, this step may comprise the transmission of one or more block identifiers to the fourth device. In another embodiment, this step may comprise the transmission of one or more location identifiers to the fourth device. In one embodiment, the first device can also transmit information that identifies the third device.

In one embodiment, the first device may also include location identifiers for one or more parts of the compaction history that are subsequent to the compatible identified parts. The first device may include these parts on the basis of speculation that the subsequent parts will also be compatible with the subsequent parts of the second data stream. In some embodiments, the number of subsequent parts that the first device identifies can be determined by the quality or quantity of compatibilities found.

After the fourth device receives the compressed data stream according to the first compression history, the fourth device can unzip the data stream anyway. In some embodiments, the fourth device can decompress the data flow using any of the techniques described in relation to steps 921 to 931 in figure 9D. In one embodiment, the fourth device can transmit a request to the identified parts of the first compaction history to the third device. These parts can then be transmitted from the third device to the second device using any means and any protocol. In some embodiments, the fourth device can then signal to the first device that it has received one or more parts of the compression history. In other embodiments, the fourth device can transmit an indication to the first device that the identified parts of the compaction history cannot be obtained, which can occur if the second device is inoperative or busy. In these cases, the first device can then relay the data stream to the third device without compressing it according to the first compression history.

I. Systems and methods for ad-hoc cache hierarchies.

Referring now to Figure 11A, a block diagram illustrating a modality that provides an ad-hoc hierarchy of caches for serving objects is shown. In a brief overview, a tool 200a intercepts a request for an object from a client to a server. Tool 200a, after discovering that the object is not in a local cache, transmits a request to the object's server. Tool 200a also transmits numerous duplicate requests to devices that may have a cached copy of the object. These devices

160 they may include a client agent 120, a tool 200b or any other device. Tool 200a can then receive the object from any of the sources to which requests were sent. Tool 200a, then, can send the object to the customer from the first respondent.

Still referring to figure 11A, now, in more detail, tools 200a 200b and clients 102a and 102b are located in a network 104a. In some embodiments, tools 200 to 200b can be WAN optimization devices, and network 104b can comprise a WAN. In other modalities, any of the tools can comprise a proxy server, proxy cache, SSL / VPN tool, firewall and / or transparent proxy. In some embodiments, a tool can serve as transparent proxies for communications between numerous clients 102a, 102b and a server 106. In some embodiments, network 104a can comprise a LAN. The two tools 200a, 200b can be on a LAN with one or more clients 102a, 102b. In one embodiment, tools 200a, 200b and clients 102a, 102b can be located in one or more branches, and server 106 can be located in a central office. In another embodiment, there may be one or more tools on network 104c that intercept traffic to server 106. Although figure 11A shows a tool 200a, the systems and methods described in relation to figure 11A can equally apply to a client agent 120 that runs on client 102a that performs the functions of tool 200a.

In the mode shown, each of the tools 200a, 200b and the client 102b can contain a cache of objects previously transmitted through the tool. A cache can comprise any type and form of storage including, without limitation, storage in memory or disks. A data object can comprise any distinct data sequence. Examples of data objects include, but are not limited to, files, images, web pages, audio files, and executable video files. In one embodiment, data objects can be stored in a cache in a tool along with an index with the name of each

161 one of the data objects. For example, a tool can maintain a cache of files or parts of files transmitted via the tool via CIFS, and can maintain an index of filenames, so that in response to receiving a request for a particular named object, the tool you can retrieve the object with this name from the cache. In another embodiment, data objects can be stored in any other identifiers including, without limitation, location identifiers, block identifiers and fingerprints.

In some embodiments, a cache can be integrated with a compression history. For example, a tool can maintain an index of named objects that have been passed through the tool, where the index contains pointers to a part or parts of a compression history that contains the object. In one embodiment, a tool can maintain an index that is compatible with the object names for the identifiers and block offsets that identify the locations of the named objects. In other embodiments, a cache can be maintained separately from one or more compression histories.

The system shown can be used to create an ad-hoc cache hierarchy. Since requests sent to devices that may have the cached object can be sent in parallel to the request to the server, the system may not result in additional latency penalties if any of the devices do not have the cached object. The system can be used in cases where tool 200a is unsure whether an object exists in the cache of another device or is unsure whether the other device is available.

Referring now to Figure 11B, a flowchart illustrating a modality of a method for providing an ad-hoc hierarchy of caches for serving objects is shown. In a brief overview, the method comprises receiving, through a tool from a client, a first request for an object from a server (step 1101). The first device identifies that the object is not located in a first tool cache (step 1103) and forwards the first request from the

162 object to the server (step 1105). The tool transmits, before receiving a response to the forwarded request, a second request from the object to a second device (step 1107). The tool receives from at least one between the server or the second device, the object (step 1109); and then transmits the object to the customer (step 1111). In some modalities, the first tools can be any one between a client, server, client agent, server agent, tool, WAN optimization device and / or transparent proxy. In one embodiment, this method can reflect the steps performed by tool 200a in figure 11A.

Still referring to figure 11B, now, in more detail, the method comprises receiving, through a tool, a first request from a client on a server for an object (step 1101). In some modalities, the first tool can intercept the first request transparently in one or more between the client, the server, a client agent, a server agent or an intermediate tool. The first request can comprise a request transmitted through any protocol and can be received in any way. Examples of requests for an object include, without limitation, HTTP requests for files, FTP requests for files, CIFS requests for some or all files, NFS requests for some or all files, and ICA requests for one or more application objects. In one embodiment, the tool can intercept, at the transport layer, a request for an application layer object. In another mode, the tool can intercept, at the network layer, a request for an application layer object. In some modalities, the request can be transmitted through a TCP connection that the tool serves as an intermediary.

In some modalities, the tool that receives the request may be local for the customer to make the request. In other modalities, the tool that receives the request can be connected to the customer via a WAN. In yet another modality, the tool that receives the request can be connected to the customer through one or more intermediate devices. In this embodiment, the intermediate devices can comprise any one between a WAN optimization device, a VPN device, and / or a transparent proxy device.

After intercepting the request, the tool can identify that the object is not located in a tool cache in any way (step 1103). This identification can be done by any means including, without limitation: performing a cached search based on an object name, a fingerprint method, and determining that a cached copy of the object has expired or, otherwise, cannot be used. In some embodiments, this step can be omitted. For example, this step can be omitted where the first tool does not maintain a cache.

The tool can then forward the request to the server (step 1105). The first tool can transmit the request forwarded to the server using any protocol or protocols, including protocols other than the protocols used to receive the first request. In some embodiments, the forwarded request may comprise the first request. In other ways, the first tool can modify, reformat, or otherwise change the first request. For example, the first tool can encrypt some or all of the first request. In some embodiments, the tool can transmit the request to a second tool that serves as a proxy for the server. In other embodiments, the forwarded request can pass through a number of intermediate devices before reaching the server 106.

After receiving the second request, the tool can transmit, before receiving a response to the forwarded request, a second request for the object on a second device (step 1107). The second device may comprise any of a client 102, server 106, tool 200, or client agent 120. In some embodiments, the second device may comprise a browser cache. In some embodiments, the tool can determine that the object can be

164 stored on a second device when searching for a previously transmitted object index. In another mode, the tool can determine that the object can be stored on a second device by consulting a compaction history or compaction history index. In some embodiments, the tool can determine whether the object has been transmitted to the second device in a predetermined period of time.

The second device can be located at any location in relation to the tool. In some embodiments, the second device can be on a LAN with the tool. In one embodiment, the second device may comprise a second tool in a group with the tool. In another embodiment, the second device can be connected to the tool via a lower latency connection than the server to the tool.

In one embodiment, the tool can transmit the second request before receiving any response to the request from the server. In another mode, the application can transmit the second request before receiving a confirmation or other confirmation from the server that the request was received. In yet another modality, the tool can transmit the second prior request to receive any response to the request from an intermediate device between the tool and the server.

The tool can transmit a number of additional requests to the object before receiving a response to the forwarded request. In one embodiment, the tool can transmit a third request to the object on a third device. In one embodiment, the tool can transmit a request to the object in each of the numerous tools in a group. In another embodiment, the tool can send a request for the object to numerous client agents 120 on a LAN with the tool. For example, a tool at a branch office, upon receipt of a request for an object, can forward the request to a server at a central office and also send a request for the object to any other tools at the branch, in addition to one or more customers located in the branch.

In some embodiments, the tool can transmit a request for a part of the object to a first device, and a request for a second part of the object on a second device. In other modalities, the tool can divide the requested object into numerous parts and send one or more requests to each part.

Devices that receive additional requests can serve them anyway. In some embodiments, devices can locate the object and start transmitting the object to the tool anyway. In other modalities, devices can ignore requests. In other embodiments, devices can determine that the object is not cached on the device. In these modalities, the devices may or may not transmit an indication to the first device that the object has not been found. In still other modalities, the devices can forward requests to one or more additional devices.

The tool can then receive, from at least one between the server or the second device, the object (step 1109). The object can be received in any way, and through any connection or protocol. In some embodiments, the tool can begin to receive the object from a plurality of sources. In these modalities, the tool can select a source of use to receive the object.

In some modalities, the tool can select the source that answered first. In other modalities, the tool can select the source that has the highest available bandwidth. In still other modalities, the tool can select the font based on the proximity to the tool. In some modalities, the tool can cancel the request or it can restart or close the connections in other sources that transmit the object.

In some embodiments, the tool can receive a first part of the object from a first device, and a second part of the object from a second device. In these modalities, the tool can re-assemble the parts of the object received from multiple sources on the object in any way.

The tool can then transmit the object to the client in any way. In some embodiments, the tool can forward the received object from server 106. In other embodiments, the tool can transmit the received object from one or more other devices.

Although the invention has been particularly shown and described with reference to specific preferred embodiments, it should be understood by those skilled in the art that various changes in shape and detail can be made therein without departing from the spirit and scope of the invention, as defined by the claims attached.