Adjudication method, device, computer equipment, readable storage medium and program product

Abstract

The application relates to a judgment method and device, computer equipment, a computer readable storage medium and a computer program product. The method comprises the following steps: obtaining each target flow table information of each execution body, and storing each target flow table information in a storage file corresponding to each execution body; determining a comparison of a target group number based on each storage file corresponding to each execution body, wherein the comparison comprises a first storage file and a second storage file, the execution body corresponding to the first storage file is different from the execution body corresponding to the second storage file, and the target group number is determined based on the number of execution bodies; and obtaining an abnormal execution body by performing an overall judgment comparison based on the first storage file and the second storage file in each comparison. The method can improve the efficiency of judgment.

Description

Technical Field

[0001] This application relates to the field of network communication technology, and in particular to an adjudication method, apparatus, computer equipment, computer-readable storage medium, and computer program product. Background Technology

[0002] The ONOS (Open Network Operating System) controller is the first open-source SDN network operating system implemented and released by The OpenNetworking Lab using Java and Apache, primarily targeting service providers and enterprise backbone networks. Cyber ​​Mimic Defense (CMD) provides universally innovative defense theories and methods to address unknown threats such as vulnerabilities, backdoors, viruses, or Trojans at different application layers in cyberspace. The mimic ONOS controller, acting as the "brain" of the network, is responsible for network management and control. By embedding an endogenous security structure based on dynamic heterogeneous redundancy within the ONOS controller and adjudicating the flow tables of multiple ONOS controller executors, it can resist network attacks based on unknown vulnerabilities and backdoors, ensuring the high reliability and security of the network "brain."

[0003] However, the current adjudication method results in low efficiency in the adjudication process when there are many information entries recorded in the flow table. Summary of the Invention

[0004] Therefore, it is necessary to provide an adjudication method, apparatus, computer equipment, computer-readable storage medium, and computer program product that can improve adjudication efficiency in response to the above-mentioned technical problems.

[0005] Firstly, this application provides a method for adjudication, the method comprising:

[0006] Obtain each target flow table information for each executor and store each target flow table information in the storage file corresponding to each executor;

[0007] Based on the storage files corresponding to each of the aforementioned executables, a comparison pair for the target number of groups is determined, wherein the comparison pair includes storage files corresponding to two different executables; the target number of groups is determined based on the number of the executables.

[0008] Based on the storage files corresponding to the two different executors in each comparison pair, an overall decision comparison is performed to obtain the abnormal executor.

[0009] In one embodiment, the step of performing an overall adjudication comparison based on the storage files corresponding to the two different execution entities in each comparison pair to obtain the abnormal execution entity includes:

[0010] The diff command is used to compare the storage files corresponding to the two different execution bodies in each comparison pair as a whole, and the current comparison result file of each comparison pair is obtained.

[0011] Obtain the size of each current comparison result file, and determine the initial exception execution body based on the size of each current comparison result file;

[0012] Obtain the historical comparison result file corresponding to the initial exception execution body; wherein, the historical comparison result file is the previous comparison result file of the current comparison result file;

[0013] If the content of the current comparison result file is consistent with that of the historical comparison result file, the initial abnormal execution body is identified as an abnormal execution body.

[0014] In one embodiment, the method further includes:

[0015] If the content of the current comparison result file is inconsistent with that of the historical comparison result file, then the current comparison result file shall be regarded as the new historical comparison result file;

[0016] Until a new initial exception execution body identical to the initial exception execution body is obtained, and the new current comparison result file used by the new initial exception execution body is obtained through the ruling;

[0017] If the content of the new current comparison result file is consistent with that of the new historical comparison result file, the new initial abnormal execution body is identified as an abnormal execution body.

[0018] In one embodiment, determining the initial exception execution body based on the size of each of the current comparison result files includes:

[0019] Obtain a preset number of candidate comparison result files from the current comparison result files of the target group number, wherein the preset number is equal to the number of execution bodies minus 1, and the preset number is less than the target group number;

[0020] The size of each candidate comparison result file is obtained. If the size of the candidate comparison result file matches the triggering condition and the main body of the candidate comparison result file includes each of the execution entities, then the execution entity whose content is inconsistent with the storage file of the other execution entities is determined as the initial abnormal execution entity. The triggering condition includes excluding combinations other than the combination where the size of each candidate comparison result file is equal to or not equal to the preset value. If the size of the candidate comparison result file is equal to the preset value, it indicates that the content of the storage file corresponding to the two different execution entities in the comparison pair is consistent. If the size of the candidate comparison result file is not equal to the preset value, it indicates that the content of the storage file corresponding to the two different execution entities in the comparison pair is inconsistent.

[0021] In one embodiment, obtaining each target flow table information for each executor includes:

[0022] Obtain the initial flow table information for each of the aforementioned executors;

[0023] For each initial flow table information, unnecessary fields are filtered out to obtain the target flow table information for each execution body.

[0024] In one embodiment, the method for determining the number of target groups includes:

[0025] The number of combinations is used as the target number of groups, wherein the number of combinations is the number of times two of the three entities are selected.

[0026] Secondly, this application also provides an adjudication device, the device comprising:

[0027] The storage module is used to acquire each target flow table information of each executor and store each target flow table information in the storage file corresponding to each executor.

[0028] The comparison pair determination module is used to determine the number of comparison pairs for the target group based on the storage files corresponding to each of the aforementioned executables. The comparison pairs include storage files corresponding to two different executables. The number of target groups is determined based on the number of executables.

[0029] The adjudication module is used to perform an overall adjudication comparison based on the storage files corresponding to the two different executors in each comparison pair to obtain the abnormal executor.

[0030] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the above-described method.

[0031] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described method.

[0032] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the above-described method.

[0033] The aforementioned adjudication method, apparatus, computer equipment, computer-readable storage medium, and computer program product first acquire each target flow table information of each executor and store each target flow table information in a storage file corresponding to each executor, storing the target flow table information as a whole in the storage files corresponding to each executor. Second, based on the storage files corresponding to each executor, a number of target groups are determined for comparison, comparing the storage files corresponding to two different executors in each group. The number of target groups is determined based on the number of executors, thus using the storage files corresponding to two different executors in each comparison group as a whole for subsequent comparison. Finally, based on the storage files corresponding to two different executors in each comparison group, an overall adjudication comparison is performed to obtain abnormal executors, thereby comparing and adjudicating the storage files of different executors in each comparison group pairwise to identify abnormal executors. In other words, only the storage files corresponding to each executor need to be compared, reducing the number of comparisons and thus improving adjudication efficiency. Attached Figure Description

[0034] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0035] Figure 1 This is a diagram illustrating the application environment of the adjudication method in one embodiment;

[0036] Figure 2 This is a flowchart illustrating the adjudication method in one embodiment;

[0037] Figure 3 This is a schematic diagram of the process for obtaining an abnormal execution body through adjudication comparison in one embodiment;

[0038] Figure 4 This is a flowchart illustrating the comparison of two decisions in one embodiment;

[0039] Figure 5 This is a flowchart illustrating the process of determining the abnormal execution body based on the size of the current comparison result file in one embodiment.

[0040] Figure 6 This is a schematic diagram of the process for obtaining each target flow table information of each executor in one embodiment;

[0041] Figure 7 This is a structural block diagram of the adjudication device in one embodiment;

[0042] Figure 8 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0043] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0044] The adjudication method described in this application can be applied to the adjudication device of an execution entity, which can be a terminal device, a server, or other devices. The adjudication method provided in this application can be applied to, for example... Figure 1 The illustration shows an application environment for a mimicry ONOS controller comprised of an executor 102 and an adjudication device. Taking the adjudication device as an example, the executor 102 communicates with the server 104 via a network. The server 104 acquires the target flow table information for each executor and stores this information in a corresponding storage file for each executor. Based on the storage files for each executor, it determines the number of target groups for comparison, where each comparison pair includes storage files corresponding to two different executors. The number of target groups is determined based on the number of executors. Based on the storage files corresponding to the two different executors in each comparison pair, an overall adjudication comparison is performed to identify abnormal executors. The server 104 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services.

[0045] In one exemplary embodiment, such as Figure 2 As shown, a decision-making method is provided, which is applied to... Figure 1 Taking the server in the example, the explanation includes the following steps S202 to S206. Wherein:

[0046] Step S202: Obtain the target flow table information for each executor and store the target flow table information in the storage file corresponding to each executor.

[0047] To facilitate understanding and better present the processing flow, assume the IP addresses of the n executors are 1.1.1.1, 1.1.1.2, 1.1.1.3, ..., 1.1.1.n. The target flow table information for executor 1.1.1.1 is stored in the file new_1.1.1.1.json. The target flow table information for executor 1.1.1.2 is stored in the file new_1.1.1.2.json. And so on, with the target flow table information for executor 1.1.1.n stored in the file new_1.1.1.n.json.

[0048] Step S204: Based on each storage file corresponding to each executor, determine the number of comparison pairs for the target group. The comparison pairs include storage files corresponding to two different executors.

[0049] The number of target groups is determined based on the number of executors. Different numbers of executors correspond to different numbers of target groups. For example, three executors correspond to 3 target groups; four executors correspond to 6 target groups; five executors correspond to 10 target groups; and six executors correspond to 15 target groups.

[0050] Optionally, the server determines the number of comparison pairs for the target group based on the number of executables. Each comparison pair contains the storage files corresponding to different executables. Taking three executables as an example, namely executable 1.1.1.1, executable 1.1.1.2, and executable 1.1.1.3, there are 3 comparison pairs: (storage file of executable 1.1.1.1, storage file of executable 1.1.1.2), (storage file of executable 1.1.1.1, storage file of executable 1.1.1.3), and (storage file of executable 1.1.1.2, storage file of executable 1.1.1.3).

