Event Processing Method, Device and System, Program Product and Storage Medium

Abstract

The present application relates to the technical field of data processing, and provides an event processing method, device, system, program product, and storage medium. Among them, the event processing method is applied to an event processing device, and specifically includes: after the current event is triggered, obtaining a current copy event corresponding to the event type of the current event from the storage space of the event processing device. Each type of event stores at most one copy event in the storage space, and the event information of the copy event is determined according to the event information of this type of event; updating the event information of the current copy event by using the event information of the current event. In this method, since each type of event stores at most one copy event in the storage space of the event processing device, even if a large number of events are generated in the event processing device, it will not occupy too much storage space. Therefore, the performance requirements for the event processing device are significantly reduced, and it is beneficial to the normal operation of the event processing device.

Description

Technical Field

[0001] The present application relates to the technical field of data processing, and in particular, to an event processing method, device, system, program product, and storage medium. Background Art

[0002] Currently, network cameras are deployed in many indoor and outdoor scenarios. During their operation, these cameras will trigger many events (for example, detecting a moving object in the picture). The cameras will cache all the triggered events locally and send them to users who are concerned about these events (for example, users with a specific APP installed on their mobile phones) at an appropriate time, so that the users can learn about the occurrence of these events and take corresponding measures.

[0003] Consequently, once the number of triggered events is excessive, caching these events will consume a large amount of storage resources. However, most cameras are embedded devices, and the internal storage resources are very limited, making it difficult to meet the demand for caching a large number of events. Or, even if the demand can be met, it may cause other functions of the camera to malfunction. Summary of the Invention

[0004] The purpose of the embodiments of the present application is to provide an event processing method, device, system, program product, and storage medium to improve at least some of the above technical problems.

[0005] To achieve the above purpose, the present application provides the following technical solutions:

[0006] In a first aspect, the embodiments of the present application provide an event processing method applied to an event processing device. The method includes: after a current event in the event processing device is triggered, obtaining a current copy event corresponding to the event type of the current event from the storage space of the event processing device; wherein, at most one copy event of each type of event is stored in the storage space, and the event information of the copy event is determined according to the event information of this type of event; updating the event information of the current copy event using the event information of the current event.

[0007] In the above method, since at most one copy event of each type of event is stored in the storage space of the event processing device (for example, a network camera), even if a large number of events are triggered in the event processing device, it will not occupy too much storage space. Therefore, the performance requirements for the event processing device are significantly reduced, and it is beneficial to the normal operation of the event processing device.

[0008] In addition, since the event information of the copy event will be continuously updated according to the latest event information, it can ensure that the latest events will not be lost.

[0009] In an implementation of the first aspect, the event information of the copy event includes at least one of the following: event type, indicating the type of the copy event; event data, indicating additional data of the copy event; latest trigger time, indicating the moment when the copy event was last triggered; number of repetitions, indicating the number of times the copy event occurs repeatedly; start time, indicating the moment when the copy event starts; end time, indicating the moment when the copy event ends; send flag, indicating whether the copy event has been sent; end flag, indicating whether the copy event has ended.

[0010] In the above implementation, the event information that the copy event may contain is listed. The event information of the copy event is not a simple copy of the event information of a certain ordinary event of the same type, but the result of fusing the event information of several ordinary events of the same type. Which event information the copy event specifically contains can be determined according to business requirements.

[0011] In an implementation of the first aspect, obtaining the current copy event corresponding to the event type of the current event from the storage space of the event processing device includes: searching for the current copy event from the storage space according to the event type of the current event; if the search for the current copy event is successful, obtaining the current copy event; if the search for the current copy event fails, creating the current copy event in the storage space; wherein, if the search for the current copy event fails, updating the event information of the current copy event with the event information of the current event includes: initializing the event information of the current copy event with the event information of the current event.

[0012] In the above implementation, a copy event is created only after a certain type of event is actually triggered, thus avoiding waste of storage space. However, copies can also be created in advance for each type of event. In this case, it can be considered that the query for the copy event can always be successful.

[0013] In an implementation of the first aspect, the method further includes: determining, according to the event information of the copy event, the copy events that have not been sent in the storage space; wherein, the copy events that have not been sent refer to the copy events that have not been successfully sent by the event processing device to the event receiving device; generating an event notification message according to the event information of the copy event that has not been sent, and sending the event notification message to the event receiving device; wherein, successfully sending the event notification message indicates that the copy event that has not been sent has been sent by the event processing device.

[0014] In the above implementation, since the event notification message is generated and sent based on the replica event rather than the single event itself, and each type of event corresponds to only one replica event, the situation of transmission delay caused by excessive number of events is significantly improved.

[0015] In an implementation manner of the first aspect, the event information of the replica event includes a sending flag. Determining the replica events that have not been sent in the storage space according to the event information of the replica event includes: determining the replica events with the sending flag being a first value in the storage space as the replica events that have not been sent; wherein, the replica events with the sending flag being a second value in the storage space are the replica events that have been sent, and when the event information of the replica events in the storage space is initialized, the sending flag therein is set to the first value; the method further includes: setting the sending flag of the newly sent replica event to the second value.

[0016] In the above implementation, by adding an information item of the sending flag to the event information, it is convenient to quickly and accurately determine whether the replica event has been sent.

[0017] In an implementation manner of the first aspect, the event information of the replica event includes an end time and / or an end flag, and the method further includes: determining the replica events that have ended in the storage space according to the event information of the replica event; if the event information of the replica event includes an end time, setting the end time of the replica event that has ended; if the event information of the replica event includes an end flag, setting the end flag of the replica event that has ended to a fourth value; wherein, the replica events with the end flag being a third value in the storage space are the replica events that have not ended, and when the event information of the replica events in the storage space is initialized, the end flag therein is set to the third value.

[0018] In the above implementation, when the sent replica event has ended, a reasonable end time can be set for it, so that the replica event can last for a period of time (the start time of the event replica can be set when its event information is initialized), and / or, by adding an information item of the end flag to the event information, it is convenient to quickly and accurately determine whether the replica event has ended.

[0019] In an implementation of the first aspect, the event information of the replica event includes the latest trigger time. Determining the replica events that have ended in the storage space according to the event information of the replica event includes: determining the replica events in the storage space whose expected end time has been exceeded by the current time as the ended replica events; wherein, the expected end time of the replica event is: the latest trigger time of the replica event plus the expected duration of the replica event; setting the end time of the ended replica events includes: setting the end time of the ended replica events to the expected end time of the ended replica events.

[0020] In the above implementation, by comparing the current time with the expected end time of the replica event, it is possible to quickly and accurately determine whether the replica event has ended.

[0021] In an implementation of the first aspect, the event information of the replica event includes the latest trigger time and / or event data. Updating the event information of the current replica event by using the event information of the current event includes: if it is determined according to the event information of the current replica event that the current replica event has not been sent, updating the latest trigger time of the current replica event by using the trigger time of the current event, and / or, updating the event data of the current replica event by using the event data of the current event; if it is determined according to the event information of the current replica event that the current replica event has been sent, initializing the event information of the current replica event by using the event information of the current event.

[0022] In the above implementation, if the current replica event has not been sent, it means that the event information of this event has not been notified to the server yet, so only some event information of the current replica event (such as the latest trigger time, event data) can be updated; if the current replica event has been sent, it means that the information of this event has been notified to the server, so the event information of the current replica event can be re-initialized by using the event information of the current event, which is equivalent to starting a new replica event.

[0023] Furthermore, if the current event also carries event data (such as a picture triggering the event, a text description of the event), the event data of the current replica event can also be updated. Note that although the original event data in the current replica event is overwritten after the update, for many application scenarios, this does not mean that the event is lost. For example, for a motion detection event (detecting a moving object in the picture), the user does not care which frame the moving object appears in, as long as the moving object is notified when it appears.

[0024] In an implementation of the first aspect, the event information of the copy event includes a sending flag. If the sending flag of the current copy event is the first value, it is determined that the current copy event has not been sent. If the sending flag is the second value, it is determined that the current copy event has been sent; wherein, the sending flag is set to the first value when the current copy event is initialized, and is set to the second value after the current copy event is sent by the event processing device.

[0025] In the above implementation, by using the value of the sending flag, it can be quickly and accurately determined whether the current copy event has been sent.

[0026] In an implementation of the first aspect, the event information of the copy event includes the number of repetitions. Updating the latest trigger time of the current copy event using the trigger time of the current event, and / or updating the event data of the current copy event using the event data of the current event includes: If it is determined according to the event information of the current copy event that the previous copy event has not ended, then update the latest trigger time of the current copy event using the trigger time of the current event, and / or update the event data of the current copy event using the event data of the current event; If it is determined according to the event information of the current copy event that the previous copy event has ended, then increment the number of repetitions of the current copy event by 1, and update the latest trigger time of the current copy event using the trigger time of the current event, and / or update the event data of the current copy event using the event data of the current event; wherein, the number of repetitions is set to 1 when the current copy event is initialized.

