CN112187854B

CN112187854B - Task processing method and device for task processing

Info

Publication number: CN112187854B
Application number: CN202010834102.9A
Authority: CN
Inventors: 姚帅
Original assignee: Huakong Tsingjiao Information Technology Beijing Co Ltd
Current assignee: Huakong Tsingjiao Information Technology Beijing Co Ltd
Priority date: 2020-08-18
Filing date: 2020-08-18
Publication date: 2023-10-20
Anticipated expiration: 2040-08-18
Also published as: CN112187854A

Abstract

The embodiment of the invention provides a task processing method, a task processing device and a task processing device. In the method, the TM end sends a task notification message to the DS end through a message server in the system under the condition that a task to be executed is acquired, namely, under the condition that the task is to be executed. Correspondingly, the DS side obtains the task configuration information under the condition of receiving the task notification message sent by the message server side. Therefore, the DS end does not need to continuously inquire, and only needs to acquire the task configuration information after receiving the notification message, so that unnecessary inquiry can be avoided, further processing resources can be saved, the burden of the inquired data service control end is reduced, and the overall stability of the system is improved.

Description

Task processing method and device for task processing

Technical Field

The present invention relates to the field of computer technologies, and in particular, to a task processing method and apparatus, and a device for task processing.

Background

In the multiparty security computing system, since each data Server (Date Server, DS, also called as data owner or data provider) has no public network IP address, the Server can not be actively connected to DS when it has tasks, the current implementation scheme is: the data service control end in the multiparty safety computing system is continuously inquired to ensure that the data service control end can send the task configuration information to the DS end when the task needs to be executed.

The above-described approach has at least the following drawbacks:

the DS acquisition task has a longer time delay, the delay time depends on the time interval of DS inquiry, if the interval is too long, the delay time is too long, if the interval is too short, the consumed processing resources are more, and a larger burden may be brought to the inquired data service control end, so that the overall stability of the system is reduced.

Disclosure of Invention

The embodiment of the invention provides a task processing method and device and a device for task processing, which can save processing resources and improve the overall stability of a system when executing tasks.

In order to solve the above problems, an embodiment of the present invention discloses a task processing method, which is applied to a task execution system, wherein the system includes a message service end, a task management TM end, a task execution ES end, and a data service DS end, and the method includes:

the TM terminal acquires a task to be executed, wherein the task to be executed comprises task configuration information;

the TM terminal stores the task configuration information;

the TM terminal sends a task notification message to the task participation node corresponding to the task to be executed through the message server terminal; the task participation node comprises an ES end and a DS end corresponding to the task to be executed;

And after receiving the task notification message, the task participation node acquires the saved task configuration information so as to execute the task to be executed.

On the other hand, the embodiment of the invention discloses a task processing device, which is applied to a task execution system, wherein the system comprises a message service end, a TM end, an ES end and a DS end, and the device comprises:

the first acquisition module is used for acquiring a task to be executed through the TM terminal, wherein the task to be executed contains task configuration information;

the storage module is used for storing the task configuration information through the TM terminal;

the first sending module is used for sending a task notification message to the task participation node corresponding to the task to be executed based on the message service end through the TM end; the task participation node comprises an ES end and a DS end corresponding to the task to be executed;

and the second acquisition module is used for acquiring the saved task configuration information after the task participation node receives the task notification message so as to execute the task to be executed.

In yet another aspect, an embodiment of the present invention discloses an apparatus for task processing, applied to a task execution system, the system including a message service side, a TM side, an ES side, and a DS side, the apparatus including a memory, and one or more programs, wherein the one or more programs are stored in the memory, and configured to be executed by the one or more processors, the one or more programs including instructions for:

the TM terminal stores the task configuration information;

In yet another aspect, embodiments of the invention disclose a machine-readable medium having instructions stored thereon that, when executed by one or more processors, cause an apparatus to perform a task processing method as described in one or more of the preceding.

The embodiment of the invention has the following advantages:

in the task processing method of the embodiment of the invention, the TM end sends the task notification message to the DS end through the message server in the system under the condition that the task to be executed is acquired, namely, under the condition that the task is to be executed. Correspondingly, the DS side obtains the task configuration information under the condition of receiving the task notification message sent by the message server side. Therefore, the DS end does not need to continuously inquire, and only needs to acquire the task configuration information after receiving the notification message, so that unnecessary inquiry can be avoided, further processing resources can be saved, the burden of the inquired data service control end is reduced, and the overall stability of the system is improved.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings that are needed in the description of the embodiments of the present invention will be briefly described below, it being obvious that the drawings in the following description are only some embodiments of the present invention, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 is a schematic diagram of an application architecture provided by the present invention;

FIG. 2 is a flowchart illustrating steps of an embodiment of a task processing method according to the present invention;

FIG. 3 is a diagram of the start logic of the TM terminal provided by the invention;

FIG. 4 is a schematic diagram of task configuration information acquisition provided by the present invention;

FIG. 5 is a block diagram of a task execution system according to the present invention;

FIG. 6 is a block diagram illustrating an exemplary task processing device according to the present invention;

FIG. 7 is a block diagram of an apparatus 800 for task processing in accordance with the present invention; a kind of electronic device with high-pressure air-conditioning system

Fig. 8 is a schematic diagram of a server in some embodiments of the invention.

Detailed Description

The following description of the embodiments of the present invention will be made clearly and fully with reference to the accompanying drawings, in which it is evident that the embodiments described are some, but not all embodiments of the invention. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.

First, an application architecture of an embodiment of the present invention is described with reference to fig. 1. The application architecture may be used to implement a Task execution system, and the architecture may include a message service end, a Task Management (TM) end, a Task Execution (ES) end, and a DS end. The Task execution system may be a scheduling and management system, which may also be referred to as a scheduler (CO) platform, where a message service end may be used to transfer messages between various ends in the system, an ES end may be used to execute a specific Task, the ES end may start Task Control (TC) threads/processes, a TM end may be used to manage TC threads/processes, and a DS end may provide services such as data storage, data provision, and calculation result storage. The task execution system can be used for realizing the task processing method provided by the embodiment of the invention.

Referring to fig. 2, there is shown a flowchart of steps of an embodiment of a task processing method of the present invention, the method being applied to a task execution system, the method comprising the steps of:

step 101, the TM terminal obtains a task to be executed, wherein the task to be executed comprises task configuration information;

102, the TM end stores the task configuration information;

Step 103, the TM terminal sends a task notification message to the task participation node corresponding to the task to be executed through the message server terminal; the task participation node comprises an ES end and a DS end corresponding to the task to be executed;

step 104, after receiving the task notification message, the task participation node acquires the saved task configuration information to execute the task to be executed.

