WO2002013485A2

WO2002013485A2 - System and method of proxying communications in a data network

Info

Publication number: WO2002013485A2
Application number: PCT/US2001/024372
Authority: WO
Inventors: Andrew A. Chien; Ying-Hung Chen
Original assignee: Entropia, Inc.
Priority date: 2000-08-04
Filing date: 2001-08-03
Publication date: 2002-02-14
Also published as: AU2001281029A1; WO2002013485A8; WO2002013485A3

Abstract

A system and method of proxying communications over a complex network (112). One embodiment of the invention comprises a first (104) and second process (108) that communicate over a complex network environment. A first proxy (120) transparently intercepts communications from the first process (104) to the second process (108) and transmits the intercepted communication to a second proxy (124). The second proxy (124) then forwards the intercepted communication to the second process (108). The first proxy (104) and the second proxy (108) can package the intercepted communications for transmission across a complex network environment (112). Since the communications are transparently intercepted, the first process (104) and the second process (108) can communicate over complex network environments, such as a firewall, without requiring intimate knowledge of such environment.

Description

SYSTEM AND METHOD OF PROXYING COMMUNICATIONS OVER A COMPLEX NETWORK ENVIRONMENT

Background of the Invention Field of the Invention

The field of the invention relates to network communications. More particularly, the field of the invention relates to a system and method of using a proxy server for managing communications between processes.

Description of the Related Art Developing a software application to communicate over complex network environments such as the

Internet can be a daunting task. For security concerns, many systems on the Internet implement firewalls which prevent unauthorized access to or from a portion of the network, thereby complicating the process of communicating across such networks.

Firewalls can be implemented in both hardware and software, or a combination of both. Firewalls are frequently used to prevent unauthorized Internet users from accessing private networks connected to the

Internet. There are several types of firewall techniques, including the use of proxy servers. A proxy server resides between an internal network and an external network. Proxy servers can inspect all traffic (in and out) over an Internet connection and determine if there is anything that should be denied transmission or access.

However, these proxy servers do not improve the quality of communications over the Internet. Furthermore, in these systems, processes that are communicating over the firewall need to be cognizant of the firewall and must implement complicated negotiation procedures in view of the firewall.

Thus, there is a need for a system that allows processes to communicate over a complex network environment, e.g., a firewall. The system should allow the processes to communicate with each other without requiring a priori knowledge of the firewall and without requiring the processes to implement negotiation procedures.

Summary of the Invention

One aspect of the invention comprises a method of proxying communications between a first process and a second process, wherein the second process executes in a network that comprises a first logical portion and a second logical portion, and wherein the network defines a communication protocol such that communication is initiated from the second logical portion of the network, and wherein the second process resides in the second logical portion of the network, the method comprising: intercepting, in a first proxy engine, a first connection message from the first process to the second process, acknowledging the connection message to the first process, waiting for a second connection message that is transmitted from a second proxy engine to the first proxy engine, wherein the second connection message includes a request to connect the second process to the first process, and wherein the second proxy engine resides in the second logical portion, and transmitting a third connection message from the second proxy engine to the second process, wherein the third connection message includes a request to connect the second process to the first process.

Another aspect of the invention comprises a method of proxying communications, the method comprising: intercepting, transparently to the first process, a communication from a first process to a second process, wherein the first process and the second process communicate according to a first protocol, packaging the intercepted communication for transmission over a network using a second protocol that is compatible with the network, and transmitting the packaged and intercepted communication over the network.

Another aspect of the invention comprises a system for proxying communications over a complex network environment, the system comprising: a first process, a second process, a first socket that is used by the first process for communicating with the second process over the complex network environment, a second socket that is used by the second process for communicating with the first process over the complex network environment, a first proxy engine for transparently intercepting communications that are transmitted to or from the first process via the first socket, and a second proxy engine for transparently intercepting communications that are transmitted to or from the second process via the second socket. Brief Description of the Drawings

Figure 1 is a block diagram illustrating a system for managing, via a first proxy and a second proxy, data traffic between a first process and a second process.

Figure 2 is a block diagram illustrating in further detail the components of the first proxy of Figure 1.

