Network-like communication and stack synchronization for different virtual machines on the same physical device

[0001] Embodiments relate to the fields of data processing and data communication, in particular, to methods and apparatuses for facilitating network-like communication between processes of different virtual machines on the same physical device and for synchronizing network communication stacks of the virtual machines.

[0002] Continuous advancements in virtualization and multi-processor core technology have given rise to new computing topologies requiring efficient communication between processes of different virtual machines on the same physical device. Traditionally, two processes engaging in network-like communication, such as client and server processes, may send and receive data through network communication stacks, such as transmission control protocol (TCP) and user datagram protocol (UDP) stacks. If the processes are processes of different computer systems connected by a network, each machine may be assigned an Internet Protocol (IP) address, and each process, a TCP/UDP port number. The IP addresses and ports are then used to identify the processes to each other across the network. If the processes are processes of the same computer system, the processes may only be identified by a port number and a special IP address (typically “127.0.0.1”) that may be used to inform the network communication stack that the destination process is local.

[0003] Virtualization technology allows two or more virtual machines to operate simultaneously on the same physical device while appearing to each other to be different physical devices. Each virtual machine may use its own network communication stack to facilitate its processes in communicating with processes of other virtual machines and devices. Often, communication between two processes of different virtual machines on the same device is facilitated by assigning each virtual machine a dummy IP address and allowing the virtual machines to communicate as if they were separate physical devices. However, like traditional communication across a network, the virtual machines on the same physical device may be unable to communicate if connectivity to the external network is impaired.

[0008] Illustrative embodiments of the present invention include, but are not limited to, methods performed by, and apparatuses having a plurality of agents of a plurality of virtual machines of a physical device. In various embodiments, first and second agents of first and second virtual machines are adapted to cooperate to ensure that a port of the physical device is listened to by only a first application of the first virtual machine and by the second agent of the second virtual machine. Also, the first and second agents are further adapted to cooperate to facilitate the first application and a second application of the second virtual machine in communicating with each other in a network-like manner.

[0009] Various aspects of the illustrative embodiments will be described using terms commonly employed by those skilled in the art to convey the substance of their work to others skilled in the art. However, it will be apparent to those skilled in the art that alternate embodiments may be practiced with only some of the described aspects. For purposes of explanation, specific numbers, materials, and configurations are set forth in order to provide a thorough understanding of the illustrative embodiments. However, it will be apparent to one skilled in the art that alternate embodiments may be practiced without the specific details. In other instances, well-known features are omitted or simplified in order not to obscure the illustrative embodiments.

[0010] Further, various operations will be described as multiple discrete operations, in turn, in a manner that is most helpful in understanding the illustrative embodiments; however, the order of description should not be construed as to imply that these operations are necessarily order dependent. In particular, these operations need not be performed in the order of presentation.

[0011] The phrase “in one embodiment” is used repeatedly. The phrase generally does not refer to the same embodiment; however, it may. The terms “comprising,” “having,” and “including” are synonymous, unless the context dictates otherwise. The phrase “A/B” means “A or B”. The phrase “A and/or B” means “(A), (B), or (A and B)”. The phrase “at least one of A, B and C” means “(A), (B), (C), (A and B), (A and C), (B and C) or (A, B and C)”. The phrase “(A) B” means “(B) or (A B)”, that is, A is optional.

[0012] FIG. 1 illustrates an overview of various embodiments of the present invention, facilitating network-like communication between processes of different virtual machines on the same physical device and synchronizing network communication stacks. As illustrated, platform or physical device 102 comprises at least two virtual machines, first virtual machine 104 and second virtual machine 114. Each of first virtual machine 104 and second virtual machine 114 includes a first/second agent 110/120. The first and second agents 110 and 120 may be adapted to cooperate to facilitate network-like communication between processes of the virtual machines 104/114, the first agent 110 acting as a proxy for processes of the second virtual machine 114 and the second agent 120 acting as a proxy for processes of the first virtual machine 104. Also, the first and second agents 110 and 120 may be adapted to cooperate to synchronize the network communication stacks of the virtual machines 104/114.

