A data processing method, device and electronic equipment
By synchronizing device status through multicast messages between gateways, the network traffic and load issues caused by cloud reliance in smart home systems are resolved, achieving efficient and accurate device status synchronization.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- NINGBO FOTILE KITCHEN WARE CO LTD
- Filing Date
- 2026-02-03
- Publication Date
- 2026-06-23
Smart Images

Figure CN122268696A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of smart home technology, and in particular to a data processing method, apparatus and electronic device. Background Technology
[0002] In smart home systems, gateways and home devices work together to provide smart home services to users. In related technologies, the gateway periodically sends requests to the cloud to obtain the latest status of each home device. This relies on the interaction between the gateway and the cloud, making it susceptible to network conditions (such as network outages) or cloud conditions (such as cloud server instability). Furthermore, constantly sending requests to the cloud not only increases network traffic consumption but also increases the load on the cloud server. Summary of the Invention
[0003] To address at least one of the aforementioned technical problems, this application provides a data processing method, apparatus, and electronic device: According to a first aspect of this application, a data processing method is provided, applied to a target gateway, wherein the target gateway is any gateway within a preset multicast group, the method comprising: Upon obtaining the first current state of the first device, a first record item indicating the first device is determined in the local record set, the first record content associated with the first record item is updated based on the first current state, and the first record item is marked with the first record state. Send a first multicast message indicating the first current state to at least one gateway in the same group, so that the at least one gateway in the same group updates its device state based on the first multicast message. The at least one gateway in the same group consists of the remaining gateways in the preset multicast group excluding the target gateway. Upon receiving a message response from each of the at least one gateway in the same group, the first record entry is marked with a second record status.
[0004] According to a second aspect of this application, a data processing apparatus is provided, configured at a target gateway, the target gateway being any gateway within a preset multicast group, the apparatus comprising: The record item determination module is used to determine, in the case of obtaining the first current state of the first device, a first record item indicating the first device in the local record set, update the first record content associated with the first record item based on the first current state, and mark the first record item with the first record state. A multicast message sending module is used to send a first multicast message indicating the first current state to at least one gateway in the same group, so that the at least one gateway in the same group updates its device state based on the first multicast message. The at least one gateway in the same group consists of the remaining gateways in the preset multicast group except for the target gateway. The record item marking module is used to mark the first record item with a second record status upon receiving a message response returned by each of the at least one gateway in the same group.
[0005] According to a third aspect of this application, an electronic device is provided, including a data processing apparatus as described in the second aspect.
[0006] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this application.
[0007] Implementing this application will have the following beneficial effects: This application provides a cloud-independent device status synchronization solution. Gateways synchronize device status based on multicast messages, thus avoiding the limitations and network traffic consumption associated with gateways periodically sending requests to the cloud to obtain the latest status of each home device. Without a cloud presence, gateways obtain device status both directly and indirectly from other gateways. This shorter device status transmission path improves the efficiency and timeliness of gateway status acquisition and enhances adaptability to multi-device scenarios. Furthermore, during multicast message-based device status synchronization between gateways, the records indicating specific devices in the local record set maintaining device status are marked based on the synchronization progress, which improves the accuracy of device status synchronization between gateways.
[0008] Other features and aspects of this application will become clear from the following detailed description of exemplary embodiments with reference to the accompanying drawings. Attached Figure Description
[0009] The objectives, technical solutions, and beneficial effects of the present invention described above can be clearly obtained through the following detailed description of specific embodiments that enable the implementation of the present invention, in conjunction with the accompanying drawings.
[0010] The same reference numerals and symbols in the accompanying drawings and the specification are used to represent the same or equivalent elements.
[0011] Figure 1 This is a flowchart illustrating a data processing method provided in this application; Figure 2 This is a flowchart illustrating the multicast message received in the response provided in this application; Figure 3This is a schematic diagram illustrating the process of adding a candidate gateway to a preset multicast group provided in this application; Figure 4 This is a block diagram of a data processing apparatus provided in this application. Detailed Implementation
[0012] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.
[0013] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or server that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices.
[0014] Various exemplary embodiments, features, and aspects of this application will now be described in detail with reference to the accompanying drawings. The same reference numerals in the drawings denote elements that have the same or similar functions. Although various aspects of the embodiments are shown in the drawings, they are not necessarily drawn to scale unless specifically indicated otherwise.
[0015] The term “exemplary” as used herein means “serving as an example, embodiment, or illustration.” Any embodiment illustrated herein as “exemplary” is not necessarily to be construed as superior to or better than other embodiments.
[0016] In this document, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent three cases: A alone, A and B simultaneously, and B alone. Furthermore, the term "at least one" in this document means any combination of at least two of any one or more elements. For example, including at least one of A, B, and C can mean including any one or more elements selected from the set consisting of A, B, and C.
[0017] Furthermore, to better illustrate this application, numerous specific details are provided in the following detailed description. Those skilled in the art should understand that this application can be implemented without certain specific details. In some instances, methods, means, components, and circuits well-known to those skilled in the art have not been described in detail in order to highlight the main points of this application.
[0018] Figure 1 This diagram illustrates a flow chart of a data processing method according to an embodiment of this application, such as... Figure 1 As shown, the method includes: S101: Upon obtaining the first current state of the first device, determine the first record item indicating the first device in the local record set, update the first record content associated with the first record item based on the first current state, and mark the first record item with the first record state; In this embodiment, the data processing method provided is executed by a target gateway, which is any gateway within a preset multicast group. Gateways within the preset multicast group can communicate using multicast. It is understood that at least one shared multicast address, such as an IP address, exists. The sending gateway can send UDP (User Datagram Protocol) packets to the multicast address, and the receiving gateway receives the UDP packets by monitoring the multicast address. Furthermore, the multicast range of UDP packets can be limited by setting the TTL (Time-To-Live) to 1 to ensure that UDP packets propagate within the local network segment. Simultaneously, a deduplication mechanism is applied to the propagation of UDP packets to prevent information duplication caused by network loops.
[0019] The first device can be any home appliance in the device set. It should be understood that multiple independent home appliances are connected directly or indirectly via wired or wireless communication to form an interconnected smart home system. The device set consists of multiple independent home appliances. Communication between home appliances often relies on a local area network (LAN). Optional home appliance types can include refrigerators, steam ovens, range hoods, washing machines, air conditioners, microwave ovens, and stereos. Similarly, multiple independent office devices can be connected directly or indirectly via wired or wireless communication to form an interconnected smart office system. The device set consists of multiple independent office devices. Communication between office devices often relies on a local area network (LAN). Optional office device types can include printers, projectors, and shredders. In practical applications, the communication mechanism between gateways based on multicast is established within the LAN. Preset multicast groups can also be part of a smart home or smart office system.
[0020] The target gateway can acquire the first current state through wired or wireless communication with the first device. The target gateway can actively acquire the first current state by sending a request to the first device, or passively acquire the first current state by receiving reports from the first device.
[0021] A gateway can maintain device status through a local record set. The local record set is designed to record the status of each device in a device set. The local record set can consist of at least one record, each consisting of a pair of record items and record content, and each record corresponds to a single device. For a record, the record items indicate a specific device, and the record content characterizes the status of that specific device. The gateway can display the device status maintained through the local record set locally. Device status includes, but is not limited to, on / off status. For example, in a smart refrigerator, device status may also include the temperature status of the refrigerator compartment and the freezer compartment. In a smart speaker, device status may also include volume status and the current operating mode (such as music playback mode or human-computer interaction mode). Compared to the display delays or errors easily caused by pulling device status from the cloud in related technologies, the data processing method provided in this application can support timely and accurate device status display, thus improving the user experience.
[0022] Upon obtaining the first current state of the first device, the target gateway can first determine whether there is a record item in its local record set indicating the first device. If a first record item indicating the first device exists, the target gateway updates the content of the first record item associated with it based on the first current state, and marks the first record item with the first record state. Before the update, the first current state and the state represented by the first record content are different. After the update, the first record content represents the first current state. The first record state can represent a modified state or an exclusive state. By marking the first record item with the first record state, the aim is to reflect that the synchronization of the device state of the first device is in the preparation stage. That is, currently only the target gateway has completed the device state update of the first device, and other gateways in the pre-defined multicast group have not yet completed the device state update of the first device. In practical applications, the first record state, as well as the second and third record states described later, can be based on the MESI protocol. This supports the consistency of the state of the same device in the local record sets of multiple gateways, avoiding data conflicts. At the same time, the problem of concurrent updates can be solved with the help of a timestamp mechanism.
[0023] If no record item indicating the first device exists, a first target record is created. The first target record includes a second record item indicating the first device and second record content representing the first current state; and the second record item is marked with the first record state. Taking into account situations such as the first device being a new device entering the device set, and the device state of the first device being omitted as an old device in the local record set, creating a first target record adapted to the first current state of the first device to update the local record set can improve the timely response to the situation where the first current state of the first device is obtained, and can improve the flexibility of maintaining the device state through the local record set.
[0024] S102: Send a first multicast message indicating the first current state to at least one group gateway, so that the at least one group gateway updates its device state based on the first multicast message, wherein the at least one group gateway consists of the remaining gateways in the preset multicast group excluding the target gateway. In this embodiment, the target gateway sends a first multicast message indicating a first current state to at least one peer gateway, enabling each peer gateway to update its device state based on the first multicast message. Assuming a preset multicast group consists of gateways 1-10, if the target gateway is gateway 1, then at least one peer gateway consists of gateways 2-10. The target gateway can send the first multicast message to at least one peer gateway by sending the first multicast message to at least one shared multicast address. For example, if at least one shared multicast address consists of multicast addresses 1-3, and the target gateway is gateway 1, then at least one peer gateway consists of gateways 2-10. Gateways 2-5 can receive the first multicast message by monitoring multicast address 1, gateways 6-9 can receive the first multicast message by monitoring multicast address 2, and gateway 10 can receive the first multicast message by monitoring multicast address 3. Alternatively, gateways 2-10 can also receive the first multicast message by monitoring the same multicast address. Upon receiving the first multicast message, the gateways in the same group update their device status based on it. For the same-group gateways updating their device status based on the first multicast message, refer to the description of the target gateway updating its device status based on the second multicast message in steps S201-S203 below; further details are omitted here. In practical applications, compared to the cloud infrastructure in related technologies, multicast messages serving device status synchronization are transmitted directly within the local area network, eliminating the need for cloud relay and significantly reducing network latency. To a certain extent, all gateways in the same group can simultaneously receive multicast messages and update their device status, ensuring real-time device status synchronization. For multi-device scenarios, frequent access to the cloud is no longer required, greatly reducing network traffic consumption and cloud server load. This also contributes to the stability of smart home or smart office systems.
[0025] As a possible implementation, before sending the first multicast message indicating the first current state to at least one gateway in the same group, the method may further include the following steps: generating the first multicast message using a first byte indicating the device identifier of the first device, a second byte indicating the first current state, a third byte indicating a timestamp, and a fourth byte indicating a checksum, wherein the checksum is obtained based on the device identifier, the first current state, and the timestamp. When generating the first multicast message, the first byte is allocated to store the device identifier of the first device, the second byte to store the first current state, the third byte to store the timestamp, and the fourth byte to allocate the checksum. By standardizing the first multicast message, it is easier and more accurate for the first multicast message to be used to support applications that update device states.
[0026] A timestamp indicates the time when the first current state of the first device was acquired. Since the target gateway can actively acquire the first current state by sending a request to the first device, or passively acquire it by receiving a report from the first device, the timestamp can be carried in the request response returned by the first device, or it can indicate the time when the target gateway received the request response. Alternatively, the timestamp can be carried in the report from the first device, or it can indicate the time when the target gateway received the report.
[0027] The checksum is derived from the device identifier, the first current state, and the timestamp. If the device identifier, the first current state, and the timestamp are considered as a whole and treated as the original data, the checksum is the transformed result of the original data. This transformation can be achieved using methods such as CRC (Cyclic Redundancy Check) and MD5 / SHA (Hash Functions). The checksum can be used to detect whether the received original data is complete.
[0028] Regardless of whether it's the first, second, third, or fourth byte, each should be considered a byte-level data in the first multicast message, without being restricted to occupying one byte. In practical applications, the multicast message format can be based on a compact binary protocol. The first byte can occupy 4 bytes, the second byte can occupy 2 bytes, the third byte can occupy 8 bytes, and the fourth byte can occupy 2 bytes.
[0029] S103: Upon receiving a message response returned by each of the at least one gateway in the same group, mark the first record item with a second record status.
[0030] In this embodiment, upon receiving message responses from at least one gateway in the same group, the target gateway marks the first record entry with a second record state. Here, "receiving message responses from at least one gateway in the same group" is used as a reference marker indicating that "at least one gateway in the same group has completed the device state update of the first device." The message response can be an acknowledgment notification indicating receipt of the first multicast message, or an update completion notification indicating the first multicast message. The second record state can represent a shared state. By marking the first record entry with the second record state, it aims to reflect that the device state synchronization of the first device has been completed; that is, not only has the target gateway completed the device state update of the first device, but other gateways in the preset multicast group have also completed the device state update of the first device.
[0031] As a possible implementation, considering the possibility of lost UDP packets and the fact that the target gateway may not be aware of every gateway in the same group, the number of gateways in the same group that return the message response within a preset time period can be determined first; then, if the number is greater than the preset number, the first record entry is marked with the second record status. This approach balances the accuracy, efficiency, and adaptability of device status synchronization. The preset time period can be set based on actual feedback. The preset number can be determined based on the total number of at least one associated gateway and a preset coefficient. At least one associated gateway is a gateway in at least one group that has historical interactions with the target gateway, indicating interactions based on multicast messages or group joining requests. The preset coefficient can be set based on actual feedback; it can be an amplifying coefficient (e.g., a preset coefficient of 2) or a reducing coefficient (e.g., a preset coefficient of 0.6).
[0032] As one possible implementation, such as Figure 2 As shown, the method further includes: S201: Upon receiving a second group broadcast message indicating a second current state from a target group gateway, determine whether the local record set contains a record item indicating a second device, wherein the second current state is the current state of the second device, and the target group gateway is any one of the at least one group gateway. S202: If the local record set contains a third record item indicating the second device and the timestamp corresponding to the third record content is earlier than the timestamp corresponding to the second group broadcast message, update the third record content based on the second current state and mark the third record item with the second record state, wherein the third record content is the record content associated with the third record item; S203: If the local record set does not contain a record item indicating the second device, a second target record is created, and a fourth record item is marked with the second record state. The second target record includes the fourth record item indicating the second device and fourth record content characterizing the second current state.
[0033] In contrast to steps S101-S103 where the target gateway is the first to complete the device status update for a specific device, here the target gateway is not the first to complete the update. Correspondingly, while in steps S101-S103 the target gateway was the sender of the multicast message, here the target gateway is the receiver of the multicast message. Regardless of whether the target gateway initiates or collaborates in synchronizing the device status of a specific device, there is a suitable device status synchronization path. Different synchronization paths focus on different aspects, providing guidance for gateways within the preset multicast group to achieve device status synchronization through interaction, thus supporting the orderliness and accuracy of device status synchronization between gateways based on multicast messages.
[0034] Upon receiving a second group broadcast message indicating the second current state from a target group gateway, the target gateway can first determine whether there is a record item in its local record set that indicates the second device.
[0035] If a third record entry exists indicating the second device, and the timestamp corresponding to the third record content is earlier than the timestamp corresponding to the second multicast message, then the third record content is updated based on the second current state, and the third record entry is marked with the second record state. Before the update, the second current state differs from the state represented by the third record content. After the update, the third record content represents the second current state. The timestamp corresponding to the third record content is related to the state represented by the third record content before the update (hereinafter referred to as the historical state). If the target gateway is the first gateway to maintain the historical state, the timestamp corresponding to the third record content can indicate the time when the target gateway acquired the historical state. If the target gateway is not the first gateway to maintain the historical state, the timestamp corresponding to the third record content can be the timestamp carried in the historical multicast message received by the target gateway. The timestamp corresponding to the second multicast message can be the timestamp carried in the second multicast message. It should be noted that the generation of historical multicast messages and the generation of second multicast messages can refer to the generation of first multicast messages, and will not be repeated here. If no record item indicating the second device exists, a second target record is created, which includes a fourth record item indicating the second device and fourth record content representing the second current state; and the fourth record item is marked with the second record state.
[0036] As a possible implementation, the method may further include the following steps: determining a fifth record item in the local record set that indicates a third device, marking the fifth record item with a third record state, wherein the time difference between the timestamp corresponding to the fifth record content and the current time is greater than or equal to a first threshold, and the fifth record content is the record content associated with the fifth record item.
[0037] The timestamp corresponding to the fifth record content is related to the state represented by the fifth record content (hereinafter referred to as the baseline state). If the target gateway is the first gateway to maintain the baseline state, the timestamp corresponding to the fifth record content can indicate the time when the target gateway acquired the baseline state. If the target gateway is not the first gateway to maintain the baseline state, the timestamp corresponding to the fifth record content can be the timestamp carried in the baseline multicast message received by the target gateway. It should be noted that the generation of the baseline multicast message can refer to the generation of the first multicast message, and will not be repeated here. The third record state can represent an invalid state. By marking the fifth record item with the third record state, it is intended to reflect that the baseline state has expired and the device state of the relevant device needs to be reacquired. Accordingly, the record corresponding to the relevant device in the local record set can be deleted. The comparison result between the first threshold and the time difference determines whether to mark the record item as expired. Using the marked record item as the anchor point is beneficial to improving the accuracy and convenience of managing the records containing the record item in the local record set. In practical applications, the first threshold can be 300 seconds, and it can also be adjusted according to actual feedback. In addition, records in the local record set can be managed based on the LRU (Least Recently Used) principle, with a maximum record count of 1000. Meanwhile, boolean device states are stored using bitmaps to achieve cache compression.
[0038] As one possible implementation, such as Figure 3 As shown, the method further includes: S301: Upon receiving a group joining request from a candidate gateway, and the target gateway is a responding gateway determined from the preset multicast group based on preset rules, the local record set is sent to the candidate gateway. S302: Upon receiving a confirmation message from the candidate gateway indicating the receipt of the local record set, send a message to the candidate gateway indicating that the joining of the preset multicast group is complete.
[0039] When a candidate gateway is not in a preset multicast group, for a JOIN request (such as a "JOIN" message) sent by a candidate gateway, if the target gateway is the responding gateway determined from the preset multicast group based on preset rules, the target gateway sends its local record set to the candidate gateway. For a preset multicast group, there exists at least one shared multicast address. When there is only one multicast address, the candidate gateway can send a JOIN request to that address. The target gateway receives the JOIN request by monitoring the multicast address. Preset rules can instruct a gateway to be randomly selected from the preset multicast group as the responding gateway. When there are at least two multicast addresses, the candidate gateway sends JOIN requests to at least two multicast addresses respectively. The target gateway receives the JOIN request by monitoring any of the multicast addresses. Preset rules can instruct a gateway to be randomly selected from the preset multicast group as the responding gateway, or can instruct the gateway with the smallest or largest multicast address bound to the preset multicast group to be the responding gateway. The selection of the responding gateway based on preset rules can be achieved through cooperation among the gateways within the preset multicast group.
[0040] If the target gateway receives a "READY" message (indicating acceptance of the local record set) from the candidate gateway, the target gateway sends a "Joining Complete" message (indicating completion of joining the preset multicast group) to the candidate gateway. Sending the local record set is equivalent to allowing the candidate gateway to also maintain the device state. Sending the local record set constitutes an offer. Sending the "Acknowledgment" message indicates that the candidate gateway agrees to maintain the device state through the local record set. Sending the "Acknowledgment" message indicates a commitment. The "Joining Complete" message (indicating completion of joining the preset multicast group) informs the candidate gateway that it has joined the preset multicast group. The candidate gateway can bind a multicast address while receiving and storing the local record set. When there are at least two multicast addresses, the bound multicast address can be any one of the at least two multicast addresses.
[0041] This provides the business logic for candidate gateways to join a preset multicast group. By standardizing the selection of responding gateways, the sending of local record sets as offers, and the receiving of response messages as acceptances, the process of candidate gateways joining the group is made more orderly, and the execution of the joining process does not have too much impact on the operation of the original gateways in the preset multicast group.
[0042] As one possible implementation, the target gateway communicates with at least one associated gateway based on a preset liveness detection mechanism. The at least one associated gateway is a gateway within the at least one group of gateways that has historical interactions with the target gateway. These historical interactions indicate interactions based on multicast messages or group join requests. The method further includes: If the time difference between the current time and the time when the associated gateway was last received is greater than or equal to a second threshold, the associated gateway is determined to be an abnormal gateway.
[0043] Communication based on a preset liveness detection mechanism can be heartbeat communication. If the time interval between the current time and the time of the last reported message from the associated gateway exceeds a second threshold, it indicates a communication interruption between the target gateway and the associated gateway, and the associated gateway is offline. The reported content from the associated gateway can be an agreed-upon heartbeat packet or a multicast message. If the target gateway and the associated gateway have agreed on periodic heartbeat packet reporting, then if no heartbeat packet is received for more than a preset number of periodic intervals, it can be determined that the communication with the associated gateway is interrupted. For example, if the associated gateway periodically reports heartbeat packets to the target gateway at 60-second intervals, and the target gateway does not receive a heartbeat packet for more than 3 periodic intervals, it is determined that the communication with the associated gateway is interrupted and the associated gateway is offline. In this case, the associated gateway may be faulty, such as no longer supporting device status maintenance. Timely identification of the associated gateway as an abnormal gateway facilitates timely repair of the associated gateway, thereby ensuring the effectiveness of device status synchronization between gateways.
[0044] In practical applications, associated gateways identified as abnormal gateways can be removed from the preset multicast group, thus removing them from the group. Correspondingly, the associated gateway can be unbound from its original multicast address. If the repaired associated gateway needs to rejoin the preset multicast group, refer to steps S301-S302 above; details are omitted here. After being removed from the preset multicast group, the associated gateway can either retain its local record set or clear it. If the local record set (hereinafter referred to as the first set) is retained, and the gateway rejoins the preset multicast group after being repaired, the first set can be updated based on the second set by comparing the timestamps corresponding to the record content of the same device when receiving the local record set (hereinafter referred to as the second set) sent by the responding gateway. Alternatively, the group joining request can also carry the reference time when the associated gateway was removed from the preset multicast group, as well as characteristic information indicating rejoining. The responding gateway can determine at least one candidate record from the local record set based on the reference time and send at least one candidate record as an offer to the associated gateway. The timestamps corresponding to the record content in the candidate records are later than the reference time. The associated gateway can update the first set based on at least one candidate record. The application of timestamps corresponding to the recorded content ensures the stability of device status synchronization between gateways within a smart home or smart office system, even in dynamic environments where gateways frequently join or leave, thus supporting the high availability of the smart home or smart office system.
[0045] As can be seen from the technical solutions provided in the embodiments of this application above, this application provides a device status synchronization solution that does not rely on the cloud. Gateways synchronize device status based on multicast messages, thus avoiding the limitations and network traffic consumption caused by "gateways periodically sending requests to the cloud to obtain the latest status of each home device." Without the cloud, gateways obtain device status both directly and indirectly from other gateways. The shorter device status transmission path improves the efficiency and timeliness of gateways obtaining device status and enhances adaptability to multi-device scenarios. Furthermore, when synchronizing device status between gateways based on multicast messages, the records indicating specific devices in the local record set maintaining device status are marked with status based on the synchronization progress, which improves the accuracy of device status synchronization between gateways.
[0046] This application also provides a data processing apparatus, such as... Figure 4 As shown, the data processing device 40 is configured at a target gateway, which is any gateway within a preset multicast group. The data processing device 40 includes: The record item determination module 401 is used to determine, in the local record set, a first record item indicating the first device when the first current state of the first device is obtained, update the first record content associated with the first record item based on the first current state, and mark the first record item with a first record state, wherein the first current state is different from the state represented by the first record content. The multicast message sending module 402 is used to send a first multicast message indicating the first current state to at least one group gateway, so that the at least one group gateway updates its device state based on the first multicast message. The at least one group gateway consists of the remaining gateways in the preset multicast group except for the target gateway. The record item marking module 403 is used to mark the first record item with a second record status when receiving a message response returned by each of the at least one gateway in the same group.
[0047] In some embodiments, the apparatus further includes: The first target record creation module is used to create a first target record when the local record set does not contain a record item indicating the first device. The first target record includes a second record item indicating the first device and second record content characterizing the first current state. A first marking module is used to mark the second record item according to the first record state.
[0048] In some embodiments, the apparatus further includes: The multicast message generation module is used to generate the first multicast message with a first byte indicating the device identifier of the first device, a second byte indicating the first current state, a third byte indicating the timestamp, and a fourth byte indicating the checksum, wherein the checksum is obtained based on the device identifier, the first current state, and the timestamp.
[0049] In some embodiments, the apparatus further includes: The gateway number determination module is used to determine the number of gateways in the same group that return the message response within a preset time period; The second marking module is used to mark the first record item with the second recording state when the number is greater than a preset number.
[0050] In some embodiments, the apparatus further includes: The judgment module is used to determine whether the local record set contains a record item indicating the second device when a second group broadcast message indicating the second current state is sent by a target group gateway. The second current state is the current state of the second device, and the target group gateway is any one of the at least one group gateway. The first synchronization module is configured to update the third record content based on the second current state, and mark the third record item with the second record state, when the local record set contains a third record item indicating the second device and the timestamp corresponding to the third record content is earlier than the timestamp corresponding to the second group broadcast message, wherein the third record content is the record content associated with the third record item; The second synchronization module is configured to create a second target record when the local record set does not contain a record item indicating the second device, and to mark a fourth record item with the second record status. The second target record includes the fourth record item indicating the second device and fourth record content characterizing the second current status.
[0051] In some embodiments, the apparatus further includes: The second marking module is used to determine the fifth record item indicating the third device in the local record set, mark the fifth record item with the third record status, and the time difference between the timestamp corresponding to the fifth record content and the current time is greater than or equal to the first threshold. The fifth record content is the record content associated with the fifth record item.
[0052] In some embodiments, the apparatus further includes: The offer sending module is used to send the local record set to the candidate gateway when it receives a group joining request sent by a candidate gateway, and the target gateway is a response gateway determined from the preset multicast group based on preset rules; The commitment response module is used to send a message indicating that the joining of the preset multicast group is complete to the candidate gateway when it receives a reception confirmation message from the candidate gateway indicating the local record set.
[0053] In some embodiments, the target gateway communicates with at least one associated gateway based on a preset liveness detection mechanism. The at least one associated gateway is a gateway in the at least one group of gateways that has historical interactions with the target gateway. The historical interactions indicate interactions based on multicast messages or interactions based on group joining requests. The apparatus further includes: The abnormal gateway determination module is used to determine that the associated gateway is an abnormal gateway if the time difference between the current time and the time when the report was last received from the associated gateway is greater than or equal to a second threshold.
[0054] In practical applications, a target gateway can include the following three modules: a multicast communication module, a state cache module, and a MESI protocol application module. The multicast communication module is responsible for sending and receiving multicast messages. The state cache module is responsible for maintaining device status through a local record set. The MESI protocol application module is responsible for marking record items based on the MESI protocol.
[0055] It should be noted that the apparatus and method embodiments described in the device embodiments are based on the same inventive concept.
[0056] This application also provides an electronic device, including the data processing apparatus described above.
[0057] Electronic devices may also include a memory and a processor, wherein the memory stores a computer program that is loaded and executed by the processor to implement the methods described above.
[0058] It should be noted that the devices and methods described in the device embodiments are based on the same inventive concept.
[0059] This application also provides a computer-readable storage medium storing a computer program that is loaded and executed by a processor to implement the above-described method.
[0060] For example, computer storage media may be random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other solid-state storage technologies, high-density digital video discs (DVDs) or other optical storage, magnetic tape cassettes, magnetic tapes, disks, or other magnetic storage devices. Of course, those skilled in the art will understand that computer storage media are not limited to the above-mentioned types.
[0061] This application also provides a computer program product, which includes a computer program that is loaded and executed by a processor to implement the above-described method.
[0062] The computer program described above can be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages. Programming languages include object-oriented programming languages—such as Smalltalk, C+, etc.—and conventional procedural programming languages—such as the "C" language or similar programming languages. The computer program can execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), can execute the computer program to implement various aspects of this application by utilizing the state information of the computer program.
[0063] The embodiments described above are merely examples of several implementations of the present invention, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these modifications and improvements all fall within the scope of protection of the present invention.
Claims
1. A data processing method, characterized in that, Applied to a target gateway, which is any gateway within a preset multicast group, the method includes: Upon obtaining the first current state of the first device, a first record item indicating the first device is determined in the local record set, the first record content associated with the first record item is updated based on the first current state, and the first record item is marked with the first record state. Send a first multicast message indicating the first current state to at least one gateway in the same group, so that the at least one gateway in the same group updates its device state based on the first multicast message. The at least one gateway in the same group consists of the remaining gateways in the preset multicast group excluding the target gateway. Upon receiving a message response from each of the at least one gateway in the same group, the first record entry is marked with a second record status.
2. The method according to claim 1, characterized in that, Before sending the first group broadcast message indicating the first current state to at least one peer gateway, the method further includes: If no record item indicating the first device exists in the local record set, a first target record is created. The first target record includes a second record item indicating the first device and second record content characterizing the first current state. The second record item is marked with the first record status.
3. The method according to claim 1 or 2, characterized in that, Before sending the first group broadcast message indicating the first current state to at least one peer gateway, the method further includes: The first multicast message is generated using a first byte indicating the device identifier of the first device, a second byte indicating the first current state, a third byte indicating the timestamp, and a fourth byte indicating the checksum, wherein the checksum is obtained based on the device identifier, the first current state, and the timestamp.
4. The method according to claim 1 or 2, characterized in that, The method further includes: Determine the number of gateways in the same group that return the message response within a preset time period; If the number is greater than a preset number, the first record item is marked with the second record status.
5. The method according to claim 1, characterized in that, The method further includes: Upon receiving a second group broadcast message indicating a second current state from a target group gateway, it is determined whether the local record set contains a record item indicating a second device, where the second current state is the current state of the second device, and the target group gateway is any one of the at least one group gateways. If the local record set contains a third record item indicating the second device, and the timestamp corresponding to the third record content is earlier than the timestamp corresponding to the second group broadcast message, the third record content is updated based on the second current state, and the third record item is marked with the second record state, wherein the third record content is the record content associated with the third record item; If no record item indicating the second device exists in the local record set, a second target record is created, and a fourth record item is marked with the second record status, the second target record including...
6. The method according to claim 1, characterized in that, The method further includes: A fifth record item indicating a third device is determined in the local record set. The fifth record item is marked with a third record status. The time difference between the timestamp corresponding to the fifth record content and the current time is greater than or equal to a first threshold. The fifth record content is the record content associated with the fifth record item.
7. The method according to claim 1, characterized in that, The method further includes: Upon receiving a group joining request from a candidate gateway, and if the target gateway is a responding gateway determined from the preset multicast group based on preset rules, the local record set is sent to the candidate gateway. Upon receiving a confirmation message from the candidate gateway indicating the receipt of the local record set, a message indicating the completion of joining the preset multicast group is sent to the candidate gateway.
8. The method according to claim 1, characterized in that, The target gateway communicates with at least one associated gateway based on a preset liveness detection mechanism. The at least one associated gateway is a gateway within the at least one group of gateways that has historical interactions with the target gateway. These historical interactions indicate interactions based on multicast messages or group join requests. The method further includes: If the time difference between the current time and the time when the associated gateway was last received is greater than or equal to a second threshold, the associated gateway is determined to be an abnormal gateway.
9. A data processing apparatus, characterized in that, Configured on a target gateway, wherein the target gateway is any gateway within a preset multicast group, the device includes: The record item determination module is used to determine, in the case of obtaining the first current state of the first device, a first record item indicating the first device in the local record set, update the first record content associated with the first record item based on the first current state, and mark the first record item with the first record state. A multicast message sending module is used to send a first multicast message indicating the first current state to at least one gateway in the same group, so that the at least one gateway in the same group updates its device state based on the first multicast message. The at least one gateway in the same group consists of the remaining gateways in the preset multicast group except for the target gateway. The record item marking module is used to mark the first record item with a second record status upon receiving a message response returned by each of the at least one gateway in the same group.
10. An electronic device, characterized in that, Includes the data processing apparatus as described in claim 9.