[0027] In the above implementation, if the current copy event has not ended, only some event information of the current copy event (e.g., the latest trigger time, event data) needs to be updated; if the current copy event has ended, in addition to updating some event information of the current copy event, the number of repetitions of the current copy event also needs to be incremented by 1, indicating that an event has started and ended once. However, it should be noted that at this time, it is not necessary to initialize the current copy event because the current copy event has not been sent.

[0028] In an implementation of the first aspect, the event information of the copy event includes an end flag. If the end flag of the current copy event is the third value, it is determined that the previous copy event has not ended. If the end flag is the fourth value, it is determined that the previous copy event has ended; wherein, the end flag is set to the third value when the current copy event is initialized, and is set to the fourth value after the expected end time of the current copy event arrives.

[0029] In the above implementation, by using the value of the end marker, it is possible to quickly and accurately determine whether the previous copy event has ended.

[0030] In one implementation of the first aspect, the method further includes: determining the copy events that have been sent in the storage space according to the event information of the copy event; wherein, the copy events that have been sent refer to the copy events whose corresponding event notification messages have been successfully sent by the event processing device to the event receiving device; destroying the copy events that have been sent.

[0031] In the above implementation, by destroying the sent copy events, the storage areas occupied by them in the storage space can be reallocated to other copy events or used for other purposes, thereby improving the utilization rate of storage resources.

[0032] In a second aspect, an embodiment of the present application provides an event processing device, including: a copy event acquisition module, configured to, after the current event in the event processing device is triggered, acquire a current copy event corresponding to the event type of the current event from the storage space of the event processing device; wherein, at most one copy event of each type of event is stored in the storage space, and the event information of the copy event is determined according to the event information of the event of this type; an event information update module, configured to update the event information of the current copy event by using the event information of the current event.

[0033] In a third aspect, an embodiment of the present application provides a computer program product, including computer program instructions, which, when read and run by a processor, execute the method provided by the first aspect or any possible implementation manner of the first aspect.

[0034] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, on which computer program instructions are stored, which, when read and run by a processor, execute the method provided by the first aspect or any possible implementation manner of the first aspect.

[0035] In a fifth aspect, an embodiment of the present application provides an event processing device, including: a memory and a processor, wherein computer program instructions are stored in the memory, and when the computer program instructions are read and run by the processor, they execute the method provided by the first aspect or any possible implementation manner of the first aspect.

[0036] In a sixth aspect, an embodiment of the present application provides an event processing system, including: at least one event processing device provided in the fifth aspect and an event receiving device, and the event receiving device is configured to receive and process the event notification message generated by the event processing device according to the event information in the copy event that has not been sent. Brief Description of the Drawings

[0037] To more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments of the present application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present application, and thus should not be regarded as a limitation of the scope. For those of ordinary skill in the art, without creative efforts, other relevant drawings can also be obtained based on these drawings.

[0038] Figure 1 Shows an application scenario of the event processing method provided by the embodiments of the present application;

[0039] Figure 2 Shows the flow of the event processing method provided by the embodiments of the present application;

[0040] Figure 3 Shows the possible execution flow of the event sending thread provided by the embodiments of the present application;

[0041] Figure 4 Shows the possible execution flow of the event destruction thread provided by the embodiments of the present application;

[0042] Figure 5 Shows the possible execution flow of the event end timing thread provided by the embodiments of the present application;

[0043] Figure 6 Shows the possible execution flow of the event trigger thread provided by the embodiments of the present application;

[0044] Figure 7 Shows the possible functional modules included in the event processing device provided by the embodiments of the present application;

[0045] Figure 8 Shows the possible structure of the event processing device provided by the embodiments of the present application. Detailed Embodiments

[0046] Figure 1 Shows an application scenario of the event processing method provided by the embodiments of the present application. The function to be realized in this scenario is to notify a mobile phone APP in real time of certain events triggered by a network camera (for example, detecting a moving object in the picture), so that the user of the APP can learn about the occurrence of these events and take corresponding measures.

[0047] Refer to Figure 1, this scenario adopts a publish / subscribe architecture to implement the above functions. The participants include mobile phone 110, server 120, and camera 130. Among them, server 120 includes a registration server and a publishing server, which can be two servers or the registration and publishing functions are integrated in the same server. And there can be one or more cameras 130. The working processes of these participants are briefly described as follows:

[0048] Processes 1 - 2: The APP on mobile phone 110 acts as a subscriber and registers with the registration server through the Internet. The registration parameters include the Token of the APP, the camera ID to be subscribed, communication-related information, etc. Among them, the Token can be the unique identifier of the APP, and a different Token is generated each time the APP is installed, while the ID is the unique identifier of camera 130.

[0049] Internal processing process of camera 130: During the working process, camera 130 will trigger events according to its built-in logic (for example, when a moving object is detected in the picture, a motion detection event is triggered). Camera 130 will put the triggered events into the buffer in the memory, and the sending thread in camera 130 will send the events in the buffer according to the interaction logic with the publishing server.

[0050] Processes 3 - 4: Camera 130 acts as a publisher and publishes a notification message to the publishing server. The message carries the camera ID, event information, etc.

[0051] Internal processing process of server 120: According to the camera ID carried in the message, the publishing server obtains the Tokens and communication information of all subscribers who have subscribed to this ID from the registration server.

[0052] Processes 5 - 6: The publishing server publishes a notification message to all subscribers who have subscribed to this ID according to the communication information. The message carries event information, etc.

[0053] However, through long-term research, the inventor found that Figure 1 the architecture in [ ] has the following problems in the working process: Once the number of events triggered by camera 130 within a short period is too large and the sending thread cannot send these events in time, it will lead to more and more events accumulating in the buffer. However, camera 130 is likely to be an embedded device with very limited memory, which is difficult to meet the demand for caching a large number of events. Or, even if it can meet the demand, it may also cause other functions of camera 130 to malfunction. Further, if the sending thread of camera 130 queues up to send events in the order of event triggering, after a large number of events accumulate, newly triggered events may have to wait for a long time to be sent, resulting in the mobile phone APP not being able to obtain event notifications in real time.

[0054] Possible solutions to the above technical problems may include:

[0055] (1) Control the frequency of events triggered by the camera 130 so that a large number of events are not generated in a short period of time.

[0056] (2) Limit the size of the buffer for storing events. If the number of events exceeds the total number of events that the buffer can accommodate, discard the newly arrived events.

[0057] However, it is difficult to implement solution (1). Sometimes the frequency of event triggering is bound to the business requirements of the APP and cannot be adjusted arbitrarily. In addition, solution (1) cannot completely solve the problem of event sending delay. For example, if the network environment between the camera 130 and the publishing server is poor, resulting in frequent failure of notification messages to be sent, even if the event triggering frequency is not high, event accumulation may still occur, leading to sending delay. In solution (2), it is difficult to determine the size of the buffer. If the buffer is set to be small, a large number of events will be lost, and thus the APP cannot be notified. If the buffer is set to be large, it will result in high memory occupancy, which may affect the operation of other functions of the camera 130. In short, solutions (1) and (2) cannot well solve the above technical problems.

[0058] The event processing method provided by the embodiments of the present application (including its various possible implementation manners) can be, but is not limited to, applied to Figure 1 the camera 130 in

[0059] which is beneficial to improving problems such as excessive memory occupancy, event sending delay, and event loss when a large number of events are triggered, and significantly improves the event processing performance of the camera 130.

[0060] Next, the technical solutions in the embodiments of the present application will be described with reference to the accompanying drawings in the embodiments of the present application. It should be noted that: similar reference numerals and letters denote similar items in the following drawings. Therefore, once an item is defined in one drawing, it does not need to be further defined and explained in subsequent drawings.

[0061] The term "comprising", "including" or any other variant thereof is intended to cover non-exclusive inclusion, such that a process, method, article or apparatus that comprises a series of elements includes not only those elements but also other elements not expressly listed, or elements that are inherent to such process, method, article or apparatus. Without further limitation, an element qualified by the statement "comprising an..." does not exclude the presence of additional identical elements in the process, method, article or apparatus that comprises the element.

[0062] The terms "first", "second", etc. are used only to distinguish one entity or operation from another entity or operation, and cannot be construed as indicating or implying relative importance, nor can it be construed as requiring or implying any actual relationship or order between these entities or operations.

[0063] Figure 2 The flowchart of an event processing method provided by an embodiment of the present application is shown. This method can be but is not limited to being executed by Figure 8 the event processing device therein. For the possible structure of the event processing device, reference can be made to the description of Figure 8 hereinafter. Referring to Figure 2 , the event processing method includes:

[0064] Step S210: After the current event in the event processing device is triggered, obtain the current copy event corresponding to the event type of the current event from the storage space of the event processing device.

[0065] An event processing device generally refers to an electronic device that can trigger an event and process the event. For example, the event processing device can be a camera (such as camera 130), a wearable device, a robot, etc.