[0013] In addition to the first and second virtual machines 104 and 114, the physical device 102 may also comprise a virtual machine manager 122 (hereinafter, “VMM 122”) capable of communicating with the first and second agents 110 and 120 of the first and second virtual machines 104 and 114 and of allocating a channel 112, which may comprise a low-level, sharable memory page. Each of the first and second virtual machines 104 and 114 may comprise one or more applications in addition to the first/second agent 110/120, such as first application 106 of the first virtual machine 104 and second application 116 of the second virtual machine 114, capable of engaging in network-like communication through the network communication stacks of their respective virtual machines, such as the first network communication stack 108 (hereinafter, “first stack 108”) of first virtual machine 104 and the second network communication stack 118 (hereinafter, “second stack 118”) of the second virtual machine 114.

[0014] In various embodiments, physical device 102 may be any single- or multi-processor or processor core central processing unit (CPU) computing system known in the art. Physical device 102 may be a personal computer (PC), a workstation, a server, a router, a mainframe, a modular computer within a blade server or high-density server, a personal digital assistant (PDA), an entertainment center, a set-top box or a mobile device. The physical device 102 may be capable of operating a plurality of operating systems in a plurality of virtual machines using virtualization technologies. If physical device 102 is a multi-processor or multi-processor core system, each virtual machine of physical device 102 may be coupled to a processor or processor core dedicated to that virtual machine. In a single processor or single processor core physical device 102, the plurality of virtual machines may share the single processor or processor core. An exemplary single-/multi-processor or processor core physical device 102 is illustrated by FIG. 3, and is described in greater detail below. Hereinafter, including in the claims, processor and processor core shall be used interchangeable, with each term including the other.

[0015] As shown and alluded to earlier, physical device 102 may comprise a plurality of virtual machines, such as first virtual machine 104 and second virtual machine 114. First and second virtual machines 104 and 114, except for the teachings of embodiments of the present invention, may be any sort of virtual machines. Each of first and second virtual machines 104 and 114 may be a self-contained operating environment that behaves as if it is a separate computer system. To an outside system coupled to physical device 102 through a networking fabric, each of first and second virtual machines 104 and 114 may appear to be a separate computing device. First and second virtual machines 104 and 114 may also appear to be separate computing devices to each other, each having its own network communication stack, such as first stack 108 of first virtual machine 104 and second stack 118 of the second virtual machine 114, to facilitate the first and second virtual machines 104 and 114 in communicating with each other and with other virtual machines/physical devices. First and second virtual machines 104 and 114 may also each have an operating system capable of managing multiple processes, such as first application 106 and first agent 110 of first virtual machine 104, and second application 116 and second agent 120 of second virtual machine 114, and may each have a protected memory space that operationally belongs exclusively to that virtual machine. Suitable virtual machines and virtualization technologies include but are not limited to those available from Microsoft Corporation of Redmond, Wash., VMware, Inc. of Palo Alto, Calif., and XenSource of Cambridge, UK.

[0016] In some embodiments, the physical device 102 may further comprise a VMM 122, which may have a service operating system (OS) (not shown) and an application programming interface (API) to facilitate processes of the first and second virtual machines 104 and 114 in communicating with the VMM 122. The VMM 122 may comprise a service partition of the physical device 102, managing the actual hardware resources of device 102, including memory pages such as the low-level, sharable memory page serving as the channel 112, and coordinating the use of the resources between the first and second virtual machines 104 and 114.

[0017] As is shown, VMM 122 may receive requests via its API from the first and/or second agents 110 and 120 for the memory location of the channel 112, which may be a low-level, persistent, sharable memory page. In one embodiment, both first and second agents 110 and 120 may request the memory location of the channel 112 at startup. In another embodiment, only one of first and second agents 110 and 120 may request the memory location of the channel 112, and may further request that the VMM 122 inform the other of the first and second agents 110 and 120 of the memory location of channel 112. In yet another embodiment, first and/or second agents 110 and 120 may request that the VMM 122 allocate a new, low-level, sharable memory page to serve as channel 112.

