CN108322345B - Method for issuing fault repair data packet and server - Google Patents
Method for issuing fault repair data packet and server Download PDFInfo
- Publication number
- CN108322345B CN108322345B CN201810121899.0A CN201810121899A CN108322345B CN 108322345 B CN108322345 B CN 108322345B CN 201810121899 A CN201810121899 A CN 201810121899A CN 108322345 B CN108322345 B CN 108322345B
- Authority
- CN
- China
- Prior art keywords
- fault
- user terminal
- data packet
- type
- information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0631—Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/069—Management of faults, events, alarms or notifications using logs of notifications; Post-processing of notifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/55—Push-based network services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
- H04L67/62—Establishing a time schedule for servicing the requests
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/16—Threshold monitoring
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
The invention is suitable for the technical field of fault repair, and provides a method for issuing a fault repair data packet and a server, wherein the method comprises the following steps: receiving equipment running logs uploaded by each user terminal; respectively determining fault information contained in each user terminal based on each equipment operation log; classifying the fault information and determining the fault type of the fault information; establishing a corresponding relation between the fault type and the user terminal according to the user terminal corresponding to the fault information contained in the fault type; and if the fault repairing data packet for repairing the fault type is acquired, the fault repairing data packet is sent to the user terminal corresponding to the fault type based on the corresponding relation. The invention only pushes the fault repairing data packet to the user terminal with the corresponding fault type, thereby reducing the instantaneous concurrent data volume of the server and reducing the requirements on the hardware and the bandwidth of the server.
Description
Technical Field
The invention belongs to the technical field of fault repair, and particularly relates to a method for issuing a fault repair data packet and a server.
Background
Failover packets, such as patches, are widely used for the failover of various applications or systems that occur during operation as an important means of thermal recovery. The existing issuing mode of the fault repairing data packet adopts a global unified pushing issuing mode, namely, software updating is uniformly performed on all user terminals of an application program or a system which needs to be repaired and is provided with the fault repairing data packet so as to modify bugs existing in the software.
However, in the above manner, the failure recovery data packets are required to be simultaneously pushed to all the user terminals, the instantaneous concurrent data volume is large, and the requirements on the hardware and bandwidth resources of the server are high. Moreover, if a part of the user terminals do not have a fault condition, the fault repairing data packet needs to be downloaded, so that data traffic of the part of the users is wasted, resource waste is caused, a new fault condition may be caused due to the installation of the fault repairing data packet, and the use experience of the users and the stability of the software are reduced.
Disclosure of Invention
In view of this, embodiments of the present invention provide a method for issuing a failure recovery packet and a server, so as to solve the problems that the existing method for issuing a failure recovery packet has high requirements on hardware and bandwidth resources of the server, and causes resource waste and reduces terminal stability for a user terminal that does not have a failure.
A first aspect of an embodiment of the present invention provides a method for issuing a failure recovery data packet, including:
receiving equipment running logs uploaded by each user terminal;
respectively determining fault information contained in each user terminal based on the equipment running logs uploaded by each user terminal; the fault information includes: a fault module identifier, a terminal software version and a fault response mode;
classifying the fault information based on the fault module identification, the terminal software version and the fault response mode, and determining the fault type of the fault information;
establishing a corresponding relation between the fault type and the user terminal according to the user terminal corresponding to the fault information contained in the fault type; the fault information corresponds to at least one user terminal;
and if a fault repairing data packet for repairing the fault type is acquired, the fault repairing data packet is sent to the user terminal corresponding to the fault type based on the corresponding relation.
A second aspect of an embodiment of the present invention provides a server, including a memory, a processor, and a computer program stored in the memory and executable on the processor, where the processor implements the following steps when executing the computer program:
receiving equipment running logs uploaded by each user terminal;
respectively determining fault information contained in each user terminal based on the equipment running logs uploaded by each user terminal; the fault information includes: a fault module identifier, a terminal software version and a fault response mode;
classifying the fault information based on the fault module identification, the terminal software version and the fault response mode, and determining the fault type of the fault information;
establishing a corresponding relation between the fault type and the user terminal according to the user terminal corresponding to the fault information contained in the fault type; the fault information corresponds to at least one user terminal;
and if a fault repairing data packet for repairing the fault type is acquired, the fault repairing data packet is sent to the user terminal corresponding to the fault type based on the corresponding relation.
A third aspect of embodiments of the present invention provides a computer-readable storage medium storing a computer program which, when executed by a processor, implements the steps of:
receiving equipment running logs uploaded by each user terminal;
respectively determining fault information contained in each user terminal based on the equipment running logs uploaded by each user terminal; the fault information includes: a fault module identifier, a terminal software version and a fault response mode;
classifying the fault information based on the fault module identification, the terminal software version and the fault response mode, and determining the fault type of the fault information;
establishing a corresponding relation between the fault type and the user terminal according to the user terminal corresponding to the fault information contained in the fault type; the fault information corresponds to at least one user terminal;
and if a fault repairing data packet for repairing the fault type is acquired, the fault repairing data packet is sent to the user terminal corresponding to the fault type based on the corresponding relation.
The method and the server for issuing the fault repairing data packet provided by the embodiment of the invention have the following beneficial effects that:
the embodiment of the invention collects the equipment running log of the user terminal, identifies the fault information contained in the user terminal, then classifies the fault information and determines the fault type contained in the user terminal. And when the fault repairing data packet of a certain fault type is obtained, the fault repairing data packet is sent to all the user terminals with the fault type, so that the aim of directionally releasing the fault repairing data packet is fulfilled. Compared with the existing method for issuing the fault repairing data packet, the embodiment of the invention only pushes the fault repairing data packet to the user terminal with the corresponding fault type because the fault repairing data packet is not pushed in a global unified way, thereby reducing the instantaneous concurrent data volume of the server and reducing the requirements on the hardware and the bandwidth of the server. On the other hand, the embodiment of the invention is a directional issuing process, and the user terminal without the corresponding fault type does not push the fault repairing data packet, thereby avoiding resource waste and improving the stability of the user terminal and the use experience of the user.
Drawings
In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings needed to be used in the embodiments or the prior art descriptions will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without inventive exercise.
Fig. 1 is a flowchart of an implementation of a method for issuing a failover data packet according to a first embodiment of the present invention;
fig. 2 is a flowchart illustrating a specific implementation of a method S103 for issuing a failover data packet according to a second embodiment of the present invention;
fig. 3 is a flowchart illustrating a specific implementation of a method S105 for issuing a failover data packet according to a third embodiment of the present invention;
fig. 4 is a flowchart illustrating a specific implementation of a method S102 for issuing a failover data packet according to a fourth embodiment of the present invention;
fig. 5 is a flowchart of a specific implementation of a method for issuing a failover data packet according to a fourth embodiment of the present invention;
fig. 6 is a block diagram of a server according to an embodiment of the present invention;
fig. 7 is a schematic diagram of a server according to another embodiment of the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention more apparent, the present invention is described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.
The embodiment of the invention collects the equipment running log of the user terminal, identifies the fault information contained in the user terminal, then classifies the fault information and determines the fault type contained in the user terminal. When a fault repairing data packet of a certain fault type is obtained, the fault repairing data packet is sent to all the user terminals with the fault type, and the problems that the existing fault repairing data packet issuing method has high requirements on hardware and bandwidth resources of a server, and resource waste and terminal stability are reduced for the user terminals without fault conditions are solved.
In the embodiment of the present invention, the execution subject of the process is a server, and the server sends the generated and received failure recovery data packet to each corresponding terminal device, so as to achieve the purpose of failure recovery. Fig. 1 shows a flowchart of an implementation of a method for issuing a failover data packet according to a first embodiment of the present invention, which is detailed as follows:
in S101, an apparatus operation log uploaded by each user terminal is received.
In this embodiment, the server is in communication connection with each user terminal, and the user terminal may send the device operation log to the server according to a preset rule. Specifically, in the running process of the user terminal, the device running log may be sent to the server at a preset time interval, and the preset time interval may be used by the user to perform device operation by himself or by the server to perform device operation on all the user terminals in a unified manner. The user terminal can also establish a log uploading process in the background after receiving the shutdown instruction, send the device running log to the server through the process, and enter a simulated shutdown state; the pseudo-shutdown state specifically includes: the user terminal closes all modules and processes which are irrelevant to the log running of the uploading device, for example, the user terminal only reserves the communication module and the log uploading process, and closes all other processes, so that the power consumption of the user terminal is reduced.
In this embodiment, the server may be configured to repair a failure condition caused by a certain application, and in this case, if the user terminal has multiple applications installed therein, the user terminal simultaneously performs communication connection with the servers corresponding to the respective applications, and sends the device operation logs generated when the user operates the respective applications to the corresponding servers, respectively.
In this embodiment, the server may create corresponding databases for different user terminals, store the device operation log into the database of the user terminal corresponding to the terminal identifier according to the terminal identifier carried in the received device operation log, and execute the relevant operation of S102 after the storage is completed.
In S102, based on the device operation log uploaded by each user terminal, respectively determining fault information included in each user terminal; the fault information includes: the system comprises a fault module identifier, a terminal software version and a fault response mode.
In this embodiment, after receiving the device operation logs sent by each user terminal, the server determines, according to a preset fault information identification rule, whether a fault condition exists in the device operation logs uploaded by the user terminal, and if the fault condition exists, generates a piece of fault information based on the device operation logs. The fault information includes a fault module identifier, a fault software version and a fault response mode. The determination mode of the fault module identifier is specifically as follows: and identifying the equipment module which executes the operation in the equipment running log, and taking the identifier of the equipment module as a fault module identifier. The determining mode of the fault software version specifically comprises the following steps: and acquiring the application program responding to the request operation in the equipment running log, installing the version number of the application program on the user terminal, and taking the version number as the terminal software version. Failure response modes include, but are not limited to: forced exit, downtime, terminal restart, and response timeout.
In this embodiment, since each device operation log records a response module responding to the current operation, if the server recognizes that the device operation log is a failure operation log, the identifier of the response module in the device operation log may be used as the identifier of the failure module of the failure information. The device running log records a starting time and an ending time besides a module for recording a response, the running time can be compared with the average running time to determine whether the operation is overtime response, and the ending mode of the running process can be acquired from the device running log, so that the fault response mode in the fault information is determined through the two aspects. Of course, for the information of the fault software version, the identifier of the environment software where the operation is requested may be directly extracted from the device operation log as the terminal software version of the fault information.
Optionally, in this embodiment, the user terminal may send the device operation record corresponding to the current operation to the server only when detecting that the user terminal has a fault, and the server may identify that the user terminal has an abnormal condition as long as receiving the device operation log sent by the terminal device, and directly extract fault information from the device operation log.
Of course, if the device operation log relates to a task request completed by the cooperative operation of a plurality of modules, one fault information may include a plurality of fault module identifiers, or different fault module identifiers may be divided into a plurality of different fault information for recording. Similarly, if a task request needs to be completed cooperatively by a plurality of application programs, one fault message may include a plurality of terminal software identifiers; and a fault message can be independently generated for different terminal software identifications to be recorded.
In S103, classifying the fault information based on the fault module identifier, the terminal software version, and the fault response mode, and determining a fault type of the fault information.
In this embodiment, the server classifies each fault information according to the fault module identifier, the terminal software version, and the fault response mode included in the fault information, and since the three feature items are used, it can be identified whether the fault conditions indicated by each fault information are the same or similar, so as to determine whether the fault conditions are caused by the same cause. For example, the server receives first fault information and second fault information, where the three feature items in the first fault information are (WIFI module, Ver1, connection timeout); the three characteristic items in the second fault information are respectively (the WIFI module, the Ver1, and the packet loss rate is high), so it can be seen that the fault module identifiers and the terminal software version numbers in the first fault information and the second fault information are the same, and the fault response modes are similar and are common response modes in which faults exist in the WIFI connection, so that the first fault information and the second fault information can be identified as the same fault type. By the method, different fault information uploaded by different user terminals can be classified into a plurality of fault types.
In this embodiment, the same fault type may contain a plurality of fault information from different fault terminals. The server database may also record the identified fault type. In this case, the server may match the fault information with an existing fault type, determine whether a corresponding created fault type exists, if so, take the matched fault type as the fault type of the fault information, and add the user terminal identifier corresponding to the fault information to a correspondence table pre-stored for the fault type. If the fault type corresponding to the fault information does not exist in the database, a fault type is created, the created fault type is matched with other received fault information, whether the other fault information received at this time belongs to the fault type is determined, and therefore the classification operation of the fault information is completed.
In S104, according to the user terminal corresponding to the fault information included in the fault type, establishing a corresponding relationship between the fault type and the user terminal; 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 corresponding relationship between the fault type and the user terminal based on the user terminal corresponding to each fault information, for example, the fault corresponding relationship is shown in table 1. Referring to table 1, the server may configure a fault number for each fault type, configure a fault description field for the fault type, and use the communication address of the user terminal as the identifier of the user terminal.
| Fault numbering | Description of faults | User terminal identification |
| 1 | WIFI connection failure | (198.15.255.14)；(185.52.61.243)； |
| 2 | Touch control dislocation of touch control screen | (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 fault information included in the fault type to a fault repair administrator, so that the fault repair administrator determines a corresponding fault repair scheme according to the fault type, and then generates a fault repair data packet for repairing the fault type; certainly, if the server stores a fault repairing algorithm, a plurality of simulation user terminals can be set up according to each fault information in the fault type, whether the fault type is repaired or not is determined by changing each parameter in the terminal software version and the output feedback of the modified simulation user terminals, and if yes, a fault repairing data packet is generated according to each parameter of the terminal software corresponding to the repaired fault type.
In S105, if a failure recovery data packet for recovering the failure type is acquired, the failure recovery data packet is sent to the user terminal corresponding to the failure type based on the correspondence.
In this embodiment, the server may locally generate the failure recovery data packet through an administrator or a failure recovery algorithm, and may also receive the failure recovery data packet sent from another device, for example, receive the failure recovery data packet sent by a terminal of the administrator or an upper server. Because the fault repair has a certain hysteresis, that is, after the fault information fed back by the user terminal is received and the fault type is determined, a certain time difference exists between the acquisition of the fault repair data packet, the server does not immediately implement the distribution process of the fault repair data packet after receiving the fault information, but pushes the fault repair data packet to the user terminal corresponding to the fault type after receiving the fault repair data packet.
In this embodiment, after acquiring a new failure recovery data packet, the server determines the failure type used by the failure recovery data packet for recovery, and queries what user terminals having the failure type exist based on the correspondence generated in S104, and then sends the failure recovery data packet to the user terminal, thereby achieving the purpose of directionally recovering the failure to the user terminal.
In particular, after the server sends the failure recovery packet to the user terminal in a certain failure type, the server may delete the terminal identifier of the user terminal from the corresponding relationship or add a sent identifier. In the subsequent process of collecting the fault information, 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 repairing data packet, the newly detected user terminal can be added into the corresponding relation of the fault type. If the mode that the user identification of the sent fault repairing data packet is deleted from the corresponding relation is adopted, the server pushes the fault repairing data packet to a user terminal which currently exists in a corresponding relation table; if the user terminal is distinguished by adding a sent identifier, the server sends the fault repairing data packet to the user terminal with the empty sent identifier.
As can be seen from the above, the method for issuing a failure recovery data packet according to the embodiment of the present invention acquires the device running log of the user terminal, identifies the failure information included in the user terminal, then classifies the failure information, and determines the type of the failure included in the user terminal. And when the fault repairing data packet of a certain fault type is obtained, the fault repairing data packet is sent to all the user terminals with the fault type, so that the aim of directionally releasing the fault repairing data packet is fulfilled. Compared with the existing method for issuing the fault repairing data packet, the embodiment of the invention only pushes the fault repairing data packet to the user terminal with the corresponding fault type because the fault repairing data packet is not pushed in a global unified way, thereby reducing the instantaneous concurrent data volume of the server and reducing the requirements on the hardware and the bandwidth of the server. On the other hand, the embodiment of the invention is a directional issuing process, and the user terminal without the corresponding fault type does not push the fault repairing data packet, thereby avoiding resource waste and improving the stability of the user terminal and the use experience of the user.
Fig. 2 shows a flowchart of a specific implementation of the method S103 for issuing a failover data packet according to the second embodiment of the present invention. Referring to fig. 2, with respect to the embodiment described in fig. 1, S103 in the method for issuing a failover data packet provided in this embodiment includes S1031 to S1033, which are detailed as follows:
in S1031, based on the fault module identifier, the terminal software version, and the fault response mode, respectively calculating a matching degree between each piece of fault information and a pre-stored fault type included in a preset fault recovery library; the model for calculating the matching degree specifically comprises:
wherein, the S is the matching degree between the fault information and the fault type; a is described1、A2、A3Respectively identifying the fault module of the fault information, the terminal software version and the parameter value of the fault response mode; b is1、B2、B3Respectively identifying the fault module of the fault type, the terminal software version and the parameter value of the fault response mode; and e is a natural constant.
In this embodiment, a fault recovery library is stored in the server, where the fault recovery library includes a plurality of fault types, and the fault type may be a fault type acquired and classified in a process of directly acquiring the terminal device, a fault type discovered by an administrator in a test process, or a fault type sent by a receiving upper server or a distributed server for synchronizing the fault database. In this case, different servers may divide the user terminals according to the difference of the regions or the difference of the types of the managed terminals, the different servers are used to manage different types of user terminals, and the servers synchronize the fault types in the fault recovery library at preset time intervals, so that the situation that fault recovery data packets are repeatedly designated is reduced, the recovery pressure of an administrator is reduced, and the fault recovery efficiency is improved.
In this embodiment, when receiving the fault information fed back by the user terminal, the server may determine whether the fault information belongs to one of the recorded fault types according to the fault module identifier, the terminal version number, and the fault response mode included in the fault information, and therefore, the matching degree calculation is performed based on the three parameters and the fault type in the fault recovery library. Calculating the degree of difference between the feature items, i.e. calculating | A1-B1|、|A2-B2I and | A3-B3And summing the three differencesAs a degree of deviation between the type of the failure and the failure information, and a degree of matching is obtained based on the degree of deviation.
Preferably, the server numbers each module based on the relevance between the modules, and a smaller difference in the numbers indicates that the two modules have a similar function and a larger relevance. For example, the communication modules may be categorized into a third category, the bluetooth module is used as the first category in the third category, the WIFI module is used as the second category in the third category, the number of the bluetooth module may be 31, and the number of the WIFI module may be 32, so that the difference between the two is 1; and the display module belongs to the 8 th major category, and the touch screen in the display module belongs to the first minor category, then the module number of the touch screen is 81, so the difference between the touch screen module and the bluetooth module is 50, and thus based on the size of the difference between the fault module identifications, whether the fault information is matched with the fault type can be determined. As mentioned above, the failure response modes can also be numbered in the above-mentioned manner, and are not described one by one here.
Particularly, since the software version numbers are numbered one by one based on the precedence order of the version generation dates, the difference between the version numbers is directly calculated, and the degree of difference between the two software versions can be determined, namely, the difference is used as one of the factors for calculating the matching degree.
In S1032, if there is one matching degree between the pre-stored fault type and the fault information that is greater than a preset matching degree threshold, the pre-stored fault type is used as the fault type of the fault information, and a fault repair data packet of the pre-stored fault type is sent to the user terminal to which the fault information belongs.
In this embodiment, if the server finds that the matching degree between one pre-stored fault type and the currently obtained fault information is greater than the preset matching threshold in the fault repairing library, the pre-stored fault type is identified as the fault type corresponding to the fault information, and particularly, if the matching degrees between a plurality of pre-stored fault types and the fault information are both greater than the preset matching threshold, the pre-stored fault type 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 one fault repair data packet for modifying the pre-stored fault type, so that the server can directly send the fault repair data packet corresponding to the pre-stored fault type to the fault terminal after determining that a certain fault information belongs to the pre-stored fault type, thereby achieving the purpose of fault repair.
In S1033, if the matching degree between any of the pre-stored fault types and the fault information is less than or equal to a preset matching degree threshold, a fault type is created according to the fault module identifier, the terminal software version, and the fault response mode carried by the fault information, and the created fault type is used as the fault type of the fault information.
In this embodiment, if the matching degrees between each pre-stored fault type and the fault information in the fault repairing library are all less than or equal to the matching degree threshold, it indicates that the fault information is newly-appeared fault information, and the server repairs the fault, so that a fault type is created based on the fault module representation, the terminal software version and the fault response mode carried by the fault information, the fault type is stored in the fault repairing library, the created fault type is identified as the fault type of the fault information, and then the related operations of S104 and S105 are executed.
In the embodiment of the invention, the fault information is matched with the pre-stored fault type, so that the situations of repeated repair and repeated storage are avoided, the working pressure of a manager for fault repair is reduced, and the fault repair efficiency is improved.
Fig. 3 is a flowchart illustrating a specific implementation of the method S105 for issuing a failover data packet according to a third embodiment of the present invention. Referring to fig. 3, in the embodiment described with respect to fig. 1, S105 in the method for issuing a failover data packet according to this embodiment further includes S1051 to S1053, which are detailed as follows:
in S1051, the data amount of the failure repair packet is acquired.
In this embodiment, before sending the failure recovery data packet, the server determines the data volume of the failure recovery data packet, and compares the data volume with a preset data volume threshold, and if the data volume of the failure recovery data packet is smaller than the preset data volume threshold, the operation of S1052 is executed; 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 amount threshold of this embodiment may be set manually by an administrator, or may be automatically adjusted by the server according to the bandwidth resource of the network where the server is located. For example, the server sets the expected duration of sending a failure recovery packet to be 4 seconds, and the occupied bandwidth resource cannot exceed 50%, and the current bandwidth resource is 100M/s, so that the data amount threshold may be: vmax 100M/s 50% × 4 200M.
In S1052, if the data amount of the failure repair data packet is smaller than a preset data amount threshold, setting a main thread to be in a serial operation mode, and sending the failure repair data packet to each user terminal corresponding to the failure type one by one through the main thread.
In this embodiment, if the server determines that the data volume of the failure recovery data packet is smaller than the preset data volume threshold, it indicates that the data volume of the failure recovery data packet is smaller, the time required for sending a data packet is shorter, and the situation that sending is not completed after the sending exceeds the preset time length due to sending the failure recovery data packet does not occur. The efficiency of sending the data packet is higher because the main thread has more hardware resources and bandwidth resources which can be called, but the server sets a maximum response time length when detecting the operation of the main thread, if the response time length exceeds a preset response threshold value, the main thread is identified to be in a response abnormal state, the operation of the main thread is terminated, and the response is carried out again. Therefore, if the data volume of the failure recovery packet is large, the server recognizes that the main thread is in the response abnormal state, and repeatedly terminates and retransmits the main thread, which results in resource waste and a failure in normal transmission of the failure packet. Therefore, when the data volume of the fault data packet is small, data can be issued through the main thread.
In this embodiment, when determining that the fault recovery data packet is sent to each user terminal through the main thread, the server may use the sequence of uploading the fault information by the user terminal as the sending sequence of sending the fault recovery data packet by the user terminal.
In S1053, if the data volume of the failure recovery data packet is greater than or equal to the data volume threshold, creating a plurality of asynchronous parallel sub-threads in the main thread, and sending the failure recovery data packet to each user terminal corresponding to the failure type through each sub-thread; the number of the sub threads is the same as the number of the user terminals included in the fault type.
In this embodiment, when the server determines that the failure recovery packet is equal to or larger than the data amount threshold, it indicates that the data amount of the failure recovery packet is large, and if the failure recovery packet is transmitted by the main thread serial method, the above-described transmission timeout is likely to occur. Therefore, in this case, the failure recovery packet is transmitted to each user terminal in parallel by the child thread.
In this embodiment, the server queries the number of terminals of the user terminal recorded in the corresponding relationship of the fault type, creates the number of sub-threads with the same number as the terminals under the main thread, and sets the operation mode of each sub-thread to an asynchronous parallel mode, thereby controlling each sub-thread to perform communication connection with each user terminal respectively, and sending a fault repairing data packet to each user terminal through each sub-thread.
Optionally, if the number of the terminals is greater than the maximum number of sub-threads of the server, creating sub-threads with the same number as the maximum number of sub-threads, performing a sending operation of a fault repairing data packet to a part of the user terminals, and after the sending operation is completed, sending the remaining part of the user terminals until all the user terminals corresponding to the fault type perform the data packet sending operation.
In the embodiment of the invention, the server selects a proper sending mode to send the data according to the data size of the fault repairing data packet, thereby improving the sending efficiency and the sending success rate.
Fig. 4 is a flowchart illustrating a specific implementation of the method S102 for issuing the failover data packet according to a fourth embodiment of the present invention. Referring to fig. 4, with respect to the embodiment described in fig. 1, an issuing method S102 for a failover packet provided in this embodiment includes: s1021 to S1023 are described in detail as follows:
in S1021, the operation duration of the operation log is determined according to the start time and the end time of the device operation log.
In this embodiment, the start time and the end time of the service response operation are recorded in the device operation logs, and the server may determine the operation duration required by the user terminal to respond to the service based on a difference between the start time and the end time.
Optionally, the server may query, based on the service type, a time threshold corresponding to the service type. Different service types require different response times, so that the corresponding time length thresholds are provided. The server can extract the service type contained in the equipment operation log, then determine the time length threshold value of the fault type, and then compare the operation time length acquired this time with the time length threshold value. In particular, the server may determine an average operation duration of the service type based on the device operation log regarding the service type fed back by the user terminal multiple times, and use the average operation duration as the duration threshold.
In this embodiment, if the server detects that the running duration is less than the preset duration threshold, it indicates that there is no abnormality in the response, and identifies the device running log as a normal running log; otherwise, if the running duration is greater than the preset duration threshold, the operation of S1022 is performed, and it is further determined whether the device running log is a fault running log.
In S1022, if the running duration is greater than a preset duration threshold, a resource consumption parameter of the device running log is obtained.
In this embodiment, since the operation duration is greater than the preset duration threshold, it indicates that the service response belongs to the timeout response, and therefore the resource condition of the user terminal consumed in the service of this time will be obtained. Because the hardware resources of the user terminal are generally occupied more for the fault response, whether the equipment running log is the fault running log can be determined based on the size of the resource consumption parameter value.
In this embodiment, the resource consumption parameter may be a value occupied by a terminal memory, or may be a percentage occupied by the operation module to calculate the resource. And the server compares the consumed resource parameters in the equipment operation log with a preset consumption threshold value. If the consumption does not exceed the preset consumption threshold, identifying the equipment running log as a normal running log; otherwise, if the preset consumption threshold is exceeded, it is identified as a fault operation log, and the operation of S1023 is performed.
In S1023, if the resource consumption parameter exceeds a preset consumption threshold, the device operation log is identified as a fault operation log, and the fault information is generated based on the fault operation log.
In this embodiment, when it is determined that the resource consumption parameter of the user terminal required for responding to the service exceeds the preset consumption threshold, the server indicates that the operation occupies a large amount of resources of the user terminal, determines that a fault condition exists in the process of responding to the service, and generates a fault message.
In the embodiment of the invention, whether the equipment running log is the fault running log is judged by the running duration and the resource consumption parameters, so that the aims of automatically identifying and extracting fault information are fulfilled, and the fault repairing efficiency is improved.
Fig. 5 is a flowchart of a specific implementation of a method for issuing a failover data packet according to a fifth embodiment of the present invention. Referring to fig. 5, with respect to the embodiments described in fig. 1 to fig. 4, before the sending, based on the correspondence, the fault repairing data packet to the user terminal corresponding to the fault type, the method for issuing the fault repairing data packet according to this embodiment further includes: s501 and S502 are specifically detailed as follows:
in S501, the network status of the ue is obtained.
In this embodiment, before sending the failure recovery data packet to the user terminal, the server may send a network status acquisition request to the user terminal, so as to determine the network status of the current user terminal. The network state is a specific connection mode for communication and connection with the internet, and is through a wired network, a wireless local area network or a mobile network. The user terminal generates a network state result based on the current network state communicated with the server and returns the network state result to the server.
In S502, if the network status satisfies a preset data packet download status, the operation of issuing the failure repair data packet to the user terminal corresponding to the failure type based on the correspondence is executed.
In this embodiment, if the server determines that the network status of the current user terminal is the preset data packet downloading status, the server sends a failure recovery data packet to the user terminal. Specifically, the packet download status is: wireless local area network status or wired network status.
Optionally, if the server determines that the current network state does not satisfy the preset data packet downloading state, a retransmission timer is set, and after the count value of the retransmission timer is greater than the retransmission count value, the relevant operation of S501 is returned until the network state of the user terminal satisfies the preset data packet downloading state, and then the downloading operation is executed.
Optionally, after receiving the network state acquisition request, the user terminal may enter a download waiting state when determining that the current state does not satisfy the preset data package download state, and actively send a data package acquisition request to the server to start a data package download operation when detecting that the network state of the user terminal satisfies the data package download state.
In the embodiment of the invention, whether to execute the data packet transmission is judged by acquiring the network state of the user terminal, thereby avoiding the waste of a large amount of data flow caused by the unintentional downloading of the user terminal.
It should be understood that, the sequence numbers of the steps in the foregoing embodiments do not imply an execution sequence, and the execution sequence of each process should be determined by its function and inherent logic, and should not constitute any limitation to the implementation process of the embodiments of the present invention.
Fig. 6 shows a block diagram of a server according to an embodiment of the present invention, where the server includes units for performing the steps in the corresponding embodiment of fig. 1. Please refer to fig. 1 and fig. 1 for the corresponding description of the embodiment. For convenience of explanation, only the portions related to the present embodiment are shown.
Referring to fig. 6, the server includes:
an equipment operation log receiving unit 61, configured to receive an equipment operation log uploaded by each user terminal;
a fault information obtaining unit 62, configured to determine, based on the device operation log uploaded by each user terminal, fault information included in each user terminal respectively; the fault information includes: a fault module identifier, a terminal software version and a fault response mode;
a fault type determining unit 63, configured to classify the fault information based on the fault module identifier, the terminal software version, and the fault response mode, and determine a fault type of the fault information;
a corresponding relationship determining unit 64, configured to establish a corresponding relationship 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 65, configured to, if a failure recovery data packet for recovering the failure type is obtained, send the failure recovery data packet to the user terminal corresponding to the failure type based on the correspondence relationship.
Optionally, the fault type determination unit 63 includes:
the matching degree calculation unit is used for calculating the matching degree of each fault information and a pre-stored fault type contained in a preset fault repair library respectively based on the fault module identification, the terminal software version and the fault response mode; the model for calculating the matching degree specifically comprises:
wherein, the S is the matching degree between the fault information and the fault type; a is described1、A2、A3Respectively identifying the fault module of the fault information, the terminal software version and the parameter value of the fault response mode; b is1、B2、B3Respectively identifying the fault module of the fault type, the terminal software version and the parameter value of the fault response mode; e is a natural constant;
a pre-stored fault type determining unit, configured to, if there is one matching degree between the pre-stored fault type and the fault information that is greater than a preset matching degree threshold, use the pre-stored fault type as the fault type of the fault information, and send a fault repair data packet of the pre-stored fault type to a user terminal to which the fault information belongs;
and the fault type creating unit is used for creating a fault type according to the fault module identification, the terminal software version and the fault response mode carried by the fault information if the matching degree of any one of the pre-stored fault types and the fault information is less than or equal to a preset matching degree threshold value, and taking the created fault type as the fault type of the fault information.
Optionally, the failure data packet sending unit 65 includes:
a data volume determining unit, configured to obtain a data volume of the failure recovery data packet;
the serial sending unit is used for setting a main thread to be in a serial operation mode if the data volume of the fault repairing data packet is smaller than a preset data volume threshold value, and sending the fault repairing data packet to each user terminal corresponding to the fault type one by one through the main thread;
a parallel sending unit, configured to create a plurality of asynchronous parallel sub-threads in the main thread if the data volume of the fault recovery data packet is greater than or equal to the data volume threshold, and send the fault recovery data packet to each user terminal corresponding to the fault type through each sub-thread; the number of the sub threads is the same as the number of the user terminals included in the fault type.
Optionally, the fault information obtaining unit 62 includes:
the running duration calculation unit is used for determining the running duration of the running log according to the starting time and the ending time of the running log of the equipment;
a resource consumption determining unit, configured to obtain a resource consumption parameter of the device operation log if the operation duration is greater than a preset duration threshold;
and the fault operation log determining unit is used for identifying the equipment operation log as a fault operation log if the resource consumption parameter exceeds a preset consumption threshold value, and generating the fault information based on the fault operation log.
Optionally, the server further comprises:
a network state obtaining unit, configured to obtain a network state of the user terminal;
a network status determining unit, configured to execute the operation of issuing the failure recovery data packet to the user terminal corresponding to the failure type based on the corresponding relationship if the network status satisfies a preset data packet download status
Therefore, the server provided by the embodiment of the invention can only push the fault repair data packet to the user terminal with the corresponding fault type, thereby reducing the instantaneous concurrent data volume of the server and reducing the requirements on the hardware and the bandwidth of the server. On the other hand, the embodiment of the invention is a directional issuing process, and the user terminal without the corresponding fault type does not push the fault repairing data packet, thereby avoiding resource waste and improving the stability of the user terminal and the use experience of the user.
Fig. 7 is a schematic diagram of a server according to another embodiment of the present invention. As shown in fig. 7, the server 7 of this embodiment includes: a processor 70, a memory 71 and a computer program 72, such as a distribution program of a failover data packet, stored in said memory 71 and operable on said processor 70. The processor 70, when executing the computer program 72, implements the steps in the above-described embodiments of the distribution method of the respective failure repair data packets, for example, S101 to S105 shown in fig. 1. Alternatively, the processor 70, when executing the computer program 72, implements the functions of the units in the above-described device embodiments, such as the functions of the modules 61 to 65 shown in fig. 6.
Illustratively, the computer program 72 may be divided into one or more units, which are stored in the memory 71 and executed by the processor 70 to accomplish the present invention. The one or more units may be a series of computer program instruction segments capable of performing specific functions, which are used to describe the execution of the computer program 72 in the server 7. For example, the computer program 72 may be divided into an apparatus operation log receiving unit, a fault information acquiring unit, a fault type determining unit, a correspondence determining unit, and a fault data packet sending unit, where the specific functions of each unit are as follows:
the device operation log receiving unit is used for receiving the device operation logs uploaded by the user terminals;
the fault information acquisition unit is used for respectively determining fault information contained in each user terminal based on the equipment running logs uploaded by each user terminal; the fault information includes: a fault module identifier, a terminal software version and a fault response mode;
a fault type determining unit, configured to classify the fault information based on the fault module identifier, the terminal software version, and the fault response mode, and determine a fault type of the fault information;
a corresponding relation determining unit, configured to establish a corresponding relation 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 the fault data packet sending unit is used for sending the fault repairing data packet to the user terminal corresponding to the fault type based on the corresponding relation if the fault repairing data packet used for repairing the fault type is obtained.
The server 7 may be a desktop computer, a notebook, a palm computer, a cloud server, or other computing devices. The server may include, but is not limited to, a processor 70, a memory 71. Those skilled in the art will appreciate that fig. 7 is merely an example of a server 7 and does not constitute a limitation of the server 7 and may include more or fewer components than shown, or some components in combination, or different components, e.g., the server may also include input output devices, network access devices, buses, etc.
The Processor 70 may be a Central Processing Unit (CPU), other general purpose Processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA) or other Programmable logic device, discrete Gate or transistor logic, discrete hardware components, etc. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.
The storage 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, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash memory Card (Flash Card), and the like, which are provided on the server 7. Further, the memory 71 may also include both an internal storage unit and an external storage device of the server 7. The memory 71 is used for storing the computer program and other programs and data required by the server. The memory 71 may also be used to temporarily store data that has been output or is to be output.
In addition, functional units in the embodiments of the present invention may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit.
The integrated modules/units, if implemented in the form of software functional units and sold or used as separate products, may be stored in a computer readable storage medium. Based on such understanding, all or part of the flow of the method according to the embodiments of the present invention may also be implemented by a computer program, which may be stored in a computer-readable storage medium, and when the computer program is executed by a processor, the steps of the method embodiments may be implemented. . Wherein the computer program comprises computer program code, which may be in the form of source code, object code, an executable file or some intermediate form, etc. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, usb disk, removable hard disk, magnetic disk, optical disk, computer Memory, Read-Only Memory (ROM), Random Access Memory (RAM), electrical carrier wave signals, telecommunications signals, software distribution medium, and the like. It should be noted that the computer readable medium may contain content that is subject to appropriate increase or decrease as required by legislation and patent practice in jurisdictions, for example, in some jurisdictions, computer readable media does not include electrical carrier signals and telecommunications signals as is required by legislation and patent practice.
The above-mentioned embodiments are only used for illustrating the technical solutions of the present invention, and not for limiting the same; although the present invention has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; such modifications and substitutions do not substantially depart from the spirit and scope of the embodiments of the present invention, and are intended to be included within the scope of the present invention.
Claims (10)
1. A method for issuing a failover packet, comprising:
receiving equipment running logs uploaded by each user terminal;
respectively determining fault information contained in each user terminal based on the equipment running logs uploaded by each user terminal; the fault information includes: a fault module identifier, a terminal software version and a fault response mode;
classifying the fault information based on the fault module identification, the terminal software version and the fault response mode, and determining the fault type of the fault information;
establishing a corresponding relation between the fault type and the user terminal according to the user terminal corresponding to the fault information contained in the fault type; the fault information corresponds to at least one user terminal;
and if a fault repairing data packet for repairing the fault type is acquired, the fault repairing data packet is sent to the user terminal corresponding to the fault type based on the corresponding relation.
2. The issuing method according to claim 1, wherein the classifying the fault information based on the fault module identifier, the terminal software version, and the fault response mode to determine the fault type of the fault information includes:
respectively calculating the matching degree of each fault information and a pre-stored fault type contained in a preset fault repairing library based on the fault module identification, the terminal software version and the fault response mode; the model for calculating the matching degree specifically comprises:
wherein, the S is the matching degree between the fault information and the fault type; a is described1、A2、A3Respectively identifying the fault module of the fault information, the terminal software version and the parameter value of the fault response mode; b is1、B2、B3Respectively identifying the fault module of the pre-stored fault type, the terminal software version and the parameter value of the fault response mode; e is a natural constant;
if the matching degree of the pre-stored fault type and the fault information is larger than a preset matching degree threshold value, taking the pre-stored fault type as the fault type of the fault information, and sending a fault repairing data packet of the pre-stored fault type to a user terminal to which the fault information belongs;
and if the matching degree of any one of the pre-stored fault types and the fault information is less than or equal to a preset matching degree threshold value, establishing a fault type according to a fault module identifier, a terminal software version and a fault response mode carried by the fault information, and taking the established fault type as the fault type of the fault information.
3. The issuing method according to claim 1, wherein, if the fault repair data packet for repairing the fault type is acquired, issuing the fault repair data packet to the user terminal corresponding to the fault type based on the correspondence relationship includes:
acquiring the data volume of the fault repairing data packet;
if the data volume of the fault repairing data packet is smaller than a preset data volume threshold value, setting a main thread into a serial operation mode, and sending the fault repairing data packet to each user terminal corresponding to the fault type one by one through the main thread;
if the data volume of the fault repairing data packet is larger than or equal to the data volume threshold, creating a plurality of asynchronous parallel sub-threads in the main thread, and respectively sending the fault repairing data packet to each user terminal corresponding to the fault type through each sub-thread; the number of the sub threads is the same as the number of the user terminals included in the fault type.
4. The issuing method according to claim 1, wherein the determining the fault information included in each user terminal based on the device operation log uploaded by each user terminal includes:
determining the operation duration of the operation log according to the starting time and the ending time of the operation log of the equipment;
if the operation duration is greater than a preset duration threshold, acquiring a resource consumption parameter of the equipment operation log;
and if the resource consumption parameter exceeds a preset consumption threshold value, identifying the equipment operation log as a fault operation log, and generating the fault information based on the fault operation log.
5. The issuing method according to any one of claims 1 to 4, wherein before the sending the failure recovery data packet to the user terminal corresponding to the failure type based on the correspondence relationship, the issuing method further includes:
acquiring the network state of the user terminal;
and if the network state meets a preset data packet downloading state, executing the operation of issuing the fault repairing data packet to the user terminal corresponding to the fault type based on the corresponding relation.
6. A server, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, the processor implementing the steps when executing the computer program:
receiving equipment running logs uploaded by each user terminal;
respectively determining fault information contained in each user terminal based on the equipment running logs uploaded by each user terminal; the fault information includes: a fault module identifier, a terminal software version and a fault response mode;
classifying the fault information based on the fault module identification, the terminal software version and the fault response mode, and determining the fault type of the fault information;
establishing a corresponding relation between the fault type and the user terminal according to the user terminal corresponding to the fault information contained in the fault type; the fault information corresponds to at least one user terminal;
and if a fault repairing data packet for repairing the fault type is acquired, the fault repairing data packet is sent to the user terminal corresponding to the fault type based on the corresponding relation.
7. The server according to claim 6, wherein the classifying the fault information based on the fault module identifier, the terminal software version, and the fault response mode to determine the fault type of the fault information comprises:
respectively calculating the matching degree of each fault information and a pre-stored fault type contained in a preset fault repairing library based on the fault module identification, the terminal software version and the fault response mode; the model for calculating the matching degree specifically comprises:
wherein, the S is the matching degree between the fault information and the fault type; a is described1、A2、A3Respectively identifying the fault module of the fault information, the terminal software version and the parameter value of the fault response mode; b is1、B2、B3Respectively identifying the fault modules of the pre-stored fault typesThe terminal software version and the parameter value of the fault response mode; e is a natural constant;
if the matching degree of the pre-stored fault type and the fault information is larger than a preset matching degree threshold value, taking the pre-stored fault type as the fault type of the fault information, and sending a fault repairing data packet of the pre-stored fault type to a user terminal to which the fault information belongs;
and if the matching degree of any one of the pre-stored fault types and the fault information is less than or equal to a preset matching degree threshold value, establishing a fault type according to a fault module identifier, a terminal software version and a fault response mode carried by the fault information, and taking the established fault type as the fault type of the fault information.
8. The server according to claim 6, wherein the issuing, based on the correspondence, the failure recovery packet to the user terminal corresponding to the failure type if the failure recovery packet for recovering the failure type is obtained includes:
acquiring the data volume of the fault repairing data packet;
if the data volume of the fault repairing data packet is smaller than a preset data volume threshold value, setting a main thread into a serial operation mode, and sending the fault repairing data packet to each user terminal corresponding to the fault type one by one through the main thread;
if the data volume of the fault repairing data packet is larger than or equal to the data volume threshold, creating a plurality of asynchronous parallel sub-threads in the main thread, and respectively sending the fault repairing data packet to each user terminal corresponding to the fault type through each sub-thread; the number of the sub threads is the same as the number of the user terminals included in the fault type.
9. The server according to claim 6, wherein the determining, based on the device operation log uploaded by each of the user terminals, the fault information included in each of the user terminals respectively includes:
determining the operation duration of the operation log according to the starting time and the ending time of the operation log of the equipment;
if the operation duration is greater than a preset duration threshold, acquiring a resource consumption parameter of the equipment operation log;
and if the resource consumption parameter exceeds a preset consumption threshold value, identifying the equipment operation log as a fault operation log, and generating the fault information based on the fault operation log.
10. A computer-readable storage medium, in which a computer program is stored which, when being executed by a processor, carries out the steps of the method according to any one of claims 1 to 5.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810121899.0A CN108322345B (en) | 2018-02-07 | 2018-02-07 | Method for issuing fault repair data packet and server |
| PCT/CN2018/083288 WO2019153505A1 (en) | 2018-02-07 | 2018-04-17 | Method for publishing fault recovery data packet and server |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810121899.0A CN108322345B (en) | 2018-02-07 | 2018-02-07 | Method for issuing fault repair data packet and server |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN108322345A CN108322345A (en) | 2018-07-24 |
| CN108322345B true CN108322345B (en) | 2020-08-21 |
Family
ID=62902145
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201810121899.0A Active CN108322345B (en) | 2018-02-07 | 2018-02-07 | Method for issuing fault repair data packet and server |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN108322345B (en) |
| WO (1) | WO2019153505A1 (en) |
Families Citing this family (27)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109254864A (en) * | 2018-09-11 | 2019-01-22 | 北京奇艺世纪科技有限公司 | A kind of application failure restorative procedure, device and electronic equipment |
| CN109144559B (en) * | 2018-09-26 | 2022-02-01 | 深圳壹账通智能科技有限公司 | Update data packet pushing method and server |
| CN111385613B (en) * | 2018-12-29 | 2022-07-08 | 深圳Tcl数字技术有限公司 | Television system repairing method, storage medium and application server |
| CN109933465B (en) * | 2019-03-12 | 2021-12-10 | 北京同城必应科技有限公司 | Exception handling method, exception handling device, server and storage medium |
| CN111786804B (en) | 2019-04-04 | 2023-06-30 | 华为技术有限公司 | Link fault monitoring method and device |
| CN110191003A (en) * | 2019-06-18 | 2019-08-30 | 北京达佳互联信息技术有限公司 | Fault repairing method, device, computer equipment and storage medium |
| CN110633099A (en) * | 2019-09-05 | 2019-12-31 | 北京无限光场科技有限公司 | Application program repairing method, device, equipment and readable medium |
| CN110704093A (en) * | 2019-09-18 | 2020-01-17 | 上海麦克风文化传媒有限公司 | Method and system for processing operation feedback online fault |
| CN111026572A (en) * | 2019-11-15 | 2020-04-17 | 北京金山云网络技术有限公司 | Fault processing method and device of distributed system and electronic equipment |
| CN112988437B (en) * | 2019-12-17 | 2023-12-29 | 深信服科技股份有限公司 | Fault prediction method and device, electronic equipment and storage medium |
| CN111190630B (en) * | 2020-01-02 | 2023-06-16 | 竞技世界（北京）网络技术有限公司 | Updating method of terminal application and server |
| CN111664543B (en) * | 2020-05-25 | 2022-12-13 | 海信空调有限公司 | Air conditioner and control method thereof |
| CN111897683A (en) * | 2020-07-10 | 2020-11-06 | 广东小天才科技有限公司 | Electronic equipment and fault repairing method and device thereof |
| CN112104497A (en) * | 2020-09-11 | 2020-12-18 | 北京达佳互联信息技术有限公司 | Terminal management method, device, system, server, terminal and storage medium |
| CN112328422A (en) * | 2020-11-06 | 2021-02-05 | 深圳市锐尔觅移动通信有限公司 | Abnormity repairing method and device, electronic equipment and storage medium |
| CN112732520B (en) * | 2020-12-30 | 2024-04-12 | 中国人民解放军32181部队 | Fault processing method and system for equipment operation monitoring software |
| CN112733369B (en) * | 2021-01-13 | 2023-06-13 | 青岛海尔科技有限公司 | Intelligent equipment maintenance method, terminal and system and electronic equipment |
| CN113051112A (en) * | 2021-03-16 | 2021-06-29 | 北京经纬恒润科技股份有限公司 | Method and system for acquiring ECU fault information |
| CN113033889B (en) * | 2021-03-19 | 2022-12-20 | 国网河北省电力有限公司邢台供电分公司 | High-voltage transmission line fault prediction method and device and terminal equipment |
| CN113255454A (en) * | 2021-04-26 | 2021-08-13 | 广西电网有限责任公司桂林供电局 | Power grid self-adaptive fault positioning method and related equipment |
| CN113190370B (en) * | 2021-05-08 | 2024-06-18 | 京东科技控股股份有限公司 | Emergency response method and device for application |
| CN113692056B (en) * | 2021-08-25 | 2024-01-19 | 维沃移动通信有限公司 | Resource sharing method and device |
| WO2023030391A1 (en) * | 2021-09-06 | 2023-03-09 | Wuhan United Imaging Healthcare Co., Ltd. | Systems and methods for failure warning |
| CN114338765B (en) * | 2021-12-10 | 2024-03-22 | 青岛海尔科技有限公司 | Equipment connection abnormality identification method and system, electronic device and storage medium |
| CN114294778B (en) * | 2021-12-27 | 2023-11-14 | 深圳市兴特能源科技有限公司 | Air circulation disinfection and purification method and system for classroom lamp |
| CN113986603B (en) * | 2021-12-28 | 2022-04-15 | 深圳市明源云科技有限公司 | Method and device for determining page loading abnormity reason and storage medium |
| CN114722029B (en) * | 2022-04-18 | 2024-01-09 | 苏州浪潮智能科技有限公司 | Method, system, equipment and storage medium for repairing monitor database |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101115264A (en) * | 2006-07-24 | 2008-01-30 | 中兴通讯股份有限公司 | Communication terminal failure monitoring system and implementing method thereof |
| CN102857365A (en) * | 2012-06-07 | 2013-01-02 | 中兴通讯股份有限公司 | Fault preventing and intelligent repairing method and device for network management system |
| CN106161079A (en) * | 2015-04-28 | 2016-11-23 | 小米科技有限责任公司 | Fault feedback method and device |
| CN106685744A (en) * | 2017-03-13 | 2017-05-17 | 福建中金在线信息科技有限公司 | Fault elimination method, apparatus and system |
| EP3240240A1 (en) * | 2016-04-25 | 2017-11-01 | Cisco Technology, Inc. | Network architecture for predictive services management in cable network environments |
| CN107357730A (en) * | 2017-07-17 | 2017-11-17 | 郑州云海信息技术有限公司 | A kind of system fault diagnosis restorative procedure and device |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102045181B (en) * | 2009-10-10 | 2013-08-07 | 中国移动通信集团公司 | Method and device for handling terminal offline fault |
| CN105335277A (en) * | 2014-06-27 | 2016-02-17 | 可牛网络技术（北京）有限公司 | Fault information processing method and device as well as terminal |
| US10193706B2 (en) * | 2015-10-21 | 2019-01-29 | Arris Enterprises Llc | Distributed rule provisioning in an extended bridge |
-
2018
- 2018-02-07 CN CN201810121899.0A patent/CN108322345B/en active Active
- 2018-04-17 WO PCT/CN2018/083288 patent/WO2019153505A1/en active Application Filing
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101115264A (en) * | 2006-07-24 | 2008-01-30 | 中兴通讯股份有限公司 | Communication terminal failure monitoring system and implementing method thereof |
| CN102857365A (en) * | 2012-06-07 | 2013-01-02 | 中兴通讯股份有限公司 | Fault preventing and intelligent repairing method and device for network management system |
| CN106161079A (en) * | 2015-04-28 | 2016-11-23 | 小米科技有限责任公司 | Fault feedback method and device |
| EP3240240A1 (en) * | 2016-04-25 | 2017-11-01 | Cisco Technology, Inc. | Network architecture for predictive services management in cable network environments |
| CN106685744A (en) * | 2017-03-13 | 2017-05-17 | 福建中金在线信息科技有限公司 | Fault elimination method, apparatus and system |
| CN107357730A (en) * | 2017-07-17 | 2017-11-17 | 郑州云海信息技术有限公司 | A kind of system fault diagnosis restorative procedure and device |
Also Published As
| Publication number | Publication date |
|---|---|
| CN108322345A (en) | 2018-07-24 |
| WO2019153505A1 (en) | 2019-08-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108322345B (en) | Method for issuing fault repair data packet and server | |
| CN109144559B (en) | Update data packet pushing method and server | |
| CN108255653B (en) | Product testing method and terminal thereof | |
| CN108600029B (en) | Configuration file updating method and device, terminal equipment and storage medium | |
| WO2021169064A1 (en) | Edge network-based anomaly processing method and apparatus | |
| JP4760491B2 (en) | Event processing system, event processing method, event processing apparatus, and event processing program | |
| CN109495306B (en) | Method and equipment for expanding capacity of service network | |
| CN112506444A (en) | Kubernetes cluster-based expansion and contraction capacity control method and device and electronic equipment | |
| WO2020000745A1 (en) | Log management method and apparatus, computer device, and storage medium | |
| CN110401662B (en) | Industrial control equipment fingerprint identification method and storage medium | |
| CN103312544B (en) | A kind of control terminal reports the method, apparatus and system of journal file | |
| WO2019223062A1 (en) | Method and system for processing system exceptions | |
| CN105099739A (en) | Plug-in type software deployment method and apparatus, and application server | |
| CN110933178B (en) | Method for adjusting node configuration in cluster system and server | |
| CN111818132A (en) | Control method and device of Internet of things equipment, computer equipment and storage medium | |
| CN111262726A (en) | Configuration information updating method and device and computer readable storage medium | |
| CN111400041A (en) | Server configuration file management method and device and computer readable storage medium | |
| WO2021056739A1 (en) | Performance analysis method, device, computer apparatus and storage medium | |
| CN109697117B (en) | Terminal control method, terminal control device and computer-readable storage medium | |
| CN108255703B (en) | SQL script fault repairing method and terminal thereof | |
| CN112785150A (en) | Production line scheduling system and method based on automobile pressure sensor | |
| CN111885159B (en) | Data acquisition method and device, electronic equipment and storage medium | |
| CN112214437B (en) | Storage device, communication method and device and computer readable storage medium | |
| CN107957942B (en) | SQL script fault repairing method and terminal thereof | |
| CN111371601A (en) | Server configuration method, device, equipment and computer readable storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |