WO2019153505A1 - Method for publishing fault recovery data packet and server - Google Patents

Abstract

The present application is applicable to the technical field of fault recovery, and provided therein are a method for publishing a fault recovery data packet and a server, wherein the method comprises: receiving device operation logs uploaded by each user terminal; determining fault information contained in each of the user terminals respectively on the basis of each of the device operation logs; classifying the fault information, and determining a fault type for the fault information; establishing a correspondence between the fault type and the user terminals according to a user terminal that corresponds to the fault information contained in the fault type; if a fault recovery data packet used for repairing the fault type is acquired, then sending the fault recovery data packet to the user terminal corresponding to the fault type on the basis of the correspondence. The present application only pushes the fault recovery data packet to a user terminal that has a corresponding fault type, thereby reducing the data volume instantaneously concurred by a server and reducing the hardware and bandwidth requirements for the server.

Description

Method and server for issuing fault repair data packet

The application claims the priority of the Chinese Patent Application No. 201810121899.0, entitled "A Method for Distributing a Fault Repair Data Packet and a Server", which is filed on February 7, 2018, the entire contents of which are incorporated by reference. Combined in this application.

Technical field

The present application belongs to the technical field of fault repair, and in particular, to a method and a server for releasing a fault repair data packet.

Background technique

Fault repair packets, such as patches, are an important means of hot fixes and are widely used for fault recovery in various applications or systems during operation. The existing fault repair data packet is distributed in a global unified push release manner, that is, a software update is uniformly performed to all the user terminals of the application or the system that is required to be repaired by the fault repair data package to modify the software. The vulnerability exists in it.

However, in the above manner, it is required to push the fault repair data packet to all user terminals at the same time, the amount of instantaneous concurrent data is large, and the hardware requirements and bandwidth resources of the server are relatively high. Moreover, if some user terminals do not have a fault condition, and the fault repair data packet needs to be downloaded, the data traffic of the part of the user is wasted, resulting in waste of resources, and a new fault condition may be caused by installing the fault repair data packet. Reduce the user experience and the stability of the software.

technical problem

In view of this, the embodiment of the present application provides a method for releasing a fault repair data packet and a server, to solve the method for distributing the fault repair data packet, and the hardware requirements and bandwidth resources of the server are high, and A user terminal that does not have a fault condition causes waste of resources and reduces stability of the terminal.

Technical solution

A method for issuing a fault repair data package provided by the application includes:

Receiving a device running log uploaded by each user terminal;

And determining, according to the device running logs uploaded by each of the user terminals, fault information included in each of the user terminals, where the fault information includes: a fault module identifier, a terminal software version, and a fault response manner;

And determining, according to the faulty module identifier, the terminal software version, and the fault response manner, the fault information, and determining a fault type of the fault information;

Determining, according to the user terminal corresponding to the fault information that is included in the fault type, a correspondence between the fault type and the user terminal; the fault information corresponding to at least one of the user terminals;

If the fault repair data packet for repairing the fault type is obtained, sending the fault repair data packet to the user terminal corresponding to the fault type based on the correspondence relationship.

Beneficial effect

The embodiment of the present application pushes the fault repair data packet to the user terminal having the corresponding fault type, which reduces the instantaneous data volume of the server and reduces the hardware and bandwidth requirements of the server. On the other hand, the embodiment of the present application is a directed release process, and the user terminal that does not have the corresponding fault type does not push the fault repair data packet, thereby avoiding waste of resources and improving the stability of the user terminal. User experience.

DRAWINGS

1 is a flowchart of an implementation of a method for issuing a fault repair data packet according to a first embodiment of the present application;

2 is a specific implementation flowchart of a method for issuing a fault repair data packet S103 according to the second embodiment of the present application;

3 is a specific implementation flowchart of a method for issuing a fault repair data packet S105 according to the third embodiment of the present application;

4 is a specific implementation flowchart of a method for issuing a fault repair data packet S102 according to the fourth embodiment of the present application;

FIG. 5 is a flowchart of an implementation of a method for issuing a fault repair data packet according to a fourth embodiment of the present application;

FIG. 6 is a structural block diagram of a server according to an embodiment of the present application;

FIG. 7 is a schematic diagram of a server according to another embodiment of the present application.

Embodiments of the invention

In the embodiment of the present application, the execution entity of the process is a server, and the server sends the fault repair data packet generated and received to each corresponding terminal device to achieve the purpose of repairing the fault. FIG. 1 is a flowchart of an implementation of a method for issuing a fault repair data packet according to a first embodiment of the present application, which is described in detail as follows:

In S101, a device running log uploaded by each user terminal is received.

In this embodiment, the server performs communication connection with each user terminal, and the user terminal may send a device operation log to the server by using a preset rule. Specifically, during the running process, the user terminal may send a device running log to the server at a preset time interval. The preset time interval may be performed by the user himself or by the server for all user terminals. After receiving the shutdown command, the user terminal can also create a log uploading process in the background, and send the device running log to the server through the process, and enter the state to be shut down; the intended shutdown state is specifically: the user terminal is shut down and the uploading device running log is All modules and processes that are irrelevant, for example, the user terminal only keeps the communication module and the process of log uploading, and closes all other processes to reduce the power consumption of the user terminal.

In this embodiment, the server may be used to repair a fault condition generated by an application. In this case, if the user terminal is installed with multiple applications, the server corresponding to each application is simultaneously connected, and The device running logs generated when the user operates each application are respectively sent to the corresponding server.

In this embodiment, the server may create a corresponding database for the different user terminals, and store the device running log in the database of the user terminal corresponding to the terminal identifier according to the terminal identifier carried in the received device running log. After the storage is completed, the related operations of S102 are performed.

In S102, the fault information included in each of the user terminals is determined according to a device operation log uploaded by each of the user terminals, and the fault information includes: a fault module identifier, a terminal software version, and a fault response manner.