[0018] Also, VMM 122 may receive, through its API, notifications from the first and/or second agents 110 and 120 that data, a message, and/or a notification has been stored in the channel 112. In response, the VMM 122 may inform the other of the first and second agents 110 and 120 of the store operation, thus facilitating the first and second agents 110 and 120 in communicating with each other via the channel 112.

[0019] As illustrated, channel 112 may be a low-level, sharable memory page of the physical device 102. In some embodiments, the channel 112 is a persistent memory page known to the VMM 122 at start up. In other embodiments, the channel 112 is allocated by the VMM 122 in response to a request by the first and/or second agents 110 and 120. Channel 112 may be capable of storing data as a buffer, and of storing notifications and messages, thus facilitating the first and second agents 110 and 120 in communicating with each other.

[0020] In various embodiments, first and second virtual machines 104 and 114 may each comprise one or more applications, such as first application 106 of first virtual machine 104 and second application process 116 of second virtual machine 114. First and second applications 106 and 116 may be any sort of processes capable of sending and receiving data in a network-like manner. For example, first application 106 may be a server process and second application 116 may be a client process. At start up or some later time, server/first application 106 may make a listen request of the first stack 108 requesting to listen at a certain port of the physical device 102. The listen request may specify the number of the port, or simply request any port, allowing the first stack 108 to assign the port. If the port specified/assigned is available, the first application 106 may be added to a port table of the first stack 108 as listening at the specified/assigned port.

[0021] Further, client/second application 116 may request to connect to server/first application 106, determining the IP address of the first application 106 in any manner known in the art, such as requesting that a domain name server (DNS) provide the IP address of the server/first application 106. The IP address provided to the client/second application 116 in response may be the same as the client/second application 116's IP address since both the first and second applications 106 and 116 are on the same physical device 102 and therefore may share the same IP. Second application 116 may also be provided with the port number at which the first application 106 is listening. Upon receiving the IP address and port number, second application 116 may send a request to the second stack 118 requesting connection to the first application 106. As will be described in more detail below, two connections may be established in response: a first connection between the second application 116 and the second agent 120, and a second connection between the first agent 110 and the first application 106. The first application 106 may receive a request for connection from the first agent 110 through the first stack 108, the first agent 110 acting as a proxy for the second application 116. In response to the request, the first application 106 may initialize and bind a socket to abstract the connection, the socket capable of reading and writing transmit/receive data.

[0022] In some embodiments, upon establishing the connections, either or both of the first and second agents 110 and 120 may transmit data to the other. First application 106 may send data to a socket abstracting the second connection, and receive data through that socket; and second application 116 may send data to a socket abstracting the first connection, and receive data through that socket.

[0023] Also, first application 106 may send a stop listening request to first stack 108 notifying the first stack 108 that it will no longer receive connections through the port at which it has been listening. In response, the first stack 108 may update the port table to indicate that first application 106 is no longer listening, and the first and second connections may be terminated in the manner discussed below.

[0024] In other embodiments, first application 106 may be a client and second application 116 may be a server, each performing the operations described above for the other application. Each of first and second applications 106 and 116 may perform some, all, or none of the above operations.

[0025] As illustrated, first and second virtual machines 104 and 114 may each comprise a network communication stack, such as first stack 108 of first virtual machine 104 and second stack 118 of second virtual machine 114. The first and second stacks 108 and 118 may be any sort of network communication stacks known in the art, such as TCP stacks and/or UDP stacks. Each stack 108/118 may have an associated port table listing each of the applications listening at each port, and may be capable of updating that table in response to listen or close requests requesting to listen at a port or to stop listening at a port. Each stack 108/118 may also be capable of forwarding a connection request or data to a given IP/port address combination, in the manner known in the art. In one embodiment, each time the port table is updated, the stack 108/118 having the updated table may notify the agent 110/120 of its respective virtual machine 104/114.

[0026] As is shown, first and second virtual machines 104 and 114 may also each comprise an agent to facilitate communication between processes of the virtual machines 104 and 114 and to synchronize the network communication stacks of the virtual machines 104 and 114. First virtual machine 104 may include a first agent 110, and second virtual machine 114 may include a second agent 120.