[0066] In an event processing device, an event can be understood as a data object that describes a certain phenomenon occurring outside or inside the event processing device. Event triggering can be understood as the process of generating a corresponding event after the event processing device detects a certain phenomenon occurring outside or inside the event processing device, and event processing can be understood as one or more operations performed on the event, such as storage, sending, etc.

[0067] For example, if the event processing device is a camera, if the camera detects a moving object in the picture, it triggers a motion detection event; if the camera detects a pedestrian in the picture, it triggers a human shape event; if the camera detects an object entering a pre-defined area in the picture, it triggers an area intrusion event; if the camera detects an object leaving a pre-defined area in the picture, it triggers a boundary crossing detection event; if the camera is started, it triggers a device online event; if the camera is turned off, it triggers a device offline event, and so on.

[0068] The event processing device can continuously trigger events according to established logic. For each triggered event, the event processing method provided by the embodiments of the present application will be executed. For the sake of elaboration, take the current event as an example. The current event can be understood as any event triggered by the event processing device and has no particularity. The triggering of the current event can be executed in step S210 or before step S210 starts to execute. In the former case, the entity that triggers the event and processes the event (referring to executing steps S210 to S220) may be the same entity, such as an event trigger thread. In the latter case, the entity that triggers the event and processes the event may be two different entities, such as an event trigger thread and an event processing thread.

[0069] Each event has its own event information, which can be understood as the attributes of the event. For example, it may include one or more of the following event information:

[0070] Event type: Represents the type of the event. For example, in the previous examples, the motion detection event and the area intrusion event mentioned are strictly speaking the motion detection type event and the area intrusion type event;

[0071] Trigger time: Represents the moment when the event occurs;

[0072] Event data: Some additional data related to the event, such as the picture that triggers the event, the text description of the event, and other information.

[0073] The duplicate event is a special event, which can be understood as a data object set for each type of event. The duplicate event also has its own event information, and the event information of the duplicate event is determined according to the event information of the ordinary event of the same type as it (referring to the actually triggered event, and similar places will not be repeatedly explained later).

[0074] For example, the duplicate event may include one or more of the following event information:

[0075] Event type: Represents the type of the duplicate event;

[0076] Event data: Represents the additional data of the duplicate event;

[0077] Latest trigger time: Represents the moment when the duplicate event was last triggered;

[0078] Repeat count: Represents the number of times the duplicate event occurs repeatedly; among them, the duplicate event occurs once from the start to the end;

[0079] Start time: Represents the start moment of the duplicate event;

[0080] End time: Represents the end moment of the duplicate event;

[0081] Transmission flag: The value can be a first value (e.g., false) or a second value (e.g., true). The first value indicates that the copy event has not been sent to the event receiving device, and the second value indicates that the copy event has been sent to the event receiving device;

[0082] End flag: The value can be a third value (e.g., false) or a fourth value (e.g., true). The third value indicates that the copy event has not ended, and the fourth value indicates that the copy event has ended.

[0083] Which event information is specifically included in the copy event can be determined according to business requirements. For example, if the information in the copy event is ultimately to be sent to a mobile APP, it can be determined according to the requirements of the mobile APP.

[0084] It can be seen that the event information of the copy event is not a simple copy of the event information of a single ordinary event of the same type, but the result of fusing the event information of several ordinary events of the same type. Or the copy event can also be regarded as the product of merging several ordinary events of the same type according to a certain specific rule. The merging rule depends on business requirements, that is, the information in the copy event after merging is sufficient to replace the ordinary event to execute specific business.

[0085] For example, for a copy event, a significant difference between it and an ordinary event is that the event information may include a start time and an end time, that is, the copy event may last for a period, while the event information of an ordinary event only has a trigger time, and this information is only a moment rather than a period. In the copy event, by extending a moment to a period, on the one hand, it is convenient to merge continuously triggered ordinary events (specific examples will be given later), thus saving storage space, and on the other hand, it is also for some business considerations. For example, after sending the copy event to the mobile APP, the mobile APP can intercept the corresponding video captured by the camera according to the start time and end time of the copy event for the user to observe and analyze.

[0086] Another example is that for the repetition times of the copy event, since it is a statistical information, it is also information that a single ordinary event does not have.

[0087] At most one corresponding copy event of each type of event is saved in the storage space of the event processing device. Among them, the storage space of the event processing device (sometimes simply referred to as the storage space later) can be the volatile and / or non-volatile memory installed in the event processing device, such as the memory of the event processing device. Saving the copy event in the storage space actually means saving the event information of the copy event. For example, these event information can be saved in the form of fields.

[0088] The "at most" in the above "at most save one copy event" can be understood as follows: Logically speaking, for each type of event, a corresponding copy event can be created in the storage space of the event processing device. For example, for a motion detection event, a motion detection copy event can be created, and for a regional intrusion event, a regional intrusion copy event can be created. However, these copy events do not necessarily exist in the storage space under all conditions. For example, if the motion detection event has never been triggered, such a copy event can be temporarily not created. After the motion detection event is actually triggered, a corresponding copy event can be created for it to save storage space. Another example is that if the motion detection event has been triggered and a corresponding copy event has been created, but the motion detection event has not been triggered again for a long time, the storage space occupied by the copy event can be recycled to save storage space, and so on.

[0089] In step S210, the copy event corresponding to the event type of the current event is called the current copy event. To obtain the current copy event, it can be searched from the storage space of the event processing device according to the event type of the current event. For example, if the event type is included in the event information of the copy event, then traverse the copy events in the storage space. If the event type of a certain copy event is the same as the event type of the current event, it means that this copy event is the current copy event.

[0090] Of course, even in some implementation manners, if the event information of the copy event does not include the event type, the current copy event can also be searched from the storage space. For example, if each type of copy event is saved at a fixed address in the storage space and the relationship between the storage address and the event type is known, then according to the event type of the current event, the storage address of the current copy event in the storage space can be located.

[0091] All the above introduced are the cases where the search for the current copy event is successful. At this time, the current copy event can be directly obtained from the storage space. For the case where the search for the current copy event fails, it means that the current copy event has not been saved in the storage space yet. Thus, the current copy event can be created in the storage space, and from the result, the current copy event is also obtained.

[0092] The so-called creation of a copy event can be understood as determining a storage area in the storage space for storing the copy event. For example, this storage area can be applied for from the administrator of the storage space when creating the copy event. Here, the administrator of the storage space can be the operating system of the event processing device or a storage management program running in the operating system, etc. Another example is that when creating the copy event, there is already a storage area that has been previously applied for in the storage space (for example, the area where the destroyed copy event was originally stored. For details on the destruction of the copy event, see the following text). Then, the copy event to be created can be directly associated with this storage area.

[0093] In one implementation, a copy event can be created in advance (for example, before the first event is triggered) in the storage space of the event processing device for each known type of event. In this way, if the copy event is not destroyed (for details on the destruction of the copy event, see the following text), then searching for the current copy event will surely succeed (excluding other external factors that may cause the search to fail). In another implementation, no copy events are created first. Only when a certain type of event is actually triggered will the copy event corresponding to that type of event be created. In this implementation, it is possible for the search for the current copy event to fail. Among them, the processing logic of the former implementation is relatively simple, while the latter implementation is more space-saving. For example, for event types that have never triggered any events, no copy events will be created for them in the storage space.

[0094] Step S220: Update the event information of the current copy event using the event information of the current event.

[0095] If the current copy event is created only in step S210, then step S220 can be understood as initializing the event information of the current copy event using the event information of the current event. When the current copy event is just created, its various event information may be meaningless values or specific values (for example, all 0). So-called initialization is to assign meaningful values to the various event information of the current copy event based on the event information of the current event. In the following text, sometimes the initialization of the event information of the copy event is also simply referred to as the initialization of the copy event.

[0096] For example, if the event information of the copy event includes all the information items mentioned above, the initialization operation may include: setting the event type of the current copy event to the event type of the current event, setting the event data of the current copy event to the event data of the current event, setting the latest trigger time of the current copy event to the trigger time of the current event, setting the repetition count of the current copy event to 1 (because initialization means that the current copy event has started, i.e., it has occurred once), setting the start time of the current copy event to the trigger time of the current event, setting the send flag of the current copy event to the first value, setting the end flag of the current copy event to the third value, and for the end time of the current copy event, it may not be set (because it is not yet possible to determine when the event will end), maintaining its original value (such as 0), or it may also be temporarily set to the expected end time of the current copy event and can be changed if necessary (see the example later). Among them, the expected end time may be the sum of the latest trigger time of the current copy event and the expected duration of the current copy event (which can be a default value, such as 15s, 30s).

[0097] If the current copy event is not created only in step S210, for example, the current copy event can be directly found from the storage space, then step S220 is information update in the narrow sense, that is, using the event information of the current event and combining specific rules to update the current event information of the current copy event to obtain the new event information of the current copy event, or in other words, integrating the event information of the current event into the current copy event, so that the event information of the current copy event can change to a certain extent following the newly triggered event. For example, the latest trigger time of the current copy event can be updated using the trigger time of the current event, and so on. Regarding the above specific rules, they will be elaborated in detail later and will not be expanded here for the time being.