Figure 3 is a block diagram illustrating in further detail the components of the second proxy of Figure 1.

Figure 4 is a flowchart illustrating one embodiment for a process of establishing a connection between the first process and the second process.

Figures 5A-5F are each diagrams illustrating certain states that occur in the process of Figure 4.

Figure 6 is a flowchart illustrating a process of establishing a connection between the first process and the second process, wherein the second process resides behind a firewall.

Figures 7A-7F are each diagrams illustrating certain states that occur in the process of Figure 6.

Figures 8A and 8B are each diagrams illustrating a process of proxying datagrams that are transmitted from a first process to a second process.

Figures 8C and 8D are each diagrams illustrating a process of proxying datagrams that are transmitted from the second process to the first process.

Figure 9 is a state machine for the first process of Figure 4, wherein data communications between the first process and the second process are initiated by the second process.

Figure 10 illustrates a state machine for the second process of Figure 6, wherein data communications between the first process and the second process are initiated by the second process. Detailed Description of the Invention The following detailed description is directed to certain specific embodiments of the invention. However, the invention can be embodied in a multitude of different ways as defined and covered by the claims. The proxy system 100 enables applications which use Internet or other protocols having a sockets interface to flexibly connect and transparently communicate through firewalls and other network infrastructure. The method provides this capability transparently to applications and adapts both the connection protocol and all other network traffic to the connectivity allowed by the firewall or other network infrastructure.

Figure 1 is a block diagram illustrating one embodiment of the proxy system 100. The proxy system 100 comprises a first process 104 that is operably connected to one or more second processes 108 over a complex network environment, such the Internet 112. A first proxy 120 and a plurality of second proxies 124 transparently intercept data communications between the first process 104 and the second processes 108 to improve one or more characteristics of the data traffic between the first process 104 and the second processes 108. The first proxy 120 is responsible for intercepting and handling the socket communications of the first process 104. The second proxies 124 are respectively responsible for intercepting and handling socket communications of the second process 108. In one embodiment of the invention, the first proxy 120 and the second proxy 124 communicate via HTTP commands.

It is noted that although only 3 second processes 108 and 3 second proxies 124 are shown, the proxy system 100 can be employed with a large number of second processes and second proxies, e.g., millions. For convenience of description, the following text will assume that the first process 104 is communicating with a single second process 108 and second proxy 124. Furthermore, the terms "first" and "second" process are used as terms of convenience; the "first" and "second" process can each be any type of software application that executes in a computing environment. Thus, in practice, the first process 104 may initiate execution before the second process 108, and vice-versa. In one embodiment of the invention, transparent proxying is achieved without use of privileged software (special drivers) by adding user, system, or kernel level libraries which remap or reconfigure target addresses in the application. For example, using Microsoft Windows operating environment, a proxy server, e.g., the first proxy 120, may proxy communications by linking to a winsock2.dll via the Service Provider Interface (SPI). Typically, the SPI is used to implement a new high performance network device. However, the proxy system 100 may use the SPI to intercept communications with various processes on the computer. Advantageously, this approach maintains compatibility with the winsock2.dll, but also allows all traffic to be transparently intercepted. Furthermore, for example, transparent proxying may be accomplished by binary rewriting of the first process 104 and the second process 108. A description of how to rewrite binary processes is disclosed in Eustace, "ATOM - A System for Building Customized Program Analysis Tools", Proceedings of the ACM SIGPLAN '94 Conference on Programming Language Design and Implementation (PLDI), pages 196-205, Orlando, Florida, 20-24 June 1994 and in and James R. La s and Eric Schnarr, "EEL: Machine-independent Executable Editing", Proceedings of the ACM SIGPLAN '95 Conference on Programming Language Design and Implementation (PLDI), pages 291-300, La Jolla, California, 18-21 June 1995.

In the proxy system 100, the respective processes have no knowledge that their communication requests are being proxied. By proxying communications, the first proxy 120 and the second proxy 124 can acquire network information and manage the use of resources to achieve good communication performance

(including reliability, bit rate, and latency). The proxy system 100 enables transparent and seamless use of a variety of techniques to manage a complex network environment.