[0051] Similarly, the number of target groups corresponding to other numbers of executors can be compared.

[0052] Step S206: Based on the storage files corresponding to the two different execution entities in each comparison pair, perform an overall adjudication comparison to obtain the abnormal execution entity.

[0053] Optionally, the server compares the storage files corresponding to the two different executables in each comparison pair as a whole, obtaining the current comparison result file for each comparison pair. Based on the size of the current comparison result file, the initial abnormal executable is determined. Then, by comparing it with historical comparison result files, it further determines whether the initial abnormal executable is indeed an abnormal executable. The historical comparison result file is the previous comparison result file of the current comparison result file.

[0054] In the aforementioned adjudication method, firstly, the target flow table information for each executor is obtained and stored in the corresponding storage file for each executor, treating the target flow table information as a whole in each executor's storage file. Secondly, based on the storage files corresponding to each executor, a number of target groups are determined for comparison, and the storage files corresponding to two different executors are compared. The number of target groups is determined based on the number of executors, thus using the storage files corresponding to two different executors in each comparison pair as a whole for adjudication comparison, so that the storage files as a whole can be compared subsequently. Finally, based on the storage files corresponding to two different executors in each comparison pair, an overall adjudication comparison is performed to obtain the abnormal executor, thus comparing and adjudicating the storage files of different executors in each comparison pair pairwise to determine the abnormal executor. That is, only the storage files corresponding to each executor need to be compared, reducing the number of comparisons and improving adjudication efficiency.

[0055] In one exemplary embodiment, such as Figure 3 As shown, based on the storage files corresponding to the two different executors in each comparison pair, an overall decision comparison is performed to obtain the abnormal executor, including steps S302 to S308. Wherein:

[0056] Step S302: The diff command is used to compare the storage files corresponding to the two different execution bodies in each comparison pair as a whole, and the current comparison result file of each comparison pair is obtained.

[0057] Optionally, taking three execution units as an example, the server compares the storage file new_1.1.1.1.json and the storage file new_1.1.1.2.json as a whole, and saves the comparison results, starting from the key fields, to the current comparison result file 1.1.1.1_1.1.1.2.txt. The diff command is then executed to obtain the current comparison result file. The diff command is as follows:

[0058] diff-u new_1.1.1.1.json new_1.1.1.2.json|tail-n+3>1.1.1.1_1.1.1.2.txt

[0059] The comparison results of the flow table information of execution bodies 1.1.1.1 and 1.1.1.2 are obtained. The comparison results include field information with the same values ​​in execution bodies 1.1.1.1 and 1.1.1.2, as well as field information with different values. Field information with different values ​​is marked with tags to clearly present inconsistent field information and values ​​when viewing the comparison results later. Tags include, for example, plus or minus signs, highlighting, underscores, etc., without specific limitations here.

[0060] The server compares the storage files new_1.1.1.1.json and new_1.1.1.3.json, and saves the comparison results, starting from the key fields, to the file 1.1.1.1_1.1.1.3.txt. The `diff` command is then executed to obtain the current comparison result file. The `diff` command is as follows:

[0061] diff-u new_1.1.1.1.json new_1.1.1.3.json|tail-n+3>1.1.1.1_1.1.1.3.txt

[0062] The comparison results of the flow table information of execution bodies 1.1.1.1 and 1.1.1.3 are obtained. The comparison results include field information with the same values ​​in execution bodies 1.1.1.1 and 1.1.1.3, as well as field information with different values. Similarly, the server can also identify field information with different values ​​using tags.

[0063] The server compares the storage files new_1.1.1.2.json and new_1.1.1.3.json, and saves the comparison results, starting from the key fields, to the file 1.1.1.2_1.1.1.3.txt. The `diff` command is then executed to obtain the current comparison result file. The `diff` command is as follows:

[0064] diff-u new_1.1.1.2.json new_1.1.1.3.json|tail-n+3>1.1.1.2_1.1.1.3.txt

[0065] The comparison results of the flow table information of execution bodies 1.1.1.2 and 1.1.1.3 are obtained. Since the flow table information in execution bodies 1.1.1.2 and 1.1.1.3 is exactly the same, the current comparison result file 1.1.1.2_1.1.1.3.txt generated after using diff judgment is an empty file.

[0066] Step S304: Obtain the size of each current comparison result file, and determine the initial exception execution body based on the size of each current comparison result file.

[0067] Optionally, the server obtains the size of each current comparison result file. The `os.path.getsize` command is executed to obtain the size of each current comparison result file. The `os.path.getsize` command is as follows:

[0068] file_size1=os.path.getsize('1.1.1.1_1.1.1.2.txt')

[0069] file_size2=os.path.getsize('1.1.1.1_1.1.1.3.txt')

[0070] file_size3=os.path.getsize('1.1.1.2_1.1.1.3.txt')

[0071] If file_size1 meets the preset value, such as file_size1 = 0, it means that the storage file corresponding to executable 1.1.1.1 is the same as the storage file corresponding to executable 1.1.1.2. If file_size1 ≠ 0, it means that the storage file corresponding to executable 1.1.1.1 is not the same as the storage file corresponding to executable 1.1.1.2.

[0072] If file_size2 meets the preset value, such as file_size2 = 0, it means that the storage file corresponding to executable 1.1.1.1 is the same as the storage file corresponding to executable 1.1.1.3. If file_size2 ≠ 0, it means that the storage file corresponding to executable 1.1.1.1 is not the same as the storage file corresponding to executable 1.1.1.3.

[0073] If file_size3 meets the preset value, such as file_size3 = 0, it means that the storage file corresponding to executable 1.1.1.2 is the same as the storage file corresponding to executable 1.1.1.3. If file_size3 ≠ 0, it means that the storage file corresponding to executable 1.1.1.2 is different from the storage file corresponding to executable 1.1.1.3.

[0074] It should be noted that the default value can be 0 or other numerical identifiers.

[0075] If file_size1 meets the preset value (e.g., equal to 0), it indicates that the storage file corresponding to executable 1.1.1.1 is the same as the storage file corresponding to executable 1.1.1.2. If file_size2 does not meet the preset value (e.g., not equal to 0), it indicates that the storage file corresponding to executable 1.1.1.1 is different from the storage file corresponding to executable 1.1.1.3. Since the storage file corresponding to executable 1.1.1.1 is the same as the storage file corresponding to executable 1.1.1.2, and the storage file corresponding to executable 1.1.1.1 is different from the storage file corresponding to executable 1.1.1.3, it is determined that executable 1.1.1.3 has been attacked. Executable 1.1.1.3 is identified as the initial abnormal executable.

[0076] If file_size1 does not meet the preset value (e.g., it is not equal to 0), it indicates that the storage file corresponding to executable 1.1.1.1 is different from the storage file corresponding to executable 1.1.1.2. If file_size2 meets the preset value (e.g., it is equal to 0), it indicates that the storage file corresponding to executable 1.1.1.1 is the same as the storage file corresponding to executable 1.1.1.3. Since the storage file corresponding to executable 1.1.1.1 is different from the storage file corresponding to executable 1.1.1.2, while the storage file corresponding to executable 1.1.1.1 is the same as the storage file corresponding to executable 1.1.1.3, it is determined that executable 1.1.1.2 has been attacked. Executable 1.1.1.2 is identified as the initial abnormal executable.

[0077] For example, if `file_size2` does not meet the preset value (e.g., it is not equal to 0), it indicates that the storage file corresponding to executable 1.1.1.1 is different from the storage file corresponding to executable 1.1.1.3. If `file_size3` meets the preset value (e.g., it is equal to 0), it indicates that the storage file corresponding to executable 1.1.1.2 is the same as the storage file corresponding to executable 1.1.1.3. Since the storage files corresponding to executable 1.1.1.1 and 1.1.1.3 are different, while the storage files corresponding to executable 1.1.1.2 and 1.1.1.3 are the same, it is determined that executable 1.1.1.1 has been attacked. Executable 1.1.1.1 is identified as the initial abnormal executable.

[0078] Step S306: Obtain the historical comparison result file corresponding to the initial exception execution body.

[0079] Among them, the historical comparison result file is the previous comparison result file of the current comparison result file.

[0080] Optionally, the server retrieves the historical comparison result file old_diff.txt corresponding to the initial exception execution body. If the initial exception execution body is execution body 1.1.1.1, then the server retrieves the historical comparison result file old_diff.txt for execution body 1.1.1.1. If the initial exception execution body is execution body 1.1.1.2, then the server retrieves the historical comparison result file old_diff.txt for execution body 1.1.1.2. If the initial exception execution body is execution body 1.1.1.3, then the server retrieves the historical comparison result file old_diff.txt for execution body 1.1.1.3.

[0081] Step S308: If the content of the current comparison result file is consistent with that of the historical comparison result file, the initial abnormal execution body is identified as an abnormal execution body.

[0082] Optionally, if the content of the current comparison result file is consistent with that of the historical comparison result file, the server determines the initial abnormal execution body obtained from the ruling as the abnormal execution body. If file_size1 meets the preset value, such as being equal to 0, and file_size2 does not meet the preset value, such as not being equal to 0, and the initial abnormal execution body obtained from the ruling is execution body 1.1.1.3, then the historical comparison result file old_diff.txt of execution body 1.1.1.3 is obtained. Since file_size2 does not meet the preset value, the diff command is executed: diff -u 1.1.1.1_1.1.1.3.txt old_diff.txt>adju.txt; The server obtains the size of the adju.txt file: adju_file_size = os.path.getsize('adju.txt'). adju_file_size equals the preset value, taking 0 as an example. If adju_file_size = os.path.getsize('adju.txt'), adju_file_size equals 0, that is, the content of the current comparison result file is consistent with the content of the historical comparison result file; if adju_file_size = os.path.getsize('adju.txt'), adju_file_size is not equal to 0, that is, the content of the current comparison result file is inconsistent with the content of the historical comparison result file. If the current comparison result file of executable 1.1.1.3 is identical to the content of the historical comparison result file old_diff.txt (adju_file_size equals 0), executable 1.1.1.3 is determined to be an abnormal executable; if the current comparison result file of executable 1.1.1.3 is inconsistent with the content of the historical comparison result file old_diff.txt (adju_file_size is not equal to 0), then executable 1.1.1.3 cannot be determined to be an abnormal executable.