[0098] Note that since initializing the event information of the current copy event and updating the event information of the current copy event are essentially assigning values to each information item that constitutes the current copy event, it is also possible to collectively refer to the two as updating the event information of the current copy event using the event information of the current event.

[0099] Brief summary Figure 2 In the method described above, in this method, since at most one copy event of each type of event is saved in the storage space of the event processing device, this copy event can be considered to integrate the event information of this type of event to a certain extent. Therefore, even if a large number of events are triggered in the event processing device, event accumulation will not occur, that is, not too much storage space will be occupied. Thus, the performance requirements for the event processing device are significantly reduced, and it is beneficial to the normal operation of the event processing device.

[0100] Furthermore, in some implementation manners, the copy event can be sent to a person, program or device (e.g., mobile phone APP) that is concerned about this event. Since the copy event is just a special event (although its event information may be different from that of a normal event), the total number of copy events is small (usually there are not too many event types), and there is no problem of queuing for sending. Therefore, the problem of event sending delay can be greatly improved, and the real-time performance of the event notification process can be enhanced.

[0101] In addition, since the event information of the copy event is continuously updated according to the latest event information (initialization can also be regarded as a kind of update), that is, it always contains the event information of the latest triggered event, the problem that the latest triggered event is lost can be effectively avoided.

[0102] It should be noted that although the event processing method and its possible implementation manners provided in the embodiments of the present application can solve Figure 1 the technical problems in the scenario, it does not mean that the event processing method can only be used in Figure 1 the scenario. For example, in the event processing method provided in the embodiments of the present application, the event processing device can just store the copy event without sending it externally, or even if it sends the copy event externally, it does not necessarily have to adopt Figure 1 the publish / subscribe architecture.

[0103] In some implementation manners, four threads can be used to cooperate to implement the above event processing method, namely an event sending thread, an event destroying thread, an event ending timing thread and an event triggering thread. Their possible execution processes are respectively as Figures 3 to 6 shown. The steps in these processes can all be executed by the event processing device, and will not be specifically described hereinafter.

[0104] The event sending thread is mainly responsible for sending the copy event to an event receiving device (e.g., Figure 1 the server 120 in Figure 1 ). In some scenarios, the event processing device needs to send the copy event to other devices, such as

[0105] the server 120 in Figure 3 . Such devices are collectively referred to as event receiving devices. Figure 3 Referring to

[0106] Step S310: Determine whether the event processing device currently allows sending the copy event.

[0107] If the event processing device currently allows the sending of duplicate events, step S320 is executed. If the event processing device currently does not allow the sending of duplicate events, the process ends. However, it should be noted that as mentioned before, the steps of S310 - S370 are periodically repeated. Therefore, the end of the process does not mean that the sending thread terminates execution. For other situations that cause the process to end in the following text, without special instructions, they can be understood similarly and will not be repeated. Since sending events involves interaction with the event receiving device, it is very likely that the event processing device cannot send duplicate events at any time. For example, for different server platforms, the frequency at which the event processing device is allowed to send events may be different. Thus, locally on the event processing device, corresponding rules can be formulated according to the docked server platform to determine whether it is currently allowed to send duplicate events to the server platform, so that the actual event sending frequency does not exceed the agreed sending frequency with the server. For example, if a certain server platform can receive at most 3 duplicate events sent by a single event processing device within every 10 seconds, then the event processing device can count the number of duplicate events that have been sent in the most recent 10 seconds. If it is less than 3, it is allowed to continue sending duplicate events currently. If it has reached 3, it is not allowed to continue sending duplicate events currently. Or, the event processing device can directly set the event sending thread to wake up 3 times every 10 seconds, and at most only one duplicate event can be sent each time, and so on.

[0108] If the event processing device can always send duplicate events, for example, if the frequency at which the event processing device itself triggers events is low, then step S310 can also be omitted.

[0109] Step S320: Determine whether duplicate events are stored in the storage space of the event processing device.

[0110] If duplicate events are stored in the storage space, all the stored duplicate events are obtained and step S330 is executed. If no duplicate events are stored in the storage space, the process ends. If there are multiple duplicate events stored in the storage space, steps S330 - S370 can be understood as steps to be executed for each of these duplicate events.

[0111] For example, if duplicate events are only created after the actual triggering of the same type of ordinary event, then there may be no corresponding duplicate events in the storage space for some time after the sending thread is started.

[0112] If it can be determined in advance that duplicate events are stored in the storage space of the event processing device, the judgment in step S320 can be omitted, and the duplicate events stored in the storage space can be directly obtained. For example, duplicate events are created in advance for each type of event, and then the sending thread is started. At this time, there must be duplicate events stored in the storage space.

[0113] Step S330: Determine whether the replica event has not been sent yet.

[0114] If the replica event has not been sent yet, execute Step S340; if the replica event has been sent, the sending process of this event ends, but for other replica events obtained in Step S320, further judgment can be made.

[0115] The sending status of the replica event can be determined through the event information of the replica event. For example, if the event information of the replica event includes a sending flag, the sending status of the replica event can be determined by detecting the value of the sending flag of the replica event in the storage space: if the sending flag is the first value, it is determined that the replica event has not been sent; if the sending flag is the second value, it is determined that the replica event has been sent. Among them, the sending flag is set to the first value when the replica event in the storage space is initialized, and is set to the second value after the replica event is sent by the event processing device (Step S370).

[0116] Although the sending status of the replica event can be quickly and accurately determined by setting the sending flag, this is not the only way to determine whether the replica event has been sent. For example, an item of sending time can also be added to the event information of the replica event. The sending time is set to a very large value (such as a time several years later) when the replica event is initialized, and is set to the current time when the replica event is sent by the event processing device. Then, if the current time has not exceeded the sending time of the replica event, it can be determined that the replica event has not been sent; if the current time has exceeded the sending time of the replica event, it can be determined that the replica event has been sent.

[0117] Step S340: Send the replica event to the event receiving device.

[0118] An event notification message can be generated according to the event information of the unsent replica event and sent to the event receiving device, that is, sending the replica event to the event receiving device can refer to sending the event notification message corresponding to the replica event to the event receiving device. As for how the event receiving device processes the event notification message after receiving it, it is not limited. For example, in Figure 1 the publishing server can further notify the mobile APP as a subscriber of the replica event in the form of a message.

[0119] The event notification message may contain all or part of the event information of the replicated event. For example, if the event information of the replicated event includes event type, event data, latest trigger time, repetition count, start time, end time, send flag, and end flag, then the event notification message may contain the event type, event data, latest trigger time, repetition count, start time, and end time. The send flag and end flag are used for local judgment by the event processing device and do not necessarily need to be sent to the event receiving device.

[0120] Among them, when the replicated event has not ended, its end time may be unknown (it can be inferred from the following content that the expected end time of the replicated event can be inferred, but it is not ensured that the replicated event will definitely end at this time). However, since the information of the event has been notified to the event receiving device after sending the replicated event, it is equivalent to that the event has ended. Therefore, the end time field in the event notification message can be set to the current time.

[0121] Step S350: Determine whether the replicated event is sent successfully.

[0122] If the replicated event is sent successfully, execute step S370; if the replicated event is sent failed, execute step S360. Among them, whether the replicated event is sent successfully can be understood as whether the corresponding event notification message is sent successfully. Only when it is determined that the replicated event is sent successfully can the replicated event be regarded as a replicated event that has been sent. Otherwise, the replicated event is still regarded as a replicated event that has not been sent.

[0123] For example, it can be known whether the replicated event is sent successfully according to the return result of the event receiving device. Or, sometimes due to network reasons, the replicated event cannot be sent out, and the event processing device can also judge by itself that the sending fails.

[0124] Step S360: Retry sending the replicated event.

[0125] The so-called retry can be understood as jumping back to step S340 to execute again to increase the probability of successfully sending the replicated event and avoid sending failures caused by accidental factors. Optionally, an upper limit can be set for the number of retries, such as 3 times, 5 times, etc. If the number of retries has reached the upper limit but the sending still fails, it indicates that the event fails to be sent this time, and the sending process of this event can be ended, but it does not affect whether other replicated events are sent successfully.

[0126] Step S360 is optional. When the first sending fails, it is completely possible not to retry and directly end the sending process of this event.

[0127] Step S370: Set the send flag in the replicated event to the second value.

[0128] If the copy event is successfully sent, it indicates that the unsent copy event has now become a sent copy event. Thus, the sending flag in the copy event in the storage space can be synchronously changed to indicate the sending status of the copy event in real time.

[0129] The sending status of the copy event may be used not only in step S330 but also in step S420 of the event destruction thread and step S640 of the event triggering thread, as described in detail later. Step S370 is optional. If it is not determined whether the copy event has been sent through the sending flag, step S370 may not be executed.

[0130] The execution order of the steps of the sending thread is not limited to S310 - S370. For example, step S310 can also be moved to be executed after S330, and so on.