Once the communications have been intercepted, the first proxy 120 and the second proxy 124 communicate over a virtual tunnel. The first proxy 120 and the second proxy 124 optimize the communications between the first process 104 and the second process 108 to account for particular characteristics of the network environment, including: networking hardware, protocol support, link speeds, firewalls, encryption, authentication protocols and mechanisms, storage and computation entities, and the type of routers. The first proxy 120 and the second proxy 124 manage network discontinuities to achieve good reliability and bit rate performance. For example, as is known by skilled one of skill in the art, speed discontinuities in the network, such as transitioning from high speed backbone to LAN to wireless, can cause packet loss. End-to-end protocols such as TCP/IP help alleviate this problem, but are often insufficient because they do not exploit more detailed knowledge of the network configuration and dynamic state. In one embodiment of the invention, the first proxy 120 and the second proxy 124 use adaptive, in-network mediated, and custom protocols to increase network performance. The first proxy 120 and the second proxy 124 support communications between processes that are across firewalls with limited protocol, address, and port access. Furthermore, the proxy system 100 may be used to optimize coordination and communication of such as active network nodes, web proxies, application server proxies, etc. Dynamic discovery, use, and management of these resources are all capabilities that a proxy system 100 can use to optimize performance, security, reliability, etc.

In many network environments, communication, storage, and namespace resources are shared amongst many users. As such, it can be an important goal to use the network non-intrusively, that is to minimize the impact on other users of the network. The proxy system 100 provides the capability to retrieve and incorporate dynamic network information and use it to manage application behavior for non-intrusiveness. For example, detecting network congestion by using information across multiple proxy servers and multiple connections can be used to coordinate a prioritized backoff scheme.

In one embodiment of the invention, the first process 104 and the first proxy 120 both reside and execute on a single computer system. Furthermore, in this embodiment, the second process 108 and the second proxy 124 reside on a single computer system. The single computer system may have any conventional general purpose single- or multi-chip microprocessor such as a Pentium processor, a Pentium Pro processor, a MIPS processor, a Power PC processor, or an ALPHA processor. In addition, the microprocessor 100 may be any conventional special purpose microprocessor such as a digital signal processor. The first process 104 and the second process 108 may be used in connection with various operating systems such as: UNIX, LINUX, OS/2, PalmOS, Windows 3.X, Windows 95, Windows 98, Windows NT, and Windows CE.

The first process 104 and the second process 108 may be written in any programming language such as C, C++, BASIC, Pascal, Java, and Fortran and ran under the well-known operating system. C, C++, BASIC, Pascal, Java, and Fortran are industry standard programming languages for which many commercial compilers can be used to create executable code. Figure 2 and 3 are block diagrams respectively illustrating certain features of the first proxy 120 and the second proxy 124. In one embodiment, the first proxy 120 and the second proxy 124 are each comprised of various modules. As can be appreciated by one of ordinary skill in the art, each of the modules comprise various sub-routines, procedures, definitional statements, and macros. Thus, the processes that are undergone by each of the modules may be arbitrarily redistributed to one of the other modules, combined together in a single module, or made available in a shareable dynamic link library. In one embodiment, each of the modules on a selected proxy are separately compiled and linked into a single executable program.

In one embodiment, the first proxy 120 includes the following modules: an InSocks module 204, an InSockEvents module 208 and a transport module 212. In this embodiment, the second proxy 124 includes the following modules: an InSocks module 304, an InSockEvents module 308 and a transport module 312. Both the first proxy 120 and the second proxy 124 maintain a socket list (Sock_Array) that describes all of the currently open sockets.

The InSocks modules 204 and 304 both include collections of sockets that are used to send and receive data to the processes that are being proxied. For example, the transport module 212 and 312 each contains information about where the 'true' remote destination is, enforcing outgoing queuing rules, and simulating incoming queues. InSockEvents modules 208 and 308 are used to communicate to the remote proxy's. The InSockEvents module 208 creates sockets, connects to the remote side, and delivers messages(Events) and receive any incoming events. On the other hand, the InSockEvents module 308 accepts the incoming connection requests, receives events and sends replies (if any).