[0027] In some embodiments, first and second agents 110 and 120 may each initialize the channel 112 at start up. Each agent 110/120 may request the memory location of channel 112 from the VMM 122 through the API of the VMM 122. In various embodiments, the API of VMM 122 is known to the first and second agents 110 and 120. In response, the first and second agents 110 and 120 may each receive the memory location of the channel 112, and may utilize the channel 112 to communicate with the other of the first and second agents 110 and 120. In another embodiment, only one of the first and second agents 110 and 120 may request the memory location of channel 112 at startup, and may request that the VMM 122 notify the agents of other virtual machines of the memory location of the channel 112.

[0028] In various embodiments, first and second agents 110 and 120 may be adapted to cooperate to ensure that only a first application 106 and the second agent 120 listen at the same port, thereby synchronizing first and second stacks 108 and 118. Referring to the example provided above of first application 106 acting as a server and second application 116 acting as a client, the first agent 110 may trap the listen request made by first application 106. First agent 110 may trap the addition of a listening process in a number of ways. In some embodiments, first agent 110 may periodically check the port table of first stack 108 to determine if any ports have been added or removed. In other embodiments, first agent 110 may be notified each time a port is added or deleted from the port table. The notification may be provided by the first stack 108 or by some other process monitoring the first stack 108 and its port table. If any new applications are listening at new ports, such as first application 106 listening at a specified/assigned port, first agent 110 may generate a listen notification and may store the notification in the channel 112. The notification may include the identity of the first application and the port number that the first application is listening at, as well as a type field indicating that the stored notification is notification of a listen event. Upon storing the notification, first agent 110 may further notify the VMM 122 through the API of the VMM 122 that something has been stored in the channel 112 (the notification to VMM 122 may specify what has been stored in channel 112, but need not do so). VMM 122 may then notify second agent 120, through the API of VMM 122, that something has been stored in the channel 112. Second agent 120 may then retrieve and process the stored notification. In response, second agent 120 may send a listen request to second stack 118 requesting to listen at the port at which first application 106 is listening. Second stack 118 may then update its port table to reflect that second agent 120 is listening at the port. Second agent 120 may then listen on second stack 118 on behalf of first application 106, ensuring that all communications, such as data and connect requests, to the port are routed to the first application 106. Thus, by listening at ports on behalf of processes of virtual machines other than their own, first and second agents 110 and 120 ensure that the stacks of all virtual machines have the same list of ports being listened to by applications, thereby synchronizing the stacks.

[0029] In some embodiments, first and second agents 110 and 120 may be adapted to cooperate to facilitate network-like communication between the first application 106 and the second application 116, with the first agent 110 acting as a proxy for the second application 116 and the second agent 120 acting as a proxy for the first application 106. Continuing to refer to the above example with first application 106 acting as a server and second application 116 acting as a client, first and second agents 110 and 120 may facilitate second application 116 in establishing a network-like connection with the first application 106. Second agent 120 may first receive a forwarded connect request from second stack 118, the request made by second application 116. Second agent 120 may receive the forwarded request because second agent 120 is listening at the same port on second stack 118 as the first application 106 is listening on first stack 108, the second agent 120 listening on behalf of the first application 106. Upon receiving the connection request, second agent 120 may establish a first connection by creating a socket abstracting the connection. The use of sockets to abstract connections is well known in the art.

[0030] The second agent 120, after establishing the first connection, may create a context to identify the connection and associate the context with the socket. The context may comprise, for example, 1) the IP address and the port of first application 106 to which the connection request is directed, 2) an indication of whether the second application 116 is local or remote (here, it is local), and 3) an indication of the communication protocol used (TCP or UDP). Next, the second agent 120 may generate a notification of the connection request comprising the above mentioned context and a field indicating the type of notification being generated, and may store the notification in the channel 112. Upon storing the notification in the channel 112, second agent 120 may further notify the VMM 122 through the API of the VMM 122 that something has been stored in the channel 112 (the notification to VMM 122 may specify what has been stored in channel 112, but need not do so). VMM 122 may then notify first agent 110, through the API of VMM 122, that something has been stored in the channel 112.

