CN115470011A

CN115470011A - Message format indicator for resource constrained devices

Info

Publication number: CN115470011A
Application number: CN202110861395.4A
Authority: CN
Inventors: A.科森蒂诺; P.安蒂诺里
Original assignee: Red Hat
Current assignee: Red Hat
Priority date: 2021-06-10
Filing date: 2021-07-29
Publication date: 2022-12-13
Also published as: EP4102367A1; US20220400158A1

Abstract

Systems and methodologies are generally described for message format communication between resource constrained devices. In some examples, a first message sent by an edge computing device may be received. It may be determined that the first message includes a first data format identifier. It may be determined that the first message includes a first data format patch. It may be determined that the first data format identifier was previously stored in association with the first data format in the data structure. In various examples, the first data format may be modified using a first data format patch to generate a first modified data format. The first modified data format may be stored in the data structure in association with the first data format identifier. In some examples, the payload of the first message may be read using the first modified data format.

Description

Message format indicator for resource constrained devices

Technical Field

The present disclosure relates generally to messaging protocols used in computer communication systems.

Background

For example, state transition (REST) Application Programming Interfaces (APIs) use a synchronous communication paradigm in which messages are sent and responses are awaited before a new request is made. REST API calls are often referred to as "synchronous" API calls, indicating that code execution and user interaction cease until the call returns the requested information. Other messaging architectures may be asynchronous because code execution and/or user interaction need not stop waiting for a response. Event Driven Architectures (EDA) employ asynchronous communication. In EDA, messages are sent by a "publisher" (the entity that generates the data) to a message broker. The message broker may be a framework that stores messages and delivers messages to "subscribers" (applications that have registered to receive particular messages from particular publishers). The various techniques described herein may generally refer to messaging protocols, whether synchronous or asynchronous.

Disclosure of Invention

The present disclosure provides new and novel systems, methods, and apparatus for updating and/or identifying message formats in a message-based computer communication architecture. In one example, an apparatus may include non-transitory computer-readable memory in communication with at least one processor. In some further examples, the apparatus may include a receiver to receive a message. The non-transitory computer-readable memory may store instructions that, when executed by the at least one processor, are configured to receive, by the receiver, a first message sent by the edge computing device. In some further examples, the instructions may be further configured to determine that the first message includes a first data format identifier. In various examples, the instructions may be further configured to determine that the first message includes a first data format patch. In some other cases, the instructions may be further configured to determine that the first data format identifier was previously stored in a data structure associated with the first data format. In other examples, the instructions may be further configured to modify the first data format using the first data format patch to generate a first modified data format. In a further example, the instructions may be configured to store the first modified data format in the data structure in association with the first data format identifier. In some further examples, the instructions may be further configured to read a payload of the first message using the first modified data format.

In another example, a method of updating a message format can include receiving a first message sent by an edge computing device. In some examples, the method may further include determining that the first message includes a first data format identifier. In some examples, the method may further include determining that the first message includes a first data format patch. In other examples, the method may include determining that the first data format identifier was previously stored in the data structure in association with the first data format. In some further examples, the method may include modifying the first data format using the first data format patch to generate a first modified data format. In other examples, the method may include storing the first modified data format in a data structure in association with a first data format identifier. In some cases, the method may include reading a payload of the first message using the first modified data format.

In yet another example, a method of providing an updated message format may include establishing a communication channel with a receiver device. In some examples, the method may include generating a first message of a first type. In some examples, the first message may include a first data format definition and a first data format identifier associated with the first data format definition. In various examples, the method may include transmitting a first message to a receiver device using a communication channel. In some examples, the method may include generating a second message of the first type. In some cases, the second message may include the first data format identifier and the patch. In various instances, the patch may include executable instructions effective to modify the first data format definition to generate a first modified data format definition. In some examples, the method may include transmitting a second message of the first type to the receiver device using the communication channel.

Additional features and advantages of the disclosed methods, apparatus, and/or systems are described in, and will be apparent from, the following detailed description and the accompanying drawings.

Drawings

Fig. 1 is a block diagram of a computer messaging architecture, according to various examples of the present disclosure.

Fig. 2 is a block diagram illustrating updating of a message data format by a receiver device, according to various examples of the present disclosure.

Fig. 3 is a flow chart illustrating an example process of updating a message format by a receiver device according to an example of the present disclosure.

Fig. 4 is a flow chart illustrating an example of a message format for providing updates by a sender device according to an example of the present disclosure.

Fig. 5A and 5B illustrate a flow diagram of an example of message data format communication between a sender device and a receiver device, in accordance with various aspects of the present disclosure.

Fig. 6 illustrates a flow diagram of an example of determining data formats for different types of messages in accordance with various aspects of the disclosure.

Fig. 7 is a block diagram of message data format communication between an edge computing device and another computing device, according to an example of the present disclosure.

Detailed Description

Many applications and/or computer systems communicate using a messaging architecture in which messages of a agreed-upon format are sent between a sender and a receiver. However, the format may change over time for various reasons. For example, software updates may occur, system integration updates may occur, new events may occur that require updating the data format to represent the events in the message payload, and so on. An example messaging architecture is described in detail below.

In various examples, a data format (e.g., data defining the format) may be specified in the payload of each message sent between the sender and the receiver so that the receiver may directly determine the data format in order to correctly parse the message payload. In such implementations, when the data format is updated, the updated format may be specified in the message payload. However, sending a data format with each message results in larger message size and increased resource consumption. This is particularly problematic for edge computing devices that may be resource constrained. For example, the edge computing device may have minimal processing power, may have limited bandwidth, and/or may be battery powered. In such edge computing devices, providing a data format with each message may result in faster battery life drain and/or may result in increased CPU usage. The edge calculation will be described in detail below.

In various examples described herein, a sender (e.g., a device and/or application sending a message) may send a full data format definition only once per messaging session, rather than sending the full data format definition with each message. For example, the sender may send the full data format definition once with the data format identifier data at the beginning of the messaging session. Thereafter, if the messages are formatted according to the same data format, the transmitter may only transmit the data format identifier without including the full data format definition in the payload of each message. The receiver may use the data format identifier to look up a data format definition extracted from an earlier message and stored in a data structure associated with the data format identifier.

Further, when the data format is updated, the transmitter may transmit patch data including executable instructions to configure to modify the data format identifier of the previous data format definition and the related data format definition. The receiver may detect the patch included in the message and may use the data format identifier to look up the appropriate data format definition to apply the patch. The receiver may modify the data format definition using the patch and may discard the previous version of the data format definition. Thereafter, when the message includes the associated data format identifier, the modified data format definition may be used to read the message.