The task to be executed may be initiated by the user through the client, and may include task configuration information, or may further include other information. Accordingly, under the condition of storing the task configuration information, other information contained in the task to be executed can be further stored, which is not limited by the embodiment of the present invention.

Further, the task configuration information may include task identification (Identity, ID) of the task to be executed, and different tasks to be executed may correspond to different task IDs. Further, the task configuration information may further include other information, for example, a node ID of a task participation node for executing the task to be executed, including: the ES end ID of the executing task and the ID of the data provider DS, etc. And the task participation node indicated by the node ID included in the task configuration information is the task participation node corresponding to the task to be executed.

In an optional implementation manner of the embodiment of the present invention, a notification pushing policy after receiving a new task request may be set in advance in the TM end, and specifically, after receiving the new task request, the TM end may acquire and store task configuration information of a task to be executed. When the TM end sends a task notification message to a task participation node corresponding to a task to be executed through the message service end, a node ID of the task participation node corresponding to the task to be executed may be determined first according to the task configuration information, and then a notification sending message including the node ID is sent to the message service end, where the notification sending message may be used to instruct the message service end to send the task notification message to the task participation node indicated by the node ID. Accordingly, after receiving the notification transmission message, the message server may transmit a task notification message to the task participation nodes indicated by the respective node IDs.

When the technical solution of the embodiment of the present invention is applied to a multiparty secure computing system, since at least two ESs are required for completing one ciphertext computing task, for an ES end, the step of obtaining the saved task configuration information in step 104 may include:

step S11, the ES end starts a task control TC process/thread corresponding to the task to be executed;

step S12, the TC process/thread sends a pull request to the TM terminal according to the task ID;

and step S13, the TC process/thread receives the task configuration information returned by the TM terminal based on the pull request.

Wherein, a process is a running activity of a program in a device on a certain data set, and is a basic unit of resource allocation and scheduling of a system. A thread is the smallest unit that an operating system can perform operational scheduling. It may be included in a process, being the actual unit of operation in the process. One thread refers to a single sequential control flow in a process, and multiple threads can be concurrent in a process, each thread executing different operations in parallel. In specific implementation, the ES end may start a TC process to execute a task to be executed, or may start a TC thread to execute a task to be executed, which is not limited in the embodiment of the present invention.

In specific implementation, the TM end may provide a grpc interface to obtain task configuration information, and the TC process/thread may support a grpc protocol, and accordingly, send, to the TM end, a pull request carrying a task ID based on the grpc interface, where the pull request may be used to request task configuration information of a task to be executed stored by the TM end. It should be noted that, when sending the pull request, the TC process/thread may be sent through the message server, or the ES end may maintain heartbeat connection with the TM end based on its own node ID, and the TC process/thread on the ES end is sent to the TM end through the heartbeat connection, which is not limited in the embodiment of the present invention. Further, the task execution system may have a plurality of tasks to be executed, and after the TM end receives the pull request, the TM end may search, according to the task ID carried in the pull request, task configuration information of the task to be executed corresponding to the task ID, and return the task configuration information to the TC process/thread. It should be noted that, the TC process/thread may receive the returned task configuration information through the following commands on the ES side: rpc execttask (TaskConfig) returns (TaskResponse) { }; the "TaskConfig" and "TaskResponse" may be extended with information in the existing "exectsk" configuration, which is not limited in the embodiment of the present invention. Further, if the task configuration information returned by the TM end is not received after the preset duration of the pull request is sent, it may be determined that the TM end has a fault, and accordingly, fault prompt information may be output to remind a staff to timely perform fault processing. In the embodiment of the invention, the log generated in the running process of the TC process/thread can be collected and then displayed through the preset management equipment, so that the running condition of the TC process/thread can be conveniently obtained. The logs may be named as task IDs, and collected in a standard (std) format by a log collection system, for example, an "elastic search" system, and the preset management device may display by reading the content collected in the elastic search system.

In one existing implementation, the TM end starts a TC process/thread through its own dock virtual service technology, and actively sends task configuration information to the TC process/thread. For example, the process of starting the TC process/thread by the TM side may refer to the starting logic diagram shown in fig. 3. In this implementation, a problem occurs at the TM end sometimes, which leads to a situation that the TC process/thread is involved and cannot be started normally. In the embodiment of the invention, each ES end starts a TC process/thread, and task configuration information is actively obtained from a TM end after starting. Thus, the problem that the TC process/thread cannot be started normally due to the problem of the TM end can be avoided, and the TC process/thread can be started normally. Meanwhile, task configuration information is actively obtained from the TM terminal after the TM terminal is started, so that whether the TM terminal has a problem or not can be timely found, and the operation condition of the TM terminal can be conveniently mastered.

Further, the ES ends in step S11 may include a first ES end and a second ES end, where the second ES end may be one or more, and the first ES end and the second ES end form a set of ES ends. In implementation, the step of the ES end opening the task control TC process/thread corresponding to the task to be executed may include: and the first ES end starts a task control TC process/thread corresponding to the task to be executed. After the TC process/thread receives the task configuration information returned by the TM end based on the pull request, the method further includes: and the TC process/thread synchronizes the task configuration information to each second ES end. For example, in a multiparty secure computing system, after one ES in a set of ESs for completing a ciphertext computing task receives a task notification message, a TC process/thread is started, and after the TC process/thread acquires configuration information, the TC process/thread synchronizes with other ESs in the set of ESs.

The first ES end may be any ES end of a set of ES ends, and the second ES end may be an ES end of the set of ES ends other than the first ES end. After the first ES end synchronizes the task configuration information to the second ES end through the opened TC process/thread, the first ES end may participate in a specific execution process of the task to be executed. In the embodiment of the invention, the first ES end starts the TC process/thread first, sends the pull request to the TM end to acquire the task configuration information, and synchronizes the acquired task configuration information to other second ES ends, so that the request amount of the pull request received by the TM end and the operation times of returning the task configuration information to be executed can be reduced, the burden of the TM end can be further reduced, and meanwhile, the operation of sending the pull request by the second ES end can be omitted, and the processing resources can be saved.

The task execution system of the embodiment of the invention can also comprise a data service control (Data Server Control, DSC) end. The task notification message also includes the address of the DSC end. The operation of the TM side to save the task configuration information in step 102 may include: and the TM terminal locally stores the task configuration information, and sends the task configuration information to the DSC terminal for storage according to the address of the DSC terminal. The address of the DSC terminal may be a network communication address or a uniform resource locator (Uniform Resource Locator, URL) of the DSC terminal, and the TM terminal may send task configuration information to the DSC terminal by accessing the address of the DSC terminal, and after receiving the task configuration information, the DSC terminal may store the task configuration information locally. Or the TM terminal can send the task configuration information to the DSC terminal for storage through the ES terminal.