[0031] In some embodiments, the first agent 110 may then retrieve and process the notification. First agent 110, acting as a proxy for second application 116, may next request a connection to first application 106, directing the request for connection to the first stack 108. First stack 108 may then forward the connection request to the first application 106, which may establish a second connection between the first application 106 and the first agent 110, and may create another socket to abstract the second connection. First agent 110 may then map the other socket to the above described context, thus allowing the context to uniquely identify the connections associated with the two sockets.

[0032] As is further illustrated, first and second agents 110 and 120 may send data to and receive data from each other. First application 106 may write data to the socket abstracting the second connection, and the first agent 110 may then read the data from the socket on behalf of the second application 116 to which the data is being transferred. The first agent 110 may then store the data in the channel 112 along with fields indicating that the context of the connections, as is discussed above, and indicating that the stored information is data to be transferred. The first agent 110 may then also utilize the VMM 122 to notify the second agent 120 of the store operation, in the manner described above. After receiving notification of the store operation from the VMM 122, the second agent 120 may retrieve the data from the channel 112 and, on behalf of the first application 106, may transmit the data to the second application 116 by writing the data to the socket abstracting the first connection.

[0033] In various embodiments, the reverse transfer of data may also be possible. Second application 116 may write data to the socket abstracting the first connection, and the second agent 120 may then read the data from the socket on behalf of the first application 106 to which the data is being transferred. The second agent 120 may then store the data in the channel 112 along with fields indicating that the context of the connections, as is discussed above, and indicating that the stored information is data to be transferred. The second agent 120 may then also utilize the VMM 122 to notify the first agent 110 of the store operation, in the manner described above. After receiving notification of the store operation from the VMM 122, the first agent 110 may retrieve the data from the channel 112 and, on behalf of the second application 116, may transmit the data to the first application 106 by writing the data to the socket abstracting the first connection.

[0034] As is also shown, the second agent 120 listening on a port on behalf of a first application 106 may stop listening on that port when the first application 106 stops listening on the port. The first and second agents 110 and 120 may also close any connections associated with the port, such as the first and second connections described above. In some embodiments, the first agent 110 may trap a close port command from the first application 106 to the first stack 108 in the same manner that it trapped the above described listen request. Upon trapping the close port command, which may stop the first application from listening on the port and remove the application-port combination from the port table of the first stack 108, the first agent 110 may close the second connection associated with that port by closing the socket abstracting the second connection. The first agent 110 may then notify the second agent 120 of the close port command in the same manner it informed the second agent 120 of the listen request, as described above. Upon receiving notification of the close port command, second agent 120, acting on behalf of the first application 106, may issue a close port command to the second stack 118 to stop listening by the second agent 120 on the port. The second stack 118 may then remove the second agent 120—port combination from its port table. Further, the second agent 120 may close the first connection associated with that port by closing the socket abstracting the first connection.

[0035] In one embodiment, prior to the closing of either connection, an error may occur and may be determined by either the first or second agent 110/120. The error may be determined in any number of manners, such as an incomplete or corrupted/unreadable transmission retrieved from the channel 112. In response, the sensing agent 110/120 may close any connections and stop listening on any ports, and may notify the other agent 110/120 in the manner described above for transmitting notifications. The other agent 110/120 may then also close any connection and stop listening on any ports. Both first and second agents 110 and 120 may then attempt to re-initialize the channel 112 in the manner described above.

[0036] FIG. 2 illustrates a flow chart view of selected operations of the methods of various embodiments of the present invention. As illustrated, in some embodiments, the first and second agents may each initialize the channel at start up, block 202. Each agent may request the memory location of the channel from the VMM through the API of the VMM. In various embodiments, the API of the VMM is known to the first and second agents. In response, the first and second agents may each receive the memory location of the channel, and may utilize the channel to communicate with the other of the first and second agents. In another embodiment, only one of the first and second agents may request the memory location of the channel at startup, block 202, and may request that the VMM notify the agents of other virtual machines of the memory location of the channel.

