Patent Publication Number: US-8533729-B2

Title: Distributed task system and distributed task management method

Description:
RELATED APPLICATIONS 
     This application is a national stage application of international patent application PCT/US08/52310, filed Jan. 29, 2008, claiming priority from Chinese patent application, Application No. 200710002961.6, filed Jan. 30, 2007, both entitled “DISTRIBUTED TASK SYSTEM AND DISTRIBUTED TASK MANAGEMENT METHOD”. 
     BACKGROUND 
     This disclosure relates to the fields of computer task scheduling and tasking strategies, and in particular to a distributed task system and a distributed task management method. 
     In computer technologies, a task is a job executed according to a preset strategy. For instance, in Windows task system, a task can be set as “automatic shutdown of the system at 12:50 AM.” At 12:50 AM, the system executes this task and completes the job of an automatic shutdown. In a computer program, a task may be a subroutine called in the program. Furthermore, in a more complex computing environment, a task may be a separate job in a great number of computing jobs either related or not related to each other. 
     At present, most task systems are single systems. The processing abilities of a single system are very limited. As the complexity and the precision requirement of the tasks continue to increase, the requirement on the processing ability of the task system also increases; hence single systems can no longer satisfy user demands. 
     In order to increase the processing abilities of task systems, distributed task system is used. Using a distributed task system, a large problem can be divided into many small problems which are distributed to many computers. For example, distributed computing is a method of computer processing in which different parts of a program are run simultaneously on two or more computers that are communicating with each other over a network. 
     A distributed task system usually has a task strategy unit and a group of task execution units. Under the control of the task strategy unit, each task execution unit takes up one or more of the tasks that need to be processed. In a distributed task system, it is usually required that a task be performed by only one task execution unit within a unit tasking time. This ensures that tasks are executed linearly in the distributed task system. It may be considered an erroneous operation for two task execution units to receive from the task strategy unit an authorization for executing the same task at the same time. 
       FIG. 1  shows a type of distributed task system in current technology. This system includes a task strategy unit  110  and N task execution units  120 . The task strategy unit  110  communicates with each task execution unit  120 . The task strategy unit  110  assigns task to one of the task execution units  120 , and monitors and manages each task execution unit  120 . Task execution unit  120  performs the task assigned from the task strategy unit  110  and reports its status to the task strategy unit  110 . The task strategy unit  110  can extend the task execution units through Remote Procedure Calls (RPC) to achieve the processing abilities of a multi-server system. 
     However, in the present distributed task systems as shown in  FIG. 1 , the task execution units  120  are passively called for service and have little to none participation in the task distribution and task strategy, which are primarily done by task strategy unit  110  alone. This can be disadvantageous because when there are a large number of tasks need for execution, and especially when long-duration tasks and short-duration tasks are mixed together, the control of the task strategy unit  110  over the task execution units  120  would become weaker and the task execution units  120  may even become out of control. 
     SUMMARY 
     This disclosure describes a distributed task management method, which is used to overcome the limitation that the task execution units can only be called to function passively and cannot perform self-balancing acts to assist the task distribution of the system. Instead of being merely passively called by the task transaction server to execute a task, the task server in the presently disclosed system performs self-balancing according to task execution conditions and task server&#39;s operation conditions. The task transaction server receives task requests from the task server, records the execution conditions, and provides feedback to the task server, while the task server executes the task according to the received feedback and the operation conditions of the task server. 
     In one embodiment, the task server has a self-balancing unit that sends a task request to the task transaction server, receives the feedback from the task transaction server, and triggers a task execution unit of the task server to perform the task according to the feedback. The task execution unit connects with the self-balancing unit and performs the task under the control of self-balancing unit. The task transaction server determines, according to the execution conditions of the task, if the task server can execute the task, and then sends feedback to the task server. When the feedback indicates that the task server can perform the task, the self-balancing unit of the task server further determines whether the task server is busy, and if not busy, triggers the task execution unit of the task server to execute the task. If the task server is busy, it sends a task check message to the task transaction server. Upon receiving the task check message, the task transaction server checks whether any other task server is requesting for this task and sends the check result to the self-balancing unit. 
     The task server may be considered to be busy if any or a combination of the following conditions are met: the current number of threads is greater than or equal to a preset bound for the number of threads; the current number of long-duration threads is greater than or equal to a preset bound for the number of long-duration threads; and an execution encumbrance value of the task server is greater than or equal to a preset threshold. 
     The task server may further include a task strategy unit connecting with the self-balancing unit and used to trigger the self-balancing unit to send the task request. 
     Another aspect of this disclosure relates to a distributed task management method. According to one embodiment of the method, a task server sends a task request to a task transaction server, which determines whether the task server can perform the task based on recorded execution conditions of the task, and sends the result to the task server. The execution conditions of the task may include such information as the identity of the requester or executor of the task, previous task execution time of the task and the task name. If the result of the determination is affirmative (i.e., the server can perform the task), the task server may perform the task. After sending the task request to the task transaction server, the task server may begin execution of the task if it receives from the task transaction server a feedback within a first time interval. The task server sends another task request if it does not receive any feedback within the first time interval. The task server abandons the request for the task if it does not receive from the task transaction server a feedback within a second time interval. 
     According to an exemplary process of determining whether the task can be performed by the task server, the task transaction server checks the execution conditions of a task requested by a task server. If the execution conditions indicate that another task server is presently executing the same task, the task transaction server may decide that the requesting task server cannot perform the requested task. If no other task server is presently executing the task, the task transaction server may decide that the requesting task server can execute the requested task. 
     In one embodiment of the method, the task server checks itself to determine whether it is busy. If not busy, the task server performs the requested task. If busy, the task server sends a task check message to request the task transaction server to check if there is another task server requesting the same task and send the check result to the self-balancing unit of the requesting task server. If the check result is affirmative, the requesting task server abandons the task request. Otherwise, the task server may execute the task. 
     In order to determine whether the task server is busy, the task server may determine whether the current number of task threads is greater than or equal to a preset bound for the number of threads. If yes, the task server is considered busy. Alternatively or additionally, the task server may also determine whether the current number of long-duration threads is greater than or equal to a preset bound for the number of long-duration task threads. If yes, the task server is considered busy. In one embodiment, the task server determines whether it is busy by estimating an execution encumbrance value of the task server according to CPU utilization rate, the current number of threads and the current number of long-duration threads. If the execution encumbrance value is greater than or equal to a preset threshold (e.g., 1.0), the task server is considered busy. 
     To perform the requested task, the task server obtains data for the task being executed, groups the data into multiple data groups according to characteristics of the data, and processes each data group. 
     The system and method disclosed herein help to remove the limitation that the task execution units (e.g., task servers) can only be called for service passively and cannot perform self-balancing acts. Compared with the existing technologies, exemplary embodiments of the distributed task system and method may have the following advantages. In the exemplary embodiments disclosed herein, the task server uses a self-balancing unit to examine its operating condition. If the task server is busy, it may transfer the task to another task server for execution, thus achieving task server&#39;s self-balance. In the self-balancing process, the task server either initiates or actively assists the task transaction server to transfer the task to another task server for execution, rather than merely passively wait for management instructions from the task transaction server. Using this mechanism, when there are a large number of tasks need to be executed, and even when long-duration tasks and short-duration tasks are mixed together, the self-balancing unit can effectively control its task execution unit (e.g., a task server). 
     Moreover, exemplary embodiments disclosed herein employ a task transaction server which provides feedback in response to the task requests of the task server. The feedback is based the execution conditions of the requested task to ensures the linear execution of the task. 
     This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. 
    
    
     
       DESCRIPTION OF DRAWINGS 
       The detailed description is described with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The use of the same reference numbers in different figures indicates similar or identical items. 
         FIG. 1  is a diagram illustrating a distributed task system using an existing technology. 
         FIG. 2  is a diagram illustrating an exemplary distributed task system in accordance with the present description. 
         FIG. 3  is flowchart of an exemplary distributed task management method in accordance with the present description. 
         FIG. 4  is a flowchart of an exemplary pre-process of the task execution in  FIG. 3 . 
         FIG. 5  shows an exemplary environment for implementing the system and method of the present description. 
     
    
    
     DETAILED DESCRIPTION 
     The distributed task system and distributed task management method are described in further detail below using the figures and exemplary embodiments. 
       FIG. 2  shows an example of a distributed task system in accordance with the present disclosure. This system has task servers  210  and  230  and task transaction server  220 , where task transaction server  220  connects separately with task server  210  and task server  230 . Task transaction server  220  is used to receive task requests from task server  210  and task server  230 , provide feedbacks to task server  210  and task server  230 , and record execution conditions of each task. The execution condition of a task may include such information as the identity of the requester or the executor of the task (i.e., which task server requests for the task, which task server executes the task, which and how many executors in a task server are assigned to execute the task, etc.), previous task execution time and task name. Task server  210  and task server  230  each send task request to task transaction server  220  and execute the respective task according to the feedback from task transaction server  220 . 
     It is appreciated that task transaction server  220  and task servers  210  and  230  may represent any computing device suitable for their respective purpose described herein, and are not limited to a real server computer, nor limited to a standalone physical computing device. 
     Task server  210  further includes task strategy unit  211 , self-balancing unit  212  and task execution unit  213 , wherein self-balancing unit  212  connects with task strategy unit  211  and task execution unit  213 . Likewise,  230  further includes task strategy unit  231 , self-balancing unit  232  and task execution unit  233 , wherein self-balancing unit  232  connects with task strategy unit  231  and task execution unit  233 . In the following, task server  210  is described in further detail for the purpose of illustration. The description is also applicable to task server  230 . It is also appreciated that the distributed task system in  FIG. 2  can have any number of task servers similar to task servers  210  and  230 . 
     Task strategy unit  211  of task server  210  is used to trigger self-balancing unit  212  to send a task request. Self-balancing unit  212  is used to send the task request to task transaction server  220 , and receive a feedback from task transaction server  220 . When the feedback indicates that task server  210  can execute the task, self-balancing unit  212  checks whether task server  210  is busy. If task server  210  is not busy, self-balancing unit  212  may instruct task execution unit  213  to execute the requested task. If task server  210  is busy, self-balancing unit  212  sends a task check message to task transaction server  220  for further determination. Upon receiving the task check message, transaction server  220  checks if there is another task server (e.g., task server  230 ) requesting for the same task, and returns the check result to self-balancing unit  212 . If the result is affirmative (i.e., another task server is requesting for the task), task server  210  may abandon its request for the task and let task transaction server  220  accept the request from the other task server (e.g., task server  230 ) to execute the task. If the result is negative (i.e., no other task server is requesting for the task), self-balancing unit  212  may instruct task execution unit  213  to perform the task anyway when task server  210  is able to execute the task. 
     A busy condition of task server  210  may be defined in a variety of ways based on the characteristics of the distributed task system. For example, a busy condition may be one in which the current number of threads (including all threads such as long-duration threads and short-direction threads) of task server  210  is greater than or equal to a preset bound for the number of threads; the current number of long-duration threads is greater than or equal to a preset bound for the number of long-duration threads; or an execution encumbrance value of task server  210  is greater than or equal to a preset threshold (e.g., 1.0). Any combination of these condition factors, and other suitable condition factors, may be used to define a busy condition of task server  210 . 
     For instance, the preset bound for the number of threads in task server  210  may be five hundred. If the current number of threads is five hundred, the current number of threads is equal to the preset bound for the number of threads, and therefore task server  210  is considered to be in a busy state and cannot execute an additional task. 
     For another instance, the preset bound for the number of long-duration threads of task server  210  may be five. If the current number of long-duration threads is five, the current number of long-duration threads is equal to the preset bound for the number of long-duration threads, and therefore task server  210  is considered to be in a busy state and cannot execute an additional task. 
     Execution encumbrance of task server  210  may be estimated in a variety of ways suitable to the characteristics of the distributed system. In one embodiment, the overall operation condition of task server  210  may be measured by an execution encumbrance estimated by CPU utilization rate and a combination of the above-described condition factors. 
     For example, the execution encumbrance value of task server  210  may be obtained according to the following formula:
 
 EC =CPU utilization rate× W   1   +NT   1d   ×W   2   /NT   1d0   +NT×W   3   /NT   0 ,
 
     where EC is execution encumbrance of task server  210 , NT 1d  is the current number of long-duration threads, NT 1do  is the preset bound for the number of long-duration threads, NT is the current number of all threads (long-duration and short-direction), and NT 0  is the preset bound for the number of all threads, and W 1 , W 2  and W 3  are weights assigned to each condition factor, and may be obtained empirically. W 1 , W 2  and W 3  may or may not be normalized such that W 1 +W 2 +W 3 =1.0. Preferably, W 1 , W 2  and W 3  are empirically selected such that an execution encumbrance value of 1.0 indicates a threshold above which the task server is considered over occupied (i.e., busy) and not available for an additional task. 
     For the purpose of illustration, assume the preset bound for the number of threads of task server  210  is five hundred, and the preset bound for the number of long-duration threads is five. If the current CPU utilization rate of task server  210  is 85%, the current number of threads is one hundred, the current number of long-duration threads is three, and W 1 , W 2  and W 3  are 0.80, 0.75 and 0.40 respectively, the current execution encumbrance value of task server can be estimated as:
 
 EC= 80%×0.80+3×0.75/5+100×0.40/500=0.68+0.45+0.08=1.21.
 
     The above W 1 , W 2  and W 3  are calibrated such that an execution encumbrance value greater than 1.0 indicates a busy status. Since the above-estimated execution encumbrance value is greater than 1.0, task server  210  is considered to be in a busy state and cannot execute additional tasks. The above exemplary values of weights W 1 , W 2  and W 3  (0.80, 0.75 and 0.40, respectively) are obtained empirically, and can be modified according to the changes in hardware and the operating system. 
     Consider another example in which the preset bound for the number of threads of task server  210  is five hundred and the preset bound for the number of long-duration threads is five. If the current CPU utilization rate of task server  210  is 80%, the current number of long-duration threads is two, and the current number of threads is fifty, the execution encumbrance is estimated as:
 