For example, fig. 4 is a schematic diagram of task configuration information acquisition provided by the embodiment of the present invention, as shown in fig. 4, a first ES end may start a TC process/thread, and acquire task configuration information from a TM end. The first ES side may then send the task configuration information to other second ES sides and DSC sides in the ES cluster.

It should be noted that, when the DS end requests the task configuration information from the DSC end, the DSC end may not receive the task configuration information sent by the ES end, which may be affected by factors such as a transmission delay. In this case, the DSC terminal can actively obtain the task configuration information from the TM terminal, and return the obtained task configuration information to the DS terminal, so as to ensure that the DS terminal can obtain the task configuration information in time.

Accordingly, for the DS end, the operation of obtaining the task configuration information of the saved task to be executed in step 104 may include:

step S21, the DS end sends a pulling request to the DSC end according to the task ID so as to acquire the task configuration information from the DSC end;

step S22, if the DS end does not receive the task configuration information returned by the DSC end within a first preset time period, the pulling request is sent to the TM end;

Step S23, the DS end receives the task configuration information returned by the TM end based on the pulling request.

The first preset duration may be set according to actual requirements, which is not limited in the embodiment of the present invention. For example, the longest time period required for returning the task configuration information by the DSC end may be used as the first preset time period. In specific implementation, the same task acquisition interfaces can be set for the DSC end and the TM end in advance, the task acquisition interfaces can be used for acquiring tasks, the DS end can acquire task configuration information based on the task acquisition interfaces of the DSC end, and the DSC end can return the task configuration information to the DS end under the condition that the DSC end has the task configuration information and is normal. Accordingly, if the DS end does not receive the task configuration information returned by the DSC end within the first preset time, the DS end can be considered that the DSC end possibly fails to return the task configuration information, the DS end can resend the pulling request to the TM end, and the task configuration information is acquired based on a task acquisition interface of the TM end. After the DS side obtains the task configuration information from the DSC side, task state information may also be returned to the DSC side in a subsequent process, so that the DSC side obtains the current state of the task. The task state may include: executing, completed, incomplete, etc. Further, the DSC end can discard the task state information corresponding to the task configuration information which is not stored, so as to avoid wasting storage resources.

In the embodiment of the invention, the TM terminal locally stores the task configuration information, the task configuration information is sent to the DSC terminal for storage, and under the condition that the DS terminal fails to pull the task configuration information from the DSC terminal, the task configuration information is pulled from the TM terminal. Specifically, the TM end may provide a grpc interface for returning task configuration information, and the task participation node may obtain config task configuration information through the grpc interface. Correspondingly, the DS end can acquire the task configuration information through the interface. In the embodiment of the invention, the task configuration information is stored by controlling the TM end and the DSC end, and the task configuration information can be provided for the DS end by both the TM end and the DSC end, so that double guarantee is provided for the DS end, and the DS end is ensured to successfully acquire the task configuration information.

Further, in an existing implementation, the DS end continuously sends a heartbeat message to the DSC end for a period of time, and the task configuration information is obtained through the heartbeat message, where the period of time determines when the DS end can take the task. Under the condition of longer time period, the DS end can acquire the task configuration information after the TM end stores the task configuration information for a longer time, and the delay of acquiring the task configuration information is larger. In the embodiment of the invention, the DS terminal obtains the task configuration information under the condition of receiving the task notification message sent by the message server terminal, so that the task configuration information can be obtained timely to a certain extent, and the delay of obtaining the task configuration information is reduced.

Meanwhile, compared with the mode that the DS end is always connected with the DSC end in a heartbeat mode, the DSC end is continuously inquired to acquire task configuration information, and further, heavy network flow and CPU burden are caused to the DSC end. In the embodiment of the invention, the DS end and the DSC end do not need to keep heartbeat connection all the time, and only need to communicate with the message service end occasionally, namely, receive the task notification message sent by the message service end, and acquire the task configuration information from the DSC end after receiving the task notification message, so that unnecessary network flow and CPU burden for the DSC end can be avoided, and the stability of the DSC end is improved.

Further, in the embodiment of the invention, because the TM terminal needs to send the task notification message to the DS terminal through the message service terminal, the DS terminal can register with the TM terminal first so as to ensure that the TM terminal can sense the existence of the DS terminal, and further, the TM terminal can send the task notification message to the DS terminal conveniently. Alternatively, the registration process of the DS end may be: the DS end sends registration information carrying the node ID of the DS end to the TM end in an initialization stage so as to characterize the DS end to be in a usable state currently; if the DS end does not receive the registration success response returned by the TM end within the third preset time, the registration request is sent to the TM end again until the registration success response is received.

The initialization stage may be that the third preset duration is set according to actual requirements when the DS end is first accessed to the task execution system, which is not limited in the embodiment of the present invention. It should be noted that, when the TM end sends the task notification message to the DS end, it may be determined whether the DS end is in a usable state, and if so, the sending operation is performed again, so as to avoid performing an unnecessary sending operation to the unusable DS end, thereby saving processing resources.

Specifically, the TM side may be preset to provide a registration interface supporting repeated registration for DS registration. After receiving the registration information sent by the DS end, the TM end may record the node ID of the DS end, so as to implement registration. And returns a registration success response after registration. Accordingly, if the DS end does not receive the registration success response returned by the TM end within the third preset duration, it may be considered that the registration is not successful, and at this time, the registration request may be sent to the TM end again until the registration success response is received. In the embodiment of the invention, the DS end registers with the TM end and repeatedly registers under the condition of successful unregistering, so that the TM end can be ensured to perceive that the DS end is in a usable state currently, and the TM end can conveniently send a task notification message to the DS end. Meanwhile, by supporting repeated registration and maintaining idempotency of the interface, the DS end can be ensured to register smoothly. For example, in a special case where a network delay occurs or the DS end is restarted, the DS end may complete registration by repeating registration.

Optionally, in the actual application scenario, the task participation node may receive a wide variety of notification messages. For example, when the TM end needs to probe the DS end, a probe notification message for instructing the DS end to send a ping instruction to the TM end may be sent, or when the TM end address changes, the TM end may send an address change notification message. For the received notification message, the task participation node may determine whether a notification type of the notification message is a task type; and if the notification type of the notification is a task type, confirming that the task notification message is received.

In a specific implementation, the notification format of the notification message may be a tuple < type, info >, where type may represent a notification type, and for example, when type is "task", it may be confirmed that the notification type of the notification message is a task type. The info represents other necessary information, for example, in the case of type "task", for the DS end, the info may be the task ID and the address of the DSC end, and accordingly, the format of the info may be expressed as request123# # # # # http:// dscUrl. It should be noted that, the specific format of the info may be extended by a language such as json, and the formats of the info corresponding to different types may be different, that is, the types of information contained in the info may be different. In the embodiment of the invention, under the condition that the notification type is judged to be the task type, the task notification message is confirmed to be received, so that unnecessary operation of acquiring the task configuration information caused by misjudgment can be avoided, and further, the processing resource can be saved.