[0083] If the initial abnormal executor is another executor, such as executor 1.1.1.1 or executor 1.1.1.2, the same logic can be used to determine whether executor 1.1.1.1 or executor 1.1.1.2 is an abnormal executor.

[0084] In this embodiment, the initial abnormal execution body is determined by the size of the current comparison result file. In order to avoid the problem of inaccurate determination due to timing issues, a second determination comparison is performed between the current comparison result file of the initial abnormal execution body and the historical comparison result file to determine the abnormal execution body, thereby improving the determination efficiency.

[0085] In one exemplary embodiment, the secondary adjudication process is as follows: Figure 4As shown, steps S402 to S406 are included. Wherein:

[0086] Step S402: If the content of the current comparison result file is inconsistent with that of the historical comparison result file, then the current comparison result file shall be used as the new historical comparison result file.

[0087] Optionally, if the contents of the current comparison result file and the historical comparison result file are inconsistent, the contents of the current comparison result file corresponding to the initial abnormal execution body that does not meet the preset value are copied to the file old_diff.txt as the new historical comparison result file.

[0088] Taking the case where file_size1 meets the preset value (e.g., equal to 0), and file_size2 does not meet the preset value (e.g., not equal to 0), and the initial exception execution body is determined to be execution body 1.1.1.3, as an example, if the current comparison result file of execution body 1.1.1.3 is inconsistent with the content of the historical comparison result file old_diff.txt (adju_file_size is not equal to 0), then the content of the current comparison result file (1.1.1.1_1.1.1.3.txt file) corresponding to the initial exception execution body (execution body 1.1.1.3) that does not meet the preset value is copied to the file old_diff.txt as the new historical comparison result file.

[0089] If file_size1 is not equal to 0 and file_size2 is equal to 0, then execution body 1.1.1.2 is determined to be the initial abnormal execution body. If the content of the current comparison result file is inconsistent with the historical comparison result file, that is, adju_file_size is not equal to 0, then the content of the current comparison result file (1.1.1.1_1.1.1.2.txt file) corresponding to the initial abnormal execution body that does not meet the preset value is copied to the file old_diff.txt as the new historical comparison result file.

[0090] If file_size3 equals 0 and file_size2 does not equal 0, then execution body 1.1.1.1 is determined to be the initial abnormal execution body. If the content of the current comparison result file is inconsistent with the historical comparison result file, that is, adju_file_size is not equal to 0, then the content of the current comparison result file (1.1.1.1_1.1.1.3.txt file) corresponding to the initial abnormal execution body that does not meet the preset value is copied to the file old_diff.txt as the new historical comparison result file.

[0091] Step S404, until a new initial exception execution body identical to the initial exception execution body is obtained, and the new current comparison result file used by the new initial exception execution body is obtained.

[0092] Here, the new initial exception executor is the initial exception executor obtained in the next or next time-sequence decision of the same executor. The new current comparison result file is the current comparison result file corresponding to the new initial executor that does not meet the preset value.

[0093] Optionally, the server obtains a new initial exception execution body that is the same as the initial exception execution body. For example, if file_size1 equals 0 and file_size2 is not equal to 0, and the initial exception execution body is execution body 1.1.1.3, then the server waits until a new initial exception execution body 1.1.1.3 appears. The server then obtains the new current comparison result file used by the new initial exception execution body 1.1.1.3, which is the current comparison result file that does not meet the preset value (such as the file 1.1.1.1_1.1.1.3.txt).

[0094] Step S406: If the content of the new current comparison result file is consistent with that of the new historical comparison result file, the new initial abnormal execution body is identified as the abnormal execution body.

[0095] Optionally, if the content of the new current comparison result file is consistent with the content of the new historical comparison result file, the initial abnormal execution body is continued to be used as the execution body. (See section 1.1.1.3). The new current comparison result file is 1.1.1.1_1.1.1.3.txt, and the content of the new historical comparison result file old_diff.txt is 1.1.1.1_1.1.1.3.txt. It is then determined whether the content of the new current comparison result file 1.1.1.1_1.1.1.3.txt is consistent with the content of the new historical comparison result file old_diff.txt. If they are consistent, the new initial abnormal execution body is determined to be the abnormal execution body.

[0096] If they are inconsistent, the new current comparison result file is used as the current comparison result file, and the process of using the current comparison result file as the new historical comparison result file is repeated until a new initial abnormal execution body is obtained that is the same as the initial abnormal execution body, and the new current comparison result file used by the new initial abnormal execution body is obtained through the ruling; if the content of the new current comparison result file is consistent with the new historical comparison result file, the step of determining the new initial abnormal execution body as the abnormal execution body is taken.

[0097] In this embodiment, when the contents of the current comparison result file and the historical comparison result file are inconsistent, that is, when it is impossible to determine the abnormal execution body, the current comparison result file is used as the new historical comparison result file for the next time sequence or the next determination, thereby ensuring the accuracy of the determination result.

[0098] In one exemplary embodiment, such as Figure 5 As shown, based on the size of the current comparison result file, the initial exception execution body is determined, including steps S502 to S504. Wherein:

[0099] Step S502: Obtain a preset number of candidate comparison result files from the current comparison result files of the target group number.

[0100] The preset quantity is equal to the number of execution bodies minus 1, and the preset quantity is less than the number of target groups.

[0101] Optionally, taking three executors as an example, this will generate three sets of current comparison result files, such as 1.1.1.1_1.1.1.2.txt (file1), 1.1.1.1_1.1.1.3.txt (file2), and 1.1.1.2_1.1.1.3.txt (file3). The default number is 2. The server retrieves two candidate comparison result files from the three sets of current comparison result files, with three possibilities: file1 and file2 as candidate comparison result files, file1 and file3 as candidate comparison result files, or file2 and file3 as candidate comparison result files.

[0102] Optionally, taking four executors as an example, this will generate six sets of current comparison result files, such as 1.1.1.1_1.1.1.2.txt (file1), 1.1.1.1_1.1.1.3.txt (file2), 1.1.1.1_1.1.1.4.txt (file3), 1.1.1.2_1.1.1.3.txt (file4), 1.1.1.2_1.1.1.4.txt (file5), and 1.1.1.3_1.1.14.txt (file6). The default number is three. The server retrieves three candidate comparison result files from the six sets of current comparison result files, resulting in 20 possibilities. For example, file1, file2, and file3 can be used as candidate comparison result files; or file1, file2, and file4 can be used as candidate comparison result files; or file1, file2, and file5 can be used as candidate comparison result files; or file1, file2, and file6 can be used as candidate comparison result files; or file1, file3, and file4 can be used as candidate comparison result files; or file1, file3, and file5 can be used as candidate comparison result files; or file1, file3, and file6 can be used as candidate comparison result files; or file1, file5, and file6 can be used as candidate comparison result files. Alternatively, file2, file3, and file4 can be used as candidate comparison result files, or file2, file3, and file5 can be used as candidate comparison result files, or file2, file3, and file6 can be used as candidate comparison result files, or file2, file4, and file5 can be used as candidate comparison result files, or file2, file4, and file6 can be used as candidate comparison result files, or file2, file5, and file6 can be used as candidate comparison result files, or file3, file4, and file5 can be used as candidate comparison result files, or file3, file4, and file6 can be used as candidate comparison result files, or file3, file5, and file6 can be used as candidate comparison result files, or file4, file5, and file6 can be used as candidate comparison result files.

[0103] Step S504: Obtain the size of each candidate comparison result file. If the size of the candidate comparison result file matches the triggering condition and the main body of the candidate comparison result file includes each execution body, then the execution body whose content is inconsistent with the storage file of other execution bodies is determined as the initial abnormal execution body.

[0104] The triggering conditions include excluding combinations where the size of each candidate comparison result file is equal to or does not equal to a preset value. For example, taking three executables, two are selected as candidate comparison result files, and the size of each candidate comparison result file is obtained, such as (file_size1=0, file_size2=0)(file_size1=0, file_size2≠0)(file_size1≠0, file_size2=0)(file_size1≠0, file_size2≠0)(file_size1=0, file_size3=0)(file_size1=0, file_size3≠0)(file_size1≠0, file_size3=0)(file_size1≠0, file_size3≠0)(file_size1≠0, file_size3≠0)(file_size2=0, file_size3=0)(file_size2=0, file_size3≠0)(file_size2≠0, file_size3≠0). The trigger condition is set to exclude combinations where the size of both comparison result files is equal to 0 or neither is equal to 0. That is, (file_size1=0, file_size2≠0), (file_size1≠0, file_size2=0), (file_size1=0, file_size3≠0), (file_size1≠0, file_size3=0), (file_size2=0, file_size3≠0), and (file_size2≠0, file_size3=0) are all trigger conditions that meet the requirements.

[0105] If the size of the candidate comparison result file is equal to a preset value, it indicates that the contents of the storage files corresponding to the two different executables in the comparison pair are consistent. For example, taking three executables as an example, with a preset value of 0, file_size1 = 0, it indicates that the storage file corresponding to executable 1.1.1.1 is the same as the storage file corresponding to executable 1.1.1.2. file_size2 = 0, it indicates that the storage file corresponding to executable 1.1.1.1 is the same as the storage file corresponding to executable 1.1.1.3. file_size3 = 0, it indicates that the storage file corresponding to executable 1.1.1.2 is the same as the storage file corresponding to executable 1.1.1.3.