In this embodiment, after receiving the device running log sent by each user terminal, the server determines, by using a preset fault information identification rule, whether the device running log uploaded by the user terminal has a fault condition, and if yes, based on The device running log generates a fault message. The fault information includes the faulty module identifier, the faulty software version, and the fault response mode. The method for determining the faulty module identifier is specifically: identifying a device module that performs an operation in the device running log, and identifying the identifier of the device module as a faulty module. The method for determining the faulty software version is specifically: obtaining an application that responds to the request operation in the running log of the device, and installing the version number of the application on the user terminal, and using the version number as the terminal software version. The fault response modes include but are not limited to: forced exit, downtime, terminal restart, and response timeout.

In this embodiment, since each device running log records a response module that responds to the current operation, if the server identifies that the device running log is a fault running log, the identifier of the response module in the device running log may be used as The faulty module identifier of the fault information. In addition to the module that records the response, the device running log records the start time and the end time. You can compare the running time with the average running time to determine whether the current operation is a timeout response. You can also obtain the device running log. The ending mode of the running process, thereby determining the fault response mode in the fault information by using the above two aspects. Of course, for the faulty software version information, the environment software identifier of the request operation can be directly extracted from the device running log as the terminal software version of the fault information.

Optionally, in this embodiment, the user terminal may send the device running record corresponding to the current operation to the server when the fault condition is detected, and the server only needs to receive the device running log sent by the terminal device. The abnormality of the user terminal can be identified, and the fault information is directly extracted from the device running log.

Of course, if a plurality of modules in the device running log cooperate to complete a task request, one fault information may include multiple fault module identifiers, and different fault module identifiers may be divided into multiple fault information for recording. Similarly, if a task request requires multiple applications to be collaboratively completed, one fault information may include multiple terminal software identifiers; or one fault information may be independently generated for different terminal software identifiers for recording.

In S103, the fault information is classified according to the faulty module identifier, the terminal software version, and the fault response manner, and the fault type of the fault information is determined.

In this embodiment, the server classifies the fault module identifier, the terminal software version, and the fault response manner included in each fault information. Because the above three feature items are used, the fault information indicated by each fault information can be identified. Whether the fault conditions are the same or similar to determine whether they are caused by the same cause. For example, the server receives the first fault information and the second fault information, where the three characteristic items in the first fault information are respectively (WIFI module, Ver1, connection timeout); the third feature items in the second fault information are respectively ( WIFI module, Ver1, high packet loss rate), it can be seen that the first fault information and the second fault information have the same fault module identifier and terminal software version number, and the fault response mode is similar, which is common for WIFI connection faults. In response, the first fault information and the second fault information can be identified as the same fault type. In the above manner, different fault information uploaded by different user terminals can be classified into multiple fault types.

In this embodiment, the same fault type may contain multiple fault information from different faulty terminals. The type of fault that has been identified and identified can also be recorded in the database of the server. In this case, the server can match the fault information with the existing fault type to determine whether there is a corresponding fault type that has been created. If yes, the matched fault type is used as the fault type of the fault information, and the fault is The user terminal identifier corresponding to the information is added to the correspondence table pre-stored by the fault type. If the fault type corresponding to the fault information does not exist in the database, create a fault type, and match the created fault type with other received fault information to determine whether other fault information received this time belongs to the fault type. Thereby completing the classification operation of the fault information.

In S104, a correspondence between the fault type and the user terminal is established according to the user terminal corresponding to the fault information included in the fault type, and the fault information corresponds to at least one of the user terminals.

In this embodiment, after determining the fault type of each fault information, the server identifies the fault information included in each fault type, and establishes a correspondence between the fault type and the user terminal based on the user terminal corresponding to each fault information. Relationship, for example, the fault correspondence is shown in Table 1. Referring to Table 1, the server can configure a fault number for each fault type, configure a fault description segment for the fault type, and use the communication address of the user terminal as the identifier of the user terminal.

Fault number	Fault description	User terminal identification
1	WIFI connection failure	(198.15.255.14); (185.52.61.243);
2	Touch screen touch misplacement	(14.56.212.250); (201.212.85.2);

Table 1

In this embodiment, after determining the fault type, the server may send the fault type and the fault information included in the fault type to the fault repair administrator, so that the fault repair administrator determines the corresponding fault repair scheme according to the fault type. And generating a fault repair data packet for repairing the fault type; of course, if the fault repair algorithm is stored in the server, a plurality of simulated user terminals can be built by using each fault information in the fault type, by changing the software version of the terminal. Each parameter, and the output feedback of the modified user terminal after modification, determines whether the fault type has been repaired, and if so, generates a fault repair data packet according to each parameter of the terminal software corresponding to the repaired fault type.

In S105, if the fault repair data packet for repairing the fault type is acquired, the fault repair data packet is sent to the user terminal corresponding to the fault type based on the correspondence relationship.

In this embodiment, the server may generate a fault repair data packet locally through an administrator or a fault repair algorithm, and may also receive a fault repair data packet sent from another device, for example, receiving the fault repair data sent by the administrator terminal or the upper server. package. Since the fault repair has a certain hysteresis, that is, the fault information fed back by the user terminal is received, and after the fault type is determined, there is a certain time difference between the fault repair data packets, and therefore, the server does not realize the fault information immediately after receiving the fault information. After the fault repair data packet is released, the fault repair data packet is pushed to the user terminal corresponding to the fault type after receiving the fault repair data packet.

In this embodiment, after obtaining a new fault repair data packet, the server determines the fault type used by the fault repair data packet for repair, and queries the user terminal that has the fault type based on the corresponding relationship generated in S104. Which, in turn, sends the fault repair data packet to the user terminal to achieve the purpose of redirecting the fault to the user terminal.