In one embodiment, the first proxy 120 never initiates the connection to the second proxy 124, but instead, waits for an incoming connection request from second proxy 124. Furthermore, in this embodiment, the second proxy 124 periodically sends requests to the first proxy 120 to check whether there are any incoming events. The first proxy 120 maintains a mapping table and multiple queues to manage multiple second processes 108/proxies 124.

Figure 2 also illustrates an exemplary data flow that is performed, in one embodiment, by the first proxy 120 when the first proxy 120 receives a connection request from the second proxy 124 (state 206). One process of sending and receiving establishing a connection between the first proxy 120 and the second proxy 124 is described in further detail below with respect to Figures 6 and 7A-7F. Upon receipt of the connection request, the InSockEvents module 208 parses the incoming data and then the InSockEvents module 208 registers the connection request. Furthermore, the InSockEvents module 208 sends any pending events to the second proxy 124. The first proxy 120 maintains a database of mappings of remote IP and queued events so that it knows which packets belong to which sockets. The first proxy 120 then simulates the request to the first process 104 by passing all the incoming events it has parsed to the transport module 212. The transport module 212 then simulates each of the events (states 222 and 226).

When the InSocks module 204 receives information from the first process 120, judging by which sockets it received data from, the first proxy 120 knows which process should receive the data. The InSocks module 204 then creates a corresponding event and passes the event to the transport module 212 and the transport module 212 handles the according to the queuing rules, and since first proxy 120 is supporting multiple second proxy/second processes, the transport module 212 puts the event into its respective queue (state 228). The contents of the queue are sent back to the respective machine when that machine sends a periodic query command (state 230 and state 206). Figure 3 illustrates an exemplary data flow that is performed when the second proxy 124 receives a packet, e.g., user datagram protocol (UDP), from the second process 108 (state 336). In this example, the InSocks module 304 receives a UDP packet from the second process 108. The InSocks module 304 creates an event, e.g., EventUDP, that contains all the relevant information such as the data payload. The InSocks module 304 passes this Event to the transport module 312 (state 344). The transport module 312, queues up the event (according to the queuing rules) in the queue array. When it is ready to send to the remote side (i.e. a rule may be set as send the events to the remote side every 10 seconds), the transport module 312 invokes InSockEvents module 308 and passes all the events from its queue (state 348). The InSockEvents module 308 creates a new socket and connects to the first proxy 120. At the state 352, any pending invents for the first proxy 120 are sent back to the first proxy 120. Upon receiving a reply from the first proxy 120, the InSockEvents module 308 determines whether any useful information was returned. If not, nothing is passed to the transport module 312. However, if there are some events that have been returned, the InSockEvents module 308 creates all the corresponding events and passes it them to the transport module 312 which simulates all events (states 356, 360, and 364)

Figure 4 is a flowchart illustrating a process of establishing a connection between a second process 504 (Figure 5A) and a first process 508 (Figure 5A). Figures 5A-5F are dataflow diagrams illustrating certain acts that occur during the process shown in Figure 4. Depending on the embodiment, certain steps may be omitted and others may be added. In the following process, an initial connection request from the second process 504 is intercepted by the second proxy 520 and converted to a form compatible with the complex network environment. A "tunnel" is then formed between the second proxy 520 and the first proxy 524 or, alternatively, if an existing tunnel exists, it can be used. The tunnel is formed by the second proxy 520 making a connection request in a protocol that is compatible with the underlying network environment. The tunnel may be used to transport the communication traffic both from the second process 504 to the first process 508 and from the second process 504 to the second process 504.

Starting at a state 400, the second process 504 initiates a request for a connection with the first process 508. This connection request is shown graphically by Figure 5A. Next, at a state 404, the second proxy 520 intercepts the request of the second process 504. Continuing to a state 408, the second proxy 520 acknowledges the request of the second process 504 (shown in Figure 5B). Moving to a state 412, the second proxy 520 requests a connection over a complex network environment with the first proxy 524.

