Abstract:
Two or more network traffic processors connected with the same LAN and WAN are identified as neighbors. Neighboring network traffic processors cooperate to overcome asymmetric routing, thereby ensuring that related sequences of network traffic are processed by the same network proxy. A network proxy can be included in a network traffic processor or as a standalone unit. A network traffic processor that intercepts a new connection initiation by a client assigns a network proxy to handle all messages associated with that connection. The network traffic processor conveys connection information to neighboring network traffic processors. The neighboring network traffic processors use the connection information to redirect network traffic associated with the connection to the assigned network proxy, thereby overcoming the effects of asymmetric routing. The assigned network proxy handles redirected network traffic in much the same way that it would handle network traffic received directly.

Description:
CROSS-REFERENCES TO RELATED APPLICATIONS 
     This application is a divisional application of U.S. Nonprovisional patent application Ser. No. 11/377,906, filed Mar. 15, 2006, which claims priority to U.S. Provisional Patent Application No. 60/663,366 filed on Mar. 18, 2005, which is incorporated by reference herein for all purposes. 
     This application is related to U.S. patent application Ser. No. 10/285,315, filed 30 Oct. 2002, entitled “Transaction Accelerator for Client-Server Communication Systems,” hereafter referred to as “McCanne I”; and U.S. patent application Ser. No. 10/640,562, filed 12 Aug. 2003, entitled “Cooperative Proxy Auto-Discovery and Connection Interception,” hereafter referred to as “McCanne IV,” each of which are incorporated by reference herein for all purposes. 
    
    
     BACKGROUND OF THE INVENTION 
     The present invention relates to field of data networks and specifically to systems and methods of improving network performance. Network proxies and other types of network devices can be used to cache or store network data, accelerate network traffic, or otherwise control or affect network traffic between clients and servers. 
     As used herein, “client” generally refers to a computer, computing device, peripheral, electronics, or the like, that makes a request for data or an action, while “server” generally refers to a computer, computing device, peripheral, electronics, or the like, that operates in response to requests for data or action made by one or more clients. A computer or other device may be considered a client, a server, or both depending upon the context of its behavior. 
     As used herein, a request can be for operation of the computer, computing device, peripheral, electronics, or the like, and/or for an application being executed or controlled by the client. One example is a computer running a word processing program that needs a document stored externally to the computer and uses a network file system client to make a request over a network to a file server. Another example is a request for an action directed at a server that itself performs the action, such as a print server, a processing server, a database server, a control server, and equipment interface server, an I/O (input/output) server, etc. 
     A request is often satisfied by a response message supplying the data requested or performing the action requested, or a response message indicating an inability to service the request, such as an error message or an alert to a monitoring system of a failed or improper request. A server might also block a request, forward a request, transform a request, or the like, and then respond to the request or not respond to the request. Generally, a request-response cycle can be referred to as a “transaction” and for a given transaction, some object (physical, logical and/or virtual) can be said to be the “client” for that transaction and some other object (physical, logical and/or virtual) can be said to be the “server” for that transaction. 
     A client issues request messages to a server, which typically delivers a response message to each request message back to the client. As described in McCanne I and McCanne IV, a network proxy communicating with one or more peer network proxies can provide transaction acceleration, traffic reduction, and other functions over a wide area network interposed between two local area networks (LANs). Typically, in such a configuration, a client&#39;s request is intercepted by a client-side network proxy, which is connected with the client via a client LAN, and delivered via the WAN to a server-side network proxy. The server-side network proxy delivers the client request message to the server via a server LAN. The request message may be transformed or processed by the two proxies so that the request message (and possibly future request messages) are more effectively transported across the intervening network than would be true without the use of the cooperating network proxies. A message generally can be structured in any format or data structure suitable for conveying information over a communications network, including a single network packet or multiple network packets. 
     In these proxy-based systems, packets sent from the client are received at the client-side proxy; packets from the client-side proxy are received at the server-side proxy; and packets from the server-side proxy are received at the server. In many networks, these arrangements from client to server are sufficient to ensure the reverse direction of communication from server to client as well, viz. that packets from the server are received at the server-side proxy, packets from the server-side proxy are received at the client-side proxy, and packets from the client-side proxy are received at the client. 
     However, in some network environments this reverse direction of communication is more problematic. In particular, a LAN including a client or server can have multiple redundant connections with the WAN. As a result, asymmetric routing can produce situations in which a response packet from server to client may traverse a different path than the path used by a request packet from client to server. Where the proxies can rearrange the communication between client and server without the knowledge or participation of the client or server, reverse traffic that bypasses the proxies and their hidden cooperative arrangements can cause performance degradation or a total failure of the proxied connection between client and server. This problem with network proxies and asymmetric routing is mentioned in “Transparent Proxy Signalling,” Knutsson, Bjorn and Peterson, Larry, Journal of Communications Networks, March 2001; however, no solution to this problem is proposed. 
     It is therefore desirable for a system and method to override the effects described here. It is further desirable for the system and method to redirect related sequences of network traffic through the appropriate WAN or other network connection. It is additionally desirable for the system and method to remain transparent to clients and servers while redirecting network traffic through the appropriate WAN or other network connection. 
     BRIEF SUMMARY OF THE INVENTION 
     In an embodiment of the invention, two or more network proxies connected with the same LAN and WAN are identified as neighbors, for example by including explicit configuration of network proxies or by an inference of a neighbor relationship from other information available. Network proxies that are neighbors cooperate to overcome the effects of asymmetric routing and other effects by forwarding packets to each other as necessary, such as to ensure that related sequences of network traffic are processed by the same network proxies. 
     In an embodiment, the proxy in a neighbor group that intercepts a new connection initiation by a client, for example by receiving a SYN packet, is considered the “owning proxy” of that connection. Upon receiving a new connection initiation by a client, the owning proxy first conveys to all of its neighboring proxies identifying information about the new connection, then opens its inner connection across the WAN to a counterpart network proxy to further communicate the new connection initiation of the client. In some cases, the information is not conveyed to all neighboring proxies, but to some of them. In such cases, it might help to simply consider that the uninformed neighboring proxies are not in fact neighbors even though they might qualify to be neighbors. 
     In an embodiment, the other proxies in the neighbor group use the identifying information they have received from the owning proxy to handle packets that might otherwise bypass the owning proxy due to asymmetric routing or other network behaviors. A neighbor proxy that receives a packet matching the identifying information might alter the addressing information of the packet so that it is received by the owning proxy. The owning proxy then can be expected to handle the packet in much the same way that it would handle a packet that it had received directly. 
     In an embodiment, a neighbor relationship can be explicitly ended by the owning proxy or the neighbor proxy. When a neighbor relationship is ended, the neighbor proxies discard the identifying information. In another embodiment, a neighbor proxy can use the identifying information to query the owning proxy for the status of the corresponding connection. The neighbor proxy discards that information if the owning proxy indicates that the connection has closed, or if the owning proxy does not recognize the connection, or if the owning proxy fails to respond. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The invention will be described with reference to the drawings, in which: 
         FIG. 1  illustrates an example network and potential problems caused by asymmetric routing. 
         FIGS. 2A and 2B  illustrate examples of networks and improved network traffic flow according to embodiments of the invention. 
         FIG. 3  illustrates an example of the information maintained by a neighboring network connection according to an embodiment of the invention. 
         FIG. 4  illustrates a method of initiating a new connection according to an embodiment of the invention. 
         FIG. 5  illustrates a method of processing network traffic associated with a connection according to an embodiment of the invention. 
         FIG. 6  illustrates an additional network according to an embodiment of the invention. 
     
    
    
     In the drawings, the use of identical reference numbers indicates similar components. 
     DETAILED DESCRIPTION OF THE INVENTION 
       FIG. 1  illustrates an example network  100  and potential problems caused by asymmetric routing.  FIG. 1  shows communication between client  110  and server  150  across a wide-area network (WAN)  130 , where the communication is mediated by two proxies, a client-side proxy  120  and a server-side proxy  140 . In this example network configuration, a message  115  sent by client  110  and addressed to server  150  is intercepted by client-side proxy  120 . Client-side proxy  120  sends message  135  to server-side proxy  140 . 
     In some applications, message  135  is identical to message  115 . In other applications, for example if client-side proxy  120  includes network acceleration or caching functions, client-side proxy  120  transforms message  115  into an equivalent message  135  that may differ from message  115  in many ways, including size, encoding, framing, addressing, or other aspects. The server-side proxy  140  receives message  135  and transforms it into message  145 , which is identical to, or an acceptable substitute for, original message  115 . As network  100  is configured, the two proxies  120  and  140  are invisible in their effect: client  110  and server  150  send and receive messages that are identical to, or an acceptable substitute for, what would occur if message  115  were simply sent directly to server  150  from client  110 . 
     A similar process applies to messages sent in the reverse direction: message  155  is addressed to client  110  but is intercepted by server-side proxy  140 . Server-side proxy  140  sends message  165  to client-side proxy  120 . In some applications, message  165  is a transformation of message  155 . Message  165  may differ from message  155  in many ways, including size, encoding, framing, addressing, or other aspects. The transformation that produces message  165  from message  155  may be entirely different from the transformation that produced message  135  from message  115 . When received by client-side proxy  120 , message  165  is transformed into message  175 , which is identical to, or an acceptable substitute for, original message  155 . Some improvements that such interceptions can provide are shown in McCanne I. 
     In some applications, client-side proxy  120  and server-side proxy  140  form an association with the first passage of messages from client  110  to server  150  via client-side proxy  120  and server-side proxy  140 . Information about that association is used to arrange a similar transformation for messages sent in the reverse direction. 
     Asymmetrical routing occurs when an initial message and a subsequent message between the client  100  and the server  150  pass through one or more different network proxies or other LAN to WAN connections. This can occur if there are redundant links between WAN  130  and server  150  or client  110 . One or more redundant links are commonly used for load balancing and improved reliability. As shown in  FIG. 1 , server  150  is connected with WAN  130  via server-side proxy  140  and an additional server-side proxy  141 . 
     In the example shown, if conventional network routing schemes are employed, there is no guarantee that messages from server  150  to client  110  will traverse the identical link that was traversed by messages from client  110  to server  150 , resulting in so-called asymmetric routing. For example, an initial communication between client  110  and server  150 , using messages  115 ,  135 , and  145 , passes through server-side proxy  140  to reach server  150 , but the response might not. 
     For example, a return communication of message  156  may be intercepted by a different server-side proxy  141 . Server-side proxy  141  does not know about client-side proxy  120  or the association between client-side proxy  120  and server-side proxy  140 . As a result, the server-side proxy  141  treats message  156  as it would any other message that it received without additional information, e.g., passing it through unaltered as message  166 . Message  166  then crosses the WAN  130  on its way to client  110 . In some arrangements, message  166   a  is received directly by client  110 , since it is addressed to client  110 ; in other arrangements, client-side proxy  120  intercepts all traffic to client  110 , but will pass message  166   b  through unaltered to client  110  as message  176 . In either case, the message  156  originally sent from server  150  to client  110  does not benefit from the association of client-side proxy  120  and server-side proxy  140 . 
     Such “one-sided” or “half-way” communication means that only one direction of traffic can benefit from the transformations performed by proxies  120 ,  140 , and  141 . In some cases, such communication patterns may violate rules for communication between client  110  and  150 , leading to communication breakdown. A similar problem occurs when there is no second server-side proxy  141  or when no server-side proxy  140 ,  141  receives message  156 , so that it is simply sent unchanged from server  150  to client  110 . 
       FIG. 2  illustrates example networks having improved network traffic flow according to embodiments of the invention.  FIG. 2A  illustrates a network  200  similar to network  100  described above. In an embodiment of the invention, server-side proxies  240  and  241  of network  200  have been configured as neighbors, so each can communicate with the other and/or has some awareness of the other. 
     A message  215  sent by client  210  and addressed to server  250  is intercepted by client-side proxy  220 . The client-side proxy  220  sends message  235  to a server-side proxy  240 . Message  235  may be identical to message  215  or a transformation of message  215  that differs in ways including size, encoding, framing, addressing, and/or other aspects. 
     When message  235  is received by server-side proxy  240 , an additional step takes place if message  235  is the establishment of a new client/server connection: in such a case, server-side proxy  240  provides new-connection information  248  derived from message  235  to neighbor server-side proxy  241 . Neighbor server-side proxy  241  stores that new-connection information  248  and associates it with owning server-side proxy  240 . 
     Server-side proxy  240  also transforms message  235  into message  245 , which is identical to, or an acceptable substitute for, original message  215 . Thus, the two proxies  220  and  240  are invisible in their effect: client  210  and server  250  send and receive messages that are identical to, or an acceptable substitute for, what would occur if message  215  were simply sent directly to server  250 . For example, network traffic communicated from server-side proxy  240  to server  250  might have the source address of client  210 . 
     For communications between the server  250  and the client  210 , neighbor server-side proxy  241  may receive message  246  addressed to client  210  from server  250 . Upon receiving communications, such as message  246  from the server  250 , neighbor server-side proxy  241  uses its stored new-connection information  248  to determine that message  246  belongs to a connection made through server-side proxy  240 . Of course, server-side proxy  240  can receive the message and handle it directly. Such message flows are not shown in  FIG. 2A , but might be expected to proceed as shown in  FIG. 1 . 
     In response to this determination, server-side proxy  241  forwards message  247  to server-side proxy  240 , in effect “forwarding” the connection to its handling proxy. Server-side proxy  240  then processes message  247 . Using information about its association with client-side proxy  220 , server-side proxy  240  transforms message  247  into message  244 , which is in turn sent across WAN  230 . Client-side proxy  220  then transforms message  244  into message  249 , where message  249  is identical to, or an acceptable substitute for, original message  246 . 
     Messages can be forwarded between neighboring network proxies in a number of different ways. In an embodiment, a forwarding server-side proxy changes the destination address of a message to the address of another neighboring server-side proxy. In one implementation of this embodiment, the forwarding proxy does not change the source address of the forwarded message to match its own address and instead retains the source address of the message, for example the server  250 . The proxy receiving the forwarded message maintains a connection state internally corresponding to a connection between itself and the original source of the message. Thus, to the proxy receiving the forwarded message from a neighboring proxy, the forwarded message appears to have been received from the original source of the message, rather than from the neighboring proxy. 
     In another embodiment, a message is forwarded from proxy  241  to a neighboring proxy by encapsulating the entire message in another message, for example in a generic routing encapsulation (“GRE”) tunnel established between neighboring proxies. In still another embodiment, a message is forwarded from a forwarding proxy to a neighboring proxy by extracting payload and destination information from original message and sending the payload in a suitable data structure across a TCP, SCTP, or similar connection between the proxies. 
     In general, messages can be forwarded between neighboring network proxies at the level of detection and forwarding of one or more network packets comprising each message, at the higher-level of semantic request and response messages, or at any intermediate level of processing. 
       FIG. 2B  illustrates an example network  255  according to an embodiment of the invention. Network  255  is similar to network  200 , except that there are two client-side network proxies. In this example, client-side proxies  290  and  291  of network  255  have been configured as neighbors, so each can communicate with the other and/or has some awareness of the other. 
     A message  265  sent by client  260  and addressed to server  275  is intercepted by client-side proxy  290 . Client-side proxy  290  sends a message  285  to server-side proxy  270 . Message  285  may be identical to message  265  or a transformation of message  265  that differs in ways including size, encoding, framing, addressing, and/or other aspects. 
     When message  265  is received by client-side proxy  290 , an additional step takes place if message  265  is the establishment of a new client/server connection. In such a case, client-side proxy  290  provides new-connection information  268  derived from message  265  to neighboring client-side proxy  291 . Neighbor client-side proxy  291  stores that new-connection information  268  and associates it with owning client-side proxy  290 . 
     Server-side proxy  270  receives message  285  and transforms it into message  287 , which is identical to, or an acceptable substitute for original message  265 . Thus the two proxies  290  and  270  are invisible in their effect: client  260  and server  275  send and receive messages that are identical to, or an acceptable substitute for what would occur if message  265  were simply sent directly to server  275 . For example, network traffic communicated from server-side proxy  270  to server  275  might have the source address of client  260 . 
     For communications between the server  275  and the client  260 , the neighbor client-side proxy  291  may receive messages from the server  275 . For example, server  275  can send message  277  directed to client  260  and server-side proxy  270  can intercept message  277  and can transform it into message  288 , which can be identical to message  277  or a transformation of message  277  that differs in ways including size, encoding, framing, addressing, and/or other aspects. For example, message  288  can be a compressed version of message  277 . 
     Due to the routing characteristics of wide area network  280 , message  288  might be received by either client-side proxy  290  or  291 . If message  288  is received by client-side proxy  290 , which previously established and therefore “owns” the connection between client  260  and server  275 , client-side proxy  290  uses information about its association with server-side proxy  270  and other previously stored information to transform message  288  into message  295 , which is in turn sent to client  260 . Message  295  is identical to, or an acceptable substitute for, original server message  277 . 
     Alternatively, if message  288  is received by client-side proxy  291 , client-side proxy  291  uses stored new-connection information  268  to determine that message  288  belongs to a connection made through client-side proxy  290 . In response to this determination, client-side proxy  291  forwards message  288  to client-side proxy  290  via message  297 . Client-side proxy  290  then transforms message  297  into message  295 , which is in turn sent to client  260 . Message  295  is identical to, or an acceptable substitute for, original server message  277 . Various messages, such as forwarding messages, can have a packet-to-packet correspondence with the messages they are transformed from, or not. 
     As with other embodiments, messages can be forwarded between neighboring network proxies in a number of different ways. In an embodiment, a forwarding client-side proxy changes the destination address of a message to the address of another neighboring client-side proxy. In one implementation of this embodiment, the forwarding proxy does not change the source address of the forwarded message to match its own address and instead retains the source address of the message, for example the server  275 . The proxy receiving the forwarded message maintains a connection state internally corresponding to a connection between itself and the original source of the message. Thus, to the proxy receiving the forwarded message from a neighboring proxy, the forwarded message appears to have been received from the original source of the message, rather than from the neighboring proxy. 
     In another embodiment, a message is forwarded from proxy  291  to neighboring proxy by encapsulating the entire message in another message, for example in a GRE tunnel established between neighboring proxies. In still another embodiment, a message is forwarded from a forwarding proxy to a neighboring proxy by extracting payload and destination information from original message and sending the payload in a suitable data structure across a TCP, SCTP, or similar connection between the proxies. 
     As discussed above, messages in general can be forwarded between neighboring network proxies at the level of detection and forwarding of one or more network packets comprising each message, at the higher-level of semantic request and response messages, or at any intermediate level of processing. 
     Although  FIGS. 2A-2B  show the neighbor configuration, new-connection information, and forwarding occurring at either the server-side proxy or client-side proxy, similar techniques may also be applied with both client-side and server-side proxies. Thus it is possible for a client-server exchange of messages to cause new-connection information to be sent to client-side neighbor proxies, then cause new-connection information to be sent to server-side neighbor proxies, then for a message to be forwarded among server-side proxies, and then for a message to be forwarded among client-side proxies. The number of neighbor proxies and the details of the new-connection information may be different on the client-side and on the server-side. In addition, these techniques can be used whether a connection is initiated at the client or the server, as appropriate. 
     In additional embodiments, proxies may be nested. For example, WAN  230  may actually be implemented as an actual WAN bracketed by a different set of client-side proxies and server-side proxies. For such a nested collection of proxies, one pairing of client-side and server-side proxies might have a non-zero number of neighbor proxies on zero, one, or both sides of the WAN; and separately, the other pairing of client-side and server-side proxies might have a non-zero number of neighbor proxies on zero, one, or both sides of the WAN. Such nestings of proxies may extend to arbitrary depth, not only the two levels described here. 
       FIG. 3  illustrates an example  300  of a data structure for conveying the information maintained by a neighboring network connection according to an embodiment of the invention.  FIG. 3  shows a portion of the neighbor information maintained by a proxy, based on new-connection messages received. Entries  301   a  and  301   b  each comprise a target element  310  and an owner element  320 . The meaning of each entry is that for any traffic received at this device addressed to the target, that traffic should be forwarded to the corresponding owner. Thus entry  301   a  allows a neighbor receiving traffic destined for 10.3.1.10:1921 to instead forward it to the owning proxy at 10.4.0.1:7810. Entry  301   b  means that traffic destined for 10.3.5.44:2044 should also be forwarded to the same owning proxy. (Examples herein use RFC 1918 private addresses to avoid any inadvertent reference to an actual network; public addresses can, of course, appear in the data structure.) 
       FIG. 3  is intended only to show the nature of the information stored and its relationship; the actual data structure is likely to include other mechanisms to allowing rapid search, cheap insertion/deletion, accommodating very large collections of information, and reclaiming old or unused entries. In addition, some embodiments will use additional information to distinguish entries, such as source address, source port, protocol number, DSCP code point, or other information readily available from received traffic. Finally, some embodiments will use forms of pattern-matching or partial specification to allow compact representations of large classes of traffic. All such likely adaptations are straightforward for one skilled in the arts. The “neighbor table” partially shown in  FIG. 3  can be stored in local memory of a proxy device, memory of a computer executing a software proxy, etc. 
       FIG. 4  illustrates a method  400  of initiating a new connection according to an embodiment of the invention. This method can be performed by one or more components in a network and/or embodied in computer-readable instructions to perform the method. In step  410 , a proxy receives a message. In step  420 , the proxy determines whether this connection can be optimized. Some connections may not be optimizable because of configuration rules, or there may be no counterpart proxy available in a suitable network location for the client and server. If the connection is not optimizable, in step  440  the proxy passes through the connection without processing it. In other embodiments, method  400  includes steps of processing the messages at the higher-level of semantic request and response messages, or at any intermediate level of processing, rather than at the level of detection and forwarding of one or more network packets comprising each message. 
     If the connection is optimizable, in step  430  the proxy determines if it has neighbors. If so, in step  450  the proxy, referred to here as the “owner proxy,” supplies new-connection information to each of its neighbors. In an embodiment, the new-connection information can be communicated with neighboring proxies using unicast, multicast, or broadcast techniques. Some proxies that would otherwise qualify as neighbors can be treated as non-neighbors, where appropriate. 
     Regardless of whether it has neighbors or not, in step  460  the owner proxy begins applying optimizations or transformations to connection traffic, in cooperation with its counterpart proxy. 
       FIG. 5  illustrates a method of processing network traffic associated with a connection according to an embodiment of the invention that begins with a proxy receiving a message. In step  510 , the proxy receives the message. In step  520 , the proxy determines whether the message&#39;s destination matches one in its neighbor table, such as that diagrammed in  FIG. 3 . If the message&#39;s destination does not match any entry in the neighbor table, the process continues with step  530  wherein the proxy processes the message normally. This can include forwarding the message to its destination and optionally transforming the message for purposes of caching or network acceleration or other operation. 
     Conversely, if in step  520  it is determined that the message does match an entry in the neighbor table, the proxy can rewrite (step  540 ) and forward (step  550 ) the message or an equivalent thereof to the appropriate neighbor network proxy for processing. Forwarding can be accomplished using a variety of different techniques, including the address swapping, tunneling, and payload extraction techniques discussed above. As described previously, embodiments of method  500  can include processing the messages comprising one or more packets at the higher-level of semantic request and response messages, at any intermediate level of processing, or at the level of detection and forwarding of the one or more network packets comprising each message. A message can be part of a packet, comprise one packet per message, or comprise a plurality of pockets, depending on context. 
     In a further embodiment, network proxies can be dynamically added. In one implementation, newly added proxies receive and process all network traffic normally, as if their neighbor tables were empty. As a result, some types of network transactions will be disrupted due to the effects of asymmetric routing and other network effects, such as those described previously. Clients and servers will recover from the disrupted network transactions by initiating a new network connection. The new network connection will be intercepted by the network proxies and result in new connection information being forwarded to a newly added proxy, thereby updating its neighbor table. 
       FIG. 6  illustrates an additional network  600  according to an embodiment of the invention. Network  600  is shown including a set of server-side proxies  605 ,  610 , and  615 . Other network elements might exist that are not shown. As with the other embodiments, each of the set of server-side proxies can be associated with one or more client-side proxies, which are omitted from  FIG. 6  for clarity. The association between client-side and server-side proxies enables transformations that improve network performance and perform possibly other roles. In this network configuration  600 , server-side proxies do not have to be in-line with the connections with the wide-area network. 
     Network  600  includes a set of routers  620 . Each of the set of routers  620  has a connection with one or more wide-area networks. A set of interceptor modules  625  are connected with the set of routers  620 . As explained in detail below, the set of interceptor modules  625  are adapted to intercept and, if necessary, redirect network traffic to preserve routing symmetry. In an embodiment, each of the set of routers  620  is associated with one of the set of interceptor modules  625 . In alternate embodiments, routers and interceptor modules may be associated in different ratios. 
     The set of interceptor modules are connected with each other and the set of server-side proxies  605 ,  610 , and  615  via a local network  630  that includes one or more network switches and other networking devices, such as network switches  631 ,  633 , and  635 . A set  640  of one or more servers, each labeled “S” in  FIG. 6 , is also connected with local network  630 . The set of servers  640  provide applications, information, and services to one or more clients. For clarity, clients are omitted from  FIG. 6 , but might be coupled to routers  620 . 
     The set of interceptor modules  625  preserve routing symmetry for network traffic between clients and the set of servers  640 . For example, a client sends an initial message  650  to a server. Initial message  650  can be communicated from the client, via a client-side network proxy, and through a wide-area network, not shown, to reach network  600 . Message  650  may be directed at a specific one of the set of servers  640  or in general to any of the set of servers  640  or a subset thereof. 
     Upon receipt of initial message  650  via router  620 ( a ) of the set of routers  620 , message  650  is passed to associated interceptor module  625 ( a ). If routing symmetry needs to be preserved for this and possibly subsequent communications with this client, interceptor module  625 ( a ) selects an appropriate server-side proxy to associate with the client&#39;s client-side proxy. Embodiments of interceptor module  625 ( a ) can select a server-side proxy in any number of ways to achieve load-balancing or other goals. Example load-balancing schemes can include round-robin, load-based, sticky, mapping using hashes of an IP address or other message property, or any other load-balancing scheme used for manipulating network traffic that is known in the art and suitable for such operations. 
     In accordance with this selection, interceptor module  625 ( a ) sends the initial message  650  to the selected server-side proxy. Additionally, interceptor module  625 ( a ) sends a new-connection information message  665  to the each of other interceptor modules of set  625  and stores a copy of this new-connection information for itself. In an embodiment, the new-connection information message  665  is communicated with the other interceptor modules using a unicast, multicast, or broadcast network protocol on the network  630 . It should be understood that similar operations could be done with proxy/interceptor pairs other than  620 ( a )/ 625 ( a ). 
     In an embodiment, the new-connection information message  665  includes one or more routing table rules for redirecting network traffic associated with the pertinent client to the selected server-side proxy. In a further embodiment, the routing table rules include one or more rules for redirecting network traffic from the pertinent client to the selected server-side proxy. Additionally, the routing table rules include one or more rules for redirecting network traffic from one or more of the set of servers  640  and directed to that client to the selected server-side proxy. 
     In further embodiments, network traffic associated with a given client is assigned to a unique port of the selected server-side proxy. In an embodiment, an autodiscovery protocol is used so that the client-side proxy and interceptor modules learn which port to connect with on the selected server-side proxy. In another embodiment, a set of rules on the client-side proxy and/or the interceptor modules define the appropriate port to connect with on the server proxy. 
     Once the other interceptor modules of set  625  have received the new-connection information message  665 , all network traffic associated with the client will be redirected through the selected server-side proxy. For example, a message  670  from server  640 ( b ) directed to the client will travel through local network  630 . Upon reaching one of the set of interceptors  625 , the receiving interceptor module will match message  670  with its stored new-connection information for the client. In response, that interceptor module will redirect message  670  to the previously selected server-side proxy. The selected server-side proxy will process and/or transform message  670  and then send the resulting message back through any one of the set of interceptor modules  625  and associated one of the set of routers  620  to the client. In another embodiment, the new-connection information is received by the set of routers  620 , which processes network traffic in a similar manner. 
     Similarly, a subsequent message  680  from the client to one of the set of servers  640  will be received by one of the set of interceptors  625 , such as interceptor  625 ( c ) in this example. Interceptor module  625 ( c ) will match message  680  with its stored new-connection information for the client. In response, the interceptor module  625 ( c ) will redirect message  680  to the previously selected server-side proxy. The selected server-side proxy will process and/or transform message  680  and then send the resulting message back through local network  630  to one of the set of servers  640 . 
     In an alternate embodiment, the some or all of the network proxies can be integrated with the interceptor modules, such that each combined unit includes a network proxy for processing and transforming associated network traffic, and an interceptor module for monitoring network traffic, creating new-connection information, and using new-connection information to redirect messages as needed to other standalone network proxies or combined interceptor module and network proxy units. In this embodiment, standalone interceptor modules can also be employed to cover additional connections with a wide-area network. 
     In a further embodiment, network proxies can be dynamically removed from the network. Neighbor proxies receive new-connection information and store this information in a neighbor table. Additionally, in this embodiment, neighbor proxies provide an acknowledgment message to the owner proxy. If the owner proxy does not receive an acknowledgment back from one or more of its neighbor proxies, the owner proxy assumes the non-responsive neighbor proxies are disabled and can purge its own neighbor table of entries associated with the non-responsive neighbor proxies. 
     The outlined flow is for an embodiment in which each message is unambiguously handled by either the receiving proxy or a neighbor. In some embodiments, it may be possible for a message to be handled either by the receiving proxy or by one of its neighbors. In such an embodiment, where such a choice should be resolved in favor of the receiving proxy, the message processing flow will include a test after receiving a message and before checking for “neighbor ownership” to determine if the message matches one that can be handled by the receiving proxy. If the message can be handled by the receiving proxy, then processing would involve normal processing and no need for the checking step. 
     Although the invention has been discussed with respect to specific embodiments thereof, these embodiments are merely illustrative, and not restrictive, of the invention. Furthermore, the system architecture discussed above is for the purposes of illustration. The invention can be implemented in numerous different forms including as a stand-alone application or as a module integrated with other applications. Thus, the scope of the invention is to be determined solely by the claims.