In edge computing systems, computing resources are typically provided on different tiers and different geographically distributed nodes. In such systems, it may be advantageous to deploy different computing resources at different levels of the edge network in order to optimize computing footprint and/or performance. Deploying computing services across multiple clusters in an edge network may allow for more efficient use of computing resources and may provide better service and/or lower latency relative to deployment within a single centralized cluster. However, devices located at the edge of such systems (so-called "edge" devices) are remote from the data center of the architecture, typically resource-constrained devices. For example, the edge computing device may include a battery-powered sensor, an internet of things device that includes minimal computing hardware, and so forth. Minimization of the computational load and/or power consumption of such devices is often highly preferred. Accordingly, power consumption, message size, latency, and/or CPU usage may be reduced using the various techniques described herein for updating and/or determining message format data.

Examples of messaging architectures include asynchronous event driven architectures and synchronous messaging protocols. The various techniques described herein for modifying and/or determining the format of message data may be used in any messaging protocol. In an EDA, the entity that generates the data is called a "publisher" and the receivers/consumers of these data are called "subscribers". The communication in the EDA is referred to as asynchronous because the publisher does not need to wait for a response from any subscriber before generating/publishing the additional data. In contrast, in a synchronous messaging architecture such as that provided by the REST API, the sender waits for a response from the recipient before sending additional data.

EDAs typically employ an architecture called a "message broker" that receives messages (data) from publishers and delivers messages to subscribers who have registered to receive such messages. Examples of message brokers include RabbitMQ, apache Kafka, JBoss Messaging, solace, and so forth. Thus, the publisher may be data generation software/hardware that sends messages to the message broker. For example, the publisher may be an intelligent thermostat that sends temperature data to the message broker, a social media network that sends new subscriber data to the message broker, an intelligent refrigerator that sends data to the message broker about food stored in the refrigerator, and so on. The publisher may be any type of application and/or embedded system that uses EDA to generate and send data. A subscriber may be an application that connects to a message broker, exhibits interest in a certain type of message (e.g., a message assigned to a particular "topic"), and maintains a connection with the message broker so that the message broker can push the message to the subscriber. Various other messaging protocols may send messages in a point-to-point manner from a sender device directly to a receiver device without the need for intermediate devices.

A message is data sent between two devices and/or applications. For example, a message may be sent from a sender device to a receiver device. In another example, a message may be sent by a publisher to a message broker and then pushed by the message broker to an associated subscriber (e.g., a receiver). The content of the message may be any data. Such messages are often described as events or commands. Event communicates facts (e.g., temperature detected by a thermostat), while command provides executable instructions to cause the subscriber application to take a particular action.

Various different protocols may be used to send messages from a sender. Examples of such protocols may include, but are not limited to, message Queue Telemetry Transport (MQTT), restricted application protocol (CoAP), advanced Message Queue Protocol (AMQP), hypertext transfer protocol (HTTP), and the like. Thus, an asynchronous Application Programming Interface (API) (e.g., asyncAPI) may be similar to a synchronous API (e.g., openAPI), but may include a different data format. In various illustrative examples used herein, EDA is described. However, the various data format modification and/or identification techniques described herein are applicable to any messaging architecture, whether synchronous or asynchronous.

Fig. 1 is a block diagram of a system 100 including a computer messaging architecture 124, according to various examples of the present disclosure. The messaging fabric 124 may be implemented using software, hardware, and/or some combination thereof. In various examples, the messaging fabric 124 can include one or more senders 121 and one or more receivers 123. The sender 121 may be hardware and/or software (e.g., an application) that may send messages to the receiver 123 via the network 104. Fig. 1 depicts example components that may be included in various implementations of a transmitter 121 and/or a receiver 123. For example, the transmitter 121 and/or receiver 123 may include one or more physical hosts, including physical host 110A. Physical host 110A, in turn, may include one or more physical processors (e.g., CPU 112A) communicatively coupled to one or more memory devices (e.g., MDs 114A-B) and one or more input/output devices (e.g., I/O116A). As used herein, the one or more physical processors 112A refer to devices capable of executing instructions encoding algorithms, logic, and/or I/O operations. In one illustrative example, a processor may follow a von Neumann architecture model and may include an Arithmetic Logic Unit (ALU), a control unit, and a plurality of registers. In one example, the processor may be a single-core processor that is typically capable of executing one instruction (or processing a single instruction pipeline) at a time, or a multi-core processor that may execute multiple instructions and/or threads simultaneously. In another example, the processor may be implemented as a single integrated circuit, two or more integrated circuits, or may be a component of a multi-chip module (e.g., where individual microprocessor die are included in a single integrated circuit package, thus sharing a single socket). A processor may also be referred to as a central processing unit ("CPU").