In particular, if the server sends a fault repair data packet to the user terminal in a certain fault type, the terminal identifier of the user terminal may be deleted from the corresponding relationship or a sent identifier may be added. During the subsequent fault information collection process, when it is detected again that the fault information fed back by a certain user terminal belongs to the fault type of the existing fault repair data packet, the newly detected user terminal may be added to the corresponding relationship of the fault type. in. If the user identifier of the failed repair data packet is deleted from the corresponding relationship, the server pushes the fault repair data packet to the user terminal currently existing in the corresponding relationship table; if the added identifier is added In the manner of distinguishing the user terminals, the server sends the fault repair data packet to the user terminal that has sent the identifier to be empty.

It can be seen that the method for distributing the fault repair data packet provided by the embodiment of the present application collects the device operation log of the user terminal, and identifies the fault information included in the user terminal, and then classifies the fault information, and determines the The type of fault that the user terminal contains. When the fault repair data packet of a fault type is obtained, the fault repair data packet is sent to all user terminals that have the fault type, and the purpose of the fault repair data packet is released. Compared with the existing method for issuing the fault repair data packet, the embodiment of the present application pushes the fault repair data packet to the user terminal having the corresponding fault type, instead of the global unified push, thereby reducing the instantaneous data volume of the server and reducing the amount of data. The hardware and bandwidth requirements for the server. On the other hand, the embodiment of the present application is a directed release process, and the user terminal that does not have the corresponding fault type does not push the fault repair data packet, thereby avoiding waste of resources and improving the stability of the user terminal. User experience.

FIG. 2 is a flowchart showing a specific implementation of a method for issuing a fault repair data packet S103 according to the second embodiment of the present application. Referring to FIG. 2, in the method for issuing the fault repair data packet provided by the embodiment, S103 includes S1031 to S1033, and the details are as follows:

In S1031, calculating, according to the faulty module identifier, the terminal software version, and the fault response manner, a matching degree between each fault information and a pre-stored fault type included in a preset fault repair library; The model of matching is specifically:

The S is a matching degree between the fault information and the fault type; the A ₁ , A ₂ , and A ₃ are respectively a fault module identifier of the fault information, the terminal software version, and the The parameter value of the fault response mode; the B ₁ , B ₂ , and B ₃ are respectively the fault module identifier of the fault type, the terminal software version, and the parameter value of the fault response mode; the e is a natural constant.

In this embodiment, a fault repairing library is stored in the server, and the fault repairing library includes multiple fault types, and the fault type may be a fault type collected and classified in the process of directly collecting the terminal device, or may be The type of fault discovered by the administrator during the test can also be the type of fault sent by the host server or distributed server to synchronize the faulty database. In this case, different servers may divide the user terminals according to different regions or different types of managed terminals, and different servers are used to manage different types of user terminals, and each server may pre-empt The set time interval synchronizes the fault type in the fault repair library, thereby reducing the situation of repeatedly specifying the fault repair data packet, reducing the repair pressure of the administrator, and improving the efficiency of fault repair.

In this embodiment, when receiving the fault information fed back by the user terminal, the server may determine, according to the faulty module identifier, the terminal version number, and the fault response manner included in the fault information, whether the fault information belongs to the recorded fault type. One of them is therefore based on the above three parameters and the failure type calculation in the fault repair library. Calculate the degree of difference between each feature item, that is, calculate |A ₁ -B ₁ |, |A ₂ -B ₂ | and |A ₃ -B ₃ |, and use the sum of the three differences as the fault type and fault The degree of deviation between the information, and the degree of matching is obtained based on the degree of deviation.

Preferably, the server numbers each module based on the association between the modules, and the smaller number difference indicates that the functions between the two modules are relatively similar and the correlation is relatively large. For example, the communication module can be classified into the third category, and the Bluetooth module is the first subclass of the large class, and the WIFI module is the second subclass of the large class, and the number of the Bluetooth module can be 31, WIFI. The module number can be 32, so the difference between the two is 1; while the display module belongs to the 8th category, and the touch screen in the display module belongs to the first subclass, the module number of the touch screen is 81. Therefore, the difference between the touch screen module and the Bluetooth module is 50, so that based on the difference between the faulty module identifiers, it can be determined whether the fault information matches the fault type. As described above, the fault response manner can also be numbered in the above manner, and will not be described one by one.

In particular, since the software version numbers are numbered one by one based on the order in which the version is generated, directly calculating the difference between the version numbers can determine the degree of difference between the two software versions, that is, as a factor for calculating the matching degree. one.

In S1032, if there is a matching degree of the pre-stored fault type and the fault information is greater than a preset matching degree threshold, the pre-stored fault type is used as a fault type of the fault information, and the pre-stored fault is A type of fault repair data packet is sent to the user terminal to which the fault information belongs.

In this embodiment, if the server finds that the matching degree between the pre-stored fault type and the currently obtained fault information is greater than a preset matching threshold, the server identifies the pre-stored fault type as the fault corresponding to the fault information. The type, in particular, if there is a plurality of pre-stored fault types and the matching degree of the fault information is greater than a preset matching degree threshold, the one of the pre-stored fault types with the highest matching degree is selected as the fault type of the fault information.

In this embodiment, each pre-stored fault type corresponds to a fault repair data packet for modifying the pre-stored fault type. Therefore, after determining that the fault information belongs to the pre-stored fault type, the server may directly send the pre-stored fault to the faulty terminal. The fault repair packet corresponding to the fault type, thereby achieving the purpose of fault repair.

In S1033, if the matching degree of any of the pre-stored fault types and the fault information is less than or equal to a preset matching degree threshold, the faulty module identifier, the terminal software version, and the fault response manner carried according to the fault information are used. Create a fault type and use the type of fault created as the fault type for the fault information.

In this embodiment, if the matching degree between each pre-stored fault type and the fault information in the fault repairing library is less than or equal to the matching degree threshold, the fault information is newly generated fault information, and the server is the fault. The repair is performed. Therefore, based on the faulty module representation, the terminal software version, and the fault response mode carried in the fault information, a fault type is created, and the fault type is stored in the fault repair library, and the created fault type is identified as The failure type of the failure information is then performed in S104 and S105.