current execution encumbrance value=80%×0.8+2×0.75/5+50×0.40/500=0.64+0.3+0.04=0.98&lt;1.
 
     Because the current execution encumbrance value is less than 1.0, task server  210  is considered as being not in a busy state, and therefore can take up an additional task. However, if one more long-duration thread is executed, the current number of long-duration threads becomes three, and accordingly the current execution encumbrance value=80%×0.8+3×0.75/5+50×0.40/500=0.64+0.45+0.04=1.13&gt;1. Task server  210  thus turns into a busy state. That is, task server  210  could take up at most one additional long-duration thread without turning busy under this circumstance. 
     In contrast, if one more short-duration thread is executed, the current execution encumbrance value=80%×0.8+2×0.75/5+51×0.40/500=0.64+0.3+0.0408=0.9808&lt;1. Therefore, task server  210  is still not in a busy state after taking up one additional short-duration task. 
     As shown in the above examples, the differential treatment of long-duration tasks and short-duration tasks in estimating the execution encumbrance of task server enables the task server to perform effective self-balancing with flexibility. 
       FIG. 3  shows a flowchart of an exemplary process using the distributed task system in  FIG. 2 . In this description, the order in which a process is described is not intended to be construed as a limitation, and any number of the described process blocks may be combined in any order to implement the method, or an alternate method. 
     In the exemplary process  300 , a task server sends a task request to task transaction server  220 . The task transaction server  220  then determines if the requesting task server can perform the task based on the recorded execution conditions of the task, and sends the result to the requesting task server. If the check result is affirmative, the requesting task server executes the task. Any task server in a distributed task system disclosed herein may be a requesting task server. For the purpose of illustration, task server  210  in  FIG. 2  is assumed in the following to be the requesting task server  220  for execution of task A. An exemplary embodiment of the process is described as follows. 
     At block  301 , task server  210  sends a task request to task transaction server  220 . Task strategy unit  211  triggers self-balancing unit  212  to send a request to task transaction server  220  for executing task A. 
     At block  302 , task server  210  determines if a feedback has been received from task transaction server  220  within a preset first time interval. If yes, the process goes to block  304 . If not, the process goes to block  303 . The preset first time interval can be any practical time suitable for the distributed task system and its management. 
     At block  303 , task server  210  determines if a second time interval elapses without receiving a feedback from task transaction server  220 . If yes, the process proceeds to block  308  to abandon the task request. If not, the process returns to block  301 . The preset second time interval can be any practical time suitable for the distributed system and its management. In general, if the second time interval counts from the beginning of the process  300 , as the first time interval does, the second time interval should be longer than the first time interval. If the second time interval counts from the end of the first time interval, the second time interval can be any suitable length. For example, the second time interval maybe 30 seconds, or a fraction (e.g., ⅓) of a scheduling interval. 
     At block  304 , task transaction server  220  determines if task server  210  can execute task A and sends a feedback to task server  210 . If yes, the process proceeds to block  305 . Otherwise, the process ends at block  310 . The determination may be based on the record of task execution conditions. 
     To determine whether task server  210  can execute task A, task transaction server  220  checks the task execution conditions of task A, and task execution conditions of any other task if necessary. The execution condition of a task may be characterized by such information as the identity of the requester or executor of the task (i.e., which task server requests for the task, which task server executes the task, which and how many executors in the task server are assigned to execute the task, etc.), previous task execution time and task name. For example, if it is determined that a different task server (task server  230 ) is currently executing task A, task transaction server  220  may decide that task server  210  cannot execute task A at the same time. If no other task server is currently executing task A, task server  210  can execute task A. 
     If it is determined that task server  210  cannot execute task A, the process  300  may end at block  310 . But if it is determined that task server  210  can execute task A (because, e.g. task A is not being executed by task server  230 ), task transaction server  220  then sends a feedback to task server  210  to indicate that it can execute task A, and the process proceeds to block  305 . 
     At block  305 , self-balancing unit  212  examines whether task server  210  is busy. If yes, the process proceeds to block  306 . Otherwise, the process proceeds to block  309 . Self-balancing unit  212  may determine whether task server  210  is busy by considering several factors, including: 
     (i) whether the current number of threads of task server  210  is greater than or equal to the preset bound for the number of threads; if yes, task server  210  is busy; 
     (ii) whether the current number of long-duration threads is greater than or equal to the preset bound for the number of long-duration threads; if yes, task server  210  is busy; and 
     (iii) whether the execution encumbrance value of task server  210  is greater than or equal to the preset threshold (e.g., 1); if yes, task server  210  is busy. 
     The execution encumbrance value of task server  210  can be computed according to its CPU utilization rate, the current number of threads and the current number of long-duration threads. 
     Consider an example of process  300  may have the following conditions: 
     the preset bound for the number of threads of task server  210  is five hundred; 
     the preset bound for the number of long-duration threads is five; 
     the current CPU utilization rate of task server  210  is 85%; 
     the current number of long-duration threads is three; 
     the current number of threads is one hundred. 
     The execution encumbrance value of task server  210  can be computed by the following formula:
 