[0106] If the size of the candidate comparison result file is not equal to the preset value, it indicates that the contents of the storage files corresponding to the two different executables in the comparison pair are inconsistent. For example, if file_size1 ≠ 0, it means that the storage file corresponding to executable 1.1.1.1 is different from the storage file corresponding to executable 1.1.1.2. If file_size2 ≠ 0, it means that the storage file corresponding to executable 1.1.1.1 is different from the storage file corresponding to executable 1.1.1.3. If file_size3 ≠ 0, it means that the storage file corresponding to executable 1.1.1.2 is different from the storage file corresponding to executable 1.1.1.3.

[0107] Optionally, taking three executors as an example, there are three sets of current result comparison files, namely file_size1 =

[0108] os.path.getsize('1.1.1.1_1.1.1.2.txt')

[0109] file_size2=os.path.getsize('1.1.1.1_1.1.1.3.txt')

[0110] file_size3=os.path.getsize('1.1.1.2_1.1.1.3.txt')

[0111] Select two candidate comparison result files and obtain the size of each candidate comparison result file, such as (file_size1=0, file_size2=0)(file_size1=0, file_size2≠0)(file_size1≠0, file_size2=0)(file_size1≠0, file_size2≠0)(file_size1=0, file_size3=0)(file_size1=0, file_size3≠0)(file_size1≠0, file_size3=0)(file_size1≠0, file_size3≠0)(file_size2=0, file_size3=0)(file_size2=0, file_size3≠0)(file_size2≠0, file_size3≠0). The trigger condition is set to exclude combinations where both comparison result files are equal to 0 or neither is equal to 0. That is, (file_size1=0, file_size2≠0), (file_size1≠0, file_size2=0), (file_size1=0, file_size3≠0), (file_size1≠0, file_size3=0), (file_size2=0, file_size3≠0), (file_size2≠0, file_size3=0) are all trigger conditions that meet the requirements. Furthermore, the main body of the comparison result file includes each executable unit. file_size1 is the storage file corresponding to executable unit 1.1.1.1 and executable unit 1.1.1.2, and file_size2 is the storage file corresponding to executable unit 1.1.1.1 and executable unit 1.1.1.3. Therefore, file_size1 and file_size2 include executable units 1.1.1.1, 1.1.1.2, and 1.1.1.3.

[0112] For example, the sizes of the candidate comparison result files (file_size1 = 0, file_size2 ≠ 0) satisfy the condition that one candidate comparison result file meets the preset value and the other does not. Furthermore, the candidate comparison result files include executables 1.1.1.1, 1.1.1.2, and 1.1.1.3. Since file_size1 equals 0, it indicates that the storage file corresponding to executables 1.1.1.1 and 1.1.1.2 is the same. Since file_size2 is not equal to 0, it indicates that the storage file corresponding to executables 1.1.1.1 and 1.1.1.3 is different. Because the storage file corresponding to executables 1.1.1.1 and 1.1.1.2 is the same, and the storage file corresponding to executables 1.1.1.1 and 1.1.1.3 is different, it is determined that executable 1.1.1.3 has been attacked. Executable 1.1.1.3 is identified as an abnormal executable.

[0113] If the sizes of the candidate comparison result files (file_size1 ≠ 0, file_size2 = 0) satisfy the condition that one candidate comparison result file meets the preset value and the other does not, and the candidate comparison result files include executables 1.1.1.1, 1.1.1.2, and 1.1.1.3, then the following conditions must be met: `file_size1` is not equal to 0, indicating that the storage file corresponding to executable 1.1.1.1 is different from the storage file corresponding to executable 1.1.1.2; `file_size2` is equal to 0, indicating that the storage file corresponding to executable 1.1.1.1 is the same as the storage file corresponding to executable 1.1.1.3. Since the storage file corresponding to executable 1.1.1.1 is different from the storage file corresponding to executable 1.1.1.2, and the storage file corresponding to executable 1.1.1.1 is the same as the storage file corresponding to executable 1.1.1.3, it is determined that executable 1.1.1.2 has been attacked. Executable 1.1.1.2 is identified as an abnormal executable.

[0114] If the sizes of the candidate comparison result files (file_size2≠0, file_size3=0) satisfy the condition that one candidate comparison result file meets the preset value and the other does not, and the candidate comparison result files include executables 1.1.1.1, 1.1.1.2, and 1.1.1.3, then the following conditions must be met: `file_size2` is not equal to 0, indicating that the storage files corresponding to executables 1.1.1.1 and 1.1.1.3 are different; `file_size3` is equal to 0, indicating that the storage files corresponding to executables 1.1.1.2 and 1.1.1.3 are the same. Since the storage files corresponding to executables 1.1.1.1 and 1.1.1.3 are different, while the storage files corresponding to executables 1.1.1.2 and 1.1.1.3 are the same, it is determined that executable 1.1.1.1 is attacked. Executable 1.1.1.1 is identified as an abnormal executable.

[0115] Optionally, taking four executables as an example, three are selected as candidate comparison result files, and the size of each candidate comparison result file is obtained. The trigger condition is set to exclude combinations where the size of all three comparison result files is equal to 0 or not equal to 0, such as (file_size1=0, file_size2=0, file_size3=0) or (file_size1≠0, file_size2≠0, file_size3≠0), both of which are excluded combinations. When there are four executables, there are 6 sets of current result comparison files, which are:

[0116] file_size1=os.path.getsize('1.1.1.1_1.1.1.2.txt')

[0117] file_size2=os.path.getsize('1.1.1.1_1.1.1.3.txt')

[0118] file_size3=os.path.getsize('1.1.1.1_1.1.1.4.txt')

[0119] file_size4=os.path.getsize('1.1.1.2_1.1.1.3.txt')

[0120] file_size5=os.path.getsize('1.1.1.2_1.1.1.4.txt')

[0121] file_size6=os.path.getsize('1.1.1.3_1.1.1.4.txt')

[0122] Three candidate comparison result files are selected, and the size of each candidate comparison result file is obtained, such as (file_size1=0, file_size2=0, file_size3=0), (file_size1=0, file_size2=0, file_size4=0), etc., or (file_size3≠0, file_size5≠0, file_size6≠0), (file_size4≠0, file_size5≠0, file_size6≠0), etc. The trigger condition is set to exclude combinations where the size of two comparison result files is both equal to 0 or neither is equal to 0; the aforementioned combinations are the excluded trigger conditions. Furthermore, the main body of the comparison result file includes each executable. For example, (file_size1 = 0, file_size2 = 0, file_size4 ≠ 0) is a combination that was not excluded. However, file_size1 is the storage file corresponding to executable 1.1.1.1 and executable 1.1.1.2, file_size2 is the storage file corresponding to executable 1.1.1.1 and executable 1.1.1.3, and file_size4 is the storage file corresponding to executable 1.1.1.2 and executable 1.1.1.3. (file_size1 = 0, file_size2 = 0, file_size4 ≠ 0) includes executable 1.1.1.1, executable 1.1.1.2, and executable 1.1.1.3, but does not include executable 1.1.1.4. Therefore, it does not meet the triggering condition.

[0123] Assume the sizes of the candidate comparison result files (file_size1≠0, file_size2=0, file_size3=0) satisfy the triggering conditions, meaning the candidate comparison result files are either all different sizes (0 or both are 0). Furthermore, the candidate comparison result files include executables 1.1.1.1, 1.1.1.2, 1.1.1.3, and 1.1.1.3. `file_size1≠0` indicates that the storage file corresponding to executable 1.1.1.1 is different from the storage file corresponding to executable 1.1.1.2. `file_size2=0` indicates that the storage file corresponding to executable 1.1.1.1 is the same as the storage file corresponding to executable 1.1.1.3. `file_size3=0` indicates that the storage file corresponding to executable 1.1.1.1 is the same as the storage file corresponding to executable 1.1.1.4. Since the storage file corresponding to Executor 1.1.1.1 is different from the storage file corresponding to Executor 1.1.1.2, the storage file corresponding to Executor 1.1.1.1 is the same as the storage file corresponding to Executor 1.1.1.3, and the storage file corresponding to Executor 1.1.1.1 is the same as the storage file corresponding to Executor 1.1.1.4, it is determined that Executor 1.1.1.2 has been attacked. Executor 1.1.1.2 is identified as an abnormal Executor.

[0124] If the size of other candidate comparison result files matches the triggering condition and the main body of the candidate comparison result files includes each execution body, then similarly, execution bodies whose contents are inconsistent with the storage files of other execution bodies can be identified as abnormal execution bodies.

[0125] It should be noted that there is no specific limit to the number of executors. The adjudication process follows the same principle.

[0126] In this embodiment, by obtaining only the current comparison result file of the storage files of each pair of executors and the size of the current comparison result file, the abnormal executor can be adjudicated based solely on the size of the current comparison result file, while ensuring the accuracy of the adjudication result. This avoids adjudicating the flow table information one by one, thereby improving the adjudication efficiency.

[0127] In one exemplary embodiment, such as Figure 6 As shown, the process of obtaining each target flow table information for each executor includes steps S602 to S604. Wherein:

[0128] Step S602: Obtain the initial flow table information for each executor.

[0129] Optionally, the server obtains the initial flow table information of several executors through control commands and stores the initial flow table information into the initial storage file of the corresponding executor. For example, there are 3 executors. For ease of understanding and to better present the processing flow, assume that the IP addresses of the 3 executors are 1.1.1.1, 1.1.1.2, and 1.1.1.3, and the username and password are root and 123456, respectively.