In the embodiment of the present application, by matching the fault information with the pre-stored fault type, the situation of repeated repair and repeated storage is avoided, the work pressure of the administrator of the fault repair is reduced, and the efficiency of fault repair is improved.

FIG. 3 is a specific implementation flowchart of a method for issuing a fault repair data packet S105 according to the third embodiment of the present application. As shown in FIG. 3, in the method for issuing the fault repair data packet provided by the embodiment, S105 further includes S1051 to S1053, which are specifically described as follows:

In S1051, the data amount of the fault repair data packet is acquired.

In this embodiment, before sending the fault repair data packet, the server first determines the data amount of the fault repair data packet, and compares the data amount with a preset data volume threshold, and the fault repair data packet data. If the amount is less than the preset data amount threshold, the operation of S1052 is performed; otherwise, if the data amount is greater than or equal to the preset data amount threshold, the operation of S1053 is performed.

Optionally, the data volume threshold of the embodiment may be manually set by an administrator, or may be automatically adjusted by the server according to the bandwidth resource of the network. For example, the server sets the estimated duration of sending a fault repair packet to 4 seconds, and the occupied bandwidth resource cannot exceed 50%. The current bandwidth resource is 100 M/s. Therefore, the data volume threshold can be: Vmax = 100 M / s * 50% * 4 = 200M.

In S1052, if the data amount of the fault repair data packet is less than a preset data amount threshold, the main thread is set to the serial operation mode, and the main thread corresponds to each user terminal corresponding to the fault type. Send the fault repair packet.

In this embodiment, if the server determines that the data amount of the fault repair data packet is less than a preset data amount threshold, it indicates that the data amount of the fault repair data packet is small, and the time required for sending a data packet is short. There is no case that the data packet is sent due to the transmission failure repair, and the transmission is not sent after the preset duration is exceeded. On this basis, the transmission efficiency of the fault repair data packet through the main thread is high. Since the main thread can call the hardware resources and the bandwidth resources are more, the efficiency of sending the data packet is also higher, but since the server detects the main thread running, it sets a maximum response duration, if the response duration exceeds the preset In response to the threshold, the main thread is identified as being in an abnormal state, and the operation of the main thread is terminated and the response is resumed. Therefore, if the amount of data of the fault repair packet is large, the server will recognize that the main thread is in an abnormal state of response, and repeatedly terminates and resends, resulting in waste of resources and failure to transmit the faulty data packet. Therefore, when the amount of data of the faulty packet is small, data can be released through the main thread.

In this embodiment, when the server determines to send the fault repair data packet to each user terminal through the main thread, the server may send the fault repair data packet according to the order in which the user terminal uploads the fault information.

In S1053, if the data amount of the fault repair data packet is greater than or equal to the data amount threshold, a plurality of asynchronous parallel child threads are created in the main thread, and respectively, by each of the child threads Each user terminal corresponding to the fault type sends the fault repair data packet; the number of the child threads is the same as the number of user terminals included in the fault type.

In this embodiment, if the server determines that the fault repair data packet is greater than or equal to the data amount threshold, it indicates that the data amount of the fault repair data packet is large, and if the main thread is serially transmitted, the foregoing sending is easily generated. Timeout situation. Therefore, in this case, the fault repair data packet will be transmitted to each user terminal in a parallel manner by the child threads.

In this embodiment, the server queries the number of terminals of the user terminal in the corresponding relationship of the fault type, and creates the number of child threads equal to the number of the terminal under the main thread, and runs the sub-threads. The mode is set to the asynchronous parallel mode, so that each sub-thread is controlled to communicate with each user terminal, and each sub-thread sends a fault repair data packet to each user terminal.

In the embodiment of the present application, the server selects an appropriate transmission mode to perform data transmission according to the data volume of the fault repair data packet, thereby improving the transmission efficiency and the success rate of the transmission.

FIG. 4 is a specific implementation flowchart of a method for issuing a fault repair data packet S102 according to the fourth embodiment of the present application. As shown in FIG. 4, with respect to the embodiment shown in FIG. 1, a method for issuing a fault repair data packet S102 provided by this embodiment includes: S1021 to S1023, which are specifically described as follows:

In S1021, the running time of the running log is determined according to the start time and the ending time of the device running log.

In this embodiment, each device operation log records the start time and the end time of the current service response operation, and the server may determine the running time required by the user terminal to respond to the service based on the difference between the start time and the end time. .

Optionally, the server may query a time threshold corresponding to the service type based on the service type. Since different service types require different response times, they have corresponding duration thresholds. The server may extract the service type included in the running log of the device, and then determine the duration threshold of the fault type, and then compare the running duration obtained by the current collection with the duration threshold. In particular, the server may determine an average running time of the service type based on a device running log of the service type that is repeatedly fed back by the user terminal, and use the average running time as a duration threshold.

In this embodiment, if the server detects that the running time is less than the preset duration threshold, it indicates that the current response is abnormal, and the device running log is identified as a normal running log; otherwise, if the running time is greater than the preset duration threshold Then, the operation of S1022 is performed to further confirm whether the device running log is a fault running log.

In S1022, if the running time length is greater than a preset duration threshold, the resource consumption parameter of the device running log is obtained.

In this embodiment, since the running time is greater than the preset duration threshold, it indicates that the current service response belongs to the timeout response, and therefore the resource status of the user terminal consumed during the current service is obtained. As a result of the failure response, the hardware resources of the user terminal are generally occupied. Therefore, based on the size of the resource consumption parameter, it is determined whether the device running log is a fault running log.

In this embodiment, the resource consumption parameter may be a value occupied by the terminal memory, or may be a percentage of the operation resource of the operation module. The server compares the consumption resource parameter in the device running log with a preset consumption threshold. If the preset consumption threshold is not exceeded, the device running log is identified as a normal running log; otherwise, if the preset consumption threshold is exceeded, the fault running log is identified, and the operation of S1023 is performed.

In S1023, if the resource consumption parameter exceeds a preset consumption threshold, the device running log is identified as a fault running log, and the fault information is generated based on the fault running log.