[0131] The event destruction thread is mainly responsible for destroying the copy events in the storage space of the event processing device. Referring to Figure 4 , the event destruction thread can have a fixed working frequency, that is, Figure 4 the steps S410 - S430 in

[0132] Step S410: Determine whether there are copy events saved in the storage space of the event processing device.

[0133] If there are copy events saved in the storage space, obtain all the saved copy events and execute step S420. If there are no copy events saved in the storage space, the process ends. If there are multiple copy events saved in the storage space, steps S420 - S430 can be understood as steps to be executed for each of these copy events. If it can be determined in advance that there are copy events saved in the storage space of the event processing device, the judgment in step S420 can be omitted, and the copy events saved in the storage space can be directly obtained.

[0134] Step S420: Determine whether the copy event has been sent.

[0135] If the copy event has been sent, execute step S430. If the copy event has not been sent, the destruction process of this event ends, but for the other copy events obtained in step S410, further judgment can be made.

[0136] For example, if the event information of a copy event includes a sending flag, it is possible to determine whether the copy event has been sent by detecting the value of the sending flag of the copy event in the storage space: if the sending flag is the first value, it is determined that the copy event has not been sent; if the sending flag is the second value, it is determined that the copy event has been sent.

[0137] Steps S410 - S420 and Figure 3 the steps S320 - S330 in are similar (judging whether a copy event has been sent and judging whether a copy event has not been sent are complementary). For the parts not mentioned in the elaboration, reference can also be made to the relevant content of steps S320 - S330.

[0138] Step S430: Destroy the copy event.

[0139] For a copy event that has been sent, it is equivalent to the event information it contains having been notified to the server. At least at the moment of executing step S430, there is no need to keep this copy event in the storage space anymore, so it can be destroyed, that is, the occupancy of the storage area currently occupied by this copy event is released, so that this storage area can be re - allocated to other copy events for use or for other purposes, thereby improving the utilization rate of storage resources. After the copy event is destroyed, it can be considered that it no longer exists in the storage space.

[0140] Among them, "destroy" can be achieved through various operations: for example, reclaim the area in the storage space occupied by the already - sent copy event. The so - called "reclaim" means returning the right to use the storage area to the manager of the storage space (for example, the operating system of the event - processing device or the storage management program). If you want to use this storage area again, you need to apply to the manager of the storage space again; for another example, empty the area in the storage space occupied by the already - sent copy event. The so - called "empty" means invalidating the data in the storage area (for example, setting all to 0), but without returning the right to use the storage area to the manager of the storage space.

[0141] In comparison, "reclaim" is a more thorough destruction behavior. For the manager of the storage space, "reclaim" enables it to manage more storage areas, so it is more flexible in the allocation of storage areas. However, both applying to the manager for a storage area and returning the storage area to the manager will incur certain overheads; while "empty" actually only destroys the data in the storage area and does not involve interaction with the manager of the storage space, so no corresponding overheads will be generated. However, since the control right of the storage area after "empty" is not in the hands of the manager, it is less flexible in allocation.

[0142] Currently, it is not excluded to destroy events through means other than "recycling" and "emptying". For example, a destruction flag can be added to the event information of the replica event or at the storage space manager to indicate whether the replica event has been destroyed. Once the destruction flag of a certain replica event is set, it indicates that the data in the storage area where the replica event is located can be regarded as invalid, and this storage area can be used for other purposes.

[0143] Furthermore, since at most one replica event of each type is saved in the storage space, if a replica event of a certain type is just sent and then destroyed, and soon after that a normal event of the same type is triggered, at this time a replica event of this type needs to be recreated, which will make the previous destruction behavior seem redundant.

[0144] For example, if the replica event is destroyed by the method of "recycling", then the storage area has just been recycled, and soon after that, a storage area needs to be applied for the newly created replica event. It is better to directly retain the original storage area; if the replica event is destroyed by the method of "emptying", then the data in the storage area has just been emptied, and then the data in the storage area needs to be assigned values (initialize the newly created replica event). It is better to directly assign values to the information items of the sent replica event.

[0145] To improve the above problems, it is also possible to wait for a period of time after the replica event is sent. If no normal event of the same type is triggered, it indicates that the storage area occupied by this replica event is indeed unlikely to be used continuously. At this time, it is more reasonable to destroy it.

[0146] For example, a sending time can be added to the event information of the replica event. The sending time is set to a very large value (for example, a time several years later) when the replica event is initialized, and the sending time is set to the current time when the replica event is sent by the event processing device. The event destruction thread works at a fixed frequency. A judgment can also be added between steps S420 and S430: judge whether the difference between the current time and the sending time of the replica event is greater than a certain time threshold (a positive number). If it is greater than the time threshold, step S430 is executed, otherwise the replica event is not destroyed temporarily. For a certain replica event, if a normal event of the same type is triggered within the time threshold after it is sent, then the replica event will be re-initialized (see step S540 in detail), resulting in the sending time being set to a very large value, so the difference between the current time and the sending time is negative and cannot be greater than the time threshold, and this replica event will not be destroyed.

[0147] The event destruction thread is optional, that is, it is also possible not to destroy the replica events in the storage space.

[0148] The event end timing thread is mainly responsible for recording the end of the event. Refer to Figure 5, the event end timing thread can have a fixed working frequency, that is Figure 5 the steps S510 - S530 in

[0149] Step S510: Determine whether there is a copy event saved in the storage space of the event processing device.

[0150] If there is a copy event saved in the storage space, obtain all the saved copy events and execute Step S520. If there is no copy event saved in the storage space, the process ends. If there are multiple copy events saved in the storage space, Steps S520 - S530 can be understood as steps to be executed for each of these copy events. If it can be determined in advance that there is a copy event saved in the storage space of the event processing device, the judgment in Step S510 can be omitted, and the copy event saved in the storage space can be directly obtained.

[0151] Step S520: Determine whether the copy event has ended.

[0152] If the copy event has ended, execute Step S530; if the copy event has not ended, the end timing process for this event ends this time, but for the other copy events obtained in Step S510, further judgment can be made.

[0153] The end state of the copy event can be determined through the event information of the copy event. For example, if the current time (the time when it reaches Step S520) has not exceeded the expected end time of the copy event, it is determined that the copy event has not ended; if the current time has exceeded the expected end time of the copy event, it is determined that the copy event has ended. Among them, the expected end time of the copy event = the latest trigger time of the copy event + the expected duration of the copy event.

[0154] The expected end time represents the currently estimated end time of the copy event, but it is not necessarily the actual end time of the copy event. It is only the actual end time of the copy event when the expected end time arrives (if the current time has exceeded the expected end time, it indicates that the expected end time has surely arrived). It may change when the expected end time has not arrived because it is impossible to predict in advance how long the copy event will last. The expected duration represents the time that the copy event can last each time a same - type ordinary event is triggered. The expected duration can take a default value, such as 10s, 15s, etc.

[0155] To better understand the calculation formula for the expected end time, the relationships between the start time, end time, expected end time, latest trigger time, and expected duration of the dungeon event are briefly described below:

[0156] As mentioned above, an ordinary event corresponds to only one moment (the trigger time), while a dungeon event corresponds to a time period (from the start time to the end time). The time period during which the dungeon event persists is based on the trigger time of an ordinary event of the same type and is extended by combining specific rules. The specific rules can be:

[0157] When the ordinary event A that causes the initialization of the dungeon event (for example, steps S630 and S650 to be described later) is triggered, the start time and the latest trigger time of the dungeon event are obtained, both being the trigger time of event A. At this time, the expected end time A of the dungeon event = the trigger time of event A + the expected duration of the dungeon event. If no ordinary event of the same type is triggered before the expected end time A arrives, the end time of the dungeon event is the expected end time A. If another ordinary event B of the same type is triggered before the expected end time A arrives, it indicates that the dungeon event is still ongoing, and the latest trigger time of the dungeon event is updated to the trigger time of event B. At this time, the expected end time B of the dungeon event = the trigger time of event B + the expected duration of the dungeon event. If no ordinary event of the same type is triggered before the expected end time B arrives, the end time of the dungeon event is the expected end time B. If another ordinary event C of the same type is triggered before the expected end time B arrives, it indicates that the dungeon event is still ongoing, and the latest trigger time of the dungeon event is updated to the trigger time of event C. At this time, the expected end time C of the dungeon event = the trigger time of event C + the expected duration of the dungeon event, and so on. Note that the above letters A, B, and C are only used to distinguish events triggered at different times and do not have special meanings.

[0158] For example, the expected duration of the dungeon event is 15s. If the above event A is triggered at the 0s, the start time and the latest trigger time of the dungeon event are both 0s, and the expected end time is 15s. Suppose that at the 10s, the above event B is triggered again. Then the latest trigger time of the dungeon event is 10s, and the expected end time of the dungeon event needs to be recalculated to be full 15s starting from 10s, that is, it becomes 25s. Suppose that at the 25s, no new event of the same type is triggered. Then the end time of the dungeon event is 25s, and the dungeon event lasts for 25s in total.