Proceeding to a state 416, the first proxy 524 accepts the request of the second proxy 520 and requests a connection with the first process 508 (Figure 5C). Next, at a state 420, the first process 508 accepts and acknowledges the request of the first proxy 524, thereby allowing it to continue as if it were already connected to the first process 508. (Figure 5D). Continuing to a state 420, the first process 508 acknowledges the request of the first proxy 524 (Figure 5D). Moving to a state 424, the first proxy 524 acknowledges the connection request of the second proxy 520 (Figure 5E) and the request is received by the second proxy 520 (Figure 5F). Figure 6 is a block diagram illustrating a process of establishing a proxied socket connection between the first proxy and the second proxy across a network wherein a connection can only be initiated by one side. Figures 7A-7F are dataflow diagrams illustrating certain acts that occur during the process shown in Figure 6.

In this process, because neither the first process 704 or the first proxy 720 can initiate "active" connections to second proxy, the first proxy 720 waits until it is the target of a connection initiated by the second proxy 724. The second proxy 724 can initiate the connection by a time-based polling or some other form of information communication, triggering. For example, the desire for a connection by the first process 704 can be communicated by the first process 704 via a previously existing connection between the first process 704 and the second process 708, which was established by a time based registration schedule. Depending on the embodiment, certain steps may be omitted and others may be added. For convenience of description, the following text assumes that the connection can only be initiated by the second proxy 724 . However, it is to be appreciated by one skilled in the art that the following process can be reversed in the event that the connection can only be initiated by the first process 704 instead of the second process 708. Referring to Figures 6 and 7A-7F, starting at a step 600, the first process 704 initiates a request for connection with a second process 400 (Figure 7A). Next, at a state 604, the first proxy 720 intercepts the request. Continuing to a state 608, the first proxy 720 acknowledges the request of the first process 704 and waits for a request for connection by the second proxy (Figure 7B). In one embodiment of the invention, the second proxy 724 periodically contacts the first proxy 720 according to a time based registration schedule. Moving to a state 612, the first proxy 720 receives a request for connection from the second proxy

724. Next, at a state 616, the first proxy 720 communicates to the second proxy 724 the request for connection of the first process 704 (Figure 7C). Proceeding to a state 620, the second proxy 724 requests connection to the second process 708 (Figure 7D). Continuing to a state 624, the second process 708 acknowledges the request for connection to the second proxy 814.

Next, at a state 628, the second proxy 724 receives an acknowledgement from the second process 708 (Figure 7E). Moving to a state 632, the second proxy 724 sends an acknowledgment of the connection request to the first proxy 720. Proceeding to a state 636, the first proxy 720 receives the acknowledgement from the second proxy 724. At the state 636, the first process 704 has established a virtual connection with the second process 708.

Advantageously, the proxy architecture 100 provides transparent and seamless socket interconnection despite complex network restrictions in protocol, port number, and authentication requirements.

Figures 8A and 8B are dataflow diagrams illustrating how datagram traffic can be proxied by the proxy system 100. A datagram is a piece of a message that is transmitted over a packet-switching network. In one embodiment, for increased efficiency, an open connection may be maintained when datagram traffic is frequent. Figure 8A illustrates the interception of a datagram by the first proxy 720. Figure 8B illustrates the use of the first proxy 720 to transmit the datagram over a tunnel between the first proxy 720 and the second proxy 724. The process of establishing a connection between the first proxy 720 and the second proxy 724 can be accomplished via either of the processes shown in Figures 4 or 6.

Figures 8C and 8D are dataflow diagrams illustrating how datagram traffic from the second process 708 to the first process 704 can be proxied by the proxy system 100. Figure 8A illustrates the interception of a datagram by the second proxy 724. Figure 8B illustrates the use of the second proxy 724 to transmit the datagram over a tunnel between the second proxy 724 and the first proxy 720.

Figure 9 illustrates the states of a finite state machine for the second proxy 724. In this embodiment, it is assumed that the second proxy 724 should initiate any communication requests with the first proxy 720. However, as discussed above with respect to Figure 7 , depending on the embodiment, the proxy system 100 can be used in systems wherein the first proxy 720 initiates all communication with the second proxy 724.