In this embodiment, when the server determines that the resource consumption parameter of the user terminal required to respond to the current service exceeds a preset consumption threshold, the server indicates that the operation consumes a large amount of resources of the user terminal, and determines the process of responding to the service. There is a fault condition and a fault message is generated.

In the embodiment of the present application, by determining whether the running log of the device is a fault running log for the running time and the resource consumption parameter, the purpose of automatically identifying and extracting fault information is achieved, and the efficiency of fault repair is improved.

FIG. 5 is a specific implementation flowchart of a method for issuing a fault repair data packet according to a fifth embodiment of the present application. As shown in FIG. 5, with respect to the embodiment shown in FIG. 1 to FIG. 4, a method for issuing a fault repair data packet according to the present embodiment is based on the corresponding relationship, and the user terminal corresponding to the fault type is Before sending the fault repair data packet, the method further includes: S501 and S502, which are specifically described as follows:

In S501, a network status of the user terminal is obtained.

In this embodiment, before sending the fault repair data packet to the user terminal, the server may send a network state acquisition request to the user terminal to determine the network state of the current user terminal. The network status is a specific connection method for communicating with the Internet, and is through a wired network, a wireless local area network, or a mobile network. The user terminal generates a network status result and returns it to the server based on the current network state communicated with the server.

In S502, if the network status meets a preset data packet downloading state, performing the operation of releasing the fault repair data packet to the user terminal corresponding to the fault type based on the corresponding relationship.

In this embodiment, if the server determines that the network status of the current user terminal is a preset data packet download status, the server sends a fault repair data packet to the user terminal. In particular, the packet download status is: wireless local area status or wired network status.

Optionally, if the server determines that the current network status does not meet the preset data packet download status, set a retransmission timer, and after the count value of the retransmission timer is greater than the retransmission count value, return to the related operation of S501 until The network status of the user terminal satisfies the preset data packet download status, and then the download operation is performed.

Optionally, after receiving the network state obtaining request, the user terminal may enter a download waiting state when determining that the current state does not satisfy the preset data packet downloading state, and when detecting that the network state of the user terminal meets the data packet downloading state, , actively send a packet acquisition request to the server to start the packet download operation.

In the embodiment of the present application, by acquiring the network status of the user terminal, it is determined whether to perform data packet transmission, and the user terminal is prevented from inadvertently downloading, thereby wasting a large amount of data traffic.

It should be understood that the size of the sequence of the steps in the above embodiments does not mean that the order of execution is performed. The order of execution of each process should be determined by its function and internal logic, and should not be construed as limiting the implementation process of the embodiments of the present application.

FIG. 6 is a structural block diagram of a server according to an embodiment of the present application, where each unit included in the server is used to execute each step in the embodiment corresponding to FIG. 1. For details, please refer to the related description in the embodiment corresponding to FIG. 1 and FIG. For the convenience of explanation, only the parts related to the present embodiment are shown.

Referring to FIG. 6, the server includes:

The device operation log receiving unit 61 is configured to receive a device operation log uploaded by each user terminal;

The fault information obtaining unit 62 is configured to determine, according to the device running logs uploaded by each of the user terminals, fault information included in each of the user terminals, where the fault information includes: a fault module identifier, a terminal software version, and a fault response manner;

The fault type determining unit 63 is configured to classify the fault information based on the faulty module identifier, the terminal software version, and the fault response manner, and determine a fault type of the fault information.

The correspondence determining unit 64 is configured to establish, according to the user terminal corresponding to the fault information that is included in the fault type, a correspondence between the fault type and the user terminal, where the fault information corresponds to at least one user. terminal;

The fault data packet sending unit 65 is configured to: if the fault repair data packet for repairing the fault type is acquired, send the fault repair data packet to the user terminal corresponding to the fault type based on the correspondence relationship.

Optionally, the fault type determining unit 63 includes:

a matching degree calculation unit, configured to calculate, according to the faulty module identifier, the terminal software version, and the fault response manner, a matching degree between each fault information and a pre-stored fault type included in a preset fault repair library; The model for calculating the matching degree is specifically:

The S is a matching degree between the fault information and the fault type; the A ₁ , A ₂ , and A ₃ are respectively a fault module identifier of the fault information, the terminal software version, and the a parameter value of the fault response mode; the B ₁ , B ₂ , and B ₃ are respectively a fault module identifier of the fault type, the terminal software version, and a parameter value of the fault response manner; the e is a natural constant;

a pre-stored fault type determining unit, configured to use the pre-stored fault type as the fault type of the fault information if there is a matching degree of the pre-stored fault type and the fault information is greater than a preset matching degree threshold The fault repair data packet of the pre-stored fault type is sent to the user terminal to which the fault information belongs;

a fault type creation unit, configured to: if the matching degree of any of the pre-stored fault types and the fault information is less than or equal to a preset matching degree threshold, the fault module identifier, the terminal software version, and the version of the terminal software carried according to the fault information In the fault response mode, a fault type is created, and the fault type created is used as the fault type of the fault information.

Optionally, the fault data packet sending unit 65 includes:

a data amount determining unit, configured to acquire a data amount of the fault repair data packet;

a serial sending unit, configured to: if the data volume of the fault repairing data packet is less than a preset data amount threshold, set the main thread to a serial running mode, and respectively correspond to the fault type by the main thread Each user terminal sends the fault repair data packet;

a parallel sending unit, configured to create a plurality of asynchronous parallel child threads in the main thread if the data amount of the fault repair data packet is greater than or equal to the data amount threshold, and respectively use each of the child threads to Each user terminal corresponding to the fault type sends the fault repair data packet; the number of the child threads is the same as the number of user terminals included in the fault type.

Optionally, the fault information obtaining unit 62 includes:

a running time calculation unit, configured to determine a working duration of the running log according to a start time and an ending time of the device running log;

a resource consumption determining unit, configured to acquire a resource consumption parameter of the device running log, if the running time is greater than a preset duration threshold;