[0159] Generally speaking, the above rules are as follows: for ordinary events that are continuously triggered within a short interval (not exceeding the expected duration), they are all regarded as multiple triggers of the same copy event, or it can also be considered that these ordinary events are merged into one copy event, and the corresponding event information also needs to be integrated.

[0160] In the above method for determining whether a copy event has ended, there are three pieces of information related to the copy event: the latest trigger time, the expected end time, and the expected duration. Among them, the latest trigger time belongs to the event information of the copy event, while the expected end time and the expected duration do not necessarily belong to the event information of the copy event, that is, there is no need to store them in the storage area occupied by the copy event. The reason is that the expected end time of the copy event can be just a temporary variable, only temporarily calculated when determining whether the copy event has ended, and the expected duration of the current copy event can be just a constant. Of course, it is not excluded to use these two pieces of information or one of them as the event information of the current copy event.

[0161] It should be understood that there are other methods to determine whether a copy event has ended by using the event information of the copy event. For example, it is considered that the copy event has ended only after it is confirmed that the copy event has been sent. During this period, no matter how long the trigger time interval of ordinary events of the same type is, it is considered that the copy event is still ongoing, and so on.

[0162] Step S530: Set the end time of the copy event to the expected end time of the copy event, and set the end flag of the copy event to the fourth value.

[0163] If the relationship between the current time and the expected end time of the copy event is used in step S520 to determine whether the copy event has ended, then according to the meaning of the expected end time described above, the end time of the copy event can be set to the expected end time of the copy event in step S530. However, if other methods are used in step S520 to determine whether the copy event has ended, the end time of the copy event can be set to other values, such as the time when the copy event is sent, and so on.

[0164] The end flag of the copy event is an event information indicating whether the copy event has ended. If the end flag of the copy event in the storage space is the third value, it indicates that the copy event has not ended. If the end flag of the copy event in the storage space is the fourth value, it indicates that the copy event has ended. Among them, the end flag of the copy event in the storage space is set to the third value during the initialization of the event information of the copy event (for example, steps S630 and S650 to be described later), and is set to the fourth value in step S530. The end flag of the copy event can be used in step S660 to quickly and accurately determine whether the copy event has ended. See the later description for details. However, the end flag is only an optional event information of the copy event. Even without this information, other methods can be used to determine whether the copy event has ended in step S660.

[0165] In some implementation manners, the end time of the copy event is set only in step S530, and the value during the initialization of the copy event (for example, 0) is maintained at other times. However, in some other implementation manners, when the latest trigger time of the copy event is updated (including during initialization, that is, it can be steps S630, S650, and S680 to be described later), the expected end time of the copy event can be calculated using the updated latest trigger time, and the end time of the copy event is set to the calculated expected end time, that is, the end time always maintains the currently inferred value. At this time, there is no need to set the end time of the copy event in step S530.

[0166] It can be understood that if the event information of the copy event does not include the end flag, there is no need to set it in step S530 either. If the event information of the copy event does not include the end time, there is no need to set it in step S530 either. In short, in different implementation manners, the two setting operations in step S530 can be all executed, only one of them can be executed, or none of them can be executed. The event trigger thread is mainly responsible for triggering events and updating the event information of the copy event according to the triggered events. Refer to Figure 6 , the event sending thread can work according to the trigger frequency of the event, that is Figure 6 steps S610 - S680 in

[0167] Step S610: Trigger the current event.

[0168] The method of triggering an event has been introduced above and will not be repeated here. Note that step S610 is optional. For example, another separate thread can also be responsible for triggering the event and notifying the event-triggering thread to execute the subsequent steps S620 to S680.

[0169] Step S620: Determine whether the current event is a new event.

[0170] If the current event is a new event, execute step S630; if the current event is not a new event, obtain the current copy event from the storage space of the event processing device and execute step S640.

[0171] The "new event" in step S620 means that the copy event of this type of event does not currently exist in the storage space of the event processing device. In other words, if the copy event corresponding to the current event (the current copy event) can be found in the storage space, it means that the current event is not a new event; if the current copy event cannot be found in the storage space, it means that the current event is a new event. The method of searching has been introduced when step S210 was described and will not be repeated here.

[0172] There are two possibilities for the current event to be a new event. One is that the current event has never been triggered before, and the other is that the current event has been triggered before and there was also a corresponding copy event in the storage space, but the copy event was later destroyed. Of course, in some implementation methods where an event destruction thread is not set, there is no second possibility.

[0173] Step S630: Create the current copy event in the storage space of the event processing device and initialize the event information of the current copy event.

[0174] Step S630 has been introduced when step S210 was described. For example, the initialization of the current copy event can include the following operations: set the event type of the current copy event to the event type of the current event, set the event data of the current copy event to the event data of the current event, set the latest trigger time of the current copy event to the trigger time of the current event, set the repeat count of the current copy event to 1, set the start time of the current copy event to the trigger time of the current event, set the send flag of the current copy event to the first value (indicating not yet sent), set the end flag of the current copy event to the third value (indicating not yet ended), and for the end time of the current copy event, it can either maintain its original value (such as 0) or be temporarily set to the expected end time of the current copy event.

[0175] It should be understood that in different implementation manners, according to different event information included in the copy event, the above initialization operations may all be executed, or only a part of them may be executed. For example, if the event information does not include an end flag, there is naturally no need to assign a value to it.

[0176] Note that the creation of the current copy event in step S630 is optional. If corresponding copy events for each type of event have been created in the storage space in advance and the event destruction thread is not set, the current copy event may not be created and can be directly initialized.

[0177] After step S630 is executed, the process can end, as Figure 6 shown. Of course, steps S640, S660, and S680 can also be continued to be executed (in this case, the current copy event must not have been sent and not ended yet), so that the entire processing process of the current event can be simplified.

[0178] Step S640: Determine whether the current copy event has been sent.

[0179] If the current copy event has been sent, step S650 is executed; if the current copy event has not been sent, step S660 is executed. For the case where an event sending thread is set, since the event sending thread updates its sending flag after each copy event is successfully sent (step S370), in step S640, it can be directly determined whether the current copy event has been sent according to the value of the sending flag. If its value is the first numerical value, it indicates that the current copy event has not been sent; if its value is the second numerical value, it indicates that the current copy event has been sent. Of course, even without a sending flag, other methods can be used to determine whether the current copy event has been sent, and step S330 can be referred to.

[0180] The two branches introduced by step S640 can be understood as follows: If the current copy event has not been sent, it means that the event information of this event has not been notified to the server, so only some event information of the current copy event can be updated (for example, the repetition count in step S670, the latest trigger time and event data in step S680); if the current copy event has been sent, it means that the information of this event has been notified to the server, which is equivalent to that this event has ended, so the event information of the current copy event can be re-initialized using the event information of the current event, which is equivalent to starting a new copy event.

[0181] Step S650: Initialize the event information of the current copy event.

[0182] The initialization operation in step S650 is similar to the initialization operation in step S630, so it will not be elaborated again. However, the initialization in step S650 is slightly different from that in step S630. Before the initialization in step S630, since the current replica event has just been created, the values of various event information of the current replica event can be without clear physical meanings (for example, all are set to 0). While before the initialization in step S650, since the current replica event has existed for some time, the values of various event information of the current replica event have clear physical meanings. However, during initialization, these values can be regarded as invalid and re-assigned. Of course, if some values do not need to be re-assigned, such as the event type, they can be skipped.

[0183] Step S650 shows that although the current replica event has been sent, as long as it has not been destroyed, the storage area it occupies can still be used to save new replica events of the same type, that is, the utilization rate of the storage space is improved.

[0184] Steps S640 and S650 are both optional. For example, it is possible that the event processing device does not need to send replica events externally.

[0185] After step S650 is executed, the process can end, as Figure 6 shown. Of course, it can also continue to execute steps S660 and S680 (at this time, the current replica event must not have ended), which simplifies the entire processing process of the current event.

[0186] Step S660: Determine whether the current replica event has ended.

[0187] If the current replica event has ended, then execute step S670; if the current replica event has not ended, then execute step S680.

[0188] The end state of the current replica event can be determined through the event information of the current replica event. The following lists two methods:

[0189] Method 1

[0190] If the current time has not exceeded the expected end time of the current replica event, it is determined that the current replica event has not ended. If the current time has exceeded the expected end time of the current replica event, it is determined that the current replica event has ended. Among them, the expected end time of the current replica event = the latest trigger time of the current replica event (referring to when it reaches step S660) + the expected duration of the current replica event.

[0191] This judgment method is similar to that introduced in step S520 and will not be elaborated again.

[0192] Method 2

[0193] If the event information of the current instance event includes an end flag, it is possible to determine whether the current instance event has ended by detecting the value of the end flag: if the end flag is the third value, it is determined that the current instance event has not ended; if the end flag is the fourth value, it is determined that the current instance event has ended. Among them, the end flag is set to the third value during the initialization of the current instance event, and is set to the fourth value after the expected end time of the current instance event arrives (step S530).