As discussed herein, memory devices 114A-B refer to volatile or non-volatile memory devices, such as RAM, ROM, EEPROM, or any other device capable of storing data. In one example, the memory device 114A may be a persistent storage device, such as a hard disk drive ("HDD"), a solid state drive ("SSD"), and/or a persistent memory (e.g., a non-volatile dual in-line memory module ("NVDIMM"). The memory devices 114A-B may additionally include data replication to prevent data loss due to failure in any one of the devices.

In one example, physical host 110A may run one or more isolated guests, such as VM155, which in turn may host additional virtual environments (e.g., VMs and/or containers). In one example, the containers (e.g., storage container 160, service containers 150A-B) may be isolated customers using any form of operating system level virtualization, e.g.,

a container, a chroma,

-VServer、FreeBSD Jails、

Container (SRP), VMware

And the like. The storage container 160 and/or the service containers 150A-B may run directly on a host operating system (e.g., host operating system 118) or in another layer of virtualization, such as in a virtual machine (e.g., VM 155). In one example, containers performing unified functions can be grouped together (e.g., in a cluster of containers deployed together)

Container set (pod). In one example, a given service may require deployment of multiple VMs, containers, and/or container sets at multiple physical locations. In one example, VM155 may be a VM executing on physical host 110A.

The transmitter 121 and/or receiver 123 may run one or more VMs (e.g., VM 155) by executing a software layer (e.g., hypervisor 120) above the hardware and below the VM155, as schematically shown in fig. 1. In one example, the hypervisor 120 may be a component of a respective host operating system 118 executing on the physical host 110A, e.g., implemented as a kernel-based virtual machine function of the host operating system 118. In another example, the hypervisor 120 may be provided by an application running on the host operating system 118A. In one example, the hypervisor 120 may run directly on the physical host 110A without requiring an operating system under the hypervisor 120. Hypervisor 120 may virtualize the physical layer, including processors, memory, and I/O devices, and present the virtualization as a device to VM155, including virtual central processing unit ("VCPU") 190A, virtual memory device ("VMD") 192A, virtual input/output ("VI/O") device 194A, and/or guest memory 195A. In one example, another virtual guest (e.g., a VM or container) may execute directly on host OS 118 without an intermediate layer of virtualization.

In one example, VM155 may be a virtual machine and may execute a guest operating system 196A that may utilize underlying VCPU 190A, VMD 192A and VI/O194A. Processor virtualization may be implemented by hypervisor 120 scheduling time slots on physical CPU 112A such that from the guest operating system's perspective, these time slots are scheduled on virtual processor 190A. The VM155 can run on any type of dependent, independent, compatible, and/or incompatible application on the underlying hardware and the host operating system 118. Hypervisor 120 can manage memory of host operating system 118 as well as memory allocated to VM155 and guest operating system 196A, such as guest memory 195A provided to guest OS 196A. In one example, the storage container 160 and/or the service containers 150A, 150B are similarly implemented.

In one example, storage controller 142 may manage storage in a dedicated storage node (e.g., NAS, SAN, etc.) in addition to the distributed storage provided by storage containers 160. In one example, storage controller 142 may deploy storage in a large logical unit (e.g., storage node 170A) with preconfigured performance characteristics. In one example, access to a given storage node (e.g., storage node 170A) may be controlled at an account and/or tenant level. In one example, a service container (e.g., service containers 150A-B) may require persistent storage for application data, and may request persistent storage with a persistent storage declaration from the orchestrator 140. In this example, storage controller 142 may allocate storage to service containers 150A-B through a storage node in the form of a persistent storage volume (e.g., storage node 170A). In one example, the persistent storage volumes of the service containers 150A-B may be allocated a portion of the storage capacity and throughput of a given storage node (e.g., storage node 170A). In various examples, the storage container 160 and/or the service containers 150A-B may deploy computing resources (e.g., storage, caching, etc.) that are part of a computing service distributed across multiple clusters (not shown in fig. 1).

Various virtualized computing systems (e.g., service containers 150A, 150B, VM 155) may be examples of computing environments that may deploy one or more of the techniques described herein for sending, storing, determining, and/or modifying the message data format of message 141. For example, the service container 150A may parse the received message 141 to determine the data format identifier. The service container 150B may detect and/or apply the patch to a previously stored data format (e.g., stored in the data structure 106). VM155 can receive message 141 and can use the included data format identifier to look up the data format associated with the data format identifier. Thereafter, VM155 may read the received message using a data format. The foregoing example is but one possible implementation of the messaging fabric 124. The actual deployment of the various services and/or systems of the messaging architecture 124 is implementation-specific details and may be modified as desired in accordance with the present disclosure. The messaging fabric 124 may be deployed across any number of physical computing devices and/or virtualized computing environments, depending on the desired implementation.

In one example, receiver 123 can receive message 141 from transmitter 121. Receiver 123 can include logic effective to parse message 141 and determine a data format identifier included in message 141 (e.g., in a header of message 141). The receiver 123 may use the data format identifier to look up the data format (e.g., data format definition) stored in the data structure 106 in association with the data format identifier. The following is an example of a data format of a message called "light measurement". In this example, the data format identifier may be "lightMeasured," although in other examples, numeric identifiers and/or any other type of data that identifies a message format from other message formats may be used.

An example data format for the lightMeasured message may be:

87. message:

88 lightMeasured：

89. name: lightMeasured

90. Title: light measurement

91. Summary: informing the ambient lighting conditions of the particular street lamp.

92. Content type: application/json

93. The method is characterized in that:

94- $ ref: '#/component/message feature/common header'

95. Payload:

96 $ ref: "#/component/mode/light measuring payload"

In this example, the data format of the lightMeasured message includes references to other sources (e.g., lines 94, 96) at which portions of the data format definition are available. Such a source may be internal to the payload of the message and/or may exist in an external location.

After determining such a data format (e.g., using a data format identifier included in message 141), receiver 123 can include logic to parse the data included in the payload of message 141 using the data format. The data format is sometimes referred to as a message "schema". In various examples described in further detail below, some of messages 141 may include patches effective to modify data format definitions previously stored by receiver 123 in data structure 106. In such an example, receiver 123 may parse message 141 to detect the patch, and may use the data format identifier included in message 141 to look up the appropriate data format stored in data structure 106 to apply the patch. Patches may include executable instructions effective to modify a stored data format. The receiver 123 may modify the stored data format using the patch and may store the modified data format in a data structure. Subsequent message 141 including the same data format identifier may be used to retrieve a modified data format, which in turn may be used to parse and/or read the payload of subsequent message 141.

Fig. 2 is a block diagram 200 illustrating updating of a message data format by a receiver device according to various examples of the present disclosure. As shown in fig. 2, the receiver 223 may receive a plurality of received messages 201. In one example, the receiver 223 may subscribe to these messages using the message broker of the EDA. In other examples, the received message 201 may be received directly from the sender device.

Message 202 of received message 201 may include data format ID1 and data format definition a. In this example, the message 202 may be an initial message of a communication session with the sender. In some examples, receiver 223 may parse message 202 and may detect data format ID1 included in message 202. The receiver 223 may search the data structure 206 using the data format ID1 as a query in a lookup operation. In one example, data format ID1 may not be found in data structure 206. Receiver 223 may store data format ID1 in data structure 206 in association with data format definition a included in message 202. Thus, act 240 may include receiver 223 receiving a new type of message 202. The new type of message 202 may include both a data format identifier (e.g., data format ID 1) and a data format definition (e.g., data format definition a). Because the data format definition was not previously stored in data structure 206 by receiver 223, the receiver may create a new entry in data structure 206 by storing data format definition a in data structure 206 in association with data format ID 1.

Subsequently, the receiver 223 may receive the message 205. The message 205 may be parsed to determine its content. The receiver 223 may determine that data format ID1 is included, but no patch or data format definition is included. Receiver 223 may search data structure 206 using data format ID1 to determine whether a data format definition (sometimes referred to herein as a "data format") was previously stored in data structure 206. In the current example, data format definition a was previously stored in association with data format ID1 (e.g., at act 240). Accordingly, in act 242, the receiver 223 may retrieve the data format definition a and may parse and/or read the payload of the message 205 using the data format definition a.

In the example shown in fig. 2, a message 208 may be received. The message 208 may be parsed by the receiver 223 to determine its content. The receiver 223 may determine that the message 208 includes the data format ID1 and the patch 220, but that the message 208 does not include a data format definition. Receiver 223 may search data structure 206 using data format ID1 to determine whether a data format definition (e.g., "data format") was previously stored in data structure 206. In the current example, data format definition a was previously stored in association with data format ID1 (e.g., at act 240). However, in this example, because message 208 also includes patch 220, receiver 223 may use patch 220 to modify data format definition a before reading message 208. Accordingly, the receiver 223 may execute instructions included in the patch 220 to modify the previously stored data format definition a. In act 244, the receiver 223 may overwrite the old data format definition A with the modified data format definition A. Thereafter, the receiver 223 may read the message including the data format ID1 using the modified data format definition a.

In this way, a sender device (e.g., sender 121 of fig. 1) may only need to send an initial message at the beginning of a messaging session to send a full data format. Thereafter, the sender device may only send the data format identifier, which the receiver 223 may use to look up the previously sent and stored data format associated with the data format identifier. In addition, when the format is to be updated, the transmitter may transmit a patch that may be used by the receiver 223 to modify a previously stored data format. The sender may send different types of messages, and each different message type may be associated with its own data format identifier that identifies the message type from among the other message types, and with its own data format definition. Accordingly, in fig. 2, data format ID1 identifies data format a, data format ID 2 identifies data format B, data format 3 identifies data format C, data format 4 identifies data format D, and so on.

Allowing edge computing devices and/or other resource constrained devices to transmit only data format identifier data and/or patch updates while minimizing the need to transmit full data format definitions saves computing resources and/or battery life for these devices. Furthermore, to update a previously established data format definition, the transmitter device may transmit a data format ID identifying the data format definition along with the patch without having to transmit the full data format definition again.

Fig. 3 is a flow chart illustrating an example process 300 for updating a message format by a receiver device in accordance with an example of the present disclosure. Although the example process 300 is described with reference to the flowchart shown in FIG. 3, it should be understood that many other methods of performing the actions associated with the process 300 may be used. For example, the order of some blocks may be changed, some blocks may be combined with other blocks, blocks may be repeated, and some blocks described may be optional. Process 300 may be performed by processing logic that comprises hardware (circuitry, dedicated logic, etc.), software, or a combination of both. In some examples, the acts described in the blocks of process 300 may represent a series of instructions comprising computer-readable machine code executable by one or more processing units of one or more computing devices. In various examples, the computer-readable machine code may include instructions selected from an instruction set and/or operating system(s) native to one or more computing devices.

The example process 300 includes receiving a first message sent by an edge computing device (block 310). As used herein, an edge computing device may be a device that is resource constrained and/or deployed at the edge of a distributed computing network. Examples of such devices may include battery-powered sensors, integrated internet of things devices, and the like. The first message may include a header and/or a payload.

In one example, process 300 may include determining that the first message includes a first data format ID (block 315). For example, logic of the receiver device may be to parse the message to determine that the data format ID is included (e.g., in a header of the message).

In one example, process 300 may include determining that the first message includes a first data format patch (block 320). For example, the logic of the receiver may effectively parse the first message to determine the patch included in the first message. In various examples, the patch may be adapted to modify a previously stored data format stored by the receiver in association with the first data format identification in the data structure.

In one example, process 300 may include determining that a first data format ID was previously stored in association with a first data format (block 325). For example, the receiver may query the data structure using the first data format ID, and may determine that the first data format ID was previously stored in the data structure in association with the first data format. In various examples, the first data format may have been received in a previous message that may also have included the first data format ID.

In one example, process 300 may include modifying the first data format using the first data format patch to generate a first modified data format (block 330). In various examples, the first data format patch may include computer-executable instructions configured to modify the first data format. The receiver may execute the computer-executable instructions such that the first data format may be modified and a first modified data format may be generated.

In one example, process 300 may include storing the first modified data format in association with the first data format identifier (block 335). For example, the receiver may overwrite a previous first data format in the data structure with a first modified data format generated using a first data format patch. Thus, the first data format ID may now be associated with the first modified data format in the data structure. A subsequent message comprising the first data format ID can now be used to retrieve the first modified data format which in turn can be used to read such a message.

In one example, process 300 may include reading a payload of the first message using the first modified data format (block 340). The first modified data format may be used to parse and read the payload of the first message. For example, the first modified data format may define various data fields and/or byte structures of the first message.

Fig. 4 is a flow diagram illustrating an example process 400 for providing an updated message format by a sender device according to an example of the present disclosure. Although the example process 400 is described with reference to the flowchart shown in fig. 4, it should be understood that many other methods of performing the actions associated with the process 400 may be used. For example, the order of some blocks may be changed, some blocks may be combined with other blocks, blocks may be repeated, and some blocks described may be optional. Process 400 may be performed by processing logic that may comprise hardware (circuitry, dedicated logic, etc.), software, or a combination of both. In some examples, the acts described in the blocks of process 400 may represent a series of instructions comprising computer-readable machine code executable by one or more processing units of one or more computing devices. In various examples, the computer-readable machine code may include instructions selected from a native instruction set and/or operating system(s) of one or more computing devices.

The example process 400 includes establishing a communication channel with a receiver device (block 410). For example, a messaging protocol may be established and used to define a communication standard between a sender and a receiver device. In various examples, an authentication and/or encryption protocol may be used for the sender and receiver devices to authenticate each other and/or to define an encryption standard for data sent via the communication channel.

The example process 400 may include generating a first message of a first type. In various instances, the first message may include a first data format definition and a first data format identifier associated with the first data format definition (block 415). In various examples, a transmitter device (e.g., an edge computing device, such as a battery-powered image sensor and/or other sensor) may generate a first message that includes a first data format definition that pertains to the first message and a first data format identifier that identifies the first data format definition from among the other data format definitions.

The example process 400 may include sending a first message of a first type to a receiver device using a communication channel (block 420). In various examples, the first message of the first type may be sent via a message broker. In some other examples, the first message of the first type may be sent directly from the sender to the receiver.

The example process 400 may include generating a second message of the first type. In various examples, the second message may include the first data format identifier and the patch. The patch may include executable instructions configured to modify the first data format definition to generate a modified data format definition (block 425). In various examples, the patch may be a patch for modifying a previously transmitted first data format definition. The receiver may use the first data format identifier to retrieve the correct data format definition to apply the patch.

The example process 400 may include sending a second message of the first type to the receiver device using the communication channel (block 430). In various examples, the second message of the first type may be sent via a message broker or by direct device-to-device communication, depending on the desired implementation and/or the particular messaging protocol used.

Fig. 5A and 5B illustrate a flow diagram 500 of an example of message data format communication between a sender device 502 and a receiver device 504, in accordance with various aspects of the present disclosure. Although the following examples are described with reference to the flow diagrams illustrated in fig. 5A and 5B, it should be understood that many other methods of performing the actions associated with fig. 5A and 5B may be used. For example, the order of some blocks may be changed, some blocks may be combined with other blocks, and some blocks described may be optional. The methods may be performed by processing logic that may comprise hardware (circuitry, dedicated logic, etc.), software, or a combination of both.

In the example shown in fig. 5A, sender device 502 may generate a first message of a first type (block 506). The first message may include a first data format identifier identifying a first data format definition. Additionally, the first message may include the first data format definition (e.g., in a payload of the first message). Sender device 502 may send a first message of a first type to receiver device 504 (block 508). As previously described, the first message may be sent over a network to the receiver device 504 and/or may be sent to the receiver device 504 via a message broker (e.g., such as whether the sender device 502 is a publisher device of an EDA and whether the receiver device 504 is a subscriber device).

Receiver device 504 may receive a first message of a first type (block 510). In various examples, receiver device 504 may determine that the first data format ID was not previously stored in a data structure configured to communicate with receiver device 504 (block 512). Accordingly, receiver device 504 may store the first data format definition in a data structure in association with the first data format ID (block 514). In various examples, the receiver device 504 may parse and/or read the payload of the first message of the first type using the first data format definition (block 516). However, in some examples, the first message of the first type may include only the first data format ID and the first data format definition.

A period of time may elapse after the receiver device 504 reads the first message of the first type using the first data format definition (block 518). Thereafter, the sender device 502 may generate a second message of the first type. The second message of the first type may include the first data format ID and the patch data (block 520). The patch data may include executable instructions configured to modify the first format definition. Sender device 502 may send a second message of the first type to receiver device 504 (block 522).

Receiver device 504 may receive a second message of the first type (block 524). Logic of the receiver device 504 may be operable to parse the second message of the first type to identify a patch included in the second message of the first type (block 526). Processing may continue at fig. 5B. For example, receiver device 504 may modify the first data format using the patch data to generate a first modified data format (block 528). In various examples, receiver device 504 may use the first data format ID included in the second message of the first type to look up the first data format stored in the data structure in association with the first data format ID. The receiver device 504 may overwrite the first data format previously stored in the data structure with a first modified data format modified using the patch (block 530). The receiver device 504 may read the second message of the first type using the first modified data format (block 532). Thereafter, a period of time may elapse (block 534).

The sender device 502 may generate a third message of the first type that includes the first data format ID (block 536). The sender device 502 may send a third message of the first type to the receiver device 504 (block 538). Receiver device 504 may receive a third message of the first type (block 540). Receiver device 504 may parse the third message to identify the first data format ID and may perform a lookup operation using the first data format ID to identify the first modified data format stored in the data structure (block 542). Thereafter, the receiver device 504 may read a third message of the first type using the first modified data format (block 544).

Fig. 6 illustrates a flow diagram 600 of an example of determining data formats for different types of messages in accordance with various aspects of the disclosure. Although the following example is described with reference to the flowchart shown in fig. 6, it should be understood that many other methods of performing the actions associated with fig. 6 may be used. For example, the order of some blocks may be changed, some blocks may be combined with other blocks, and some blocks described may be optional. The methods may be performed by processing logic that comprises hardware (circuitry, dedicated logic, etc.), software, or a combination of both.

In the illustrated example flowchart 600, the sender device 602 may generate a first message of a first type that includes a first data format ID (block 606). In various examples, the sender device 602 may be one or more of a sensor, an embedded system, an edge computing device, an internet of things device, a resource constrained device, and the like. In one example, the first message of the first type may be a message of a first topic of the EDA. For example, the sender device may be a camera device and may send video data to the subscriber device. The video data may be formatted according to a first data format identified by a first data format ID. The sender device 602 may send a first message of a first type to the receiver device 604 (block 608).

Receiver device 604 may receive a first message of a first type (block 610). Receiver device 604 may identify a first data format ID included in a first message of a first type. The receiver device may look up the first data format definition using the first data format ID to query the data structure (block 612). Receiver device 604 may parse the first message of the first type to determine that the patch is not included in the first message of the first type (block 614). Therefore, the updating of the first data format definition is not performed at the current stage of the processing. Receiver device 604 may read a first message of a first type (e.g., a payload of the first message of the first type) using a first data format definition (block 616). For example, the first data format definition may be machine readable data that provides instructions on how to parse and/or interpret the first type of message. Thereafter, a period of time may elapse (block 618).

The sender device 602 may generate a first message of a second type. The first message of the second type may include a second data format ID different from the first data format ID (block 620). In various examples, the second data format ID may identify a different data format definition relative to the first data format definition identified by the first data format ID. In the above example where the transmitter device 602 is a camera device, the second type of first message may be audio data, telemetry data, or the like. The audio data, telemetry data, etc. may be formatted according to a second data format identified by a second data format ID. The sender device 602 may send a first message of a second type to the receiver device 604 (block 622).

The receiver device 604 may receive the first message of the second type (block 624). Receiver device 604 may look up the second data format definition using the second data format ID (block 626). For example, receiver device 604 may use the second data format ID as a query to search for a data structure in which the second data format ID is stored in association with the second data format definition. Receiver device 604 may parse the first message of the second type to determine that the patch is not included in the first message of the second type (block 628). Thus, no updating of the second data format definition is performed at the current stage of processing. Receiver device 604 may read the first message of the second type using the second data format definition (block 630).

Thus, as shown in the example of fig. 6, different types of messages may be sent by the sender device, and the sender device need only include the complete data format definition in the first message of a given type. Thereafter, once the data format definition has been stored in the receiver-side memory, the sender device only needs to send the data format ID to read the message correctly. In addition, the sender device may switch between different message types associated with different data formats by switching the data format IDs included in the different types of messages — provided that the receiver device has been previously provided with a complete data format definition.

In some examples, the receivers and/or receiver devices described herein may be less resource constrained relative to the transmitter device. Thus, in some examples, to provide fault tolerance, a receiver device may maintain a log of messages received from a sender device. In such a log, the receiver device may maintain a record of the data format definition, data format ID, and patch transmitted by the transmitter. Thus, if the data structure of the receiver device is corrupted, the log may be consulted to determine and/or reconstruct the appropriate data format definition including any applicable patches.

Fig. 7 is a block diagram of a system 700 in which message data format information is communicated between an edge computing device 712 and a first computing device 702 (e.g., a receiver device) according to an example of the present disclosure. The system 700 may include a first computing device 702 configured to communicate with an edge computing device 712. In various examples, the first computing device 702 can be a receiver device that includes at least one processor 704, a receiver 706 (e.g., receiver circuitry of a radio), and non-transitory computer-readable memory 708 in communication with the at least one processor 704. The non-transitory computer-readable memory 708 may store instructions 710, which when executed by the at least one processor 704, the instructions 710 may be configured to perform one or more of the various techniques described herein. The first computing device 702 may include a data structure 718. In at least some examples, the data structure 718 may be part of the non-transitory computer-readable memory 708, while in other examples, the data structure 718 may be a separate component.

The edge computing device 712 may send a first message 714 to the first computing device 702. In various examples, the receiver 706 of the first computing device 702 can receive the first message 714. First message 714 may include a first data format ID 716 (e.g., a first data format identifier), a first data format patch 720, and/or a payload 730. The first data format ID 716 may be used to search the data structure 718 to determine that the first data format ID 716' was previously stored in the data structure 718 in association with the first data format 722. The first data format 722 may be a data format definition for interpreting, parsing, and/or reading messages received by the first computing device 702. In various examples, the instructions 710 may be configured to cause the at least one processor 704 to determine that the first message 714 includes the first data format patch 720. The instructions 710 may be further configured to cause the at least one processor 704 to modify the first data format 722 to generate a first modified data format 724. The instructions 710 may be further configured to cause the at least one processor 704 to store the first modified data format 724 in a data structure in association with the first data format ID 716 ". The instructions 710 may be further configured to cause the at least one processor 704 to read a payload 730 of the first message 714 using the first modified data format 724.

It should be understood that all of the disclosed methods and processes described herein may be implemented using one or more computer programs or components. These components may be provided as a series of computer instructions on any conventional computer-readable or machine-readable medium, including volatile or non-volatile memory such as RAM, ROM, flash memory, magnetic or optical disks, optical storage, or other storage media. The instructions may be provided as software or firmware, and/or may be implemented in whole or in part in hardware components, such as ASICs, FPGAs, DSPs, or any other similar devices. The instructions may be executed by one or more processors, which when executing the series of computer instructions, perform or facilitate the performance of all or part of the disclosed methods and processes.

Various aspects of the subject matter described herein may be used alone or in combination with one or more other aspects described herein. In a first example aspect of the disclosure, an apparatus includes at least one processor, a receiver, and a non-transitory computer-readable memory. The non-transitory computer-readable memory stores instructions that, when executed by the at least one processor, are configured to receive, by a receiver, a first message sent by an edge computing device. The instructions may also be configured to determine that the first message includes a first data format identifier. The instructions may also be configured to determine that the first message includes a first data format patch. In some examples, the instructions may be further configured to determine that the first data format identifier was previously stored in the data structure in association with the first data format. In some cases, the instructions may be further configured to modify the first data format using the first data format patch to generate a first modified data format. In some examples, the instructions may be further configured to store the first modified data format in the data structure in association with the first data format identifier. In various examples, the instructions may be further configured to read a payload of the first message using the first modified data format.

According to a second example aspect of the disclosure, which may be used in combination with any one or more other aspects described herein (e.g., the first aspect), wherein the non-transitory computer-readable memory stores further instructions that, when executed by the at least one processor, are further configured to: receiving, from the receiver, a second message sent by the edge computing device; determining that the second message includes the first data format identifier; determining that the first data format identifier is stored in the data structure in association with the first modified data format; and reading the payload of the second message using the first modified data format.

According to a third example aspect of the present disclosure, the third example aspect may be used in combination with any one or more other aspects described herein (e.g., the first aspect), wherein the non-transitory computer-readable memory stores further instructions that, when executed by the at least one processor, are further configured to receive a second message sent by the edge computing device from the receiver, determine that the second message includes a second data format identifier, determine that the second data format identifier is not stored in the data structure, determine that the second message includes data defining the second data format, store the data defining the second data format in the data structure in association with the second data format identifier, and read a payload of the second message using the second data format.

According to a fourth example aspect of the present disclosure, the fourth example aspect may be used in combination with any one or more other aspects described herein (e.g., the first aspect), wherein the non-transitory computer-readable memory stores further instructions that, when executed by the at least one processor, are further configured to receive a second message sent by the edge computing device from the receiver, parse the second message to determine whether a patch is included in the second message, and determine that the second message does not include the patch.

According to a fifth example aspect of the disclosure, which may be used in combination with any one or more other aspects described herein (e.g., the fourth aspect), wherein the non-transitory computer-readable memory stores further instructions that, when executed by the at least one processor, are further configured to determine that the second message includes the first data format identifier, determine that the first data format identifier is stored in the data structure in association with the first modified data format, and read the payload of the second message using the first modified data format.

According to a sixth example aspect of the present disclosure, the sixth example aspect may be used in combination with any one or more other aspects described herein (e.g., the first aspect), wherein the non-transitory computer-readable memory stores further instructions that, when executed by the at least one processor, are further configured to receive a second message sent by the edge computing device from the receiver, parse the second message to determine whether a patch is included in the second message, determine that the second message includes a first modified data format patch, determine that the second message includes a first data format identifier, determine that the first data format identifier was previously stored in the data structure in association with the first modified data format, modify the first modified data format using the first modified data format patch to generate a second modified data format, and overwrite the first modified data format in the data structure with the second modified data format.

According to a seventh example aspect of the present disclosure, which may be used in combination with any one or more other aspects described herein (e.g., the sixth aspect), wherein the non-transitory computer-readable memory stores further instructions that, when executed by the at least one processor, are further configured to read the payload of the second message using the second modified data format.

According to an eighth example aspect of the present disclosure, this eighth example aspect may be used in combination with any one or more other aspects described herein (e.g., the first aspect), wherein the first message is sent using an asynchronous messaging protocol.

According to a ninth example aspect of the present disclosure, this ninth example aspect may be used in combination with any one or more other aspects described herein (e.g., the first aspect), wherein the first message is sent by the battery-powered edge computing device using an asynchronous messaging protocol.

According to a tenth example aspect of the present disclosure, this tenth example aspect may be used in combination with any one or more other aspects described herein (e.g., the first aspect), wherein the non-transitory computer-readable memory stores further instructions that, when executed by the at least one processor, are further configured to receive a second message sent by the edge computing device from the receiver, determine that the second message includes a second data format identifier, determine a second data format stored in the data structure in association with the second data format identifier, and read a payload of the second message using the second data format.

Various aspects of the subject matter described herein may be used alone or in combination with one or more other aspects described herein. In an eleventh example aspect of the disclosure, a method includes receiving a first message sent by an edge computing device, determining that the first message includes a first data format identifier, determining that the first message includes a first data format patch, determining that the first data format identifier was previously stored in a data structure in association with a first data format, modifying the first data format using the first data format patch to generate a first modified data format, storing the first modified data format in the data structure in association with the first data format identifier, and reading a payload of the first message using the first modified data format.

According to a twelfth example aspect of the disclosure, which may be used in conjunction with any one or more other aspects described herein (e.g., the eleventh aspect), receiving a second message sent by the edge computing device, determining that the second message includes a first data format identifier, determining that the first data format identifier is stored in a data structure in association with a first modified data format, and reading a payload of the second message using the first modified data format.

In a thirteenth example aspect of the present disclosure, which may be used in conjunction with any one or more other aspects described herein (e.g., the eleventh aspect), receiving a second message sent by an edge computing device, determining that the second message includes a second data format identifier, determining that the second data format identifier is not stored in a data structure, determining that the second message includes data defining a second data format, storing the data defining the second data format in the data structure in association with the second data format identifier, and reading a payload of the second message using the second data format.

In a fourteenth example aspect of the present disclosure, which may be used in conjunction with any one or more other aspects described herein (e.g., the eleventh aspect), the method includes receiving a second message sent by an edge computing device, parsing the second message to determine whether a patch is included in the second message, and determining that the second message does not include a patch.

In a fifteenth example aspect of the disclosure, which may be used in combination with any one or more other aspects described herein (e.g., the fourteenth aspect), the determining that the second message includes the first data format identifier, determining that the first data format identifier is stored in the data structure in association with the first modified data format, and reading the payload of the second message using the first modified data format.

In a sixteenth example aspect of the present disclosure, the sixteenth example aspect can be used in combination with any one or more other aspects described herein (e.g., the eleventh aspect), receiving a second message sent by an edge computing device, parsing the second message to determine whether a patch is included in the second message, determining that the second message includes a first modified data format patch, determining that the second message includes a first data format identifier, determining that the first data format identifier was previously stored in a data structure in association with a first modified data format, modifying the first modified data format using the first modified data format patch to generate a second modified data format, and overwriting the first modified data format with the second modified data format in the data structure.

According to a seventeenth example aspect of the present disclosure, which may be used in combination with any one or more other aspects described herein (e.g., the sixteenth aspect), the payload of the second message is read using the second modified data format.

According to an eighteenth example aspect of the disclosure, this eighteenth example aspect may be used in combination with any one or more other aspects described herein (e.g., the eleventh aspect), wherein the first message is sent using an asynchronous messaging protocol.

According to a nineteenth example aspect of the present disclosure, this nineteenth example aspect may be used in combination with any one or more other aspects described herein (e.g., the eleventh aspect), wherein the first message is sent by the battery-powered edge computing device using an asynchronous messaging protocol.

According to a twentieth example aspect of the present disclosure, which may be used in combination with any one or more other aspects described herein (e.g., the eleventh aspect), the method includes receiving a second message sent by the edge computing device, determining that the second message includes a second data format identifier, determining a second data format stored in the data structure in association with the second data format identifier, and reading a payload of the second message using the second data format.

Various aspects of the subject matter described herein may be used alone or in combination with one or more other aspects described herein. In a twenty-first example aspect of the disclosure, a method includes establishing a communication channel with a receiver device, generating a first message of a first type, the first message including a first data format definition and a first data format identifier associated with the first data format definition, transmitting the first message to the receiver device using the communication channel, generating a second message of the first type, the second message including the first data format identifier and a patch, the patch including executable instructions effective to modify the first data format definition to generate a first modified data format definition, and transmitting the second message of the first type to the receiver device using the communication channel.

According to a twenty-second example aspect of the present disclosure, which may be used in combination with any one or more other aspects described herein (e.g., the twenty-first aspect), further comprising: generating a third message of the first type, the third message comprising the first data format identifier, wherein the receiver device is configured to: parsing the third message to identify the first data format identifier; and using the first data format identifier to look up the first modified data format definition.

According to a twenty-third example aspect of the disclosure, which may be used in combination with any one or more other aspects described herein (e.g., the twenty-second aspect), wherein the receiver device is further configured to read the payload of the third message using the first modified data format definition.

According to a twenty-fourth example aspect of the present disclosure, which may be used in combination with any one or more other aspects described herein (e.g., the twenty-first aspect), further comprising sending a first message of a second type to the receiver device, the second message comprising a second data format definition and a second data format identifier associated with the second data format definition.

According to a twenty-fifth example aspect of the disclosure, this twenty-fifth example aspect may be used in combination with any one or more other aspects described herein (e.g., the twenty-fourth aspect), wherein the receiver device is effective to: parsing the first message of the second type to determine a second data format definition and a second data format identifier associated with the second data format definition; and storing the second data format definition in the database in association with the second data format identifier.

According to a twenty-sixth example aspect of the present disclosure, which may be used in combination with any one or more other aspects described herein (e.g., the twenty-fifth aspect), further comprising: generating a second message of a second type, the second message comprising a second data format identifier and excluding any data format definitions; and sending a second message of a second type to the receiving device using the communication channel.

Various aspects of the subject matter described herein may be used alone or in combination with one or more other aspects described herein. In a twenty-seventh example aspect of the present disclosure, an apparatus comprises: at least one processor; a transmitter; and a non-transitory computer-readable memory storing instructions that, when executed by the at least one processor, are configured to: establishing a communication channel with a receiver device; generating a first message of a first type, the first message comprising a first data format definition and a first data format identifier associated with the first data format definition; transmitting, using a transmitter, a first message of a first type to a receiver device; generating a second message of the first type, the second message comprising the first data format identifier and a patch, the patch comprising executable instructions effective to modify the first data format definition to generate a first modified data format definition; and transmitting, using the transmitter, a second message of the first type to the receiver device.

According to a twenty-eighth example aspect of the present disclosure, which may be used in combination with any one or more other aspects described herein (e.g., the twenty-seventh aspect), wherein the non-transitory computer-readable memory stores further instructions that, when executed by the at least one processor, are further configured to: generating a third message of the first type, the third message comprising the first data format identifier, wherein the receiver device is configured to: parsing the third message to identify the first data format identifier; and using the first data format identifier to look up the first modified data format definition.

According to a twenty-ninth example aspect of the disclosure, which may be used in combination with any one or more other aspects described herein (e.g. the twenty-eighth aspect), wherein the receiver device is further configured to read the payload of the third message using the first modified data format definition.

According to a thirty-third example aspect of the present disclosure, this thirty-third example aspect may be used in combination with any one or more other aspects described herein (e.g., the twenty-seventh aspect), wherein the non-transitory computer-readable memory stores further instructions that, when executed by the at least one processor, are further configured to: the method further includes transmitting, using the transmitter, a first message of a second type to the receiver device using the communication channel, the second message including a second data format definition and a second data format identifier associated with the second data format definition.

According to a thirty-first example aspect of the disclosure, this thirty-first example aspect may be used in combination with any one or more other aspects described herein (e.g., the thirty-first aspect), wherein the receiver device is effective to: parsing the first message of the second type to determine a second data format definition and a second data format identifier associated with the second data format definition; and storing the second data format definition in the database in association with the second data format identifier.

According to a thirty-second example aspect of the present disclosure, this thirty-second example aspect may be used in combination with any one or more other aspects described herein (e.g., the thirty-first aspect), wherein the non-transitory computer-readable memory stores further instructions that, when executed by the at least one processor, are further configured to: generating a second message of a second type, the second message comprising a second data format identifier and excluding any data format definitions; and transmitting, using the transmitter, a second message of a second type to the receiver device via the communication channel.

Various aspects of the subject matter described herein may be used alone or in combination with one or more other aspects described herein. In a thirty-third example aspect of the present disclosure, a system comprises: means for receiving a first message sent by an edge computing device; means for determining that the first message includes a first data format identifier; means for determining that the first message includes a first data format patch; means for determining that the first data format identifier was previously stored in association with the first data format in the data structure; means for modifying the first data format using the first data format patch to generate a first modified data format; means for storing the first modified data format in the data structure in association with the first data format identifier; and means for reading the payload of the first message using the first modified data format.

According to a thirty-fourth example aspect of the present disclosure, which may be used in combination with any one or more other aspects described herein (e.g., the thirty-third aspect), the system further comprises: means for receiving a second message sent by the edge computing device; means for determining that the second message includes the first data format identifier; means for determining that the first data format identifier is stored in the data structure in association with the first modified data format; and means for reading the payload of the second message using the first modified data format.

According to a thirty-fifth example aspect of the present disclosure, which may be used in combination with any one or more other aspects described herein (e.g., the thirty-third aspect), the system further comprises: means for receiving a second message sent by the edge computing device; means for determining that the second message includes a second data format identifier; means for determining that the second data format identifier is not already stored in the data structure; means for determining that the second message includes data defining a second data format; means for storing data defining a second data format in a data structure in association with a second data format identifier; and means for reading the payload of the second message using the second data format.

To the extent that any of these aspects are mutually exclusive, it is understood that such mutual exclusion should not limit the combination of such aspect with any other aspect, whether or not such aspect is explicitly recited. Any of these aspects may be claimed as systems, methods, apparatuses, devices, media, etc. without limitation.

It should be understood that various changes and modifications to the example embodiments described herein will be apparent to those skilled in the art. Such changes and modifications can be made without departing from the spirit and scope of the present subject matter and without diminishing its intended advantages. It is therefore intended that such changes and modifications be covered by the appended claims.

Claims

1. An apparatus, comprising:

at least one processor;

a receiver; and

a non-transitory computer-readable memory storing instructions that, when executed by the at least one processor, are configured to:

receiving, by the receiver, a first message sent by an edge computing device;

determining that the first message includes a first data format identifier;

determining that the first message comprises a first data format;

storing the first data format in a data structure in association with the first data format identifier;

receiving, by the receiver, a second message sent by the edge computing device;

determining that the second message includes the first data format identifier;

retrieving the first data format from the data structure using the first data format identifier; and

reading a payload of the second message using the first data format.

2. The device of claim 1, wherein the non-transitory computer-readable memory stores further instructions that, when executed by the at least one processor, are further configured to:

receiving, by the receiver, a third message sent by the edge computing device;

determining that the third message includes the first data format identifier;

determining that the third message includes a first data format patch;

determining that the first data format identifier was previously stored in association with the first data format in the data structure;

modifying the first data format using the first data format patch to generate a first modified data format;

storing the first modified data format in the data structure in association with the first data format identifier; and

reading a payload of the third message using the first modified data format.

3. The apparatus of claim 2, wherein the non-transitory computer-readable memory stores further instructions that, when executed by the at least one processor, are further configured to:

receiving, from the receiver, a fourth message sent by the edge computing device;

determining that the fourth message includes the first data format identifier;

determining that the first data format identifier is stored in the data structure in association with the first modified data format; and

reading a payload of the fourth message using the first modified data format.

4. The apparatus of claim 2, wherein the non-transitory computer-readable memory stores further instructions that, when executed by the at least one processor, are further configured to:

determining that the fourth message includes a second data format identifier;

determining that the second data format identifier is not stored in the data structure;

determining that the fourth message includes data defining a second data format;

storing the data defining the second data format in the data structure in association with the second data format identifier; and

reading a payload of the fourth message using the second data format.

5. The apparatus of claim 2, wherein the non-transitory computer-readable memory stores further instructions that, when executed by the at least one processor, are further configured to:

parsing the fourth message to determine whether a patch is included in the fourth message; and

determining that the fourth message does not include a patch.

6. The apparatus of claim 5, wherein the non-transitory computer-readable memory stores further instructions that, when executed by the at least one processor, are further configured to:

determining that the fourth message includes the first data format identifier;

reading a payload of the fourth message using the first modified data format.

7. The apparatus of claim 2, wherein the non-transitory computer-readable memory stores further instructions that, when executed by the at least one processor, are further configured to:

parsing the fourth message to determine whether a patch is included in the fourth message;

determining that the fourth message includes a first modified data format patch;

determining that the fourth message includes the first data format identifier;

determining that the first data format identifier was previously stored in the data structure in association with the first modified data format;

modifying the first modified data format using the first modified data format patch to generate a second modified data format; and

overwriting the first modified data format with the second modified data format in the data structure.

8. The apparatus of claim 7, wherein the non-transitory computer-readable memory stores further instructions that, when executed by the at least one processor, are further configured to read a payload of the fourth message using the second modified data format.

9. The device of claim 1, wherein the non-transitory computer-readable memory stores further instructions that, when executed by the at least one processor, are further configured to:

receiving, from the receiver, a third message sent by the edge computing device;

determining that the third message includes a second data format identifier;

determining a second data format stored in the data structure in association with the second data format identifier; and

reading a payload of the third message using the second data format.

10. The device of claim 1, wherein the first message is sent by a battery-powered edge computing device using an asynchronous messaging protocol.

11. A method, comprising:

receiving a first message sent by an edge computing device;

determining that the first message includes a first data format identifier;

determining that the first message includes a first data format patch;

determining that the first data format identifier was previously stored in a data structure in association with a first data format;

reading a payload of the first message using the first modified data format.

12. The method of claim 11, further comprising:

receiving a second message sent by the edge computing device;

determining that the second message includes the first data format identifier;

reading a payload of the second message using the first modified data format.

13. The method of claim 11, further comprising:

receiving a second message sent by the edge computing device;

determining that the second message includes a second data format identifier;

determining that the second message includes data defining a second data format;

reading a payload of the second message using the second data format.

14. The method of claim 11, further comprising:

receiving a second message sent by the edge computing device;

parsing the second message to determine whether a patch is included in the second message; and

determining that the second message does not include a patch.

15. The method of claim 14, further comprising:

determining that the second message includes the first data format identifier;

reading a payload of the second message using the first modified data format.

16. The method of claim 11, further comprising:

receiving a second message sent by the edge computing device;

parsing the second message to determine whether a patch is included in the second message;

determining that the second message includes a first modified data format patch;

determining that the second message includes the first data format identifier;

17. The method of claim 16, further comprising reading a payload of the second message using the second modified data format.

18. A method, comprising:

establishing a communication channel with a receiver device;

generating a first message of a first type, the first message comprising a first data format definition and a first data format identifier associated with the first data format definition;

transmitting the first message to a receiver device using the communication channel;

generating a second message of the first type, the second message comprising the first data format identifier and a patch, the patch comprising executable instructions effective to modify the first data format definition to generate a first modified data format definition; and

transmitting a second message of the first type to the receiver device using the communication channel.

19. The method of claim 18, further comprising:

generating a third message of the first type, the third message comprising the first data format identifier, wherein the receiver device is configured to:

parsing the third message to identify the first data format identifier; and

using the first data format identifier to look up the first modified data format definition.

20. The method of claim 19, wherein the receiver device is further configured to read a payload of the third message using the first modified data format definition.