The fault running log determining unit is configured to: if the resource consumption parameter exceeds a preset consumption threshold, identify the device running log as a fault running log, and generate the fault information based on the fault running log.

Optionally, the server further includes:

a network status obtaining unit, configured to acquire a network status of the user terminal;

a network status determining unit, configured to: if the network status meets a preset data packet download status, perform the operation of releasing the fault repair data packet to the user terminal corresponding to the fault type based on the corresponding relationship

Therefore, the server provided by the embodiment of the present application can also push the fault repair data packet only to the user terminal having the corresponding fault type, thereby reducing the instantaneous concurrent data volume of the server and reducing the hardware and bandwidth requirements of the server. On the other hand, the embodiment of the present application is a directed release process, and the user terminal that does not have the corresponding fault type does not push the fault repair data packet, thereby avoiding waste of resources and improving the stability of the user terminal. User experience.

FIG. 7 is a schematic diagram of a server according to another embodiment of the present application. As shown in FIG. 7, the server 7 of this embodiment includes a processor 70, a memory 71, and computer readable instructions 72 stored in the memory 71 and executable on the processor 70, such as a fault repair packet. Release program. When the processor 70 executes the computer readable instructions 72, the steps in the embodiment of the method for issuing the respective fault repair data packets are implemented, such as S101 to S105 shown in FIG. 1. Alternatively, the processor 70, when executing the computer readable instructions 72, implements the functions of the various units in the various apparatus embodiments described above, such as the functions of modules 61 through 65 shown in FIG.

Illustratively, the computer readable instructions 72 may be partitioned into one or more units, the one or more units being stored in the memory 71 and executed by the processor 70 to complete the application. . The one or more units may be a series of computer readable instruction instructions segments capable of performing a particular function for describing the execution of the computer readable instructions 72 in the server 7. For example, the computer readable instructions 72 may be divided into a device operation log receiving unit, a failure information acquisition unit, a failure type determination unit, a correspondence relationship determination unit, and a failure data packet transmission unit, each of which has a specific function as described above.

The server 7 can be a computing device such as a desktop computer, a notebook, a palmtop computer, and a cloud server. The server may include, but is not limited to, a processor 70, a memory 71. It will be understood by those skilled in the art that FIG. 7 is only an example of the server 7, and does not constitute a limitation on the server 7, and may include more or less components than those illustrated, or combine some components, or different components, such as The server may also include an input and output device, a network access device, a bus, and the like.

The processor 70 may be a central processing unit (CPU), or may be other general-purpose processors, a digital signal processor (DSP), an application specific integrated circuit (ASIC), Field-Programmable Gate Array (FPGA) or other programmable logic device, discrete gate or transistor logic device, discrete hardware components, etc. The general purpose processor may be a microprocessor or the processor or any conventional processor or the like.

The memory 71 may be an internal storage unit of the server 7, such as a hard disk or a memory of the server 7. The memory 71 may also be an external storage device of the server 7, such as a plug-in hard disk equipped with the server 7, a smart memory card (SMC), and a Secure Digital (SD) card. Flash card, etc. Further, the memory 71 may also include both an internal storage unit of the server 7 and an external storage device. The memory 71 is configured to store the computer readable instructions and other programs and data required by the server. The memory 71 can also be used to temporarily store data that has been output or is about to be output.

The above-mentioned embodiments are only used to explain the technical solutions of the present application, and are not limited thereto; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still implement the foregoing embodiments. The technical solutions described in the examples are modified or equivalently replaced with some of the technical features; and the modifications or substitutions do not deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and should be included in Within the scope of protection of this application.

Claims (20)

1. A method for issuing a fault repair data packet, comprising:

   Receiving a device running log uploaded by each user terminal;

   And determining, according to the device running logs uploaded by each of the user terminals, fault information included in each of the user terminals, where the fault information includes: a fault module identifier, a terminal software version, and a fault response manner;

   And determining, according to the faulty module identifier, the terminal software version, and the fault response manner, the fault information, and determining a fault type of the fault information;

   Determining, according to the user terminal corresponding to the fault information that is included in the fault type, a correspondence between the fault type and the user terminal; the fault information corresponding to at least one of the user terminals;

   If the fault repair data packet for repairing the fault type is obtained, sending the fault repair data packet to the user terminal corresponding to the fault type based on the correspondence relationship.
2. The method according to claim 1, wherein the fault information is classified based on the faulty module identifier, the terminal software version, and the fault response mode, and the fault information is determined to be faulty. Types, including:

   Calculating, according to the faulty module identifier, the terminal software version, and the fault response manner, a matching degree between each fault information and a pre-stored fault type included in a preset fault repair database; and calculating a model of the matching degree Specifically:

   

   The S is a matching degree between the fault information and the fault type; the A ₁ , A ₂ , and A ₃ are respectively a fault module identifier of the fault information, the terminal software version, and the a parameter value of the fault response mode; the B ₁ , B ₂ , and B ₃ are respectively a fault module identifier of the fault type, the terminal software version, and a parameter value of the fault response manner; the e is a natural constant;

   If the matching degree of the pre-stored fault type and the fault information is greater than a preset matching degree threshold, the pre-stored fault type is used as the fault type of the fault information, and the fault of the pre-stored fault type is repaired. The data packet is sent to the user terminal to which the fault information belongs;

   If the matching degree of the pre-stored fault type and the fault information is less than or equal to the preset matching degree threshold, create a fault according to the faulty module identifier, the terminal software version, and the fault response mode carried in the fault information. Type and the type of failure created as the type of failure for the fault information.
3. The method according to claim 1, wherein if the fault repair data packet for repairing the fault type is acquired, the user terminal corresponding to the fault type is issued based on the correspondence relationship. The fault repair data package includes:

   Obtaining the data amount of the fault repair data packet;

   If the data volume of the fault repair data packet is less than a preset data volume threshold, set the main thread to a serial operation mode, and send the fault to each user terminal corresponding to the fault type one by one by the main thread. Repair the data packet;

   If the data volume of the fault repair data packet is greater than or equal to the data volume threshold, create a plurality of asynchronous parallel child threads in the main thread, and respectively correspond to the fault type by each of the child threads. Each user terminal sends the fault repair data packet; the number of the child threads is the same as the number of user terminals included in the fault type.