In another optional embodiment of the present invention, the DSC end may not be set in the task execution system, and correspondingly, for the DS end in the task participation node, the DS end may send a pull request to the TM end according to the task ID; and the DS end receives the task configuration information returned by the TM end based on the pull request. Specifically, the implementation manner of sending the pull request by the DS end to obtain the task configuration information according to the task ID may refer to the foregoing related description, which is not described herein again. In the embodiment of the invention, the DSC end is not required to be arranged in the task execution system, and the DS end directly pulls the task configuration information from the TM end, so that the hardware cost of the task execution system can be reduced, and the realization cost of the task processing method is further reduced.

In another optional embodiment of the present invention, after step 103, the method may further include:

and step A, if the pulling request is not received within a second preset time period, the TM terminal repeatedly executes the operation of sending the task notification message until the number of repeated execution reaches a preset number threshold or the pulling request is received. The second preset duration and the preset frequency threshold may be set according to actual requirements, which is not limited in the embodiment of the present invention. Normally, the task participation node receives the task notification message, and responds to the task notification message by sending a pull request to the TM end. If the pull request is not received within a second preset time period. The task participation node may be considered not to normally receive the task notification message. In this case, the TM side may repeatedly send the task notification message through the message server, and further, if the number of times of repeated execution reaches the preset number of times threshold or a pull request is received, execution may be stopped, so as to avoid wasting processing resources. Of course, the repeated transmission may be stopped when the duration of performing the repeated transmission operation reaches the preset duration, which is not limited in the embodiment of the present invention.

Correspondingly, when the task participation node sends a pulling request to the TM terminal according to the task ID, whether the task ID is received for the first time or not can be judged; and if the task ID is received for the first time, sending the pulling request to the TM terminal. In a specific embodiment, the task participating node may record the task ID carried in the received task notification message each time, and when sending the pull request according to the task ID, may detect whether the task ID exists in the recorded task ID, and if not, may consider that the task ID is received for the first time, and send the pull request to the TM end according to the task ID.

In the embodiment of the invention, the TM terminal repeatedly transmits the task notification message under the condition that the pulling request is not received within the second preset time, so that the task notification message can be ensured to be normally transmitted to the task participation node to a certain extent. Further, it may happen that the task participation node receives the task notification message, but due to factors such as network delay, the pull request is not timely sent to the TM end, and further the TM end repeatedly sends the task notification message. In the embodiment of the invention, when the task participation node sends the pulling request according to the task ID in the task notification message, the pulling request is sent only when the task ID is received for the first time, so that the problem of repeated sending of the pulling request caused by repeated sending of the task notification message by the TM end can be avoided, and the processing resource is saved.

Further, in another alternative embodiment of the present invention, the following operations may be performed prior to step 103: the task participation node sends a channel allocation request to the message server; and after receiving the channel allocation request, the message service end allocates a corresponding message sending channel to the task participation node. Wherein the channel allocation request may be used to subscribe to a channel belonging to the task participation node with the message server. The channel allocation request may carry a node ID of the task participation node, the message server may establish a correspondence between the node ID and a channel (channel), and channels corresponding to different node IDs may be different, where the channel corresponding to the node ID of the task participation node is the channel allocated to the task participation node. It should be noted that, the channel information of the channel corresponding to the task participation node may represent the node ID of the task participation node, so that the message server may conveniently determine the channel corresponding to the task participation node according to the node ID of the task participation node. For example, the channel information of the channel corresponding to the DS end may be url: privpy/aaa/dsid. Where "dsid" denotes the node ID of the DS end.

Correspondingly, the sending, by the TM side, a task notification message to the task participation node corresponding to the task to be executed through the message service side may include:

Step S31, the TM terminal sends the node ID of the task participation node included in the task to be executed to the message service terminal;

and step S32, the message server side sends the task notification message to the task participation node according to the received message sending channels corresponding to the node IDs.

In specific implementation, the TM end and the message service end may be virtual services deployed on the same server, and accordingly, the TM end may communicate with the message service end through a communication mechanism inside the server. Alternatively, the TM peer and the message service peer are deployed on different servers, and accordingly, the TM peer may communicate with the message service peer through a network connection between the servers.

Further, the message server side can determine a message sending channel corresponding to each node ID according to the established corresponding relationship, and send the task notification message through the corresponding message sending channel. In the embodiment of the invention, each task participation node registers the message sending channel belonging to the message server side, and the message server side sends the task notification message through the message sending channel corresponding to each task participation node, so that the mutual interference among a plurality of task notification messages sent to a plurality of task participation nodes can be avoided, and the message sending efficiency is further improved.

In an alternative embodiment of the present invention, after obtaining the saved task configuration information, the method further includes:

b, the task participation node performs multiparty safety calculation according to the task configuration information so as to complete the task to be executed; specifically, performing the task to be performed may include: the DS end sends a data ciphertext to an ES end appointed in the task configuration information according to the task configuration information; and the ES end executes multiparty security calculation according to multiparty security calculation protocol aiming at the received data ciphertext. Therefore, the specified ES end executes multiparty security calculation on the data ciphertext according to multiparty security calculation protocols, and the calculation can be realized on the premise that the data are kept secret mutually, so that the security of the data participating in the calculation is improved. It should be noted that the DS side may share a corresponding certificate with the ES side, so that the computing process supports the security layer transmission (Transport Layer Security, TLS) and the data authorization (auth).

Further, after the ES end performs the multiparty security computation according to the multiparty security computation protocol with respect to the received data ciphertext, the method further includes:

step C, the ES end sends a result acquisition notification message to a result demand end through the message server end;

Step D, the result demand end sends a result pulling request to the ES end after receiving the result acquisition notification message;

and E, the result demand end receives the calculation result of the multiparty security calculation returned by the ES end.

The result acquisition notification message may indicate that the multiparty security computation is completed, and the result pulling request may be used to acquire the computation result of the multiparty security computation from the ES end. After the ES side receives the result pulling request, the calculation result of the multiparty secure calculation may be returned to the result demand side accordingly. The result demand end may be specified according to actual demand. For example, the result requirement end may be a DS end, or may be a client that initiates a task to be performed, or the like. Further, in an existing implementation, the result request end continuously sends a heartbeat message to the DSC end in a time period, and the calculation result is obtained through the heartbeat message, where the time period determines when the result request end can take the calculation result. In the case of a longer time period, a larger delay may be caused in obtaining the calculation result by the result demand end. In the embodiment of the invention, after the multi-party security calculation is completed, the ES end sends the result acquisition notification message to the result demand end through the message service end, and the result demand end sends the result pulling request to the ES end after receiving the result acquisition notification message, so that the operation that the result demand end continuously sends heartbeat messages can be omitted, the resource consumption of the result demand end is reduced, and the acquisition efficiency of the result demand end is improved. Meanwhile, after the result acquisition notification message is received, the calculation result can be timely acquired by sending the result pulling request to the ES end, and delay is reduced.

