As computing systems have become more dependent on network communications, system performance requirements have increasingly become more demanding. Many of these requirements are related to distributed system architectures wherein a first system, such as a client, may need to invoke remote command execution on one or more other systems such as server systems. In many instances, it is desirable to execute a plurality of commands on multiple servers concurrently—without having to wait for a command to complete on one server before moving to the next server. Waiting becomes even more important when commands require substantial time to complete. Unfortunately, conventional system architectures do not provide an acceptable interface to enable remote commands to execute substantially in parallel without undue delay. Thus, remote command performance needs to be improved in order to meet and/or exceed the challenges presented by modern distributed systems.
Another challenge associated with remote command execution is related to command execution during and/or after a disruption in communications between the client and the server. The disruptions may be caused by network problems (e.g., intermittent connection) or may be hardware/software related whereby a server must be rebooted because of a system crash. In some instances, system commands may cause a disruption in network communications. For example, when an IP address is added to a network card, all existing TCP connections for that card may be dropped. Network disruptions, as described above, will likely present a problem for conventional architectures. If the command were executed as part of a conventional remote procedure call, then the procedure will likely fail in the event of a disruption since these processes rely on TCP connections remaining open for the duration of the call.
Some attempts have been implemented to try and address the above problems. One approach involves splitting the remote procedure calls into two method invocations—a “Begin” and “Finish” invocation. In a Begin invocation, input parameters are sent to the method without waiting for the execution of the actual call. When the caller desires to retrieve the results of the invocation, the Finish invocation is called wherein output parameters of the method may be filled in with the result of the execution. Although concurrent execution of commands may be provided by the Begin and Finish invocation, other problems are still unresolved. For example, two separate versions of the interface for the Begin and Finish invocation must be provided in order to execute the method—a synchronous and asynchronous version. Secondly, the client must explicitly request for the results of the remote method invocation and risk blocking if the execution is not completed.
Another attempt to address the above problems has involved the utilization of callback pointers wherein the client is required to pass a callback pointer in the method invocation. Upon receipt of the call, a server may spin a new thread, then pass the callback pointer to the thread and return. The new thread may then call the client back on the supplied callback pointer when processing is complete. However, this interface may fail if the server calls back on an interface pointer that is no longer valid due to the client shutting down and/or crashing. Additionally, significant overhead is involved with callback pointers since these pointers must be marshaled across various processes, machines and threads.
Unfortunately, neither of the above implementations solve the problem caused by network connections being reset as part of the remote command invocation since both implementations substantially rely on persistent and/or continuous network connections remaining available during remote command execution.