Distributed Computing practice (C #)-2

Because it is a simulation and experiment, I have not done very well in many places, but it can save some time, because I use a peering structure. Here we will talk about the structure of the computing node, A computing point contains three basic functions:
1) external task request management: It is responsible for receiving computing tasks of external requests and forwarding internal task request management functions to the target computing node based on the route information provided by the customer;
2) internal task request management: receives tasks or commands sent from computing nodes and calls local task execution functions.
3) task execution management: responsible for executing specific tasks, including code deployment and code execution. because the code loading and execution involve security and uninstallation issues, if you use a new process outside the host to execute the customer's Code, although it can solve the clearance problem after the code is executed, however, both control and communication are troublesome, and it is not conducive to the customer's code to use the services provided by the host. However, if the code is executed directly in the host process, security issues will occur (the user's code can access the whole process space, the thread does not have the isolation function), and after execution, the user's Code cannot be uninstalled. Therefore, to simplify the problem, the CLR application domain (appdomain) management function is used here, which can solve the above problems perfectly.

In addition to the above three basic functions, the computing node also includes the heartbeat service. Because of the large number of nodes, if each node publishes heartbeat information to each other, the efficiency is of course very low, therefore, I have set up a central node (equivalent to a master node). Everyone sends the node to the central node and obtains the status of other nodes from the central node. In this way, if the central node fails, the impact must be very high. But in fact, to solve this problem, you can set 2-3 such central nodes. If 1st are down, 2nd central nodes will be responsible for this status forwarding.

Each node is uniquely identified by the IP address, port, and service name. to simplify management, it is better to use the IP address and port to uniquely identify a node.
I directly use WCF for inter-node communication. Of course, writing this layer by myself is also acceptable, but I don't think it is necessary.

Let's take a look at the external task request management:
1) external service interface:

 

/// <Summary> /// used to provide public services to the customer. /// </Summary> [servicecontract (protectionlevel = system. net. security. protectionlevel. none)] public interface icomputingservice {// <summary> /// task Assembly deployment service /// </Summary> /// <Param name = "taskcommd"> </param>/ // <returns> </returns> [operationcontract] list <execresult> deploytaskassembely (taskcommand taskcommd ); /// <summary> /// execute a task or command to execute the service and merge the results. /// </Summary> /// <Param name = "taskcommd"> </param> /// <returns> </returns> [operationcontract] execresult executetaskcommand (taskcommand taskcommd ); /// <summary> /// the task or command executes the service, but the result is not merged. /// </Summary> /// <Param name = "taskcommd"> </param> /// <returns> </returns> [operationcontract] list <execresult> executetaskcommandex (taskcommand taskcommd ); /// <summary> /// provides the computing command query service during execution /// </Summary> /// <returns> </returns> [operationcontract] list <calccommand> getcalccmmds (); /// <summary> /// provide the current home assembly list service // </Summary> /// <returns> </returns> [operationcontract] list <calccommand> getcurrassemblies (); /// <summary> /// obtain the computing node Information Service /// </Summary> /// <returns> </returns> [operationcontract (protectionlevel = system. net. security. protectionlevel. none)] list <calcnodeinfo> getcalcnodeinfos (); // todo: add your service operation here}

This is an external service, and the corresponding client call proxy is implemented in the dcscomputingsvcproxy class. The core implementation of external request task management is in the dcscomputingdispather class.

This class is responsible for forwarding tasks to the target computing node based on the routing information provided by the user, or calling local internal request Task Management to execute the tasks it is responsible. These codes are too long to be pasted. The key technical point is multi-thread processing.

The service interfaces for internal request Task Management on computing nodes are as follows:

/// <Summary> /// internal distributed computing service, which is not publicly available. /// </Summary> [servicecontract] public interface idistributedcomputingservice {// <summary> /// task code subordinate service /// </Summary> /// <Param name = "calccommd"> </param> // <returns> </returns> [operationcontract] execresult deploytaskassembely (calccommand calccommd ); /// <summary> /// task execution service /// </Summary> /// <Param name = "calccommd"> </param> /// <returns> </returns> [Opera Tioncontract] execresult executetaskcommand (calccommand calccommd ); /// <summary> /// provides the list service for the commands being executed on the current node /// </Summary> /// <returns> </returns> [operationcontract] list <calccommand> getcalccmmds (); /// <summary> /// obtain the current Assembly list service /// </Summary> /// <returns> </returns> [operationcontract] list <calccommand> getcurrassemblies (); /// <summary> /// list of computing node information. /// </Summary> /// <returns> </returns> [operat Ioncontract] list <calcnodeinfo> getcalcnodeinfos (); // <summary> // register a service node. /// </Summary> /// <Param name = "nodeinfo"> </param> /// <returns> </returns> [operationcontract] string registercalcnodeinfo (calcnodeinfo nodeinfo );}}

Functions are similar to external services, but they are much simpler.

Continue tomorrow...