It should be noted that, in the process of executing the task to be executed, the TC process/thread may periodically return task state information to the TM end. Specifically, when the task starts to be executed, the TM end may call a preset "execttask" interface, and send "startTcRequest" protocol information to a control port of the ES end, where the control port may be a 7001 port. Task state information may be returned based on the "execttask" interface. Specifically, the TM end may send protobuf protocol-based information to the interface every second to obtain task state information until the task end position. Accordingly, the ES end may forward the information based on the protobuf protocol to the TC process/thread, and after the TC process/thread returns the task state information, send the task state information to the TM end. Further, the TM side calls the "execttask" interface, and the operation of acquiring the returned task state information based on the "execttask" interface and sending the information based on the protobuf protocol to the interface every second may be called when executing the specific code of the troubleshooting task.

Alternatively, the message server in the embodiment of the present invention may be a notification service based on the publish PUB/subscribe SUB protocol. Since the notification service can support multiple operating systems and programming languages, the notification service can be used to implement the message service in a diversified manner, for example, to separate the processing logic of the message service from the actual task processing procedure. Meanwhile, because the notification service can realize communication with smaller network overhead and support various client network environments, the DS/ES can be ensured to send messages to the DS/ES through the message service terminal when the DS/ES is in various network environments. For example, in the case where the DS end does not have a public network IP address, since the notification service can support communication with and without a public network IP address, it can be ensured that a message can be sent to the DS end. Meanwhile, the notification service is mature and reliable, so that the notification service is adopted to realize the message service end, and the reliability and stability of the message service end can be ensured. The notification system selected in the message service end can be a micro message queue, and further, an analog message queue with an interface consistent with the micro message queue can be set. Thus, the message sending efficiency of the message service end can be improved to a certain extent through the double message queues.

Further, in an alternative embodiment of the present invention, for a DS end in a task participation node, the message service end may allocate at least two message sending channels for the DS end, where a message sending channel may correspond to a multiparty secure computing system. It should be noted that, at least two message sending channels allocated by the message server side to the DS side may be understood as a plurality of services subscribed by the DS side to the message server side. Further, the operation of the message server in step S32 to send the task notification message to the task participation node according to the received message sending channels corresponding to the node IDs may include:

step S32a, the message service end sends the task notification message to the DS end through a message sending channel corresponding to a target multiparty security computing system in at least two message sending channels distributed to the DS end; the target multiparty secure computing system is the task execution system.

In the implementation, the message server may first find a message sending channel corresponding to the target multiparty secure computing system, and then send a task notification message through the message sending channel. In the embodiment of the invention, the DS end can provide services for a plurality of multiparty safety computing systems by distributing a plurality of message sending channels corresponding to different multiparty safety computing systems for the DS end. Thus, the DS end is shared by a plurality of multiparty secure computing systems, and the utilization rate of the DS end can be improved to a certain extent. For example, two message sending channels may be allocated to the DS end, where one message sending channel may correspond to the multi-party security computing system a, and another message sending channel may correspond to the multi-party security computing system B, so as to implement that the DS end simultaneously interfaces with the multi-party security computing system a and the multi-party security computing system B, and simultaneously provides services for two or more multi-party security computing systems.

Further, fig. 5 is a schematic diagram of a task execution system provided by the embodiment of the present invention, as shown in fig. 5, a TM end may send a task notification message to one of an ES end and a DS end through a message service end, and accordingly, the ES end may pull task configuration information from the TM end through an internal opened TC process/thread, and then synchronize the pulled task configuration information to each ES end, and send the task configuration information to a DSC end for storage, so that the DS end obtains the task configuration information from the DSC end. Further, the DS end and the ES end may also return status information to the TM end. Compared with the existing architecture, the task processing method provided by the embodiment of the invention can be realized by only adding the message server on the basis of the existing architecture, and has the advantages of less modification to the architecture and lower realization cost.

It should be noted that, for simplicity of description, the method embodiments are shown as a series of acts, but it should be understood by those skilled in the art that the embodiments are not limited by the order of acts, as some steps may occur in other orders or concurrently in accordance with the embodiments. Further, those skilled in the art will appreciate that the embodiments described in the specification are presently preferred embodiments, and that the acts are not necessarily required by the embodiments of the invention.

Device embodiment

Referring to fig. 6, there is shown a block diagram of an embodiment of a task processing device of the present invention, where the device is applied to a task execution system, and the system includes a message service end, a TM end, an ES end, and a DS end, and the device may specifically include:

the first obtaining module 601 is configured to obtain a task to be executed through the TM end, where the task to be executed includes task configuration information;

a saving module 602, configured to save the task configuration information through the TM end;

a first sending module 603, configured to send, by using the TM end, a task notification message to a task participation node corresponding to the task to be executed based on the message server end; the task participation node comprises an ES end and a DS end corresponding to the task to be executed;

and the second obtaining module 604 is configured to obtain, after receiving the task notification message through the task participation node, the saved task configuration information, so as to execute the task to be executed.

Optionally, the task configuration information includes a task identifier ID of the task to be executed;

for the ES end in the task participation node, the second obtaining module 604 is specifically configured to:

Starting a task control TC process/thread corresponding to the task to be executed through the ES end;

sending a pull request to the TM terminal through the TC process/thread according to the task ID;

and receiving the task configuration information returned by the TM terminal based on the pull request through the TC process/thread.

Optionally, the ES end includes a first ES end and a second ES end;

the second obtaining module 604 is further configured to:

starting a task control TC process/thread corresponding to the task to be executed through the first ES end;

after receiving, by the TC process/thread, the task configuration information returned by the TM side based on the pull request, the second obtaining module 604 is further specifically configured to:

and synchronizing the task configuration information to each second ES end through the TC process/thread.

Optionally, the system further comprises: the data service controls the DSC end, and the task notification message also comprises the address of the DSC end;

the saving module 602 is specifically configured to:

the TM end locally stores the task configuration information, and

according to the address of the DSC end, the task configuration information is sent to the DSC end for storage;

correspondingly, for the DS end in the task participation node, the second obtaining module 604 is further specifically configured to:

Sending a pulling request to the DSC end through the DS end according to the task ID so as to acquire the task configuration information from the DSC end;

if the DS end does not receive the task configuration information returned by the DSC end within a first preset time period, the DS end sends the pulling request to the TM end;