[0037] In various embodiments, the first and second agents may be adapted to cooperate to ensure that only a first application and the second agent listen at the same port, thereby synchronizing the first and second stacks. Referring to the example provided above of the first application acting as a server and the second application acting as a client, the first agent may trap the listen request made by first application, block 204. The first agent may trap the addition of a listening process in a number of ways. In some embodiments, the first agent may periodically check the port table of the first stack to determine if any ports have been added or removed. In other embodiments, the first agent may be notified each time a port is added or deleted from the port table. The notification may be provided by the first stack or by some other process monitoring the first stack and its port table. If any new applications are listening at new ports, such as the first application listening at a specified/assigned port, the first agent may generate a listen notification and may store the notification in the channel, notifying the second agent of the listening request, block 206. The notification may include the identity of the first application and the port number that the first application is listening at, as well as a type field indicating that the stored notification is notification of a listen event. Upon storing the notification, the first agent may further notify the VMM through the API of the VMM that something has been stored in the channel (the notification to the VMM may specify what has been stored in the channel, but need not do so). The VMM may then notify second agent, through the API of the VMM, that something has been stored in the channel. The second agent may then retrieve and process the stored notification. In response, the second agent may send a listen request to the second stack requesting to listen at the port that the first application is listening at, block 208. The second stack may then update its port table to reflect that the second agent is listening at the port. The second agent may then listen on the second stack on behalf of the first application, ensuring that all communications, such as data and connect requests, to the port are routed to the first application. Thus, by listening at ports on behalf of processes of virtual machines other than their own, the first and second agents ensure that the stacks of all virtual machines have the same list of ports being listened to by applications, thereby synchronizing the stacks.

[0038] In some embodiments, the first and second agents may be adapted to cooperate to facilitate network-like communication between the first application and the second application, with the first agent acting as a proxy for the second application and the second agent acting as a proxy for the first application, blocks 210-240. Continuing to refer to the above example with the first application acting as a server and the second application acting as a client, the first and second agents may facilitate the second application in establishing a network-like connection with the first application, blocks 210-214. The second agent may first receive a forwarded connect request from the second stack, the request made by the second application. The second agent may receive the forwarded request because the second agent is listening at the same port on the second stack as the first application is listening on the first stack, the second agent listening on behalf of the first application. Upon receiving the connection request, the second agent may establish a first connection by creating a socket abstracting the connection, block 210. The use of sockets to abstract connections is well known in the art.

[0039] The second agent, after establishing the first connection, block 210, may create a context to identify the connection and associate the context with the socket. The context may comprise, for example, 1) the IP address and the port of the first application to which the connection request is directed, 2) an indication of whether the second application is local or remote (here, it is local), and 3) an indication of the communication protocol used (TCP or UDP). Next, the second agent may generate a notification of the connection request comprising the above mentioned context and a field indicating the type of notification being generated, and may store the notification in the channel, notifying the first agent of the connection request, block 212. Upon storing the notification in the channel, the second agent may further notify the VMM through the API of the VMM that something has been stored in the channel (the notification to the VMM may specify what has been stored in the channel, but need not do so). The VMM may then notify the first agent, through the API of the VMM, that something has been stored in the channel.

[0040] In some embodiments, the first agent may then retrieve and process the notification. The first agent, acting as a proxy for the second application, may next request a connection to the first application, directing the request for connection to the first stack, block 214. The first stack may then forward the connection request to the first application, which may establish a second connection between the first application and the first agent, and may create another socket to abstract the second connection. The first agent may then map the other socket to the above described context, thus allowing the context to uniquely identify the connections associated with the two sockets.

[0041] As is further illustrated, the first and second agents may send data to and receive data from each other, blocks 216-230. The first application may write data to the socket abstracting the second connection, and the first agent may then read the data from the socket on behalf of the second application to which the data is being transferred, block 216. The first agent may then store the data in the channel, block 218, along with fields indicating the context of the connections, as is discussed above, and indicating that the stored information is data to be transferred. The first agent may then also utilize the VMM to notify the second agent of the store operation, in the manner described above. After receiving notification of the store operation from the VMM, the second agent may retrieve the data from the channel, block 220, and, on behalf of the first application, may transmit the data to the second application, block 222, by writing the data to the socket abstracting the first connection.