[0130] Furthermore, the server uses the curl command to obtain the flow table information of the three executables. The server retrieves the initial flow table information of executable 1.1.1.1 and saves it to the initial storage file 1.1.1.1.json. The following curl command is executed to obtain the initial flow table information of executable 1.1.1.1:

[0131] curl --user root:123456-X GET --header'Accept:application / json"http: / / 1.1.1.1:8181 / onos / v1 / flows'>1.1.1.1.json

[0132] The initial flow table information of executor 1.1.1.1 is as follows:

[0133] {"flows":[{"groupId":0,"state":"ADDED","life":139,"liveType":"UNKNOWN","lastSeen":1711507778403,"p ackets":0,"bytes":0,"id":"281475436203394","appId":"org.onosproject.core","priority":30000,"timeou t":0,"isPermanent":true,"deviceId":"device:bmv2:s2","tableId":0,"tableName":"0","treatment":{"instruc tions":[{"type":"OUTPUT","port":"CONTROLLER"}],"deferred":[]},"selector":{"criteria":[{"type":"ETH_TYP E","ethType":"0x79cc"}]}}]}

[0134] The server retrieves the initial flow table information of executable 1.1.1.2 and saves it to the initial storage file 1.1.1.2.json. The following curl command is executed to retrieve the initial flow table information of executable 1.1.1.2:

[0135] curl --user root:123456-X GET --header'Accept:application / json"http: / / 1.1.1.2:8181 / onos / v1 / flows'>1.1.1.2.json

[0136] The initial flow table information of Executor 1.1.1.2 is as follows:

[0137] {"flows":[{"groupId":0,"state":"ADDED","life":139,"liveType":"UNKNOWN","lastSeen":1711507778403,"p ackets":0,"bytes":0,"id":"281475436203394","appId":"org.onosproject.core","priority":40000,"timeou t":0,"isPermanent":true,"deviceId":"device:bmv2:s2","tableId":0,"tableName":"0","treatment":{"instruc tions":[{"type":"OUTPUT","port":"CONTROLLER"}],"deferred":[]},"selector":{"criteria":[{"type":"ETH_TYP E","ethType":"0x79cc"}]}}]}

[0138] The server retrieves the initial flow table information of executable 1.1.1.3 and saves it to the initial storage file 1.1.1.3.json. The following curl command is executed to retrieve the initial flow table information of executable 1.1.1.3:

[0139] curl --user root:123456-X GET --header'Accept:application / json"http: / / 1.1.1.3:8181 / onos / v1 / flows'>1.1.1.3.json

[0140] The initial flow table information of Executor 1.1.1.3 is as follows:

[0141] {"flows":[{"groupId":0,"state":"ADDED","life":139,"liveType":"UNKNOWN","lastSeen":1711507778403,"p ackets":0,"bytes":0,"id":"281475436203394","appId":"org.onosproject.core","priority":40000,"timeou t":0,"isPermanent":true,"deviceId":"device:bmv2:s2","tableId":0,"tableName":"0","treatment":{"instruc tions":[{"type":"OUTPUT","port":"CONTROLLER"}],"deferred":[]},"selector":{"criteria":[{"type":"ETH_TYP E","ethType":"0x79cc"}]}}]}

[0142] Step S604: For each initial flow table information, filter and delete unnecessary field information in the initial flow table information to obtain the target flow table information for each execution body.

[0143] Among them, non-essential field information refers to fields that are not compared with those involved in the adjudication.

[0144] Alternatively, in traffic billing scenarios, the focus is entirely different. Operators need to accurately measure the network resources used by users as the basis for charging. Therefore, the number of packets and bytes becomes the core data for billing, directly reflecting the actual traffic consumption of users. At the same time, the source of the traffic (used to distinguish different users or services) and the processing action (such as whether it is included in the billing) are also indispensable information. In this case, fields such as life (lifetime), liveType (activity type), lastSeen (last appearance time), and timeout (timeout setting) are considered unnecessary fields because they do not directly contribute to calculating costs and may increase the complexity and cost of data processing.

[0145] Optionally, in network security monitoring scenarios, the real-time nature and accuracy of data are crucial. The core of a monitoring system lies in quickly identifying and responding to potential security threats. Therefore, information such as the source IP address, destination IP address, protocol type, and the system's processing actions constitute the foundation and key information for analysis; this information is core to network security analysis. In contrast, fields such as life (lifetimeframe), liveType (activity type), lastSeen (last appearance time), packets (number of packets), bytes (number of bytes), and timeout (timeout setting), while potentially helpful for in-depth analysis in certain contexts, are generally considered unnecessary in the initial stages of network security monitoring and rapid response.

[0146] Furthermore, in a network security scenario using mimicry defense, the server uses the `cat` command to filter and delete unnecessary fields from the flow table of execution body 1.1.1.1, obtaining the target flow table information for execution body 1.1.1.1. Alternatively, the target flow table information can be saved to the storage file `new_1.1.1.1.json`, and the following `cat` command can be executed to filter and delete unnecessary fields from the flow table of execution body 1.1.1.1:

[0147] cat 1.1.1.1.json|jq'.flows[]|=del(.lastSeen,.life,.liveType,.packets,.bytes)'>new_1.1.1.1.json

[0148] The target flow table information for Executor 1.1.1.1 is as follows:

[0149] {"flows": [{"groupId":0,"state":"ADDED","id": "281475436203394","appId":"org.onosproject.core","priority": 30000,"timeout": 0,"isPermanent":true,"deviceId":"device:bmv2:s2","tableId":0,"tableName":"0","treatment":{"instructions":[{"type" :"OUTPUT","port":"CONTROLLER"}],"deferred":[]},"selector":{"criteria":[{"type":"ETH_TYPE","ethType":"0x79cc"}]}}]}

[0150] The server uses the `cat` command to filter and delete unnecessary fields from the flow table of execution body 1.1.1.2, obtaining the target flow table information for execution body 1.1.1.1. This target flow table information is then saved to the storage file `new_1.1.1.2.json`. The following `cat` command is executed to filter and delete unnecessary fields from the flow table of execution body 1.1.1.2:

[0151] cat 1.1.1.2.json|jq'.flows[]|=del(.lastSeen,.life,.liveType,.packets,.bytes)'>new_1.1.1.2.json

[0152] The target flow table information for Executor 1.1.1.2 is as follows:

[0153] {"flows":[{"groupId":0,"state":"ADDED","id":"281475436203394","appId":"org.onosproject.core","priority":40000,"timeout":0,"isPermanent":true,"deviceId":"device:bmv2:s2","tableI d":0,"tableName":"0","treatment":{"instructions":[{"type":"OUTPUT","port":"CONTROLLER"}],"deferred":[]},"selector":{"criteria":[{"type":"ETH_TYPE","ethType":"0x79cc"}]}}]}

[0154] The server uses the `cat` command to filter and delete unnecessary fields from the flow table of execution body 1.1.1.3, obtaining the target flow table information for execution body 1.1.1.3. This target flow table information is then saved to the storage file `new_1.1.1.3.json`. The following `cat` command is executed to filter and delete unnecessary fields from the flow table of execution body 1.1.1.3:

[0155] cat 1.1.1.3.json|jq'.flows[]|=del(.lastSeen,.life,.liveType,.packets,.bytes)'>new_1.1.1.3.json

[0156] The target flow table information for Executor 1.1.1.3 is as follows:

[0157] {"flows":[{"groupId":0,"state":"ADDED","id":"281475436203394","appId":"org.onosproject.core","priority":40000,"timeout":0,"isPermanent":true,"deviceId":"device:bmv2:s2","tab leId":0,"tableName":"0","treatment":{"instructions":[{"type":"OUTPUT","port":"CONTROLLER"}],"deferred":[]},"selector":{"criteria":[{"type":"ETH_TYPE","ethType":"0x79cc"}]}}]}

[0158] In this embodiment, by filtering out unnecessary fields in the initial flow table information to obtain the target flow table information, the number of fields to be compared in the target flow table information can be reduced, thereby improving the efficiency of comparison and decision-making.

[0159] In one exemplary embodiment, such as Figure 7 As shown, the method for determining the target number of groups includes: using the number of combinations as the target number of groups, where the number of combinations is the number of two executors selected from at least three executors.

[0160] The combination number is the number of combinations where two files are randomly selected from at least three executables. Since the comparison is between the storage files corresponding to the executables pairwise, it is necessary to select two storage files corresponding to at least three executables for combination. For example, with three executables, the combination number is C3. 2 =3; if there are four execution bodies, the combination number is C4. 2 =6. If there are five execution entities, the combination number is C5. 2 =10; and so on, we can get the number of combinations of n executors.