[0194] If method 2 is adopted, it actually directly utilizes the update result of the end flag in the event end timing thread (step S530), simplifying the logic of the event trigger thread. If method 1 is adopted, the event end timing thread may not be set at this time. In addition, method 1 makes a more accurate judgment directly based on the current time and the expected end time of the current instance event. In method 2, whether the judgment result is correct depends on whether the value of the end flag is correct. If the event end timing thread fails to update its end flag in time when the current instance event ends (for example, the working frequency of the event end timing thread is set too low), it is possible that the current instance event has ended, but its end flag has not been updated to the fourth value, which will affect the judgment result in step S660.

[0195] Of course, it is not excluded that there are other ways to judge whether the current instance event has ended besides method 1 and method 2.

[0196] The two branches introduced by step S660 can be understood as follows: if the current instance event has not ended, only some event information of the current instance event needs to be updated (for example, the latest trigger time and event data in step S680), and the event information of the current event is incorporated into the event information of the current instance event; if the current instance event has ended, in addition to updating some event information of the current instance event, the repeat count of the current instance event needs to be incremented by 1, indicating that an event start and end have occurred. However, it should be noted that at this time, it is not necessary to initialize the event information of the current instance event because the current instance event has not been sent, or its event information has not been notified to the server. Initializing it is equivalent to losing the event information.

[0197] Step S670: Increment the repeat count of the current instance event by 1.

[0198] The repeat count of the current instance event indicates how many times the start and end of an event have occurred in total before the current instance event is sent. This event information can be set for business purposes.

[0199] Steps S660 and S670 are both optional. For example, if it is considered that a copy event has ended only after it has been sent, and regardless of how long the triggering time interval of ordinary events of the same type is during this period, it is considered that the copy event is still ongoing, then at this time, determining whether the copy event has ended is equivalent to determining whether the copy event has been sent, that is, steps S660 and S670 can be not executed, and step S640 is directly connected to step S680.

[0200] Step S680: Update the latest triggering time of the current copy event using the triggering time of the current event, and update the event data of the current copy event using the event data of the current event.

[0201] The purpose of step S680 is to incorporate the event information of the current event into the event information of the current copy event. On the one hand, it expands the content of the event information of the current copy event, and on the other hand, it makes the event information of the current copy event always follow the latest event information in whole or in part, so that the latest event information will not be lost.

[0202] Among them, whether to update the event data of the current copy event is optional, either because the information item is not set in the event information at all, or because some types of events may not have corresponding event data. For example, the motion detection event, device online event, and device offline event mentioned above can be without pictures (the picture is the event data), while the humanoid event, area intrusion event, and out-of-bounds detection event can be with pictures. Whether to update the latest triggering time of the current copy event is also optional. For example, if there is no requirement for the latest triggering time in the business requirements, the event information of the copy event can not include the latest triggering time. If neither the latest triggering time nor the event data of the current copy event needs to be updated (or there is no such information at all), then step S680 can also be not executed, or it can be used to update other information in the current copy event.

[0203] The event sending thread, event destroying thread, event end timing thread, and event triggering thread can work independently. However, since these threads will all access the copy events in the storage space, to avoid data out-of-sync problems, it can be specified that only one of these threads can access the copy events in the storage space at the same time. For example, this purpose can be achieved by means of locking.

[0204] Optionally, not all of the above four threads need to be set. For example, if the event handling method does not need to send a copy event, the event sending thread may not be set; if the event handling method does not need to destroy the copy event, the event destruction thread may not be set. In addition, even if all the functions of the above four threads are to be implemented, it is not necessary to split these functions into four threads. For example, they can also be all merged into one thread, or merged into two or three threads. In short, the implementation methods are very flexible.

[0205] Figure 7 shows the possible functional modules included in the event processing device 700 provided by an embodiment of the present application. Refer to Figure 7 , the event processing device 700 includes:

[0206] A copy event acquisition module 710, configured to, after a current event in the event processing device is triggered, acquire a current copy event corresponding to the event type of the current event from the storage space of the event processing device; wherein, at most one copy event of each type of event is stored in the storage space, and the event information of the copy event is determined according to the event information of the event of this type;

[0207] An event information update module 720, configured to update the event information of the current copy event by using the event information of the current event.

[0208] In an implementation manner of the event processing device 700, the copy event acquisition module 710 acquiring a current copy event corresponding to the event type of the current event from the storage space of the event processing device includes: searching for the current copy event from the storage space according to the event type of the current event; if the search for the current copy event is successful, obtaining the current copy event; if the search for the current copy event fails, creating the current copy event in the storage space; wherein, if the search for the current copy event fails, the event information update module 720 updating the event information of the current copy event by using the event information of the current event includes: initializing the event information of the current copy event by using the event information of the current event.

[0209] In an implementation of the event processing device 700, the device further includes: an event sending module, configured to: determine, according to the event information of the duplicate event, the duplicate events that have not been sent in the storage space; wherein, the duplicate events that have not been sent refer to the duplicate events for which the corresponding event notification messages have not been successfully sent by the event processing device to the event receiving device; generate an event notification message according to the event information of the duplicate events that have not been sent, and send the event notification message to the event receiving device; wherein, successfully sending the event notification message indicates that the duplicate events that have not been sent have been sent by the event processing device.

[0210] In an implementation of the event processing device 700, the event information of the duplicate event includes a sending flag, and the event sending module determines the duplicate events that have not been sent in the storage space according to the event information of the duplicate event, including: determining the duplicate events with the sending flag being a first value in the storage space as the duplicate events that have not been sent; wherein, the duplicate events with the sending flag being a second value in the storage space are the duplicate events that have been sent, and when the event information of the duplicate events in the storage space is initialized, the sending flag therein is set to the first value; the event sending module is further configured to: set the sending flag of the newly sent duplicate event to the second value.

[0211] In an implementation of the event processing device 700, the event information of the duplicate event includes an end time and / or an end flag, and the device further includes: an event end processing module, configured to: determine, according to the event information of the duplicate event, the duplicate events that have ended in the storage space; if the event information of the duplicate event includes an end time, set the end time of the duplicate events that have ended; if the event information of the duplicate event includes an end flag, set the end flag of the duplicate events that have ended to a fourth value; wherein, the duplicate events with the end flag being a third value in the storage space are the duplicate events that have not ended, and when the event information of the duplicate events in the storage space is initialized, the end flag therein is set to the third value.

[0212] In an implementation of the event processing device 700, the event information of the duplicate event includes the latest trigger time. The event end processing module determines the duplicate events that have ended in the storage space according to the event information of the duplicate event, including: determining the duplicate events whose expected end time has been exceeded by the current time in the storage space as the ended duplicate events; wherein, the expected end time of the duplicate event is: the latest trigger time of the duplicate event plus the expected duration of the duplicate event; the event end processing module sets the end time of the ended duplicate event, including: setting the end time of the ended duplicate event to the expected end time of the ended duplicate event.

[0213] In an implementation of the event processing device 700, the event information of the duplicate event includes the latest trigger time and / or event data. The event information update module 720 updates the event information of the current duplicate event by using the event information of the current event, including: if it is determined according to the event information of the current duplicate event that the previous duplicate event has not been sent, updating the latest trigger time of the current duplicate event by using the trigger time of the current event, and / or, updating the event data of the current duplicate event by using the event data of the current event; if it is determined according to the event information of the current duplicate event that the previous duplicate event has been sent, initializing the event information of the current duplicate event by using the event information of the current event; wherein, the sent duplicate event refers to the duplicate event that has been sent by the event processing device.

[0214] In an implementation of the event processing device 700, the event information of the duplicate event includes a sending flag. If the sending flag of the current duplicate event is the first value, it is determined that the current duplicate event has not been sent. If the sending flag is the second value, it is determined that the current duplicate event has been sent; wherein, the sending flag is set to the first value when the current duplicate event is initialized, and is set to the second value after the current duplicate event is sent by the event processing device.

[0215] In an implementation of the event processing device 700, the event information of the duplicate event includes the number of repetitions. The event information update module 720 updates the latest trigger time of the current duplicate event by using the trigger time of the current event, and / or updates the event data of the current duplicate event by using the event data of the current event, including: if it is determined according to the event information of the current duplicate event that the current duplicate event has not ended, then updating the latest trigger time of the current duplicate event by using the trigger time of the current event, and / or updating the event data of the current duplicate event by using the event data of the current event; if it is determined according to the event information of the current duplicate event that the current duplicate event has ended, then incrementing the number of repetitions of the current duplicate event by 1, and updating the latest trigger time of the current duplicate event by using the trigger time of the current event, and / or updating the event data of the current duplicate event by using the event data of the current event; wherein, the number of repetitions is set to 1 when the current duplicate event is initialized.

[0216] In an implementation of the event processing device 700, the event information of the duplicate event includes an end flag. If the end flag of the current duplicate event is the third value, it is determined that the current duplicate event has not ended. If the end flag is the fourth value, it is determined that the current duplicate event has ended; wherein, the end flag is set to the third value when the current duplicate event is initialized, and is set to the fourth value after the expected end time of the current duplicate event arrives.