4. The method according to claim 1, wherein the determining, according to the device running logs uploaded by the respective user terminals, the fault information included in each of the user terminals, includes:

   Determining an operation duration of the operation log according to a start time and an end time of the device operation log;

   Obtaining a resource consumption parameter of the device running log, if the running time is greater than a preset duration threshold;

   If the resource consumption parameter exceeds a preset consumption threshold, the device running log is identified as a fault running log, and the fault information is generated based on the fault running log.
5. The method according to any one of claims 1 to 4, wherein before the sending the fault repair data packet to the user terminal corresponding to the fault type, the method further includes:

   Obtaining a network status of the user terminal;

   If the network status meets the preset data packet downloading status, performing the operation of releasing the fault repair data packet to the user terminal corresponding to the fault type based on the corresponding relationship.
6. A server, comprising:

   The device running log receiving unit is configured to receive a device running log uploaded by each user terminal;

   The fault information obtaining unit is configured to determine, according to the device running logs uploaded by each of the user terminals, fault information included in each of the user terminals, where the fault information includes: a fault module identifier, a terminal software version, and a fault response manner;

   a fault type determining unit, configured to classify the fault information based on the faulty module identifier, the terminal software version, and the fault response manner, and determine a fault type of the fault information;

   a correspondence determining unit, configured to establish a correspondence between the fault type and the user terminal according to the user terminal corresponding to the fault information included in the fault type; the fault information corresponds to at least one user terminal ;

   And a failure data packet sending unit, configured to send the fault repair data packet to the user terminal corresponding to the fault type, based on the correspondence relationship, if the fault repair data packet for repairing the fault type is obtained.
7. The server according to claim 6, wherein the failure type determining unit comprises:

   a matching degree calculation unit, configured to calculate, according to the faulty module identifier, the terminal software version, and the fault response manner, a matching degree between each fault information and a pre-stored fault type included in a preset fault repair library; The model for calculating the matching degree is specifically:

   

   The S is a matching degree between the fault information and the fault type; the A ₁ , A ₂ , and A ₃ are respectively a fault module identifier of the fault information, the terminal software version, and the a parameter value of the fault response mode; the B ₁ , B ₂ , and B ₃ are respectively a fault module identifier of the fault type, the terminal software version, and a parameter value of the fault response manner; the e is a natural constant;

   a pre-stored fault type determining unit, configured to use the pre-stored fault type as the fault type of the fault information if there is a matching degree of the pre-stored fault type and the fault information is greater than a preset matching degree threshold The fault repair data packet of the pre-stored fault type is sent to the user terminal to which the fault information belongs;

   a fault type creation unit, configured to: if the matching degree of any of the pre-stored fault types and the fault information is less than or equal to a preset matching degree threshold, the fault module identifier, the terminal software version, and the version of the terminal software carried according to the fault information In the fault response mode, a fault type is created, and the fault type created is used as the fault type of the fault information.
8. The server according to claim 6, wherein the faulty data packet transmitting unit comprises:

   a data amount determining unit, configured to acquire a data amount of the fault repair data packet;

   a serial sending unit, configured to: if the data volume of the fault repairing data packet is less than a preset data amount threshold, set the main thread to a serial running mode, and respectively correspond to the fault type by the main thread Each user terminal sends the fault repair data packet;

   a parallel sending unit, configured to create a plurality of asynchronous parallel child threads in the main thread if the data amount of the fault repair data packet is greater than or equal to the data amount threshold, and respectively use each of the child threads to Each user terminal corresponding to the fault type sends the fault repair data packet; the number of the child threads is the same as the number of user terminals included in the fault type.
9. The server according to claim 6, wherein the fault information acquiring unit comprises:

   a running time calculation unit, configured to determine a working duration of the running log according to a start time and an ending time of the device running log;

   a resource consumption determining unit, configured to acquire a resource consumption parameter of the device running log, if the running time is greater than a preset duration threshold;

   The fault running log determining unit is configured to: if the resource consumption parameter exceeds a preset consumption threshold, identify the device running log as a fault running log, and generate the fault information based on the fault running log.
10. The server according to any one of claims 6 to 9, wherein the server further comprises:

    a network status obtaining unit, configured to acquire a network status of the user terminal;

    The network state determining unit is configured to: if the network state meets a preset data packet downloading state, perform the operation of releasing the fault repair data packet to the user terminal corresponding to the fault type based on the correspondence relationship.
11. A server, comprising: a memory, a processor, and computer readable instructions stored in the memory and executable on the processor, the processor executing the computer readable instructions Implement the following steps:

    Receiving a device running log uploaded by each user terminal;

    And determining, according to the device running logs uploaded by each of the user terminals, fault information included in each of the user terminals, where the fault information includes: a fault module identifier, a terminal software version, and a fault response manner;

    And determining, according to the faulty module identifier, the terminal software version, and the fault response manner, the fault information, and determining a fault type of the fault information;

    Determining, according to the user terminal corresponding to the fault information that is included in the fault type, a correspondence between the fault type and the user terminal; the fault information corresponding to at least one of the user terminals;

    If the fault repair data packet for repairing the fault type is obtained, sending the fault repair data packet to the user terminal corresponding to the fault type based on the correspondence relationship.