[0161] Taking three executors as an example, the number of combinations corresponding to three executors is C3. 2 =3, which are (the storage file corresponding to Executor 1.1.1.1, the storage file corresponding to Executor 1.1.1.2, (the storage file corresponding to Executor 1.1.1.1, the storage file corresponding to Executor 1.1.1.3, and (the storage file corresponding to Executor 1.1.1.2, the storage file corresponding to Executor 1.1.1.3).

[0162] The four execution bodies correspond to C4. 2=6 sets of comparison pairs. These are (the storage file corresponding to execution body 1.1.1.3, the storage file corresponding to execution body 1.1.1.2), (the storage file corresponding to execution body 1.1.1.3, the storage file corresponding to execution body 1.1.1.3), (the storage file corresponding to execution body 1.1.1.3, the storage file corresponding to execution body 1.1.1.4), (the storage file corresponding to execution body 1.1.1.2, the storage file corresponding to execution body 1.1.1.3), (the storage file corresponding to execution body 1.1.1.2, the storage file corresponding to execution body 1.1.1.4), and (the storage file corresponding to execution body 1.1.1.3, the storage file corresponding to execution body 1.1.1.4). Similarly, n execution bodies correspond to C. n 2 Group comparison.

[0163] It should be noted that this application only requires at least three executors, and the specific number is not limited.

[0164] In this embodiment, the number of target groups can be accurately determined based on the number of executors, so as to improve the efficiency of subsequent adjudication.

[0165] In an exemplary embodiment, assume there are three executors. For ease of understanding and to better illustrate the processing flow, assume the IP addresses of the three executors are 1.1.1.1, 1.1.1.2, and 1.1.1.3, and the username and password are root and 123456, respectively. The server retrieves the flow table information of the three executors using the curl command. The server retrieves the initial flow table information of executor 1.1.1.1 and saves it to the initial storage file 1.1.1.1.json. The following curl command is executed to retrieve the initial flow table information of executor 1.1.1.1:

[0166] curl --user root:123456-X GET --header'Accept:application / json" http: / / 1.1.1.1:8181 / onos / v1 / flows'>1.1.1.1.json.

[0167] The initial flow table information of executor 1.1.1.1 is as follows:

[0168] {"flows":[{"groupId":0,"state":"ADDED","life":139,"liveType":"UNKNOWN","lastSeen":1711507778403,"p ackets":0,"bytes":0,"id":"281475436203394","appId":"org.onosproject.core","priority":30000,"timeou t":0,"isPermanent":true,"deviceId":"device:bmv2:s2","tableId":0,"tableName":"0","treatment":{"instruc tions":[{"type":"OUTPUT","port":"CONTROLLER"}],"deferred":[]},"selector":{"criteria":[{"type":"ETH_TYP E","ethType":"0x79cc"}]}}]}

[0169] The server retrieves the initial flow table information of executable 1.1.1.2 and saves it to the initial storage file 1.1.1.2.json. The following curl command is executed to retrieve the initial flow table information of executable 1.1.1.2:

[0170] curl --user root:123456-X GET --header'Accept:application / json"http: / / 1.1.1.2:8181 / onos / v1 / flows'>1.1.1.2.json

[0171] The initial flow table information of Executor 1.1.1.2 is as follows:

[0172] {"flows":[{"groupId":0,"state":"ADDED","life":139,"liveType":"UNKNOWN","lastSeen":1711507778403,"p ackets":0,"bytes":0,"id":"281475436203394","appId":"org.onosproject.core","priority":40000,"timeou t":0,"isPermanent":true,"deviceId":"device:bmv2:s2","tableId":0,"tableName":"0","treatment":{"instruc tions":[{"type":"OUTPUT","port":"CONTROLLER"}],"deferred":[]},"selector":{"criteria":[{"type":"ETH_TYP E","ethType":"0x79cc"}]}}]}

[0173] Similarly, the server obtains the initial flow table information of the executable 1.1.1.3 and saves it to the initial storage file 1.1.1.3.json. The following curl command is executed to obtain the initial flow table information of the executable 1.1.1.3. The curl command and the content of the initial flow table information will not be described in detail.

[0174] Non-essential fields include lastSeen, life, liveType, packets, bytes, etc. The server uses the cat command to filter and delete fields in the flow table of execution body 1.1.1.1 that do not need to participate in the decision-making process, thus obtaining the target flow table information for execution body 1.1.1.1.

[0175] You can also save the target flow table information to the storage file new_1.1.1.1.json. Then, execute the following cat command to filter out fields in the flow table of execution body 1.1.1.1 that do not need to participate in the decision-making process:

[0176] cat 1.1.1.1.json|jq'.flows[]|=del(.lastSeen,.life,.liveType,.packets,.bytes)'>new_1.1.1.1.json

[0177] The target flow table information for Executor 1.1.1.1 is as follows:

[0178] {"flows": [{"groupId":0,"state":"ADDED","id": "281475436203394","appId":"org.onosproject.core","priority": 30000,"timeout": 0,"isPermanent":true,"deviceId":"device:bmv2:s2","tableId":0,"tableName":"0","treatment":{"instructions":[{"type" :"OUTPUT","port":"CONTROLLER"}],"deferred":[]},"selector":{"criteria":[{"type":"ETH_TYPE","ethType":"0x79cc"}]}}]}

[0179] The server uses the `cat` command to filter and delete unnecessary fields from the flow table of execution body 1.1.1.2, obtaining the target flow table information for execution body 1.1.1.1. This target flow table information is then saved to the storage file `new_1.1.1.2.json`. The following `cat` command is executed to filter and delete unnecessary fields from the flow table of execution body 1.1.1.2:

[0180] cat 1.1.1.2.json|jq'.flows[]|=del(.lastSeen,.life,.liveType,.packets,.bytes)'>new_1.1.1.2.json

[0181] The target flow table information for Executor 1.1.1.2 is as follows:

[0182] {"flows":[{"groupId":0,"state":"ADDED","id":"281475436203394","appId":"org.onosproject.core","priority":40000,"timeout":0,"isPermanent":true,"deviceId":"device:bmv2:s2","tableI d":0,"tableName":"0","treatment":{"instructions":[{"type":"OUTPUT","port":"CONTROLLER"}],"deferred":[]},"selector":{"criteria":[{"type":"ETH_TYPE","ethType":"0x79cc"}]}}]}

[0183] Similarly, the server uses the `cat` command to filter and delete unnecessary fields from the flow table of execution body 1.1.1.3, obtaining the target flow table information for execution body 1.1.1.3. This target flow table information is then saved to the storage file `new_1.1.1.3.json`. The `cat` command is then executed again to filter and delete unnecessary fields from the flow table of execution body 1.1.1.3, obtaining the target flow table information for execution body 1.1.1.3. The details of the `cat` command are omitted here. The target flow table information is as follows:

[0184] {"flows":[{"groupId":0,"state":"ADDED","id":"281475436203394","appId":"org.onosproject.core","priority":40000,"timeout":0,"isPermanent":true,"deviceId":"device:bmv2:s2","tab leId":0,"tableName":"0","treatment":{"instructions":[{"type":"OUTPUT","port":"CONTROLLER"}],"deferred":[]},"selector":{"criteria":[{"type":"ETH_TYPE","ethType":"0x79cc"}]}}]}

[0185] The server determines the number of target groups based on the number of executors. For example, three executors correspond to three groups, including comparison pairs of storage files corresponding to two different executors. The number of target groups is determined by using the combination number as the target group number, where the combination number is the number of times two executors are selected from at least three executors. The combination number is the number of times two executors are randomly selected from at least three executors for combination. Since the comparison is between pairs of storage files corresponding to executors, it is necessary to randomly select two storage files corresponding to at least three executors for combination. Taking three executors as an example, the combination number for three executors is C3. 2 =3, namely (new_1.1.1.1.json, new_1.1.1.2.json)(new_1.1.1.1.json, new_1.1.1.3.json)(new_1.1.1.2.json, new_1.1.1.3.json). The server compares the stored files new_1.1.1.1.json and new_1.1.1.2.json, and saves the comparison results, starting from the key fields, to the current comparison result file 1.1.1.1_1.1.1.2.txt. The diff command is executed to obtain the current comparison result file. The diff command is as follows:

[0186] diff-unew_1.1.1.1.jsonnew_1.1.1.2.json|tail-n+3>1.1.1.1_1.1.1.2.txt

[0187] The comparison results of the flow table information of execution bodies 1.1.1.1 and 1.1.1.2 are obtained. The comparison results include field information with the same values ​​in execution bodies 1.1.1.1 and 1.1.1.2, as well as field information with different values. The field information with different values ​​is marked with tags so that the inconsistent field information and values ​​can be clearly presented when viewing the comparison results later.

[0188] The server compares the storage files new_1.1.1.1.json and new_1.1.1.3.json, and saves the comparison results, starting from the key fields, to the file 1.1.1.1_1.1.1.3.txt. The `diff` command is then executed to obtain the current comparison result file. The `diff` command is as follows:

[0189] diff-unew_1.1.1.1.jsonnew_1.1.1.3.json|tail-n+3>1.1.1.1_1.1.1.3.txt

[0190] The comparison results of the flow table information of execution bodies 1.1.1.1 and 1.1.1.3 are obtained. The comparison results include the field information with the same value in execution bodies 1.1.1.1 and 1.1.1.3, as well as the field information with different field values.

[0191] The server compares the storage files new_1.1.1.2.json and new_1.1.1.3.json, and saves the comparison results, starting from the key fields, to the file 1.1.1.2_1.1.1.3.txt. The `diff` command is then executed to obtain the current comparison result file. The `diff` command is as follows:

[0192] diff-unew_1.1.1.2.jsonnew_1.1.1.3.json|tail-n+3>1.1.1.2_1.1.1.3.txt

[0193] The comparison results of the flow table information of execution bodies 1.1.1.2 and 1.1.1.3 are obtained. Since the flow table information in execution bodies 1.1.1.2 and 1.1.1.3 is exactly the same, the current comparison result file 1.1.1.2_1.1.1.3.txt generated after using the diff command is an empty file.

[0194] The server retrieves the size of each current comparison result file. The `os.path.getsize` command is used to obtain the size of each current comparison result file. The `os.path.getsize` command is as follows:

[0195] file_size1=os.path.getsize('1.1.1.1_1.1.1.2.txt')

[0196] file_size2=os.path.getsize('1.1.1.1_1.1.1.3.txt')

[0197] file_size3=os.path.getsize('1.1.1.2_1.1.1.3.txt')

[0198] If file_size1 meets the preset value, such as file_size1 = 0, it means that the storage file corresponding to executable 1.1.1.1 is the same as the storage file corresponding to executable 1.1.1.2. If file_size1 ≠ 0, it means that the storage file corresponding to executable 1.1.1.1 is not the same as the storage file corresponding to executable 1.1.1.2.

[0199] If file_size2 meets the preset value, such as file_size2 = 0, it means that the storage file corresponding to executable 1.1.1.1 is the same as the storage file corresponding to executable 1.1.1.3. If file_size2 ≠ 0, it means that the storage file corresponding to executable 1.1.1.1 is not the same as the storage file corresponding to executable 1.1.1.3.

[0200] If file_size3 meets the preset value, such as file_size3 = 0, it means that the storage file corresponding to executable 1.1.1.2 is the same as the storage file corresponding to executable 1.1.1.3. If file_size3 ≠ 0, it means that the storage file corresponding to executable 1.1.1.2 is different from the storage file corresponding to executable 1.1.1.3.

[0201] It should be noted that the default value can be 0 or other numerical identifiers.

[0202] Taking three executables as an example, two files are selected as candidate comparison result files, and the size of each candidate comparison result file is obtained, such as (file_size1=0, file_size2=0)(file_size1=0, file_size2≠0)(file_size1≠0, file_size2=0)(file_size1≠0, file_size2≠0)(file_size1=0, file_size3=0)(file_size1=0, file_size3≠0)(file_size1≠0, file_size3=0)(file_size1≠0, file_size3≠0)(file_size2=0, file_size3=0)(file_size2=0, file_size3≠0)(file_size2≠0, file_size3≠0). The trigger condition is set to exclude combinations where the size of both comparison result files is equal to 0 or neither is equal to 0. That is, (file_size1=0, file_size2≠0)(file_size1≠0, file_size2=0)(file_size1=0, file_size3≠0)(file_size1≠0, file_size3=0)(file_size2=0, file_size3≠0)(file_size2≠0, file_size3=0) are all triggering conditions that meet the requirements.

[0203] If the size of the candidate comparison result file equals a preset value, it indicates that the contents of the storage files of two different executables are identical. For example, taking three executables as an example, with a preset value of 0, `file_size1 = 0` indicates that the storage files corresponding to executables 1.1.1.1 and 1.1.1.2 are the same. `file_size2 = 0` indicates that the storage files corresponding to executables 1.1.1.1 and 1.1.1.3 are the same. `file_size3 = 0` indicates that the storage files corresponding to executables 1.1.1.2 and 1.1.1.3 are the same.

[0204] If the size of the candidate comparison result file is not equal to the preset value, it indicates that the contents of the storage files of the two different executables are inconsistent. For example, if file_size1 ≠ 0, it means that the storage file corresponding to executable 1.1.1.1 is different from the storage file corresponding to executable 1.1.1.2. If file_size2 ≠ 0, it means that the storage file corresponding to executable 1.1.1.1 is different from the storage file corresponding to executable 1.1.1.3. If file_size3 ≠ 0, it means that the storage file corresponding to executable 1.1.1.2 is different from the storage file corresponding to executable 1.1.1.3.

[0205] Select two candidate comparison result files and obtain the size of each candidate comparison result file, such as (file_size1=0, file_size2=0)(file_size1=0, file_size2≠0)(file_size1≠0, file_size2=0)(file_size1≠0, file_size2≠0)(file_size1=0, file_size3=0)(file_size1=0, file_size3≠0)(file_size1≠0, file_size3=0)(file_size1≠0, file_size3≠0)(file_size2=0, file_size3=0)(file_size2=0, file_size3≠0)(file_size2≠0, file_size3≠0). The trigger condition is set to exclude combinations where both comparison result files are equal to 0 or neither is equal to 0. That is, (file_size1=0, file_size2≠0), (file_size1≠0, file_size2=0), (file_size1=0, file_size3≠0), (file_size1≠0, file_size3=0), (file_size2=0, file_size3≠0), (file_size2≠0, file_size3=0) are all trigger conditions that meet the requirements. Furthermore, the main body of the comparison result file includes each executable unit. file_size1 is the storage file corresponding to executable unit 1.1.1.1 and executable unit 1.1.1.2, and file_size2 is the storage file corresponding to executable unit 1.1.1.1 and executable unit 1.1.1.3. Therefore, file_size1 and file_size2 include executable units 1.1.1.1, 1.1.1.2, and 1.1.1.3.

[0206] For example, the size of the candidate comparison result files (file_size1 = 0, file_size2 ≠ 0) satisfies the condition that one candidate comparison result file meets the preset value and the other does not. The candidate comparison result files include executables 1.1.1.1, 1.1.1.2, and 1.1.1.3. Since file_size1 equals 0, it indicates that the storage file corresponding to executables 1.1.1.1 and 1.1.1.2 is the same. Since file_size2 is not equal to 0, it indicates that the storage file corresponding to executables 1.1.1.1 and 1.1.1.3 is different. Because the storage file corresponding to executables 1.1.1.1 and 1.1.1.2 is the same, and the storage file corresponding to executables 1.1.1.1 and 1.1.1.3 is different, it is determined that executable 1.1.1.3 is attacked. Executable 1.1.1.3 is identified as the initial abnormal executable.

[0207] If the sizes of the candidate comparison result files (file_size1 ≠ 0, file_size2 = 0) satisfy the condition that one candidate comparison result file meets the preset value and the other does not, and the candidate comparison result files include executables 1.1.1.1, 1.1.1.2, and 1.1.1.3, then the following conditions must be met: `file_size1` is not equal to 0, indicating that the storage file corresponding to executable 1.1.1.1 is different from the storage file corresponding to executable 1.1.1.2; `file_size2` is equal to 0, indicating that the storage file corresponding to executable 1.1.1.1 is the same as the storage file corresponding to executable 1.1.1.3. Since the storage file corresponding to executable 1.1.1.1 is different from the storage file corresponding to executable 1.1.1.2, and the storage file corresponding to executable 1.1.1.1 is the same as the storage file corresponding to executable 1.1.1.3, it is determined that executable 1.1.1.2 is attacked. Executable 1.1.1.2 is identified as the initial abnormal executable.

[0208] If the sizes of the candidate comparison result files (file_size2≠0, file_size3=0) satisfy the condition that one candidate comparison result file meets the preset value and the other does not, and the candidate comparison result files include executables 1.1.1.1, 1.1.1.2, and 1.1.1.3, then the following conditions must be met: `file_size2` is not equal to 0, indicating that the storage files corresponding to executables 1.1.1.1 and 1.1.1.3 are different; `file_size3` is equal to 0, indicating that the storage files corresponding to executables 1.1.1.2 and 1.1.1.3 are the same. Since the storage files corresponding to executables 1.1.1.1 and 1.1.1.3 are different, while the storage files corresponding to executables 1.1.1.2 and 1.1.1.3 are the same, it is determined that executable 1.1.1.1 is attacked. Executable 1.1.1.1 is identified as the initial abnormal executable.

[0209] The historical comparison result file is the previous comparison result file for the current comparison result file. The server retrieves the historical comparison result file old_diff.txt corresponding to the initial exception execution body. If the initial exception execution body is execution body 1.1.1.1, then the historical comparison result file old_diff.txt for execution body 1.1.1.1 is retrieved. If the initial exception execution body is execution body 1.1.1.2, then the historical comparison result file old_diff.txt for execution body 1.1.1.2 is retrieved. If the initial exception execution body is execution body 1.1.1.3, then the historical comparison result file old_diff.txt for execution body 1.1.1.3 is retrieved.

[0210] If the current comparison result file and the historical comparison result file have the same content, the server will determine the initial abnormal execution body obtained from the ruling as the abnormal execution body. If file_size1 meets the preset value, such as being equal to 0, and file_size2 does not meet the preset value, such as not being equal to 0, the initial abnormal execution body obtained from the ruling is execution body 1.1.1.3, and then the historical comparison result file old_diff.txt of execution body 1.1.1.3 is obtained. Since file_size2 does not meet the preset value, the command is executed: diff -u 1.1.1.1_1.1.1.3.txt old_diff.txt>adju.txt; The server obtains the size of the adju.txt file: adju_file_size = os.path.getsize('adju.txt'). adju_file_size equals the preset value, taking 0 as an example. If adju_file_size = os.path.getsize('adju.txt'), adju_file_size equals 0, that is, the content of the current comparison result file is consistent with the content of the historical comparison result file; if adju_file_size = os.path.getsize('adju.txt'), adju_file_size is not equal to 0, that is, the content of the current comparison result file is inconsistent with the content of the historical comparison result file. If the current comparison result file of executable 1.1.1.3 is identical to the content of the historical comparison result file old_diff.txt (adju_file_size equals 0), executable 1.1.1.3 is determined to be an abnormal executable; if the current comparison result file of executable 1.1.1.3 is inconsistent with the content of the historical comparison result file old_diff.txt (adju_file_size is not equal to 0), then executable 1.1.1.3 cannot be determined to be an abnormal executable.

[0211] If the initial abnormal executor is another executor, such as executor 1.1.1.1 or executor 1.1.1.2, the same logic can be used to determine whether executor 1.1.1.1 or executor 1.1.1.2 is an abnormal executor.

[0212] If the contents of the current comparison result file are inconsistent with those of the historical comparison result file, the contents of the current comparison result file corresponding to the initial exception execution body that does not meet the preset value are copied to the file old_diff.txt as the new historical comparison result file.

[0213] Taking the case where file_size1 meets the preset value (e.g., equal to 0), and file_size2 does not meet the preset value (e.g., not equal to 0), and the initial exception execution body is determined to be execution body 1.1.1.3, as an example, if the current comparison result file of execution body 1.1.1.3 is inconsistent with the content of the historical comparison result file old_diff.txt (adju_file_size is not equal to 0), then the content of the current comparison result file (1.1.1.1_1.1.1.3.txt file) corresponding to the initial exception execution body (execution body 1.1.1.3) that does not meet the preset value is copied to the file old_diff.txt as the new historical comparison result file.

[0214] If file_size1 is not equal to 0 and file_size2 is equal to 0, then execution body 1.1.1.2 is determined to be the initial abnormal execution body. If the content of the current comparison result file is inconsistent with the historical comparison result file, that is, adju_file_size is not equal to 0, then the content of the current comparison result file (1.1.1.1_1.1.1.2.txt file) corresponding to the initial abnormal execution body that does not meet the preset value is copied to the file old_diff.txt as the new historical comparison result file.

[0215] If file_size3 equals 0 and file_size2 does not equal 0, then execution body 1.1.1.1 is determined to be the initial abnormal execution body. If the content of the current comparison result file is inconsistent with the historical comparison result file, that is, adju_file_size is not equal to 0, then the content of the current comparison result file (1.1.1.1_1.1.1.3.txt file) corresponding to the initial abnormal execution body that does not meet the preset value is copied to the file old_diff.txt as the new historical comparison result file.

[0216] Here, the new initial exception executor is the initial exception executor obtained in the next or next time-sequence decision of the same executor. The new current comparison result file is the current comparison result file corresponding to the new initial executor that does not meet the preset value.

[0217] The server obtains a new initial exception execution body that is the same as the initial exception execution body. For example, if the initial exception execution body is execution body 1.1.1.1, the server waits until a new initial exception execution body 1.1.1.1 appears. The server then obtains the new current comparison result file used by the new initial exception execution body 1.1.1.1, which is the current comparison result file that does not meet the preset value (such as the file 1.1.1.1_1.1.1.3.txt).

[0218] If the content of the new current comparison result file is consistent with the content of the new historical comparison result file, and the initial abnormal execution body is used as the execution body (1.1.1.1), the new current comparison result file is 1.1.1.1_1.1.1.3.txt, and the content of the new historical comparison result file old_diff.txt is 1.1.1.1_1.1.1.3.txt. It is then determined whether the content of the new current comparison result file 1.1.1.1_1.1.1.3.txt is consistent with the content of the new historical comparison result file old_diff.txt. If they are consistent, the new initial abnormal execution body is determined to be the abnormal execution body.

[0219] If they are inconsistent, the new current comparison result file is used as the current comparison result file, and the process of using the current comparison result file as the new historical comparison result file is repeated until a new initial abnormal execution body is obtained that is the same as the initial abnormal execution body, and the new current comparison result file used by the new initial abnormal execution body is obtained through the ruling; if the content of the new current comparison result file is consistent with the new historical comparison result file, the step of determining the new initial abnormal execution body as the abnormal execution body is taken.

[0220] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0221] Based on the same inventive concept, this application also provides an adjudication apparatus for implementing the adjudication method described above. The solution provided by this apparatus is similar to the implementation described in the above method; therefore, specific limitations in one or more adjudication apparatus embodiments provided below can be found in the limitations of the adjudication method described above, and will not be repeated here.

[0222] In one exemplary embodiment, such as Figure 7 As shown, an adjudication device is provided, comprising: an acquisition and storage module 701, a comparison and determination module 702, and an adjudication module 703, wherein:

[0223] The storage module 701 is used to acquire the target flow table information of each executor and store the target flow table information in the storage file corresponding to each executor.

[0224] The comparison pair determination module 702 is used to determine the number of comparison pairs for the target group based on the storage files corresponding to each executor. The comparison pair includes storage files corresponding to two different executors. The number of target groups is determined based on the number of executors.

[0225] The adjudication module 703 is used to perform an overall adjudication comparison based on the storage files corresponding to the two different executors in each comparison pair to obtain the abnormal executor.

[0226] In an exemplary embodiment, the adjudication module 703 is further configured to use a diff command to adjudicate and compare the storage files corresponding to the two different execution bodies in each comparison pair as a whole, to obtain the current comparison result file of each comparison pair; obtain the size of each current comparison result file, and determine the initial abnormal execution body based on the size of each current comparison result file; obtain the historical comparison result file corresponding to the initial abnormal execution body; wherein, the historical comparison result file is the previous comparison result file of the current comparison result file; and determine the initial abnormal execution body as an abnormal execution body if the content of the current comparison result file is consistent with that of the historical comparison result file.

[0227] In an exemplary embodiment, an adjudication device is provided, which further includes a secondary adjudication module, used to take the current comparison result file as a new historical comparison result file when the content of the current comparison result file is inconsistent with that of the historical comparison result file; until a new initial abnormal execution body is obtained that is the same as the initial abnormal execution body, and a new current comparison result file used by the adjudication to obtain the new initial abnormal execution body is obtained; and when the content of the new current comparison result file is consistent with that of the new historical comparison result file, the new initial abnormal execution body is determined as an abnormal execution body.

[0228] In an exemplary embodiment, the adjudication module 703 is further configured to obtain a preset number of candidate comparison result files from the current comparison result files of the target group number, wherein the preset number is equal to the number of execution bodies minus 1, and the preset number is less than the target group number; obtain the size of each candidate comparison result file; if the size of the candidate comparison result file matches the triggering condition and the main body of the candidate comparison result file includes each execution body, then the execution body whose content is inconsistent with the storage file of other execution bodies is determined as the initial abnormal execution body, wherein the triggering condition includes excluding combinations other than the size of each candidate comparison result file being equal to or not equal to the preset value; if the size of the candidate comparison result file is equal to the preset value, it indicates that the content of the storage files corresponding to the two different execution bodies in the comparison pair is consistent; if the size of the candidate comparison result file is not equal to the preset value, it indicates that the content of the storage files corresponding to the two different execution bodies in the comparison pair is inconsistent.

[0229] In an exemplary embodiment, the storage module 701 is further configured to acquire the initial flow table information of each executor; for each initial flow table information, unnecessary field information in the initial flow table information is filtered and deleted to obtain the target flow table information of each executor.

[0230] In one exemplary embodiment, a decision-making apparatus is provided, comprising a target array determination module that uses a combination number as the target group number, wherein the combination number is the number of times two execution entities are selected from at least three execution entities.

[0231] Each module in the aforementioned adjudication device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can invoke and execute the operations corresponding to each module.

[0232] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 8As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores flow table information. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When executed by the processor, the computer program implements a decision-making method.

[0233] Those skilled in the art will understand that Figure 8 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0234] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0235] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0236] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0237] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0238] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0239] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for adjudicating disputes, characterized in that, The method includes: Obtain each target flow table information for each executor and store each target flow table information in the storage file corresponding to each executor; Based on the storage files corresponding to each of the aforementioned executables, a comparison pair for determining the target number of groups is determined, wherein the comparison pair includes storage files corresponding to two different executables; the target number of groups is determined based on the number of the executables. Based on the target flow table information in the storage file corresponding to the two different executors in each comparison pair, which is treated as a whole, an overall adjudication comparison is performed to obtain the abnormal executor.