[0217] In an implementation of the event processing device 700, the device further includes: an event destruction module, configured to: determine the duplicate events that have been sent in the storage space according to the event information of the duplicate event; wherein, the duplicate events that have been sent refer to the duplicate events whose corresponding event notification messages have been successfully sent by the event processing device to the event receiving device; destroy the duplicate events that have been sent.

[0218] The event processing device 700 provided in the embodiments of the present application can be used to execute the event processing method provided in the embodiments of the present application. Its implementation principle and the technical effects produced have been introduced in the foregoing method embodiments. For brief description, for the parts not mentioned in the device embodiments, reference can be made to the corresponding content in any of the foregoing method embodiments.

[0219] Figure 8 Shows a possible structure of the event processing device 800 provided in the embodiments of the present application. Refer to Figure 8 , the event processing device 800 includes: a processor 810, a memory 820, and a communication interface 830. These components are interconnected and communicate with each other through a communication bus 840 and / or other forms of connection mechanisms (not shown).

[0220] Among them, the processor 810 includes one or more (only one is shown in the figure), which can be an integrated circuit chip with the ability to process signals. The above-mentioned processor 810 can be a general-purpose processor, including a central processing unit (CPU), a microcontroller unit (MCU), a network processor (NP), or other conventional processors; it can also be a dedicated processor, including a graphics processing unit (GPU), a neural-network processing unit (NPU), a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components. Moreover, when there are multiple processor 810s, a part of them can be general-purpose processors and another part can be dedicated processors.

[0221] The memory 820 includes one or more (only one is shown in the figure), which can be, but is not limited to, a random access memory (RAM), a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), etc.

[0222] The processor 810 and other possible components can access the memory 820, read and / or write the data therein. In particular, one or more computer program instructions can be stored in the memory 820, and the processor 810 can read and run these computer program instructions to implement the event processing method provided by the embodiments of the present application.

[0223] The communication interface 830 includes one or more (only one is shown in the figure), which can be used to communicate directly or indirectly with other devices for data interaction. For example, the event processing device 800 can use the communication interface 830 to interact with the event receiving device. The communication interface 830 can include interfaces for wired and / or wireless communication.

[0224] It can be understood that Figure 8 The structure shown is only schematic, and the event processing device 800 may also include more or fewer components than Figure 8 shown in, or have a configuration different from Figure 8 shown. For example, the event processing device 800 may also include an image acquisition module for acquiring images (including videos), and the images here can be used as the event data mentioned above.

[0225] Figure 8 Each component shown in can be implemented by hardware, software, or a combination thereof. The event processing device 800 may be a physical device, such as a camera (for example, Figure 1 the camera 130 in), a drone, an unmanned ship, a wearable device, a mobile phone, a PC, a server, a robot, etc., or may be a virtual device, such as a virtual machine, a container, etc. Moreover, the event processing device 800 is not limited to a single device, and can also be a combination of multiple devices or a cluster composed of a large number of devices.

[0226] The embodiment of the present application also provides a computer-readable storage medium, on which computer program instructions are stored. When these computer program instructions are read and run by a processor, the event processing method provided by the embodiment of the present application is executed. For example, the computer-readable storage medium can be implemented as Figure 8 the memory 820 in the event processing device 800 in.

[0227] The embodiment of the present application also provides a computer program product, which includes computer program instructions. When these computer program instructions are read and run by a processor, the event processing method provided by the embodiment of the present application is executed.

[0228] The embodiment of the present application also provides an event processing system, which includes an event receiving device and at least one event processing device. Among them, the event receiving device is used to receive and process the event notification message generated by the event processing device according to the event information of the untransmitted copy event. The event receiving device can, but is not limited to, adopt a server, and the event processing device is used to execute the event processing method provided by the embodiment of the present application. The event processing device can, but is not limited to, adopt the Figure 8 structure in. For example, for Figure 1In the server 120 and the camera 130, if the camera 130 can execute the event processing method provided in the embodiments of the present application (for example, the above computer program product is deployed on the camera 130), and the server 120 can receive and process the above event notification message generated by the camera 130, it can be considered that the server 120 and the camera 130 constitute one of the above event processing systems.

[0229] The above are only the embodiments of the present application and are not intended to limit the protection scope of the present application. For those skilled in the art, the present application can have various changes and modifications. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. An event processing method, characterized in that, applied to an event processing device, the method includes: After the current event in the event processing device is triggered, obtain a current copy event corresponding to the event type of the current event from the storage space of the event processing device; wherein, at most one copy event of each type of event is stored in the storage space, and the event information of the copy event is determined according to the event information of the event of this type; Update the event information of the current copy event by using the event information of the current event; The event information of the copy event includes an end time and / or an end flag, and the method further includes: Determine the copy events that have ended in the storage space according to the event information of the copy event; If the event information of the copy event includes an end time, set the end time of the copy event that has ended; If the event information of the copy event includes an end flag, set the end flag of the copy event that has ended to a fourth value; wherein, the copy event with an end flag of a third value in the storage space is an unended copy event, and when the event information of the copy event in the storage space is initialized, the end flag therein is set to the third value; The event information of the copy event includes a latest trigger time and / or event data, and the updating the event information of the current copy event by using the event information of the current event includes: If it is determined according to the event information of the current copy event that the current copy event has not been sent, update the latest trigger time of the current copy event by using the trigger time of the current event, and / or, update the event data of the current copy event by using the event data of the current event; If it is determined according to the event information of the current copy event that the current copy event has been sent, initialize the event information of the current copy event by using the event information of the current event; The event information of the copy event includes a repetition count, and the updating the latest trigger time of the current copy event by using the trigger time of the current event, and / or, updating the event data of the current copy event by using the event data of the current event includes: If it is determined according to the event information of the current copy event that the current copy event has not ended, update the latest trigger time of the current copy event by using the trigger time of the current event, and / or, update the event data of the current copy event by using the event data of the current event; If it is determined according to the event information of the current copy event that the current copy event has ended, increment the repetition count of the current copy event by 1, and update the latest trigger time of the current copy event by using the trigger time of the current event, and / or, update the event data of the current copy event by using the event data of the current event; wherein, the repetition count is set to 1 when the current copy event is initialized.

2. The event processing method according to claim 1, characterized in that, Obtaining a current copy event corresponding to the event type of the current event from the storage space of the event processing device includes: Searching for the current copy event in the storage space according to the event type of the current event; If the search for the current copy event is successful, obtaining the current copy event; If the search for the current copy event fails, creating the current copy event in the storage space; Wherein, if the search for the current copy event fails, updating the event information of the current copy event using the event information of the current event includes: Initializing the event information of the current copy event using the event information of the current event.

3. The event processing method according to any one of claims 1-2, characterized in that the method further includes: Determining the copy events that have not been sent in the storage space according to the event information of the copy event; Generating an event notification message according to the event information of the copy event that has not been sent, and sending the event notification message to an event receiving device; wherein, successfully sending the event notification message indicates that the copy event that has not been sent has been sent by the event processing device.

4. The event processing method according to claim 3, characterized in that the event information of the copy event includes a sending flag, and determining the copy events that have not been sent in the storage space according to the event information of the copy event includes: Determining the copy events with the sending flag being a first value in the storage space as the copy events that have not been sent; wherein, the copy events with the sending flag being a second value in the storage space are the copy events that have been sent, and when the event information of the copy events in the storage space is initialized, the sending flag therein is set to the first value; the method further includes: Setting the sending flag of the newly sent copy event to the second value.

5. The event processing method according to claim 1, characterized in that determining the copy events that have ended in the storage space according to the event information of the copy event includes: Determining the copy events whose expected end time has been exceeded by the current time in the storage space as the copy events that have ended; wherein, the expected end time of the copy event is: the latest trigger time of the copy event plus the expected duration of the copy event; setting the end time of the copy event that has ended includes: Setting the end time of the copy event that has ended to the expected end time of the copy event that has ended.

6. The event processing method according to any one of claims 4-5, characterized in that the method further includes: Determining the copy events that have been sent in the storage space according to the event information of the copy event; Destroying the copy events that have been sent.

7. A computer program product, characterized in that it includes computer program instructions, and when the computer program instructions are read and run by a processor, the method according to any one of claims 1-6 is executed.

8. A computer-readable storage medium, characterized in that Computer program instructions are stored on the computer-readable storage medium. When the computer program instructions are read and executed by a processor, the method according to any one of claims 1-6 is performed.

9. An event processing device, characterized in that it comprises: a memory and a processor, wherein computer program instructions are stored in the memory, and when the computer program instructions are read and executed by the processor, the method according to any one of claims 1-6 is performed.

10. An event processing system, characterized in that it comprises: an event receiving device and at least one event processing device according to claim 9, wherein the event receiving device is configured to receive and process an event notification message generated by the event processing device according to the event information of a copy event not yet sent.

Images