WO2006112844A1 - Accelerateur de transactions client-serveur transparent - Google Patents

Accelerateur de transactions client-serveur transparent Download PDF

Info

Publication number
WO2006112844A1
WO2006112844A1 PCT/US2005/013269 US2005013269W WO2006112844A1 WO 2006112844 A1 WO2006112844 A1 WO 2006112844A1 US 2005013269 W US2005013269 W US 2005013269W WO 2006112844 A1 WO2006112844 A1 WO 2006112844A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction
client
server
transactions
requests
Prior art date
Application number
PCT/US2005/013269
Other languages
English (en)
Inventor
Steven Mccanne
Michael J. Demmer
Arvind Jain
David Tze-Si Wu
Original Assignee
Riverbed Technology, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Riverbed Technology, Inc. filed Critical Riverbed Technology, Inc.
Priority to PCT/US2005/013269 priority Critical patent/WO2006112844A1/fr
Publication of WO2006112844A1 publication Critical patent/WO2006112844A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols

Definitions

  • McCanne IV Auto-Discovery and Connection Interception
  • the present invention relates to data transport over networks in general and more particularly may relate to improvements in data transport at the transport level between a client and a server.
  • LAN Local Area Network
  • WAN Wide Area Networks
  • a WAN might be used to provide access to widely used and critical infrastructure, such as file servers, mail servers and networked storage. This access most often has very poor throughput when compared to the performance across a LAN. Whether an enterprise is taking a centralized approach or a distributed approach, high performance communication across the WAN is essential in order to minimize costs and maximize productivity. Enterprise IT managers today typically take one of two approaches to compensate for the performance challenges inherent in WANs:
  • the two primary causes of the slow throughput on WANs are well known: high delay (or latency) and limited bandwidth.
  • the "bandwidth" of a network of channel refers to measure of the number of bits that can be transmitted over a link or path per unit of time.
  • “Latency” refers to a measure of the amount of time that transpires while the bits traverse the network, e.g., the time it takes a given bit transmitted from the sender to reach the destination.
  • “Round-trip time” refers to the sum of the "source-to-destination” latency and the "destination-to-source” latency. If the underlying paths are asymmetric, the round-trip latency might be different than twice a one-way latency.
  • throughput is sometimes confused with bandwidth but refers to a measure of an attained transfer rate that a client-server application, protocol, etc. achieves over a network path. Throughput is typically less than the available network bandwidth.
  • the speed of light a fundamental and fixed constant, implies that information transmitted across a network always incurs some nonzero latency as it travels from the source to the destination. In practical terms, this means that sending a packet from Silicon Valley to New York and back could never occur faster than about 30 milliseconds (ms), the time information in an electromagnetic signal would take to travel that distance in a direct path cross-country.
  • this cross-country round trip time is more in the range of 100 ms or so, as signals in fiber or copper do not always travel at the speed of light in a vacuum and packets incur processing delays through each switch and router. This amount of latency is quite significant as it is at least two orders of magnitude higher than typical sub-millisecond LAN latencies. [0009] Other round-trips might have more latency. Round trips from the West
  • WAN network bandwidth limits almost always impact client-server application throughput across the WAN, but more bandwidth can be bought. With latency, lower latency cannot be bought if it would require faster than light communications. In some cases, network latency is the bottleneck on performance or throughput. This is often the case with window-based transport protocols such as TCP or a request-response protocol such as the Common Internet File System (CIFS) protocol or the Network File System (NFS) protocol. High network latency particularly slows down "chatty" applications, even if the actual amounts of data transmitted in each transaction are not large. "Chatty" applications are those in which client-server interactions involve many back-and-forth steps that might not even depend on each other.
  • CIFS Common Internet File System
  • NFS Network File System
  • the throughput of client-server applications that are not necessarily chatty but run over a window-based protocol can also suffer from a similar fate.
  • This can be modeled with a simple equation that accounts for the round-trip time (RTT) and the protocol window (W).
  • RTT round-trip time
  • W protocol window
  • the window defines how much data the sender can transmit before requiring receipt of an acknowledgement from the receiver. Once a window's worth of data is sent, the sender must wait until it hears from the receiver. Since it takes a round-trip time to receive the acknowledgement from the receiver, the rate at which data can be sent is simply the window size divided by the round trip time:
  • a TCP device attempts to adapt its window to the underlying capacity of the network. So, if the underlying bottleneck bandwidth (or the TCP sender's share of the bandwidth) is roughly B bits per second, then a TCP device attempts to set its window to B x RTT, and the throughput, T, would be:
  • the throughput would be equal to the available rate.
  • a TCP device will dynamically adjust its sending rate and continually push the network into momentary periods of congestion that cause packet loss to detect bandwidth limits.
  • a TCP device continually sends the network into congestion then aggressively backs off.
  • the slow reaction time results in throughput limitations.
  • CWS is roughly determined by the packet size (S) and the loss rate (p). Taking this into account, the actual throughput of a client-server application running over TCP is:
  • Fig. 1 is a graph that illustrates this problem from a very practical perspective. That graph shows the performance of a TCP data transfer when the network is experiencing a low degree of network loss (less than 1/10 of 1 percent) for increasing amounts of latency.
  • the bottom curve represents the TCP throughput achievable from a Tl line, which is roughly equal to the available bandwidth (1.544 Mb/s) all the way up to 100 ms latencies.
  • the top curve illustrates the performance impact of the protocol window at higher bandwidths.
  • the TCP throughput starts out at the available line rate (45 Mb/s) at low latencies, but at higher latencies the throughput begins to decay rapidly (in fact, hyperbolically). This effect is so dramatic that at a 100 ms delay (i.e., a typical cross-country link), TCP throughput is only 4.5 Mb/s of the 45 Mb/s link.
  • Fig. 1 shows, if the round trip time (RTT) is greater than a critical point (just 15 ms or so in this example) then increasing the bandwidth of the link will only marginally improve throughput at higher latency and at even higher latencies, throughput is not increased at all with increases in bandwidth.
  • RTT round trip time
  • Fig. 2 graphs a surface of throughput model derived above, presuming a TCP transfer over a 45 Mb/s T3 link.
  • the surface plots throughput as a function of both round-trip times and loss rates. This graph shows that both increasing loss and increasing latency impair performance. While latency has the more dramatic impact, they combine to severely impact performance. In environments with relatively low loss rates and normal WAN latencies, throughput can be dramatically limited.
  • Existing Approaches to Overcoming WAN Throughput Problems [0024] Given the high costs and performance challenges of WAN-based enterprise computing and communication, many approaches have been proposed for dealing with these problems.
  • this type of approach employs some sort of versioning system to keep track of version numbers of files (or data objects) so that differences between versioned data can be sent between application components across the network.
  • some content management systems have this capability and storage backup software generally employs this basic approach.
  • these systems do not deal with scenarios where data is manipulated outside of their domain. For example, when a file is renamed and re-entered into the system the changes between the old and new versions are not captured.
  • versioning cannot be carried out between the different components.
  • This approach of managing versions and communicating updates can be viewed as one specific (and application-specific) approach to compression. More generally, data compression systems can be utilized to ameliorate network bandwidth bottlenecks. Compression is a process of representing one set of data with another set of data wherein the second set of data is, on average, a smaller number of bits than the first set of data, such that the first set of data, or at least a sufficient approximation of the first set of data, can be recovered from an inverse of the compression process in most cases. Compression allows for more efficient use of a limited bandwidth and might result in less latency, but in some cases, no latency improvement occurs.
  • compression might add to the latency, if time is needed to compress data after the request is made and time is needed to decompress the data after it is received. This may be able to be improved if the data can be compressed ahead of time, before the request is made, but that may not be feasible if the data is not necessarily available ahead of time for compression, or if the volume of data from which the request will be served is too large relative to the amount of data likely to be used.
  • One way to deploy compression is to embed it in applications. For example, a Web server can compress the HTML pages it returns before delivering them across the network to end clients. Another approach is to deploy compression in the network without having to modify the applications.
  • network devices have included compression options as features (e.g., in routers, modems, dedicated compression devices, etc) [D. Rand, "The PPP Compression Control Protocol (CCP)", Request-for-Comments 1962, June 1996]. This is a reasonable thing to do, but the effectiveness is limited. Most methods of lossless data compression typically reduce the amount of data (i.e., bandwidth) by a factor of 1.5 to 4, depending on the inherent redundancy present.
  • WAN bottlenecks is to replicate servers and server data in local servers for quick access.
  • This approach in particular addresses the network latency problem because a client in a remote site can now interact with a local server rather than a remote server.
  • the challenge with this kind of approach is the basic problem of managing the ever-exploding amount of data, which requires scaling up storage, application and file servers in many places, and trying to make sure that the files people need are indeed available where and when they are needed.
  • these approaches are generally non-transparent, meaning the clients and servers must be modified to implement and interact with the agents and/or devices that perform the replication function. For example, if a file server is replicated to a remote branch, the server must be configured to send updates to the replica and certain clients must be configured to interact with the replica while others need to be configured to interact with the original server.
  • proxies transport-level or application-level devices
  • proxies function as performance-enhancing intermediaries between the client and the server.
  • a proxy is the terminus for the client connection and initiates another connection to the server on behalf of the client.
  • the proxy connects to one or more other proxies that in turn connect to the server.
  • Each proxy may forward, modify, or otherwise transform the transactions as they flow from the client to the server and vice versa.
  • proxies include (1) Web proxies that enhance performance through caching or enhance security by controlling access to servers, (2) mail relays that forward mail from a client to another mail server, (3) DNS relays that cache DNS name resolutions, and so forth.
  • Caching is a process of storing previously transmitted results in the hopes that the user will request the results again and receive a response more quickly from the cache than if the results had to come from the original provider. Caching also provides some help in mitigating both latency and bandwidth bottlenecks, but in some situations it does not help much. For example, where a single processor is retrieving data from memory it controls and does so in a repetitive fashion, as might be the case when reading processor instructions from memory, caching can greatly speed a processor's tasks.
  • file systems have employed caching mechanisms to store recently accessed disk blocks in host memory so that subsequent accesses to cached blocks are completed much faster than reading them in from disk again as in BSD Fast File System [McKusick, et al., "A Fast File System for BSD", ACM Transactions on Computer Systems, Vol. 2(3), 1984], the Log-based File System [Rosenblum and Ousterhout, "The Design and Implementation of a Log-structured File System", ACM Transactions on Computer Systems, Vol. 10(1), 1992], etc.
  • a requestor requests data from some memory, device or the like and the results are provided to the requestor and stored in a cache having a faster response time than the original device supplying the data. Then, when the requestor requests that data again, if it is still in the cache, the cache can return the data in response to the request before the original device could have returned it and the request is satisfied that much sooner.
  • Caching has its difficulties, one of which is that the data might change at the source and the cache would then be supplying "stale" data to the requestor. This is the "cache consistency" problem. Because of this, caches are often "read only” requiring that changes to data be transmitted through the cache back to the source in a "write- through” fashion. Another problem with caching is that the original source of the data might want to track usage of data and would not be aware of uses that were served from the cache as opposed to from the original source. For example, where a Web server is remote from a number of computers running Web browsers that are "pointed to" that Web server, the Web browsers might cache Web pages from that site as they are viewed, to avoid delays that might occur in downloading the Web page again.
  • the Web server operator might try to track the total number of "page views" but would be unaware of those served by the cache.
  • an Internet service provider might operate the cache remote from the browsers and provide cached content for a large number of browsers, so a Web server operator might even miss unique users entirely.
  • DNS Domain Name System
  • RR resource records
  • Clients can also send queries to relays, which act as proxies and cache portions of master name servers' stored datasets.
  • a query can be "recursive", which causes the relay to recursively perform the query on behalf of the client.
  • the relay can communicate with another relay and so forth until the master server is ultimately contacted. If any relay on the path from the client to the server has data in its cache that would satisfy the request, then it can return that data back to the requestor.
  • Web caching provides only a loose model for consistency between the origin data and the cached data.
  • Web data is cached for a period of time based on heuristics or hints in the transactions independent of changes to the origin data. This means that cached Web data can occasionally become inconsistent with the origin server and such inconsistencies are simply tolerated by Web site operators, service providers, and users as a reasonable performance trade-off.
  • this model of loose consistency is entirely inappropriate for general client-server communication such as networked file systems.
  • the consistency model must be wholly correct and accurate to ensure proper operation of the application using the file system.
  • the primary challenge is to provide a consistent view of a file to multiple clients when these clients read and write the file concurrently.
  • a condition called "concurrent write sharing" occurs and measures must be taken to guarantee that reading clients do not access stale data after a writing client updates the file.
  • NFS Network File System
  • An agent at the client maintains a cache of file system blocks and, to provide consistency, their last modification time. Whenever the client reads a block, the agent at the client checks to determine if the requested block is in its local cache. If it is and the last modification time is less than some configurable parameter (to provide a medium level of time-based consistency), then the block is returned by the agent. If the modification time is greater than the parameter, then the last-modification time for the file is fetched from the server.
  • NFS Network File System
  • NFS can employ locking via the NFS Lock Manager (NLM). Under this configuration, when the agent at the client detects the locking condition, it disables caching and thus forces all requests to be serviced at the server, thereby ensuring strong consistency.
  • NLM NFS Lock Manager
  • NFS attempts to combat latency with the well-known "read-ahead” algorithm, which dates back to at least the early 1970's as it was employed in the Multics I/O System [Feiertag and Organick, "The Multics Input/Output System", Third ACM Symposium on Operating System Principles, October 1971].
  • the read-ahead algorithm exploits the observation that clients often open files and sequentially read each block. That is, when a client accesses block k, it is likely in the future to access block k+1.
  • a process or agent fetches blocks ahead of the client's request and stores those blocks in the cache in anticipation of the client's forthcoming request. In this fashion, NFS can mask the latency of fetching blocks from a server when the read-ahead turns out to successfully predict the client read patterns. Read-ahead is widely deployed in modern file systems.
  • CIFS Server Message Block
  • each node, or network cache, in the system contains a cache of file data that can be accessed by different clients.
  • the file data in the cache is indexed by file identification information, relating the image of data in the cache to the server and file it came from.
  • a cache could enhance performance in certain cases by using read-ahead to retrieve file data ahead of a client's request and storing said retrieved data in the cache.
  • a client that opens a file must look up each component of the path (once per round-trip) to ultimately locate the desired file handle and file-based read-ahead does nothing eliminate these round-trips.
  • the system must perform complex protocol conversions between the native protocols that the clients and servers speak and the systems internal caching protocols, effectively requiring that the system replicate the functionality of a server (to interoperate with a client) and a client (to interoperate with a server).
  • a network transaction accelerator for accelerating transactions involving data transfer between at least one client and at least one server over a network, wherein a transaction involves a request and at least one response in response to the request, comprising a client-side engine coupled to a client, a server-side engine coupled to the server and a transaction predictor configured to predict, based on past transactions, which transactions are likely to occur in the future between the client and server.
  • the transaction predictor might be in the server-side engine, the client-side engine, or both.
  • the client-side engine receives indications of requests from the client, a transaction buffer for storing results of predicted transactions received from the server or the server-side engine ahead of receipt of a corresponding request, and a collator for collating the requests from the client with the stored results or received results, wherein a request and a response that are matched by the collator are identified and the matched response is provided to the client in response to the matched request.
  • the server-side engine receives indications of transactions including requests and responses and conveys requests to the server in response to actual transactions or predicted transactions.
  • the network transaction accelerators might also perform segment cloning using persistent segment storage at each end.
  • the network transaction accelerators might also comprise a transaction mapping table that maps transaction identifiers of actual requests and transaction identifiers of synthetic requests to mapped transaction identifiers, such that responses to requests are uniquely identifiable by their mapped transaction identifiers even when transaction identifiers of synthetic requests might overlap with transaction identifiers of actual requests and a transaction mapper that maps transaction to a mapped transaction identifier and replaces the transaction's identifier as received by the network transaction accelerator with the mapped transaction identifier for received requests that are forwarded toward the server and replaces the mapped transaction identifier with the replaced transaction identifier for responses that are returned toward the client.
  • Fig. 1 is a graph of throughput versus latency illustrating throughput degradation for high latencies.
  • Fig. 2 is a graph of loss rate, latency and throughput illustrating throughput degradation for high latencies or large loss rates.
  • Fig. 3 is a schematic diagram of a network using acceleration engines for accelerating transactions, possibly also for segment cloning.
  • Fig. 4 is a schematic diagram of an acceleration engine.
  • Fig. 5 is a schematic diagram of a network path between a client and a server including a pair of acceleration engines separated by a network with WAN-like characteristics, wherein the acceleration engines include transaction prediction and segment cloning.
  • Fig. 6 is a swim diagram illustrating a transaction acceleration process including predicted transactions.
  • Fig. 7 is a block diagram of one possible arrangement of a transaction predictor.
  • Fig. 8 is a swim diagram of a conventional set of transactions, including a file open, followed by a stat request, read requests and close requests.
  • Fig. 9 is a swim diagram of the requests shown in Fig. 8, with transaction prediction used to accelerate the requests.
  • Fig. 10 is a swim diagram illustrating transaction prediction performed at the client side of an engine pair.
  • Fig. 11 illustrates state diagrams for Markov models used for transaction prediction
  • Fig. 11 A illustrates a first scheme for modeling
  • Fig. 1 1 B illustrates a second scheme for modeling
  • Fig. 12 illustrates a state diagram for a Markov model used for transaction prediction including edge counts. DETAILED DESCRIPTION OF THE INVENTION
  • a transaction is a logical set of steps that result in data moving from one place to another.
  • the data being moved exists at its origin independent of the transaction, such as a file read transaction where the file exists on the disk of the server.
  • the data is generated for the transaction at the origin, such as in response to a request for computation, lookup, etc.
  • the computer, computer device, etc., initiating the transaction is referred to as the "client” and the computer, computer device, etc., that responds, or is expected to respond, is referred to as the "server”.
  • Data can flow in either direction.
  • a file system client might initiate a transaction by requesting a file read from a file server.
  • the corresponding data will be returned from the server responding to the request, so in that case, the bulk of the data flows from the server to the client.
  • the bulk of the data flows from the client to the server, either as part of the initial request or as subsequent messages.
  • a transaction can be in multiple parts, but in a simple transaction, a client sends a request (data, a message, a signal, etc., explicitly being the request or indicative of, or representing, the request) to a server and the server responds with a response (data, a message, a signal, etc., explicitly being the response or indicative of, or representing, the response) to the client. More complex transactions, for example, might involve some back and forth, as might be needed for a server to clarify a request, verify the authority of the client to receive a response to the request, get additional information needed for preparing the response, etc.
  • connection means can also be used, such as a point-to-point wired or wireless channel.
  • nodes nodes
  • a transaction might begin with a client at one node making a request for file data directed to a server at another node, followed by a delivery of a response containing the requested file data.
  • Other transactions might be a request for a specific part of a file, the entire file, all or some of another data construct, or a transaction might relate to data flowing from the requestor or relate to a command.
  • Examples of transactions include “read a block”, “read a file”, “read a stream”, “write a block with this data” (an example of data flowing from the requestor), “open a file”, “perform a calculation on this data”, “get an e-mail with these characteristics”, “send an e-mail”, “check for new e-mails", “list directory contents”, etc.
  • Some transactions might involve large amounts of data flowing in one direction or both directions. Some transactions might even involve interactions having more than one requestor and/or more than one receiver. For clarity of description, these many transaction types are described in terms of a typical simple transaction, where one client makes a request of one server and that one server responds to the request in a manner expected by the client. However, upon reading this disclosure, a person of ordinary skill will be able to apply these concepts to one-to-many and many-to-many transactions between client(s) and server(s) or more generally between two nodes. Where data flow is described in one direction, it should be understood that data might flow in the other direction and/or information might flow in only one direction, but data and/or signals flow in both directions to accomplish the movement of information.
  • client access to a server can be "tunneled” through transaction accelerators that map transactions onto sequences of variable-length segments with content-induced segment cut points.
  • the segments can be stored at various places, typically within high-speed access of both the clients and the servers, with the segments stored using a scalable, persistent naming system.
  • the segments can be decoupled from file-system and other system data blocks and structures, so that a matching segment might be found in multiple contexts. Instead of caching files, blocks, or other system dependent constructs, segments can be stored and bound to references that are used to represent the segment contents.
  • Fig. 4 illustrates one possible configuration 100 of a network that benefits from aspects of the present invention.
  • acceleration engines (“engines” for short) are interposed in or near a network path between one or more clients and one or more servers.
  • the engine is implemented entirely in software, while in other implementations the engine might be implemented in hardware, firmware or some combination of hardware, firmware and/or software.
  • engines are shown in the figures as hardware boxes, but it should be understood that the engine might be software running on a general-purpose computer or using the computing facilities of other devices on the network.
  • a special router or switch might be devised that runs the engine in software in addition to its regular function.
  • a dedicated engine appliance is deployed in the network infrastructure between client and server sites and might be based on the LinuxTM operating system.
  • the engines reduce bandwidth usage and reduce latency for transactions between clients and servers.
  • Such transactions might include copying a file from a distant file server to a local storage device, backing up remote file servers to a main data center storage device, sending a very large CAD file to a colleague over a large distance, etc.
  • transactions need not be limited to file related activities.
  • near may refer to physical proximity, but can also refer to network proximity.
  • Network proximity relates to performance attributes.
  • two nodes of a LAN might be considered more near than two nodes separated by a slow network channel.
  • engines are positioned to be in network proximity with the nodes that seek a benefit from the engines.
  • the engine is a transport-level proxy that conceptually operates in pair-wise configurations, with one engine situated near one or more servers (the "server site") and another situated near clients (the “client site”).
  • Engines communicate with one another in a paired fashion, i.e., a transaction between one client and one server might be accelerated using a particular client-side engine and a particular server-side engine.
  • Engines might be clustered and meshed across a WAN, possibly allowing any engine to communicate directly with any other engine. While one engine might be described as a client-side engine and another engine described as a server-side engine, it should be understood that engines can be symmetric, such that data could be accelerated from the client to the server or from the server to the client.
  • a given engine could be a client-side engine for one transaction and a server-side engine for another transaction, possibly involving the same network devices.
  • Engines can intercept client-server connections without interfering with normal client-server interactions, file semantics, or protocols. All client requests can be passed through to the server normally, while relevant traffic is optimized to improve performance.
  • Engine 102 is typically installed in the path so that appropriate transport connections can be intercepted and processed. At the server side, however, there is more flexibility. As shown in Fig. 4, the engine may be deployed completely out of path (engine 104), in-path directly in front of the servers (engine 106), or logically in-path but adjacent (engine 108) to a collection of servers that are load-balanced by a Layer 4 switch.
  • a device configuration model is fairly generic so that an engine can support other sorts of topologies and configurations and even potentially fit into unanticipated scenarios.
  • the client-side engine can also be deployed out of path, whereby the engine is assigned its own IP address and clients communicate directly with the client-side engine using that IP address (much as a Web client can communicate directly with a Web proxy cache using the Web cache's IP address). Optimizations
  • engines perform two core optimizations: a connection bandwidth-reducing technique called “segment cloning” (such as the segment cloning described in McCanne I) and a latency reduction and avoidance technique referred to herein as "transaction prediction”.
  • segment cloning such as the segment cloning described in McCanne I
  • transaction prediction a latency reduction and avoidance technique referred to herein as "transaction prediction”.
  • Some engines might perform just one of the two optimizations, and some engines might perform other operations as well.
  • the two optimizations can work independently or in conjunction with one another depending on characteristics and workload of the data being sent across the network.
  • Segment cloning replicates data within and across the network as described in McCanne I. This protocol-independent format reduces transmissions of data patterns that appear subsequently in the system. Rather than attempt to replicate data blocks from a disk volume, or files from a file system, or even e-mail messages or Web content from application servers and maintain the necessary consistency, engines represent and store data in a protocol- and application-independent format that represents data in variable-length, compressed data units called "segments". A working set of segments is maintained in persistent storage within each engine and cloned into other engines on demand as data flows through the engines or is proactively moved ahead of demand based on intelligent replication policies. The elegance of the approach is that quite surprisingly there are no consistency issues to be tackled even in the presence of replicated data. J0074] Engines also address latency problems using transaction prediction.
  • engines By anticipating client behavior (based on past observations of client-server dialogues), engines speculatively inject transactions on behalf of a client based on a model of its past behavior.
  • the result of the predicted transaction is buffered for a small window of time, normally at the client-side engine. When and if the client actually issues the predicted transaction, the result can be immediately returned, thereby hiding the effects of the wide-area round-trip. If the prediction fails because the client does not issue the predicted transaction within the window of time allotted for the predicted event, then the results are simply discarded.
  • the amount of time predicted results are held before being discarded can be determined by a configurable parameter and in some embodiments the time is in the range of a few seconds.
  • the transaction prediction logic can modulate its behavior and adjust its aggressiveness to limit its overall impact on the network. For example, if the server-side engine decides that it should perform a certain set of predictions on behalf of the client, it first passes the predicted results through a segmenter, e.g., as described in McCanne I. If these results are represented in a sufficiently small envelope of information (perhaps guided by the bandwidth policies described below), they can be shipped across the network to the client-side to potentially short-circuit the predicted client activity. If the results are too large, the prediction can simply be aborted, or the depth and/or scope of prediction can be reduced to adhere to prescribed bandwidth policies.
  • a segmenter e.g., as described in McCanne I.
  • Engine Architecture [0082] Though the engine might appear as an infrastructure device with network interfaces and so forth, it can be embodied almost entirely in software. This software can be delivered in an appliance form-factor: pre-configured and installed on a qualified server. For example, it might be provided as hardware and software, with software pre-loaded on a microprocessor-based server with appliance hardware running the LinuxTM operating system, Microsoft Windows, etc.
  • An engine may connect to a network with one or more network interfaces.
  • the engine could include two network interfaces.
  • an engine could utilize a dual-port network interface so that the device could be inserted transparently into a network.
  • One such configuration is to insert the device between a layer-2 switch and a router and function as an link-layer relay or bridge between said switch and said router, as illustrated by engine 200 in Fig. 5.
  • Some dual-port network interfaces include physical bypass circuits with watchdog timers that fail-over when the device malfunctions. Using a dual-ported network interface, all traffic processed by the engine can thus be intercepted and delivered to a local proxy process running on the device, e.g., using the techniques described in McCanne IV.
  • any traffic that need not be processed by the engine can be simply forwarded from one interface to the other unmodified.
  • a low-end branch office device might be a single-CPU, 1 U device with low-cost internal ATA disks.
  • Datacenter devices might have higher-performance, multi-way CPUs with an option for external storage attachment, e.g., via FiberChannel or iSCSI.
  • Some variants of the engine can be packaged as blades in a blade server or as software that could be installed on a client desktop or integrated into application server software.
  • a system employs an event-driven programming model that is SMP capable and is written in portable C++.
  • the programming model is event-based with threads hidden behind the event model, providing the concurrency mechanism needed to benefit from SMP-equipped configurations.
  • Engine 200 might comprise a set of interdependent software modules: (1) a core data processing module that runs as a user-level process, handling connection processing and implementing the segment cloning and/or transaction prediction, (2) a set of user-level processes that handle administrative tasks such as on-line configuration, monitoring, watchdog capabilities, etc., and (3) a kernel module that provides the hooks to transparently intercept client-server connections.
  • a password-protected Web server might provide GUI-based administrative access to engine 200, including an assortment of configuration, monitoring, and logging capabilities.
  • a command-line interface (CLI) might be accessible via ssh. The CLI includes a set of logging capabilities that can selectively enable log capture of many difference aspects of the running system.
  • An SNMP agent also runs on the box and supports a queryable MIB as well as a set of simple traps.
  • the Web server UI, the SNMP agent, and the CLI processes all communicate with the core engine process via a local RPC interface (as well as shared memory, in some cases).
  • a device's configuration can be stored in a single XML configuration file. These configuration files can be exported from and imported into the device via the CLI, admitting a model where centralized scripts can be developed (by the customer, an integrator, or consulting services) to control and/or configure large numbers of boxes from a central location.
  • a client-side engine interact with a server-side engine where the two engines are assumed to know about each other and to be in network proximity with the client or server for which the engines are supporting a transaction.
  • McCanne IV techniques that engines could use to find other engines in a path between a client and server might be techniques that are used for the two engines to find each other.
  • other techniques might be used, such as explicit maintenance of a set of pointers in each engine by an administrator.
  • a mapping from a destination server address to its nearest engine might be maintained in a table at the client-side engine. This table could be configured by the operator using explicit knowledge of the deployment.
  • FIG. 6 illustrates a processing pipeline whereby a client and server connection has been successfully intercepted.
  • CTX client transport module
  • STX server transport module
  • NAT network address translation
  • the server can connect to the server-side engine IP address rather than the NAT'd client address when the server-side engine is not directly in path, but this discussion assumes transparent operation at both the client and server sites.
  • the CTX and STX modules can handle all communication with outside clients and servers including connection management, flow control, buffering, and so forth.
  • the Client-Side Input Module For each incoming stream (of TCP segments or UDP datagrams or variations thereof), the Client-Side Input Module (CSIM) performs protocol-specific processing, e.g., performing transaction prediction and providing certain key hints to the segment cloning layer to improve overall performance.
  • the CSIM decides that a client request (either synthetic or actual) should be forwarded toward the server, it passes it on to the Intelligent Transport Layer (ITL), which employs segment cloning to transform the request into a thin transaction envelope (described below).
  • ITL Intelligent Transport Layer
  • the Encoder and Decoder modules implement the segment cloning scheme by processing their input against the persistent segment store and implementing the necessary protocol machinery to ensure that segments are properly transmitted and distributed.
  • TMUX Server-Side Output Module
  • SSOM Server-Side Output Module
  • the TMUX implements a virtual connection layer wherein multiple transport connections are multiplexed over a single physical transport connection between pairs of engines.
  • This layer provides a set of services analogous to the UNIXTM socket interface: connection setup and teardown, multiplexing of channels, reliable transport, etc. It also provides the foundation for implementing bandwidth policies so that the device may be configured with an aggregate rate limit by the operator.
  • the TMUX transport multiplexes all traffic
  • this connection while typically based on TCP, could be instead based on other types of reliable transport protocols where customer environments would benefit.
  • TMUX TCP transport could be modified with extensions to support high-speed TCP for Large Congestion Windows (as described in Internet Draft draft-floyd-tcp-highspeed-02.txt,
  • the TMUX transport distributes network data across multiple, parallel transport connections. For example, large amounts of data from a single client-server connection could be striped across multiple TCP connections to provide increased throughput compared to using a single TCP connection.
  • One approach for implementing the TMUX module is to add a virtual connection header to each message that flows from a CSIM to an SSIM and vice versa.
  • the virtual connection header contains a connection identifier that uniquely determines the CSIM/SSIM pair on both ends of the multiplexed communication channel. This abstraction allows multiple CSIMs to send messages to their respective SSIMs and in turn relay the messages to/from the appropriate servers (and vice versa).
  • the client/server-side input/output modules can perform needed protocol specific optimizations.
  • the client-side modules and server-side modules work in concert to implement transaction prediction, as some predictions are more appropriately carried out at the client end while others are more suited to the server end.
  • the modules can communicate with one another out of band and coordinate their actions in a way that optimizes the overall performance outcome.
  • Transaction Prediction Even with segment cloning and other techniques to reduce bandwidth usage, network links still would have an inherent latency imposed by the speed of light, which can have a dramatic impact on overall client-server throughput and performance as described above. This latency can be addressed by transaction prediction using the engines described herein. [0100] In most of these examples, a pair of engines is assumed. However, as explained the later below, it is possible to perform the transaction prediction described herein using a single engine, if paired segment cloning is not done.
  • An engine attempts to anticipate client behaviors before they occur and execute predicted transactions ahead of client activity. Once the client actually issues the predicted transaction, the transaction results can be immediately produced without incurring a wide-area round trip.
  • Predicting transactions is quite different than caching.
  • caching a cache maintains a store of data that represents data objects such as files, file blocks, Web pages, email messages, etc. where the cached data is a copy of all or part of the data object being cached. Those copies must be exact, i.e., a cache must be able to detect when its data no longer matches the official copy of the object (cache consistency) and determine how long to keep what data copies.
  • a cache needs to maintain its store and implement server-like protocol machinery to serve client requests for the cached data objects. Likewise, a cache must implement client-like protocol machinery to issue requests to the server for data that is missing from its cache.
  • Fig. 7 illustrates, by a simple example, transaction prediction.
  • the swim diagram in Fig. 7 represents the interactions for one instance of a client opening a file and sequentially reading all the blocks of that file.
  • the "open" request flows across the network through the engines (client-side engine and server-side engine) and ultimately to the origin file server.
  • the server responds with an "open” response.
  • the server-side engine Upon receiving the "open" response from the server, the server-side engine is in a position to consult its database of past client behaviors and decide, for example, that the file being opened (perhaps in the context defined by earlier transactions) is always sequentially read and closed.
  • the server-side engine can predict that the next transactions will be requests from the client for blocks of the file, requested sequentially.
  • the server-side engine can inject synthetically produced read requests into the client's session such that the server would receive those requests as if the client sent them and respond accordingly.
  • the server-side engine might further note that once the blocks have been retrieved and passed through the segment cloning subsystem, the resulting transmission to the client-side engine would require less than a hundred bytes to convey more than a megabyte of data (as an example) and use that observation to schedule transmission of the results of the synthetic read requests to the client-side engine with awareness that the transmission would have virtually no impact on the network.
  • transaction prediction can be done with many other types of client-server based software operating over a WAN.
  • client-server based software operating over a WAN.
  • this initial round-trip can also be eliminated by the engine when an access to one particular file can predict an access to another file.
  • the operating system at a client (or an agent in a network cache) would pre-fetch file data into a cache and serve that cached data to local clients from the cache thereby avoiding a round-trip to the origin server for each such read from the cache.
  • This approach creates a difficulty in interfacing the cache with access control and security mechanisms in a file system.
  • the cache When a client opens a file for data that has been cached, the cache must invoke all the mechanisms that a server would invoke to ensure that the client has permission to read the data from the cache.
  • client requests are not served from a cache but instead, client requests are predicted and injected into the client's active session so interaction between the client and the server can have precisely the same access semantics as if the client were communicating directly with the server.
  • Engines doing transaction prediction can make fairly deep predictions about the set of future transactions that are likely to occur by computing the maximum likelihood path through the Markov chain described later, or using one of many other methods for predicting client behavior. With caching, savings does not come until the cache is filled or partially filled with copies of data objects that can be served up, so first requests to a cache are always slow. With transaction prediction, requests might be anticipated at any time.
  • predicted transactions can be used to inject synthetic requests for a data ahead of the actual transaction. Additional examples of how an engine might predict a transaction will now be described below.
  • PDB prediction data base
  • the PDB could be stored in engine itself, in the engine's RAM, on its disk, or across both the RAM and disk.
  • the PDB could be stored external to the engine, e.g., on a database server, whereby the engine would communicate with said database via query and update protocols.
  • a transaction predictor might be integrated with an engine, such that each engine has its own transaction predictor, but other implementations might have transaction predictors that are separate from the engines and not require one-to-one correspondence.
  • the transaction predictor maintains a database of transaction patterns that are patterned using a Markov chain model.
  • Certain sentinel transactions represent a state in a low-order Markov model and estimates of the state transition probabilities are maintained by keeping track of the number of times each edge in the Markov chain is traversed. Over time, as more transactions are observed, transition probabilities are improved and the confidence levels increase. For transactions that are not amenable to prediction, confidence levels never increase, which informs the transaction predictor to be less aggressive in such cases.
  • a transaction predictor determines that there is a very high likelihood of a future transaction occurring, it may decide to go ahead and perform that transaction rather than wait for the response from the server to propagate back to the client and then back to the server.
  • the performance improvement in this scenario comes from the time saved by not waiting for each serial transaction to arrive prior to making the next request. Instead, the transactions can be pipelined one right after the other.
  • Predicted transactions are preferably only executed ahead of the client's actual transaction when it is safe to do so.
  • transaction predictors might be designed with enough knowledge of the underlying protocols (e.g., CIFS oplocks, etc) to know precisely when and if it is safe to do so. In cases where such predictions are unsafe, the transactions are simply relayed back to the origin server and the benefit of transaction is lost in these rare cases. Fortunately, a wide range of important applications turn out to have very predictable behaviors and, as a consequence, transaction prediction can enhance performance significantly.
  • Fig. 8 illustrates one possible arrangement of components in a transaction predictor 800. These components represent modules that comprise the higher- level CSlM and SSIM entities illustrated in Fig. 6. As shown in Fig. 8, transaction predictor 800 comprises an observer module 802, a collator module 804, a learning module 806, a predictor module 808, and a transaction ID mapping table 810. A persistent prediction database 820 is also shown. In this example, persistent prediction database 820 is part of learning module 806 and prediction buffer 830 is part of collator module 804.
  • one instance of each of the modules is invoked for client-server session or transaction stream, except that learning module 806 (and prediction database 820) operates over all sessions and streams for a global view.
  • learning module 806 and prediction database 820
  • the per-session modules are allocated to manage the data flow and perform transaction predictions.
  • the per-session modules are simply freed up and all data in any predicted requests that remains is discarded.
  • the knowledge inferred from observations of transactions patterns is stored persistently in the global learning module 806, which persists across sessions.
  • a collection of modules situated in an engine near the server may cooperate with another collection of modules situated in an engine near the client to perform cooperative transaction prediction.
  • the transaction predictor at the server-side engine may execute predicted transactions and transmit the predicted result over the network to the transaction predictor at the client-side engine.
  • the client-side engine may compute the set of predicted transactions that should be performed, communicate this information to the server-side engine to execute the predicted transactions and return the results with optional modifications or based on certain conditions.
  • Request-response protocols typically use transaction identifiers (TIDs) and those are useful in transaction prediction.
  • TIDs provide clients with an easy way to match responses with requests, and request-response protocols typically include some form of a TID in the header of each request and response message.
  • the server may copy the TID into the response message.
  • the use of TIDs allows messages to be processed out of order and/or in parallel while simultaneously allowing the client to relate each response back the request it had originally issued.
  • the transaction predictor When performing transaction prediction, the transaction predictor generates a TID to attach to each predicted transaction that is preferably distinct from any TID from any actual client-generated transaction TID.
  • the transaction predictor chooses a TID that conflicts with a TID for a client-generated transaction that is pending, the engine might erroneously match the response for the client-generated transaction with the request from the predicted transaction. Likewise, if the client chooses a TID that happens to have been used by a predicted transaction that is pending, then the responses can likewise be confused. To avoid these problems, the transaction predictor preferably tracks the TIDs of client-generated requests and ensures that conflicts do not arise. One method for accomplishing this is to map all requests onto new TIDs that are guaranteed not to collide. This mapping can be maintained in a table so that when the corresponding response arrives from the server, the TID can be mapped back to its original value. Each entry in the table could store an indication of whether the request was originally generated by the client or was synthetically generated by the transaction predictor as part of transaction prediction.
  • Observer module 802 monitors the stream of transactions and attempts to "learn" the patterns of transactions by storing certain modeling information in the persistent prediction database 820. To this end, when a client transmits a request, observer module 802 receives the request and updates learning module 806 with whatever information is required for the particular learning algorithm that is in effect. Many different approaches for the learning algorithms are possible. Some of these approaches are described herein in later sections.
  • Collator module 804 receives the request from observer module 802 once server module 802 finishes its processing. Collator module 804 consults the prediction buffer 830 tied to the client session associated with the request portion of the transaction currently being handled to see if the transaction has been predicted. The result may or may not be present, as the request might still be in transit between the client and the server. If the transaction had been predicted, then it is not sent to the server. Instead, if the response is present in the prediction buffer, then that result is returned. If the result is not present, then the request is stored in collator module 804 to wait for the response that is in transit.
  • predictor module 808 intercepts the response and queries transaction ID mapping table 810 using the transaction ID from the response to determine if the response was the result of a predicted transaction or of a normal client request. In the latter case, the response is simply forwarded to the client. In the former case, the response is stored in the prediction buffer for that transaction ID in anticipation of the corresponding request from the client. When the result is stored in this fashion, the transaction predictor also checks for a waiting request in collator module 804. If a corresponding waiting request is present in collator module 804, then the response is matched against that waiting request and sent on the client (after modifying the TID to match the TID used by the client in the successfully predicted transaction).
  • the response may be dropped from the prediction buffer. If such a request does arrive for the predicted response, then the predicted result is returned to the client (after modifying the TID to match the TID used by the client) and the response is removed from the prediction buffer.
  • predictor module 808 may decide, based on measurements or inherent knowledge of the underlying protocol and/or application, that the predicted transaction might be used again later. In this case, rather than delete the predicted response from the prediction buffer altogether, it can predict that the same response may be needed and transmit an identical synthetic request to the server. Based on inherent knowledge of the underlying protocol and/or application, if the predictor can further deduce that the result will be the same, then the value could be immediately re-saved into the prediction buffer rather than waiting for the response from the server.
  • a transaction predictor describes how predicted transactions can be synthetically injected into a client-server session and how responses can be collated with actual client requests, these operations are described independently of how particular transactions might be predicted.
  • the particular decisions about which transactions can be predicted and the particular predicted transactions can be determined in a modularized fashion. Different prediction mechanisms can be employed within such a module to provide different tradeoffs in terms of implementation overheads (storage, computation, etc.) versus the overall efficacy of the process.
  • One approach to transaction prediction is to encode static logic into the transaction predictor that recognizes common transaction patterns and performs prediction accordingly. This approach can be thought of as programming the transaction predictor with a set of "recipes". Each recipe represents a pattern or set of patterns that are to be recognized along with a set of predicted actions that can be taken on behalf of the recognized pattern.
  • recipes would typically be protocol and/or application dependent. For example, in the context of a file system, one recipe could be to recognize open-file requests that include "read access” to cause certain file reads to be performed. Similarly, an open request could cause a certain type of "star” operation to always be predicted since a stat is an inexpensive operation compared to the large round-trip associated with performing the operation across a WAN.
  • a recipe could be more complex. For example, certain specific patterns of file-system behavior could be matched against a database of static patterns that identify certain applications. Put another way, when a certain pattern is encountered, the transaction predictor can conclude with high probability that a certain application is in fact the client program (otherwise, at the network file system level there is no knowledge of what application is invoking the file system protocol). Once the transaction predictor knows what application is running, then it can perform various optimizations that have been statically configured into the system that will benefit the particular application that is running. Dynamic Prediction: A Markovian Learning Module
  • a value can be any of a number of common data types, e.g., from a simple integer result to a large buffer of data.
  • the request includes a TID, which is copied into the server response so the client can collate the responses to pending requests to allow for multiple outstanding requests and/or message reordering.
  • Fig. 9 depicts a set of transactions between a client and server that would be modeled by the prediction system.
  • This example is illustrative of a network file system protocol such as CIFS or NFS.
  • Each transaction request and response is labeled Ui, V], etc. using the terminology defined above.
  • a TID is prepended to each request and response.
  • the client opens a file for read access (U 1 ), and the server responds with a file handle to be used in subsequent operations on the file (V ⁇ ). Then, the client issues a "stat" call to retrieve various attributes about the file (U 2 ), which the server returns (V 2 ).
  • Fig. 10 shows how the example transaction sequence of Fig. 9 might be optimized across a WAN using transaction prediction.
  • the transactions flow through two engines, one near the client and one near the server.
  • Vl server-side engine
  • prediction can occur because the file is opened and the file handle is available. Presuming the learning algorithm has gathered sufficient information, predicted requests can be executed against the open file.
  • the predictor at the server-side engine generates requests U 2 , U 3 , etc. and relays the predicted results V 2 , V 3 , etc. across the network to the client-side predictor module.
  • Fig. 1 1 illustrates another approach. There, the client-side engine determines what predictions are to be carried out and sends a message summarizing those predictions to the server-side engine. At this point, because the client-side engine does not have the file handle corresponding to the open file, it cannot send the actual predicted transactions verbatim, but instead sends a template of the predicted transactions that the server-side engine executes against.
  • This template can be implemented in a number of ways including a scripting language, a byte code program for a virtual machine, or a template definition that defines a data structure that can be interpreted by the server-side engine. Building the PDB
  • the Markov model managed by learning module 806 is stored the persistent prediction database (PDB).
  • PDB persistent prediction database
  • Each state represents a single request (i.e., an opcode and literal parameters), or in higher-order Markov models, could actually represent a fixed-length sequence of requests.
  • An "edge” represents a predictive relationship between states. In different embodiments of transaction predictors, an edge may represent different aspects of correlation between subsequent transactions. To develop the model, suppose Si and Sj are two states representing requests Ui and Uj. Then, some example schemes for mapping transaction sequences onto states and edges in the Markov model are as follows:
  • Each state has a limited number of edges, say N, originating from it. Whenever a request Uj follows Ui in exact sequence in one or more observed client-server transaction streams, then an edge (Si, Sj) is added to the PDB. If the number of edges emanating from Si exceeds N, then the least recently referenced such edge is removed from the PDB. This not only limits the amount of storage required for the PDB, but it can also improve the system's speed of adaptation.
  • Fig. 12 illustrates Markov models representing Scheme 1 and Scheme
  • the present invention embodies higher order Markov chains. For example, in a second-order model, each state would represent two adjacent transactions so that the transition probability would be dependent on the current transaction and previous transaction (yet remain independent of all prior transactions). [0146] To compute the Markov chain transition probabilities, learning module
  • each edge is a count of how many times it has been logically traversed (i.e., how many times the two transactions represented by the head and tail of the edge have been encountered adjacent to each other). For each new transaction encountered, the set of edges that are logically traversed by the observation are computed and the edge counts are updated according to the definition of the edge (as outlined in the various schemes defined above). Then the probability of each edge emanating from a particular state can be computed as that edge's count divided by sum of all the edges' counts emanating from that state.
  • Fig. 13 illustrates how edge counts can be used to make predictions.
  • the transaction predictor may choose to perform requests U 3 and U 4 or not depending on the level of aggressiveness desired.
  • the transaction predictor could allocate a certain bandwidth budget to predictions and perform them only if there is available bandwidth to ship the resulting data across the network.
  • the decision to execute predicted transactions could be tied to the segment cloning system described above. For example, if the result of U 3 and U 4 after passing through the segmentation scheme are represented in just a few bytes, the cost for sending the results across the network are virtually free so the transaction predictor can afford to be aggressive.
  • the transaction predictor can explore multiple paths through the Markov model simultaneously in a way that controls the impact on the underlying network.
  • learning module 806 may impose a limit on the amount of state that is maintained. Different algorithms may be used to decide which entries to remove from PDB 820 as they become old or infrequently used. For example, a node that corresponds to an operation on a file that has been removed from the file system would eventually be deleted. Because PDB 820 provides a predictive optimization and it is not relied upon for correct operation of the protocol, PDB 820 can maintain a fixed number of entries that are aged and replaced as necessary.
  • Attached to this state could be dynamically collected information such as how frequently this file is opened and read in its entirety, whether this file is always read sequentially or randomly, how often this file is written to, how and when "stat" operations are applied to this file, how often is this file opened in error, etc.
  • a predictor when a predictor sees (or predicts) an open for a particular file, it can perform a set of predicted transactions that are synthesized using a combination of logic and the dynamic information collected. For example, if the predictor knows that 99% of the time the file is written to and never read, then no predictions might be carried out (because the writes cannot be normally predicted by the predictor). However, if the predictor knows that 99% of the time the file is opened, a few blocks are read, then the file is closed, then usually all of the requests can be effectively predicted and transmitted across the network ahead of the actual requests.
  • segment cloning can be driven either by client activity or by a server-side process that proactively distributes segments from a server-side engine to one or more client-side engines.
  • a server-side process that proactively distributes segments from a server-side engine to one or more client-side engines.
  • an engine might simply expose a protocol interface for PSD so that external agents can be built that perform such functions, e.g., for content distribution, file system replication, e-mail delivery, and so forth.
  • the HTTP message's header is extended (as the protocol allows) to include the destination IP addresses of the client-side engines as well as authentication information.
  • the HTTP post message's body contains raw data.
  • the server-side engine Upon receiving a PSD request, the server-side engine simply pushes the data through the segment-cloning system to the desired client sites. Each client-side engine receives the corresponding segments, updates its segment store, and otherwise discards the original data buffer. In this fashion, the segment store can be pre-populated with data that an external site might know will be of use at that location.
  • the engine architecture effects an important separation of policy and mechanism, i.e., the mechanism for performing PSD is factored out from the myriad of agents that could be built to implement various sorts of replication logic.
  • This approach is powerful for at least two reasons. First, it allows interesting integration opportunities to be implemented in customer environments either by the customer itself or by consultants. For example, a customer might have an existing business application that could benefit from the ability to move data proactively out of an application server and into client-side engines. With the PSD interface, this could be carried out quite easily in many cases. [0159] Secondly, this approach allows engines to integrate easily with existing server systems.
  • an agent could be placed inside a file server that monitored file system activity and based on configured policies, performed segment distribution in response to file changes.
  • This approach is quite elegant because it achieves most all the benefits of file system mirroring without actually having to mirror the file system.
  • the client site can remain 100% synchronized with the master file server because engines logically send all transactions back to the server (even though the data might be actually mirrored and not sent over the network when a client accesses it).
  • transaction accelerators can inject transactions toward the server in anticipation of client needs and provide the response to the client with less latency.
  • the accelerators can short-circuit a client transaction and not forward it on to the server if the accelerators can ensure the semantics of the underlying protocol are preserved.
  • accelerators need not have complete information about the underlying protocol and just match up requests and responses, while the server (or other element) ensures that an accelerator is not given data in a manner that a client would get data that is incorrect.
  • transactions can be injected aggressively toward the server with little resulting impact on the network, thereby providing greater transaction performance to the end client.
  • protocol specific enhancements might be used. For example, where a protocol includes response packets, a client might initiate a file open transaction by sending a file open request.
  • One of a pair of accelerators client-side, server-side
  • client-side, server-side might predict a transaction and generate a synthetic request to the server, such as a request to read the first block of the file that is being opened.
  • the server-side accelerator might then receive the response to the read request and include that data in a response message send back to the client acknowledging the file open request.
  • the client-side accelerator could then store that read data and use it to make up a response for the client request for a file read, if and when that client request comes in as predicted. Summary
  • distributed infrastructure can have a performance as if it were centralized, thus allowing key assets to be centralized rather than being duplicated at multiple distributed sites.
  • One advantage of this is that systems that assume that they are local resources, and behave accordingly on a network, can be implemented remotely while maintaining the performance of local access.
  • Transaction prediction processes take advantage of the highly predictable nature of most applications and can pipeline multiple transaction requests into single transactions whenever possible. Notably, transaction prediction also works where some transactions are not predictable and others are partially predictable. Transaction prediction might result in a synthetic transaction request being generated in advance of the actual request, with the results of the synthetic transaction being held until the predicted transaction actually occurs. [0164] In addition to better supporting systems that expect local access levels of performance, acceleration engine is as described herein can enable new services that are otherwise impractical, such as remote branch office database backups.
  • the acceleration engine can be implemented without client or server changes and can thus be entirely transparent. Furthermore, with the automatic proxy discovery mechanisms and techniques described in McCanne IV, engines can pair up to provide improved network performance without the clients or servers even needing to be aware of the presence of the acceleration engines.
  • the acceleration engines need not be tied to any particular protocol or application. Some versions might support a limited set of commonly used protocols (i.e., CIFS, NFS, HTTP, FTP, WebDAV, Remote Backup, etc.), with extensibility over time as users dictate.

Abstract

Dans un réseau qui transfert des demandes de clients à des serveurs et des réponses de serveurs à des clients, un accélérateur de transactions de réseau sert à accélérer des transactions concernant des transferts de données entre au moins un client et au moins un serveur par le réseau, cet accélérateur comprenant un moteur côté client, un moteur côté serveur et un prédicteur de transactions conçu pour prévoir, sur la base de transactions passées, quelles transactions sont susceptibles d'avoir lieu dans le futur entre clients et serveurs. Le prédicteur de transactions peut-être intégré dans le moteur coté serveur, le moteur coté client ou dans les deux. Le moteur côté client, qui reçoit des indications de demandes émises par le client, comprend un tampon de transactions stockant les résultats de transactions prévues reçues de la part du serveur ou du moteur coté serveur avant la réception d'une demande correspondante, ainsi qu'un collecteur qui collecte les demandes émises par le client avec les résultats stockés ou reçus, une demande et une réponse mises en correspondance par le collecteur étant identifiées et la réponse étant fournie au client pour répondre à la demande correspondante. Le moteur côté serveur reçoit des indications de transactions, y compris des demandes et des réponses, et il transmet des demandes au serveur en réponse à des transactions effectuées ou prévues.
PCT/US2005/013269 2005-04-18 2005-04-18 Accelerateur de transactions client-serveur transparent WO2006112844A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/US2005/013269 WO2006112844A1 (fr) 2005-04-18 2005-04-18 Accelerateur de transactions client-serveur transparent

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2005/013269 WO2006112844A1 (fr) 2005-04-18 2005-04-18 Accelerateur de transactions client-serveur transparent

Publications (1)

Publication Number Publication Date
WO2006112844A1 true WO2006112844A1 (fr) 2006-10-26

Family

ID=35124607

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2005/013269 WO2006112844A1 (fr) 2005-04-18 2005-04-18 Accelerateur de transactions client-serveur transparent

Country Status (1)

Country Link
WO (1) WO2006112844A1 (fr)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7953912B2 (en) 2008-02-22 2011-05-31 International Business Machines Corporation Guided attachment of accelerators to computer systems
US8250578B2 (en) 2008-02-22 2012-08-21 International Business Machines Corporation Pipelining hardware accelerators to computer systems
US8726289B2 (en) 2008-02-22 2014-05-13 International Business Machines Corporation Streaming attachment of hardware accelerators to computer systems
US8775663B1 (en) 2007-04-25 2014-07-08 Netapp, Inc. Data replication network traffic compression
WO2021228379A1 (fr) * 2020-05-13 2021-11-18 Telefonaktiebolaget Lm Ericsson (Publ) Transfert de données d'un second nœud à un premier nœud

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0813326A2 (fr) * 1996-06-14 1997-12-17 International Business Machines Corporation Dispositif et procédé pour la production de réponses prédictives
WO2001063420A1 (fr) * 2000-02-22 2001-08-30 Flash Networks Ltd. Systeme et procede permettant d'accelerer les interactions client/serveur par utilisation de requetes predictives
US20040088376A1 (en) * 2002-10-30 2004-05-06 Nbt Technology, Inc. Transaction accelerator for client-server communication systems
US20040215746A1 (en) * 2003-04-14 2004-10-28 Nbt Technology, Inc. Transparent client-server transaction accelerator

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0813326A2 (fr) * 1996-06-14 1997-12-17 International Business Machines Corporation Dispositif et procédé pour la production de réponses prédictives
WO2001063420A1 (fr) * 2000-02-22 2001-08-30 Flash Networks Ltd. Systeme et procede permettant d'accelerer les interactions client/serveur par utilisation de requetes predictives
US20040088376A1 (en) * 2002-10-30 2004-05-06 Nbt Technology, Inc. Transaction accelerator for client-server communication systems
US20040215746A1 (en) * 2003-04-14 2004-10-28 Nbt Technology, Inc. Transparent client-server transaction accelerator

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
AMER A ET AL INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS: "File access prediction with adjustable accuracy", CONFERENCE PROCEEDINGS OF THE 2002 IEEE INTERNATIONAL PERFORMANCE, COMPUTING, AND COMMUNICATIONS CONFERENCE. (IPCCC). PHOENIX, AZ, APRIL 3 - 5, 2002, IEEE INTERNATIONAL PERFORMANCE, COMPUTING AND COMMUNICATIONS CONFERENCE, NEW YORK, NY : IEEE, US, vol. CONF. 21, 3 April 2002 (2002-04-03), pages 131 - 140, XP010588364, ISBN: 0-7803-7371-5 *
PADMANABHAN VENKATA N ET AL: "Using predictive prefetching to improve World Wide Web latency", IEEE TRANSACTIONS ON ANTENNAS AND PROPAGATION, IEEE INC. NEW YORK, US, vol. 26, no. 3, July 1996 (1996-07-01), pages 22 - 36, XP002104433, ISSN: 0018-926X *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8775663B1 (en) 2007-04-25 2014-07-08 Netapp, Inc. Data replication network traffic compression
US7953912B2 (en) 2008-02-22 2011-05-31 International Business Machines Corporation Guided attachment of accelerators to computer systems
US8250578B2 (en) 2008-02-22 2012-08-21 International Business Machines Corporation Pipelining hardware accelerators to computer systems
US8726289B2 (en) 2008-02-22 2014-05-13 International Business Machines Corporation Streaming attachment of hardware accelerators to computer systems
WO2021228379A1 (fr) * 2020-05-13 2021-11-18 Telefonaktiebolaget Lm Ericsson (Publ) Transfert de données d'un second nœud à un premier nœud

Similar Documents

Publication Publication Date Title
US8069225B2 (en) Transparent client-server transaction accelerator
US8856222B2 (en) Transaction acceleration for client-server communication systems
US7139811B2 (en) Double-proxy remote data access system
US9930099B2 (en) Hybrid segment-oriented file server and WAN accelerator
US9172620B2 (en) Cooperative proxy auto-discovery and connection interception
US8463843B2 (en) Throttling of predictive ACKs in an accelerated network communication system
EP1570365B1 (fr) Accelerateur de transactions pour systemes de communication client-serveur
US20020161860A1 (en) Method and system for differential distributed data file storage, management and access
US20040128427A1 (en) Method and system for responding to file system requests
US20090319600A1 (en) Optimizing program requests over a wide area network
JP2004342069A (ja) データ・キャッシュ方法およびデータ・キャッシュ装置
WO2006112844A1 (fr) Accelerateur de transactions client-serveur transparent
WO2006112845A9 (fr) Distribution de contenu fondee sur l'affinite de l'utilisateur utilisant des mandataires d'extremites de connexion
Clark Optimising the Web for a GPRS link
Mohare Web Proxy Mechanisms for Wireless Networks

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

NENP Non-entry into the national phase

Ref country code: RU

122 Ep: pct application non-entry in european phase

Ref document number: 05753930

Country of ref document: EP

Kind code of ref document: A1