2. The method according to claim 1, characterized in that, The overall adjudication comparison based on the target flow table information in the storage file corresponding to the two different execution entities in each comparison pair, which is treated as a whole, to obtain the abnormal execution entity includes: The diff command is used to compare the target flow table information in the storage file corresponding to the two different execution bodies in each comparison pair as a whole, so as to obtain the current comparison result file of each comparison pair. Obtain the size of each current comparison result file, and determine the initial exception execution body based on the size of each current comparison result file; Obtain the historical comparison result file corresponding to the initial exception execution body; wherein, the historical comparison result file is the previous comparison result file of the current comparison result file; If the content of the current comparison result file is consistent with that of the historical comparison result file, the initial abnormal execution body is identified as an abnormal execution body.

3. The method according to claim 2, characterized in that, The method further includes: If the content of the current comparison result file is inconsistent with that of the historical comparison result file, then the current comparison result file shall be regarded as the new historical comparison result file; Until a new initial exception execution body identical to the initial exception execution body is obtained, and the new current comparison result file used by the new initial exception execution body is obtained through the ruling; If the content of the new current comparison result file is consistent with that of the new historical comparison result file, the new initial abnormal execution body is identified as an abnormal execution body.

4. The method according to claim 2, characterized in that, The step of determining the initial exception execution body based on the size of each current comparison result file includes: Obtain a preset number of candidate comparison result files from the current comparison result files of the target group number, wherein the preset number is equal to the number of execution bodies minus 1, and the preset number is less than the target group number; The size of each candidate comparison result file is obtained. If the size of the candidate comparison result file matches the triggering condition and the main body of the candidate comparison result file includes each of the execution entities, then the execution entity whose content is inconsistent with the storage file of the other execution entities is determined as the initial abnormal execution entity. The triggering condition includes excluding combinations other than the combination where the size of each candidate comparison result file is equal to or not equal to the preset value. If the size of the candidate comparison result file is equal to the preset value, it indicates that the content of the storage file corresponding to the two different execution entities in the comparison pair is consistent. If the size of the candidate comparison result file is not equal to the preset value, it indicates that the content of the storage file corresponding to the two different execution entities in the comparison pair is inconsistent.

5. The method according to claim 1, characterized in that, The step of obtaining each target flow table information for each executor includes: Obtain the initial flow table information for each of the aforementioned executors; For each initial flow table information, unnecessary fields are filtered out to obtain the target flow table information for each execution body.

6. The method according to claim 1, characterized in that, The methods for determining the number of target groups include: The number of combinations is used as the target number of groups, wherein the number of combinations is the number of times two of the three entities are selected.

7. A decision-making device, characterized in that, The device includes: The storage module is used to acquire each target flow table information of each executor and store each target flow table information in the storage file corresponding to each executor. The comparison pair determination module is used to determine the number of comparison pairs for the target group based on the storage files corresponding to each of the aforementioned executables. The comparison pairs include storage files corresponding to two different executables. The number of target groups is determined based on the number of executables. The adjudication module is used to perform an overall adjudication comparison based on the target flow table information as a whole in the storage file corresponding to the two different executors in each comparison pair, and to obtain the abnormal executor.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images