and receiving the task configuration information returned by the TM terminal based on the pull request through the DS terminal.

Optionally, the task configuration information includes a task identifier ID of the task to be executed; for the DS end in the task participation node, the second obtaining module 604 is further specifically configured to:

sending a pulling request to the TM terminal through the DS terminal according to the task ID;

Optionally, after the TM end sends, through the message server, a task notification message to the task participation node corresponding to the task to be executed, the first obtaining module 601 is specifically configured to:

if the pulling request is not received within the second preset time, repeatedly executing the operation of sending the task notification message through the TM end until the number of repeated execution reaches a preset number threshold or the pulling request is received;

Correspondingly, the second obtaining module 604 is further specifically configured to:

judging whether the task ID is received for the first time;

and if the task ID is received for the first time, sending the pulling request to the TM terminal.

Optionally, the apparatus further includes:

the second sending module is used for sending a channel allocation request to the message server through the task participation node;

the allocation module is used for allocating a corresponding message sending channel to the task participation node after receiving the channel allocation request through the message service terminal;

accordingly, the first obtaining module 601 is specifically configured to:

the node ID of the task participation node included in the task to be executed is sent to the message server through the TM terminal;

and sending the task notification message to the task participation node through the message server according to the received message sending channels corresponding to the node IDs.

Optionally, the apparatus further includes:

the execution module is used for the task participation node to perform multiparty safety calculation according to the task configuration information so as to complete the task to be executed;

correspondingly, for a DS end in the task participation node, the message service end distributes at least two message sending channels for the DS end, wherein one message sending channel corresponds to one multiparty security computing system; the first obtaining module 601 is further specifically configured to:

The message server side sends the task notification message to the DS side through a message sending channel corresponding to a target multiparty security computing system in at least two message sending channels distributed to the DS side; the target multiparty secure computing system is the task execution system.

Optionally, the message server is a notification service based on a publish PUB/subscribe SUB protocol.

Optionally, the apparatus further includes:

the registration module is used for sending registration information carrying the node ID of the DS to the TM terminal in an initialization stage by the DS terminal so as to characterize the DS terminal to be in a usable state currently;

and the third sending module is used for sending the registration request to the TM terminal again until receiving the registration success response if the DS terminal does not receive the registration success response returned by the TM terminal within a third preset time period.

Optionally, the apparatus further includes:

the judging module is used for judging whether the notification type of the notification message is a task type or not for the received notification message by the task participation node;

and the confirmation module is used for confirming that the task notification message is received if the notification type of the notification is a task type.

Optionally, the execution module is specifically configured to:

sending a data ciphertext to an ES end appointed in the task configuration information through the DS end according to the task configuration information;

and executing multiparty security calculation according to multiparty security calculation protocol by the ES terminal aiming at the received data ciphertext.

Optionally, the apparatus further includes:

a fourth sending module, configured to send a result acquisition notification message to a result demand end by using the ES end through the message service end;

a fifth sending module, configured to send a result pulling request to the ES end after the result request end receives the result acquisition notification message;

and the receiving module is used for receiving the calculation result of the multiparty security calculation returned by the ES end by the result demand end.

According to the task processing device provided by the embodiment of the invention, the task notification message is sent to the DS end through the message server in the system under the condition that the task to be executed is acquired through the TM end, namely, under the condition that the task is to be executed. Correspondingly, under the condition that the DS end receives the task notification message sent by the message server end, task configuration information is obtained. Therefore, the DS end does not need to continuously inquire, and only needs to acquire the task configuration information after receiving the notification message, so that unnecessary inquiry can be avoided, further processing resources can be saved, the burden of the inquired data service control end is reduced, and the overall stability of the system is improved.

For the device embodiments, since they are substantially similar to the method embodiments, the description is relatively simple, and reference is made to the description of the method embodiments for relevant points.

In this specification, each embodiment is described in a progressive manner, and each embodiment is mainly described by differences from other embodiments, and identical and similar parts between the embodiments are all enough to be referred to each other.

The specific manner in which the various modules perform the operations in the apparatus of the above embodiments have been described in detail in connection with the embodiments of the method, and will not be described in detail herein.

An embodiment of the invention provides a device for task processing, comprising a memory, and one or more programs, wherein the one or more programs are stored in the memory, and configured to be executed by one or more processors, the one or more programs comprising instructions for: acquiring a character string to be processed; converting the character string to be processed into integer type target data according to character codes of all characters in the character string to be processed in a memory; encrypting the target data to obtain ciphertext data; inputting the ciphertext data into a multiparty secure computing system, and executing preset operation on the ciphertext data through the multiparty secure computing system to obtain ciphertext of an operation result corresponding to the character string to be processed.

Fig. 7 is a block diagram illustrating an apparatus 800 for task processing, according to an example embodiment. For example, apparatus 800 may be a mobile phone, computer, digital broadcast terminal, messaging device, game console, tablet device, medical device, exercise device, personal digital assistant, or the like.

Referring to fig. 7, apparatus 800 may include one or more of the following components: a processing component 802, a memory 804, a power component 806, a multimedia component 808, an audio component 810, an input/output (I/O) interface 812, a sensor component 814, and a communication component 816.

The processing component 802 generally controls overall operation of the apparatus 800, such as operations associated with display, telephone calls, data communications, camera operations, and recording operations. Processing element 802 may include one or more processors 820 to execute instructions to perform all or part of the steps of the methods described above. Further, the processing component 802 can include one or more modules that facilitate interactions between the processing component 802 and other components. For example, the processing component 802 can include a multimedia module to facilitate interaction between the multimedia component 808 and the processing component 802.

The memory 804 is configured to store various types of data to support operations at the device 800. Examples of such data include instructions for any application or method operating on the device 800, contact data, phonebook data, messages, pictures, videos, and the like. The memory 804 may be implemented by any type or combination of volatile or nonvolatile memory devices such as Static Random Access Memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic or optical disk.

The power supply component 806 provides power to the various components of the device 800. The power components 806 may include a power management system, one or more power sources, and other components associated with generating, managing, and distributing power for the device 800.

The multimedia component 808 includes a screen between the device 800 and the user that provides an output interface. In some embodiments, the screen may include a Liquid Crystal Display (LCD) and a Touch Panel (TP). If the screen includes a touch panel, the screen may be implemented as a touch screen to receive input signals from a user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensor may sense not only the boundary of a touch or slide action, but also the duration and pressure associated with the touch or slide operation. In some embodiments, the multimedia component 808 includes a front camera and/or a rear camera. The front camera and/or the rear camera may receive external multimedia data when the device 800 is in an operational mode, such as a shooting mode or a video mode. Each front camera and rear camera may be a fixed optical lens system or have focal length and optical zoom capabilities.