12. The server according to claim 11, wherein the fault information is classified based on the faulty module identifier, the terminal software version, and the fault response mode, and the fault type of the fault information is determined. ,include:

    Calculating, according to the faulty module identifier, the terminal software version, and the fault response manner, a matching degree between each fault information and a pre-stored fault type included in a preset fault repair database; and calculating a model of the matching degree Specifically:

    

    The S is a matching degree between the fault information and the fault type; the A ₁ , A ₂ , and A ₃ are respectively a fault module identifier of the fault information, the terminal software version, and the a parameter value of the fault response mode; the B ₁ , B ₂ , and B ₃ are respectively a fault module identifier of the fault type, the terminal software version, and a parameter value of the fault response manner; the e is a natural constant;

    If the matching degree of the pre-stored fault type and the fault information is greater than a preset matching degree threshold, the pre-stored fault type is used as the fault type of the fault information, and the fault of the pre-stored fault type is repaired. The data packet is sent to the user terminal to which the fault information belongs; if the matching degree of any of the pre-stored fault types and the fault information is less than or equal to a preset matching degree threshold, the fault module carried according to the fault information The identification, the terminal software version, and the fault response mode create a fault type and use the created fault type as the fault type of the fault information.
13. The server according to claim 11, wherein if the fault repair data packet for repairing the fault type is acquired, the user terminal is issued according to the correspondence relationship to the user terminal corresponding to the fault type. Fault repair packets, including:

    Obtaining the data amount of the fault repair data packet;

    If the data volume of the fault repair data packet is less than a preset data volume threshold, set the main thread to a serial operation mode, and send the fault to each user terminal corresponding to the fault type one by one by the main thread. Repair the data packet;

    If the data volume of the fault repair data packet is greater than or equal to the data volume threshold, create a plurality of asynchronous parallel child threads in the main thread, and respectively correspond to the fault type by each of the child threads. Each user terminal sends the fault repair data packet; the number of the child threads is the same as the number of user terminals included in the fault type.
14. The server according to claim 11, wherein the determining the fault information included in each of the user terminals based on the device running logs uploaded by the respective user terminals includes:

    Determining an operation duration of the operation log according to a start time and an end time of the device operation log;

    Obtaining a resource consumption parameter of the device running log, if the running time is greater than a preset duration threshold;

    If the resource consumption parameter exceeds a preset consumption threshold, the device running log is identified as a fault running log, and the fault information is generated based on the fault running log.
15. The server according to any one of claims 11 to 14, wherein the processor further implements the following steps when the computer readable instructions are executed:

    Obtaining a network status of the user terminal;

    If the network status meets the preset data packet downloading status, performing the operation of releasing the fault repair data packet to the user terminal corresponding to the fault type based on the corresponding relationship.
16. A computer readable storage medium storing computer readable instructions, wherein the computer readable instructions, when executed by a processor, implement the following steps:

    Receiving a device running log uploaded by each user terminal;

    And determining, according to the device running logs uploaded by each of the user terminals, fault information included in each of the user terminals, where the fault information includes: a fault module identifier, a terminal software version, and a fault response manner;

    And determining, according to the faulty module identifier, the terminal software version, and the fault response manner, the fault information, and determining a fault type of the fault information;

    Determining, according to the user terminal corresponding to the fault information that is included in the fault type, a correspondence between the fault type and the user terminal; the fault information corresponding to at least one of the user terminals;

    If the fault repair data packet for repairing the fault type is obtained, sending the fault repair data packet to the user terminal corresponding to the fault type based on the correspondence relationship.
17. The computer readable storage medium according to claim 16, wherein the fault information is classified based on the faulty module identifier, the terminal software version, and the fault response manner, and the fault is determined. The type of information failure, including:

    Calculating, according to the faulty module identifier, the terminal software version, and the fault response manner, a matching degree between each fault information and a pre-stored fault type included in a preset fault repair database; and calculating a model of the matching degree Specifically:

    

    The S is a matching degree between the fault information and the fault type; the A ₁ , A ₂ , and A ₃ are respectively a fault module identifier of the fault information, the terminal software version, and the a parameter value of the fault response mode; the B ₁ , B ₂ , and B ₃ are respectively a fault module identifier of the fault type, the terminal software version, and a parameter value of the fault response manner; the e is a natural constant;

    If the matching degree of the pre-stored fault type and the fault information is greater than a preset matching degree threshold, the pre-stored fault type is used as the fault type of the fault information, and the fault of the pre-stored fault type is repaired. The data packet is sent to the user terminal to which the fault information belongs; if the matching degree of any of the pre-stored fault types and the fault information is less than or equal to a preset matching degree threshold, the fault module carried according to the fault information The identification, the terminal software version, and the fault response mode create a fault type and use the created fault type as the fault type of the fault information.
18. The computer readable storage medium according to claim 16, wherein if the fault repair data packet for repairing the fault type is acquired, the user corresponding to the fault type is based on the correspondence relationship The terminal issues the fault repair data packet, including:

    Obtaining the data amount of the fault repair data packet;

    If the data volume of the fault repair data packet is less than a preset data volume threshold, set the main thread to a serial operation mode, and send the fault to each user terminal corresponding to the fault type one by one by the main thread. Repair the data packet;

    If the data volume of the fault repair data packet is greater than or equal to the data volume threshold, create a plurality of asynchronous parallel child threads in the main thread, and respectively correspond to the fault type by each of the child threads. Each user terminal sends the fault repair data packet; the number of the child threads is the same as the number of user terminals included in the fault type.
19. The computer-readable storage medium according to claim 16, wherein the determining, according to the device operation log uploaded by each of the user terminals, the fault information included in each of the user terminals, respectively, includes:

    Determining an operation duration of the operation log according to a start time and an end time of the device operation log;

    Obtaining a resource consumption parameter of the device running log, if the running time is greater than a preset duration threshold;

    If the resource consumption parameter exceeds a preset consumption threshold, the device running log is identified as a fault running log, and the fault information is generated based on the fault running log.
20. The computer readable storage medium according to any one of claims 16 to 19, wherein the processor further implements the following steps when the computer readable instructions are executed:

    Obtaining a network status of the user terminal;

    If the network status meets the preset data packet downloading status, performing the operation of releasing the fault repair data packet to the user terminal corresponding to the fault type based on the corresponding relationship.

Images