At a state 900, a timer interrupt occurs and the second proxy 724 reads from the first proxy 720. After the read, the second proxy 724 determines whether either: (i) the second proxy 724 has received a connection request from the first proxy 720, or (ii) the second proxy 724 has received a connection request from the second process 708. If the second proxy 724 has received a connect request from the first proxy 720, the second proxy enters a state 904 . If the second proxy 724 has received a connection request from the second process 708, the second proxy 724 enters a state 908. If neither of these events occurs, the second proxy 724 stays at the state 900.

At the state 908, the second proxy 724 writes a connection request to the first proxy 720 and acknowledges the connection request from the second process 708. Upon receiving a connection acknowledgement from the first proxy 720, the second proxy 724 enters a state 912. Referring again to a state 900, if the second proxy 724 has received a connect request from the first proxy 720, the second proxy 724 enters the state 904 . At the state 904, the second proxy 724 connects to the second process 708 and writes an acknowledgement to the first proxy 720. The second proxy 724 then enters a state 912. The second proxy 724 enters the state 912, from either: (i) the state 908 if the second proxy 724 has received a connection acknowledgment from the first proxy 720 or (ii) the state 904 after the second proxy 724 has acknowledged a connection request from the first proxy 720. At the state 912, the second process 708 has a virtual connection to the first process 704. At the state 912, the second proxy 724: (i) receives data from second process 704, (ii) sends periodic send/query messages while piggybacking the data to first proxy 720, and (iii) receives data (if any) from first proxy 720. Upon receiving any data from the first proxy 720, the second proxy 724 forwards the information to the second process 708.

Upon receiving a close connection request from the second process 708, the second proxy 724 enters a close state 916. In the close state 916, the second proxy 724 writes a close connection request to the first proxy 720 and the second proxy 724 acknowledges the close connection request to the second process 708. Once the acknowledgement of close connect request arrives from first proxy 720, then the virtual connection is now closed.

Referring again to the state 912, upon receiving a close connection request from the first proxy 720, the second proxy 724 enters a close state 920. In the close state 920, the second proxy 724 writes a close connection request to the second process 708. Upon receiving an acknowledgment from the second process 708, the second proxy 724 writes an acknowledgment to the first proxy 720

Figure 10 illustrates the state of a finite state machine for the first proxy 720. In this embodiment, it is assumed that the second proxy 724 should initiate any communication requests with the first process 704.

Starting at a state 1000, one of two events occurs: a connection request is received from the second proxy 724, or, alternatively, a connection request is received from the first process 704. If a connection request is received from the second proxy 724, the first proxy 720 proceeds to a state 1008. If a connection request is received from the first process 704, the process proceeds to a state 1004.

At the state 1008 , the first proxy 720 sends a connection request to the first process 704, Upon receipt of an acknowledgement from the first process 704, the first proxy 720 sends an acknowledgment to the second proxy 720 . The first proxy 720 then enters a connected state 1012 (described below). Referring again to the state 1000, upon receiving connection request from the first process 704, the first proxy 720 enters the state 1004 wherein the first proxy 720 waits for a connection request from the second proxy 724. Upon receipt of the connection request, the first proxy 720 sends a connection request to second proxy 724 and waits for second proxy 724 to acknowledge it. Once first proxy 720 receives the acknowledgment from second proxy 724, the first proxy 720 enters the connected state 1012. At the state 1012, the first proxy 720: (i) receives data from the first process 704, (ii) waits for a message from the second proxy 724, and (iii) sends the data in a reply message to the second proxy 724. Upon receiving any data from the second proxy 724, the first proxy 720 forwards the information to the first process 704.

From the state 1012, upon receiving a close connection from the first process 704, the first proxy 720 enters a closing state 1016. At the state 1016, the first proxy 720 waits for and accepts a message from the second proxy 724. In reply, the first proxy 720 sends a close connection request to the second proxy 724. The first proxy 720 then receives an acknowledgement from the second proxy 724.

Referring again to the state 1012, if the first proxy 720 receives a close connection request from the second proxy 724, the first proxy enter the state 1020. At the state 1020, the first proxy sends a close connection request to the first process 704. Upon receiving an acknowledgment from the first process 704, the first proxy 720 waits for an receives a message from the second proxy 724. In response to the message, the first proxy writes an acknowledgement to the second proxy 724.