The audio component 810 is configured to output and/or input audio signals. For example, the audio component 810 includes a Microphone (MIC) configured to receive external audio signals when the device 800 is in an operational mode, such as a call mode, a recording mode, and a voice information processing mode. The received audio signals may be further stored in the memory 804 or transmitted via the communication component 816. In some embodiments, audio component 810 further includes a speaker for outputting audio signals.

The I/O interface 812 provides an interface between the processing component 802 and peripheral interface modules, which may be a keyboard, click wheel, buttons, etc. These buttons may include, but are not limited to: homepage button, volume button, start button, and lock button.

The sensor assembly 814 includes one or more sensors for providing status assessment of various aspects of the apparatus 800. For example, the sensor assembly 814 may detect an on/off state of the device 800, a relative positioning of the components, such as a display and keypad of the apparatus 800, the sensor assembly 814 may also detect a change in position of the apparatus 800 or one component of the apparatus 800, the presence or absence of user contact with the apparatus 800, an orientation or acceleration/deceleration of the apparatus 800, and a change in temperature of the apparatus 800. The sensor assembly 814 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. The sensor assembly 814 may also include a light sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, the sensor assembly 814 may also include an acceleration sensor, a gyroscopic sensor, a magnetic sensor, a pressure sensor, or a temperature sensor.

The communication component 816 is configured to facilitate communication between the apparatus 800 and other devices, either in a wired or wireless manner. The device 800 may access a wireless network based on a communication standard, such as WiFi,2G or 3G, or a combination thereof. In one exemplary embodiment, the communication component 816 receives broadcast signals or broadcast related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, the communication component 816 further includes a Near Field Communication (NFC) module to facilitate short range communications. For example, the NFC module may be implemented based on radio frequency information processing (RFID) technology, infrared data association (IrDA) technology, ultra Wideband (UWB) technology, bluetooth (BT) technology, and other technologies.

In an exemplary embodiment, the apparatus 800 may be implemented by one or more Application Specific Integrated Circuits (ASICs), digital Signal Processors (DSPs), digital Signal Processing Devices (DSPDs), programmable Logic Devices (PLDs), field Programmable Gate Arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic elements for executing the methods described above.

In an exemplary embodiment, a non-transitory computer readable storage medium is also provided, such as memory 804 including instructions executable by processor 820 of apparatus 800 to perform the above-described method. For example, the non-transitory computer readable storage medium may be ROM, random Access Memory (RAM), CD-ROM, magnetic tape, floppy disk, optical data storage device, etc.

Fig. 8 is a schematic diagram of a server in some embodiments of the invention. The server 1900 may vary considerably in configuration or performance and may include one or more central processing units (central processing units, CPU) 1922 (e.g., one or more processors) and memory 1932, one or more storage media 1930 (e.g., one or more mass storage devices) that store applications 1942 or data 1944. Wherein the memory 1932 and storage medium 1930 may be transitory or persistent. The program stored in the storage medium 1930 may include one or more modules (not shown), each of which may include a series of instruction operations on a server. Still further, a central processor 1922 may be provided in communication with a storage medium 1930 to execute a series of instruction operations in the storage medium 1930 on the server 1900.

The server 1900 may also include one or more power supplies 1926, one or more wired or wireless network interfaces 1950, one or more input/output interfaces 1958, one or more keyboards 1956, and/or one or more operating systems 1941, such as Windows Server, mac OS XTM, unixTM, linuxTM, freeBSDTM, and the like.

A non-transitory computer readable storage medium, which when executed by a processor of an apparatus (server or terminal), enables the apparatus to perform the task processing method shown in fig. 2.

A non-transitory computer readable storage medium, which when executed by a processor of an apparatus (server or terminal), enables the apparatus to perform a task processing method applied to a task execution system including a message service side, a TM side, an ES side, and a DS side, the method comprising: the TM terminal acquires a task to be executed, wherein the task to be executed comprises task configuration information; the TM terminal stores the task configuration information; the TM terminal sends a task notification message to the task participation node corresponding to the task to be executed through the message server terminal; the task participation node comprises an ES end and a DS end corresponding to the task to be executed; and after receiving the task notification message, the task participation node acquires the saved task configuration information so as to execute the task to be executed.

The embodiment of the invention discloses A1, a task processing method, which is applied to a task execution system, wherein the system comprises a message service end, a Task Management (TM) end, a task Execution (ES) end and a Data Service (DS) end, and the method comprises the following steps:

the TM terminal stores the task configuration information;

A2, the method according to A1, wherein the task configuration information comprises a task identification ID of the task to be executed;

for the ES end in the task participation node, the obtaining the saved task configuration information includes:

the ES end starts a task control TC process/thread corresponding to the task to be executed;

the TC process/thread sends a pull request to the TM terminal according to the task ID;

and the TC process/thread receives the task configuration information returned by the TM terminal based on the pull request.

A3, according to the method of A2, the ES ends comprise a first ES end and a second ES end;

the ES end starts a task control TC process/thread corresponding to the task to be executed, and the method comprises the following steps:

The first ES end starts a task control TC process/thread corresponding to the task to be executed;

after the TC process/thread receives the task configuration information returned by the TM end based on the pull request, the method further includes:

and the TC process/thread synchronizes the task configuration information to each second ES end.

A4, the method of A1, the system further comprising: the data service controls the DSC end, and the task notification message also comprises the address of the DSC end;

the TM end stores the task configuration information, which comprises the following steps:

the TM end locally stores the task configuration information, and

correspondingly, for the DS end in the task participation node, the acquiring the saved task configuration information of the task to be executed includes:

the DS end sends a pulling request to the DSC end according to the task ID so as to acquire the task configuration information from the DSC end;

if the DS end does not receive the task configuration information returned by the DSC end within a first preset time period, the pulling request is sent to the TM end;

And the DS end receives the task configuration information returned by the TM end based on the pull request.

A5, the method according to A1, wherein the task configuration information comprises a task identification ID of the task to be executed; for the DS end in the task participation node, the obtaining the saved task configuration information includes:

the DS end sends a pulling request to the TM end according to the task ID;

A6, after the TM terminal sends a task notification message to the task participation node corresponding to the task to be executed through the message service terminal according to the method from A2 to A5, the method further comprises:

if the pulling request is not received within the second preset time, the TM terminal repeatedly executes the operation of sending the task notification message until the number of repeated execution reaches a preset number threshold or the pulling request is received;

correspondingly, the sending a pull request to the TM end according to the task ID includes:

judging whether the task ID is received for the first time;

A7, the method of A1, the method further comprising:

the task participation node sends a channel allocation request to the message server;

after receiving the channel allocation request, the message service end allocates a corresponding message sending channel to the task participation node;