execution encumbrance value=CPU utilization rate×0.8+number of long-duration threads×0.75/5+number of threads×0.4/500.
 
     According to the above formula, the current execution encumbrance value of task server  210  is estimated as follows:
 
85%×0.8+3×0.75/5+100×0.4/500=0.68+0.45+0.08=1.21.
 
     Since the above execution encumbrance value is greater than 1.0, task server  210  is considered to be in a busy state. The process therefore proceeds to block  306 . 
     The weight values 0.8, 0.75 and 0.4 used in the above formula are obtained empirically. They can be modified according to changes in hardware and the operating system of the distributed task system. 
     At block  306 , self-balancing unit  212  sends a check message for task A to task transaction server  220 . The check message may request task transaction server  220  to check if there is any other task server also requesting the execution of task A. The check message may or may not inform task transaction server  220  of the current busy status of task server  210 . 
     At block  307 , task transaction server  220  checks whether another task server (e.g., task server  230 ) has applied or is applying for execution of task A. If yes, the process proceeds to block  308 . Otherwise, the process may proceed to block  309  to instruct task server  210  to execute the requested task A. Due to the busy status of task server  210 , the execution of task A may be delayed. Alternatively, task transaction server  220  may resort to other resources that can execute task A. 
     At block  308 , if it has been determined that another task server is available to execute task A, the busy task server  210  may cancel the request for execution of task A, and ends the process and  310 . 
     At block  309 , self-balancing unit  212  triggers task execution unit  213  to execute task A. The process  300  arrives at block  309  in two exemplary scenarios. In the first scenario, it has been determined that task server  210  can execute task A and is further in a non-busy state, so task server  210  proceeds to execute the requested task A. In the second scenario, although it has been determined that task server  210  can execute the task, task server  210  is found to be temporarily busy. But at the same time there may be no other task servers requesting for executing task A. In this scenario, it may be reasonable to instruct task server  210  to execute task A anyway. 
       FIG. 4  shows a flowchart of an exemplary pre-process before executing task A in  FIG. 3 . Task execution unit  213  of task server  210  performs the pre-process before it executes task A. 
     At block  401 , task execution unit  213  receives data of task A. The data is to be processed when executing task A. 
     At block  402 , task execution unit  213  groups the received data into data groups according to the type of the data and execution time(s) necessary for processing the data. 
     At block  403 , task execution unit  213  assigns actual computing resources such as executors to each data group to process the data group. A task server usually has multiple executors available to execute a certain task. Task execution unit  213  may dynamically determine a suitable number of executors to execute each data group of task A, according to the characteristics of each data group such as the amount of data that needs to be processed and the time needed to process the data. For example, if a certain data group has one thousand units of data and need to be completed within one minute, task execution unit  213  may decide that twenty executors are needed to process this data group. Accordingly, task execution unit  213  assigns a sufficient number (e.g. twenty) of executors to process this data group if the needed executors are available. 
     At block  404 , execution unit  213  processes each group of data and monitors the execution conditions of the task. As indicated at block  403 , execution unit  213  may call different executors to run different groups of data, such that the executors called are optimally suitable for running the corresponding group of data. Execution unit  213  may also monitor various execution conditions of task A. For instance, if execution unit  213  detects that the task (or a certain data group of the task) has taken longer than maximum allowed execution time, execution unit  213  may make a mark to indicate that task execution is in an abnormal state. 
     The above-described exemplary embodiments are able to accomplish self-balancing using self-balancing unit  212 , which examines whether task server  210  is busy, and transfers the task to another task server for execution if task server  210  has been determined to be busy. Moreover, task transaction server  220  provides feedback in response to the task request of task server  210 . The feedback is based on the execution conditions of each task to ensure the linear execution of the requested task. 
     Implementation Environment 
     The above-described techniques may be implemented with the help of a computing device, such as a server, a personal computer (PC) or a portable device having a computing unit. 
       FIG. 5  shows an exemplary environment for implementing the method of the present disclosure. Computing system  501  is implemented with computing device  502  which includes processor(s)  510 , I/O devices  520 , computer readable media (e.g., memory)  530 , and network interface (not shown). Other computing devices such as  541 ,  542  and  543  may have similar components. The computer device  502  is connected to servers  541 ,  542  and  543  through network(s)  590 . Each computing device  502 ,  541 ,  542  and  543  may be used to serve as a task transaction server or a task server. For example, computing device  502  may serve as a task transaction server, and each computer device  541 ,  542  and  543  may serve as a task server. 
     The computer readable media  530  stores application program modules  532  and data  534  (such as data of task execution conditions). Application program modules  532  contain instructions which, when executed by processor(s)  510 , cause the processor(s)  510  to perform actions of a process described herein (e.g., the processes of  FIGS. 3-4 ). 
     It is appreciated that the computer readable media may be any of the suitable memory devices for storing computer data. Such memory devices include, but not limited to, hard disks, flash memory devices, optical data storages, and floppy disks. Furthermore, the computer readable media containing the computer-executable instructions may consist of component(s) in a local system or components distributed over a network of multiple remote systems. The data of the computer-executable instructions may either be delivered in a tangible physical memory device or transmitted electronically. 
     It is also appreciated that a computing device may be any device that has a processor, an I/O device and a memory (either an internal memory or an external memory), and is not limited to a personal computer. For example, a computer device may be, without limitation, a server, a PC, a game console, a set top box, and a computing unit built in another electronic device such as a television, a display, a printer or a digital camera. 
     Especially, each computer device  502 ,  541 ,  542  and  543  may be a server computer, or a cluster of such server computers, connected through network(s)  590 , which may either be Internet or an intranet. The present disclosed distributed task system thus configured may be used to handle a variety of computational tasks, including being used as part of an e-commerce system used for processing online commercial transactions. 
     The present distributed task system and distributed task management method can be used in combination with any existing distributed task system and method. For example, Remote Procedure Call (RPC) may be used in combination with the present disclosed techniques. RPC allows a computer program to cause a subroutine or procedure to execute in another address space (commonly on another computer on a shared network) without the programmer explicitly coding the details for this remote interaction. 
     It is appreciated that the potential benefits and advantages discussed herein are not to be construed as a limitation or restriction to the scope of the appended claims. 
     Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as exemplary forms of implementing the claims.