Advantageously, the proxy system 100 transparently captures and mediates traffic between two process. The proxy system manages connection protocols, data protocols, and shutdown protocols.

While the above detailed description has shown, described, and pointed out novel features of the invention as applied to various embodiments, it will be understood that various omissions, substitutions, and changes in the form and details of the device or process illustrated may be made by those skilled in the art without departing from the spirit of the invention. The scope of the invention is indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.

Claims

WHAT IS CLAIMED IS:

1. A method of proxying communications between a first process (104) and a second process (108), wherein the second process (108) executes in a network that comprises a first logical portion and a second logical portion, and wherein the network defines a communication protocol such that communication is initiated from the second logical portion of the network, and wherein the second process resides in the second logical portion of the network, the method comprising: intercepting, in a first proxy engine (120), a first connection message from the first process (104) to the second process (108), wherein the first proxy engine (120) resides in the first logical portion; acknowledging the connection message to the first process; waiting for a second connection message that is transmitted from a second proxy engine (124) to the first proxy engine (120), and wherein the second proxy engine (124) resides in the second logical portion; and transmitting a third connection message from the second proxy engine (124) to the second process (108), wherein the third connection message includes a request to connect the second process (108) to the first process (104).

2. The method of Claim 1 , wherein the second connection message is periodically transmitted from the second proxy engine (124) to the first proxy engine (120).

3. A system for proxying communications over a complex network environment (112), the system comprising: a first process (104); a second process (108); a first socket that is used by the first process for communicating with the second process (108) over the complex network environment (112); a second socket that is used by the second process for communicating with the first process (104) over the complex network environment (112); a first proxy engine (120) for transparently intercepting communications that are transmitted to or from the first process (104) via the first socket; and a second proxy engine (124) for transparently intercepting communications that are transmitted to or from the second process (108) via the second socket.

4. The system of Claim 3, wherein the proxy system implements a communication protocol wherein the second process (108) initiates all communications to the first process (104), wherein the first proxy engine (120) stores all communications initiated by the first process (104) and stores the communications until a connection request is received by the first proxy engine (120) from the second proxy engine (124).

5. The system of Claim 3, wherein the first proxy engine (120) and the second proxy engine (124) communicate with each other using a hypertext transfer protocol.

6. The system of Claim 3, additionally comprising: a first computer having a central processing unit wherein the first process (104) and the first proxy engine (120) are both executing on the central processing unit of the first computer; and a second computer having a central processing unit wherein the second (108) process and the second proxy engine (124) are both executing on the central processing unit of the second computer.

7. A method proxying communications, the method comprising: intercepting, transparently to the first process (104), a communication from a first process

(104) to a second process (108); packaging the intercepted communication for transmission over a complex network environment (112); transmitting the packaged and intercepted communication over the complex network environment (112); unpackaging the intercepted communication; and transparently transmitting the unpackaged and intercepted communication to the second process (108).

8. The method of Claim 7, additionally comprising transmitting the packaged and intercepted communication from a first proxy engine (120) to a second proxy engine (124), wherein the second proxy engine (124) unpackages the intercepted communication and transmits the unpackaged and intercepted communication to the second process (108).

9. The method of Claim 7, wherein intercepting, transparently to the first process comprises rewriting an executable binary of the first process (104) to communicate with a first proxy engine (120) instead of the second process (108).

10. The method of Claim 7, wherein intercepting transparently to the first process (104) comprises requesting, via a user level programming interface, the communications from the first process (104) to the second process (108).

11. A system for proxying communications, the system comprising: means for intercepting, transparently to the first process (104), a communication from a first process (104) to a second process (108); means for packaging the intercepted communication for transmission over a network (112); means for transmitting the packaged and intercepted communication over the network (112); means for unpackaging the intercepted communication; and means for transparently transmitting the unpackaged and intercepted communication to the second process (108).

12. The system of Claim 11, additionally comprising means for transmitting the packaged and intercepted communication from a first proxy engine (120) to a second proxy engine (124), wherein the second proxy engine (124) unpackages the intercepted communication and transmits the unpackaged and intercepted communication to the second process (108).