correspondingly, the TM terminal sends a task notification message to the task participation node corresponding to the task to be executed through the message service terminal, and the task notification message comprises:

the TM terminal sends the node ID of the task participation node included in the task to be executed to the message server terminal;

and the message server side sends the task notification message to the task participation node according to the received message sending channels corresponding to the node IDs.

A8, after the task configuration information stored in the storage device is obtained according to the method of A6, the method further comprises:

the task participation node performs multiparty safety calculation according to the task configuration information so as to complete the task to be executed;

correspondingly, for a DS end in the task participation node, the message service end distributes at least two message sending channels for the DS end, wherein one message sending channel corresponds to one multiparty security computing system; the message server sends the task notification message to the task participation node according to the received message sending channels corresponding to the node IDs, and the message server comprises the following steps:

The message service end sends the task notification message to the DS end through a message sending channel corresponding to a target multiparty security computing system in at least two message sending channels distributed to the DS end; the target multiparty secure computing system is the task execution system.

A9, the method according to A1, wherein the message service end is a notification service based on a publish PUB/subscribe SUB protocol.

A10, the method according to A1, characterized in that the method further comprises:

the DS end sends registration information carrying the node ID of the DS end to the TM end in an initialization stage so as to characterize the DS end to be in a usable state currently;

if the DS end does not receive the registration success response returned by the TM end within the third preset time, the registration request is sent to the TM end again until the registration success response is received.

A11, the method of A1, the method further comprising:

for the received notification message, the task participation node judges whether the notification type of the notification message is a task type;

and if the notification type of the notification is a task type, confirming that the task notification message is received.

A12, executing the task to be executed according to the method of A1, wherein the executing the task to be executed comprises:

the DS end sends a data ciphertext to an ES end appointed in the task configuration information according to the task configuration information;

and the ES end executes multiparty security calculation according to multiparty security calculation protocol aiming at the received data ciphertext.

A13, according to the method of A12, after the ES end executes the multiparty security calculation according to the multiparty security calculation protocol with respect to the received data ciphertext, the method further comprises:

the ES end sends a result acquisition notification message to a result demand end through the message service end;

the result demand end sends a result pulling request to the ES end after receiving the result acquisition notification message;

and the result demand end receives the calculation result of the multiparty security calculation returned by the ES end.

The embodiment of the invention discloses a B14 and a task processing device, which are applied to a task execution system, wherein the system comprises a message service end, a TM end, an ES end and a DS end, and the device comprises:

The embodiment of the invention discloses a C15, a device for task processing, which is applied to a task execution system, wherein the system comprises a message service end, a TM end, an ES end and a DS end, the device comprises a memory and one or more programs, wherein the one or more programs are stored in the memory and are configured to be executed by one or more processors, and the one or more programs comprise instructions for:

the TM terminal stores the task configuration information;

The embodiment of the invention discloses D16, a machine-readable medium, having instructions stored thereon, which when executed by one or more processors, cause an apparatus to perform the task processing method as described in one or more of A1 to A13.

Other embodiments of the invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention following, in general, the principles of the invention and including such departures from the present disclosure as come within known or customary practice within the art to which the invention pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the invention being indicated by the following claims.

It is to be understood that the invention is not limited to the precise arrangements and instrumentalities shown in the drawings, which have been described above, and that various modifications and changes may be effected without departing from the scope thereof. The scope of the invention is limited only by the appended claims.

The foregoing description of the preferred embodiments of the invention is not intended to limit the invention to the precise form disclosed, and any such modifications, equivalents, and alternatives falling within the spirit and scope of the invention are intended to be included within the scope of the invention.

The task processing method, the task processing device and the task processing device provided by the invention are described in detail, and specific examples are applied to illustrate the principle and the implementation of the invention, and the description of the examples is only used for helping to understand the method and the core idea of the invention; meanwhile, as those skilled in the art will have variations in the specific embodiments and application scope in accordance with the ideas of the present invention, the present description should not be construed as limiting the present invention in view of the above.

Claims

1. The task processing method is characterized by being applied to a task execution system, wherein the system comprises a message service end, a Task Management (TM) end, a task Execution (ES) end and a Data Service (DS) end, and the method comprises the following steps:

The TM terminal stores the task configuration information;

after receiving the task notification message, the task participation node acquires the saved task configuration information so as to execute the task to be executed;

the system further comprises: the data service controls the DSC end, and the task notification message also comprises the address of the DSC end;

the TM end locally stores the task configuration information, and

the task configuration information comprises a task ID of the task to be executed; for the DS end in the task participation node, the obtaining the saved task configuration information includes:

2. The method according to claim 1, wherein for the ES end in the task participation node, the obtaining the saved task configuration information includes:

3. The method of claim 2, wherein the ES terminal comprises a first ES terminal and a second ES terminal;

4. The method according to claim 1, wherein for the DS end in the task participation node, the obtaining the saved task configuration information includes:

The DS end sends a pulling request to the TM end according to the task ID;

5. The method according to any one of claims 2 to 4, wherein after the TM peer sends, through the message server, a task notification message to the task participation node corresponding to the task to be performed, the method further includes:

judging whether the task ID is received for the first time;

6. The method according to claim 1, wherein the method further comprises:

7. The method of claim 5, wherein after the obtaining the saved task configuration information, the method further comprises:

8. The method of claim 1, wherein the message service is a notification service based on a publish PUB/subscribe SUB protocol.

9. The method according to claim 1, wherein the method further comprises:

if the DS end does not receive the registration success response returned by the TM end within the third preset time, the DS end sends a registration request to the TM end again until the registration success response is received.

10. The method according to claim 1, wherein the method further comprises:

11. The method of claim 1, wherein the performing the task to be performed comprises:

12. The method of claim 11, wherein the ES-side, after performing the multiparty security computation according to the multiparty security computation protocol with respect to the received data ciphertext, further comprises:

13. A task processing device, applied to a task execution system, the system including a message service end, a TM end, an ES end, and a DS end, the device comprising:

The second acquisition module is used for acquiring the saved task configuration information after the task participation node receives the task notification message so as to execute the task to be executed;

the storage module is specifically configured to:

the TM end locally stores the task configuration information, and

the task configuration information comprises a task ID of the task to be executed; for the DS end in the task participation node, the second obtaining module is further specifically configured to:

14. An apparatus for task processing, characterized by being applied to a task execution system, the system comprising a message service side, a TM side, an ES side, and a DS side, the apparatus comprising a memory, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by one or more processors, the one or more programs comprising instructions for:

the TM terminal stores the task configuration information;

the TM end locally stores the task configuration information, and

15. A machine readable medium having instructions stored thereon which, when executed by one or more processors, cause an apparatus to perform the task processing method of any of claims 1 to 12.