[0042] In various embodiments, the reverse transfer of data may also be possible, blocks 224-230. The second application may write data to the socket abstracting the first connection, and the second agent may then read the data from the socket on behalf of the first application to which the data is being transferred, block 224. The second agent may then store the data in the channel, block 226, along with fields indicating the context of the connections, as is discussed above, and indicating that the stored information is data to be transferred. The second agent may then also utilize the VMM to notify the first agent of the store operation, in the manner described above. After receiving notification of the store operation from the VMM, the first agent may retrieve the data from the channel, block 228, and, on behalf of the second application, may transmit the data to the first application, block 230, by writing the data to the socket abstracting the first connection.

[0043] As is also shown, the second agent listening on a port on behalf of a first application may stop listening on that port when the first application stops listening on the port, blocks 232-240. The first and second agents may also close any connections associated with the port, such as the first and second connections described above. In some embodiments, the first agent may trap a close port command from the first application to the first stack, block 232, in the same manner that it trapped the above described listen request. Upon trapping the close port command, which may stop the first application from listening on the port and remove the application-port combination from the port table of the first stack, the first agent may close the second connection associated with that port, block 234, by closing the socket abstracting the second connection. The first agent may then notify the second agent of the close port command, block 236, in the same manner it informed the second agent of the listen request, as described above. Upon receiving notification of the close port command, the second agent, acting on behalf of the first application, may issue a close port command to the second stack, and may stop listening on the port, block 238. The second stack may then remove the second agent-port combination from its port table. Further, the second agent may close the first connection associated with that port, block 240 by closing the socket abstracting the first connection.

[0044] FIG. 3 illustrates an example computer system suitable for use to practice various embodiments of the present invention. As shown, computing system 300 includes a number of processors or processor cores 302, and system memory 304. For the purpose of this application, including the claims, the terms “processor” and “processor cores” may be considered synonymous, unless the context clearly requires otherwise. Additionally, computing system 300 includes mass storage devices 306 (such as diskette, hard drive, compact disc read only memory (CDROM) and so forth), input/output devices 308 (such as keyboard, cursor control and so forth) and communication interfaces 310 (such as network interface cards, modems and so forth). The elements are coupled to each other via system bus 312, which represents one or more buses. In the case of multiple buses, they are bridged by one or more bus bridges (not shown). In various embodiments, mass storage devices 306 may be divided into multiple partitions for use by the virtual machines, with each virtual machine having exclusive use of the assigned partition.

[0045] Each of these elements performs its conventional functions known in the art. In particular, system memory 304 and mass storage 306 may be employed to store a working copy and a permanent copy of the programming instructions implementing the agent processes, the communication services/stacks of the various virtual machines, and so forth, herein collectively denoted as 322. As described earlier, each virtual machine may include an agent process. In various embodiments, the agent process may be a corresponding instance of an agent program of computer system 300 instantiated for the particular virtual machine. The agent may be implemented by assembler instructions supported by processor(s) 302 or high level languages, such as C, that can be compiled into such instructions.

[0046] The permanent copy of the programming instructions may be placed into permanent storage 306 in the factory, or in the field, through, for example, a distribution medium (not shown), such as a compact disc (CD), or through communication interface 310 (from a distribution server (not shown)). That is, one or more distribution media having an implementation of the agent program may be employed to distribute the agent and program various computing devices.

[0047] The constitution of these elements 302-312 are known, and accordingly will not be further described.

[0048] Although specific embodiments have been illustrated and described herein, it will be appreciated by those of ordinary skill in the art that a wide variety of alternate and/or equivalent implementations may be substituted for the specific embodiments shown and described, without departing from the scope of the embodiments of the present invention. This application is intended to cover any adaptations or variations of the embodiments discussed herein. Therefore, it is manifestly intended that the embodiments of the present invention be limited only by the claims and the equivalents thereof.