13. A system for proxying communications between a first process (104) and the second process (108), wherein the second process (108) executes in a system that defines a communication protocol such that all communication is initiated by the second process (108), the system comprising: means for intercepting, in a first proxy engine (120), a first connection request from the first process to the second process (108); means for acknowledging the connection request to the first process (104); means for waiting for a second connection request that is transmitted from a second proxy engine (124) to the first proxy engine (120); and means for transmitting the a third connection request from second proxy engine (124) to the second process (108), wherein the third connection request to connect the second process (108) to the first process (104).

14. The system of Claim 13, wherein the second connection request is periodically transmitted from the second proxy engine (124) to the first proxy engine (120).

15. A program storage device storing instructions that when executed performs the method comprising: intercepting, transparently to the first process, a communication from a first process (104) to a second process (108); packaging the intercepted communication for transmission over a complex network environment (112); transmitting the packaged and intercepted communication over the network environment (112); unpackaging the intercepted communication; and transmitting the unpackaged and intercepted communication to the second process (108).

16. A method of proxying communications, the method comprising: intercepting, transparently to a first process (104), a communication from the first process (104) to a second process (108), wherein the first process (104) and the second process (108) communicate according to a first protocol; packaging the intercepted communication for transmission over a network (112) using a second protocol that is compatible with the network (112); transmitting the packaged and intercepted communication over the network (112); unpackaging the intercepted communication; converting the unpackaged communication for transmission to the second process (108) using the first protocol; and transparently transmitting the converted communication to the second process (108).

17. The method of Claim 16, additionally comprising transmitting the packaged and intercepted communication from a first proxy engine (120) to a second proxy engine (124), wherein the second proxy engine (108) unpackages the intercepted communication and transmits the unpackaged and intercepted communication to the second process (108).

18. A system for proxying communications, the system comprising: means for intercepting, transparently to a first process, a communication from the first process (104) to a second process (108), wherein the first process (104) and the second process (108) communicate according to a first protocol; means for packaging the intercepted communication for transmission over a network (112) using a second protocol that is compatible with the network (112); means for transmitting the packaged and intercepted communication over the network

(112); means for unpackaging the intercepted communication; means for converting the unpackaged communication for transmission to the second process (108) using the first protocol; and means for transparently transmitting the converted communication to the second process

(108).

19. The system of Claim 18, additionally comprising means for transmitting the packaged and intercepted communication from a first proxy engine (120) to a second proxy engine (124), wherein the second proxy engine (124) unpackages the intercepted communication and transmits the unpackaged and intercepted communication to the second process (108).

20. A program storage device storing instructions that when expected, perform the steps comprising: intercepting, transparently to a first process (104), a communication from the first process (104) to a second process (108), wherein the first process (104) and the second process (108) communicate according to a first protocol; packaging the intercepted communication for transmission over a network using a second protocol that is compatible with the network (112); and transmitting the packaged and intercepted communication over the network (112).

21. A method of proxying communications, the method comprising: intercepting, transparently to a first process, a communication from the first process (104) to a second process (108), wherein the first process (104) and the second process (108) communicate according to a first protocol; packaging the intercepted communication for transmission over a network (112) using a second protocol that is compatible with the network (112); and transmitting the packaged and intercepted communication over the network (112).

22. A system for proxying communications between a first process (104) and a second process (108), wherein the second process executes in a network that comprises a first logical portion and a second logical portion, and wherein the network defines a communication protocol such that communication is initiated from the second logical portion of the network, and wherein the second process resides in the second logical portion of the network, the system comprising: means for intercepting, in a first proxy engine (120), a first connection message from the first process (104) to the second process (108), wherein the first proxy engine (120) resides in the first logical portion; means for acknowledging the connection message to the first process (104); means for waiting for a second connection message that is transmitted from a second proxy engine (124) to the first proxy engine (120), and wherein the second proxy engine (124) resides in the second logical portion; and means for transmitting a third connection message from the second proxy engine (124) to the second process (108), wherein the third connection message includes a request to connect the second process (108) to the first process (104).

23. The system of Claim 22, wherein the second logical portion comprises a firewall.