Interface-adaptive data exchange

In embodiments, apparatuses, computer-readable media, and methods for interface-adaptive data exchange may be described. A sender and a receiver may communicate using different versions of a data exchange interface. A serializer may be configured to obtain data generated according to a first version of the data exchange interface and to write data to a communication medium for communication to the receiver such that it may be understood by the receiver based on the receiver's version of the data exchange interface. The serializer may be configured to omit one or ones of data that may be not be understood by the receiver based on the receiver's version of the data exchange interface. In some embodiments, the serializer may omit one or ones of data which are not permitted in the current context according to the interface definition. In various embodiments, the serializer may determine the extent of the omitted data based on an end delimeter, a length of data to-be-omitted, or a description of the sender's version of the data exchange interface. Other embodiments may be described.

BACKGROUND

Devices that communicate with each other, such as over a network, may often make use of interfaces or protocols that may define or describe types and/or formats of data that may be exchanged between the devices. For example, in various smart power systems, a power meter may send power usage data to a receiving device using an interface understood by both devices. Over time, however, the capabilities of one or both of the devices may be modified or otherwise updated. In some circumstances, the data exchange interface used between the devices may be updated to a new version as well, such as in order to support the modifications to the capabilities of the devices.

However, in some scenarios, it may not be possible, or desirable, for both devices to utilize the same version of the data exchange interface. For instance, in the smart power example described above, updates to the power meter may be remotely managed by the power company and may occur on a completely different schedule than updates to the receiving device, which might be controlled by individual home/building owners and completed when convenient (if ever). In addition, some devices may intentionally implement custom versions of standard data exchange interfaces to support vendor-specific extensions and proprietary features that provide a competitive edge. These receivers may therefore be difficult to update to a new interface version. Additionally, some devices may lack the facility to be updated—for example, some devices may implement a data exchange interface in hardware logic, or may lack sufficient storage or additional computing power to incorporate an update to an interface. Thus, even when the sending device is able to be updated, the receiving device may not be able to be updated as regularly, if at all. For these and other reasons, two devices which intended to communicate may find themselves relying on mismatched versions of a data exchange interface.

In some existing techniques, this potential mismatch may be addressed utilizing code or other logic operated by the receiver device to translate between different interface versions. However, receiver-side translation may be hard to implement efficiently on low-power receivers. Further it may be just as difficult to keep translation logic up-to-date as it would be to update a receiver's interface logic. Thus, such receiver code may not deal well with continued updates to the interface on the sender end.

DETAILED DESCRIPTION

As used herein, the term “module” may refer to, be part of, or include an Application Specific Integrated Circuit (“ASIC”), an electronic circuit, a processor (shared, dedicated, or group) and/or memory (shared, dedicated, or group) that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable components that provide the described functionality.

Referring now toFIG. 1, examples of interface-adaptive data exchange are shown between a receiver100and a sender190, where the sender190is sending data to the receiver100. The data may be generated at the sender190by a generator140. As illustrated, the sender190and the receiver100may have knowledge of one or more versions of a data exchange interface that may be used to describe data that may be sent between the sender190and the receiver100. However, the sender190may, in various embodiments, have been updated to generate data according to a newer or extended version of the data exchange interface than that known by the receiver100. Thus, as illustrated, the generator140of the sender190may generate data in version V3130, while the receiver100may have knowledge only of V1110. This may lead to a mismatch between the sender190and the receiver100; for example, the sender190may, relying on its later or extended version of the data exchange interface, generate information which the receiver100cannot understand.

This mismatch may be understood using an example data exchange interface.FIG. 2illustrates an example finite automaton200for different versions of a data exchange interface, in accordance with various embodiments. In addition to the examples described herein, further examples of the usage of finite automata to describe data exchange interfaces may be found in U.S. Pat. No. 7,565,339, entitled “Knowledge Based Encoding of Data,” filed Mar. 31, 2006, which is herein incorporated by reference in its entirety. In various embodiments, the example automaton200may describe a data exchange interface for sending a usage report, such as, for example, from a smart power meter. In various embodiments the automaton200may include transitions that describe specific data sent from a power meter. For the ease of illustration, the illustrated automaton200may show transitions for both a version V1and a version V2of a data exchange interface; however, in various embodiments, an automaton that is describing V1of the data exchange interface may not include the transitions that are used in the V2version of the interface.

The automata200may include a state210, where there is a “Usage report” transition to a state220. From this state220, there may be one or more transitions, which may also depend on the version of the data exchange interface. Thus, in both V1and V2version of the data exchange interface, the automata may describe a transition to a state230along a “Use” transition, such as to describe normal usage of power measured by the power meter. In contrast, the automata also describes a “Power spike” transition to the state230, but this transition only exists in the V2version of the interface. Further, within a particular transition, the automaton200may describe additional transitions to further provide other information related to the usage or power spike information. For example the automaton200may describe that, in both versions of the interface, the interface may expect “Start,” “End,” and “Usage” transitions to provide particular pieces of information related to normal power usage. Similarly, in version V2of the interface, the automaton200describes “Time” and “Spike amount” transitions.

It may be noted that, in various embodiments, a device implementing an older version of a data exchange interface may not understand information sent according to a newer or extended version of the interface. Thus, for example, if a receiver100implements only version V1of a data exchange interface that is described by the automaton200, the receiver100may not understand “Power spike” information, including the “Time” and “Spike amount” information. However, the sender190may include this information when generating data to send to the receiver100.

Thus, returning toFIG. 1, in various embodiments, the techniques described herein may address a mismatch between a sender190and receiver100, such as the one described above, by identifying data that can be understood by the receiver100according to its version of the data exchange interface, and by removing data that cannot be understood by the receiver100. In various embodiments the removal may include omission of one or ones of data that are not identified as conforming to the receiver's version of the data exchange interface.

In various embodiments, the sender190may communicate with the receiver100via a serializer150. In various embodiments, the serializer may be configured to receive data that has been generated and to write that data to a communication medium for communication to the receiver100. In various embodiments, the serializer150may be configured to write data to various communications media, including, but not limited to, wired or wireless networks, transitory and non-transitory computer-readable media, and other media. In various embodiments, the serializer150may be configured to write the data according to various formats with or without compression. In various embodiments, the serializer may be configured to compress data before writing it based on one or more knowledge representations of the generated data. Additional examples of the serializer150may be found in U.S. Pat. No. 7,565,339.

In various embodiments, the serializer150may also be configured to perform the above-described identification and removal of data. Thus in various embodiments, the serializer150may identify data which may be understood by the receiver100based on the receiver's version of the data exchange interface and may remove data that cannot be understood by the receiver. Thus, the serializer150may thereby send data which is adapted to be understood by a receiver based on the receiver's version of the data exchange interface. In various embodiments, the serializer may therefore be configured to consult a grammar, an interface definition, an automaton, or other information describing the version of the data exchange interface used by the receiver100and to remove data that is not described in this information as appropriate. Thus, in the illustrated example, the serializer150may have knowledge of multiple versions of the data exchange interface, such as V1110, V2120, and V3130, in order to communicate with different receivers that each utilize these different versions of the data exchange interface. In various embodiments, the serializer150may perform this removal during a writing of the generated data to a communication medium. In various embodiments, the serializer150may perform this removal by omitting the one or ones of data that cannot be understood by the receiver100during the writing. In various embodiments, the serializer150may be configured to perform this omission by omitting data that would otherwise cause an error according to the serializer150's consultation of the description of the receiver100′s version of the data exchange interface. In various embodiments, the serializer150may be configured to determine a length of the data that would otherwise cause an error and to omit the writing of data until this length is reached.

FIG. 3illustrates an example interface-adaptive data exchange process300, in accordance with various embodiments. In various embodiments, the process may be performed by the sender190to send data to the receiver100such that the data will be understood by the receiver100according to the version of a data exchange interface used by the two devices. While process300lists various actions in a particular order, in various embodiments, one or more actions of process300may be repeated, changed in order, combined, or omitted entirely. the process may begin at operation310, where the generator140of the sender190may generate data for transmission to the receiver100. In various embodiments, the generator140may generate the data according to a version of the data exchange interface used by the sender190, regardless of any version of the data exchange interface that may be used by the receiver100. For example, if the generator140is generating data to send to a power meter according to the automaton200describe above, the generator140may include both “Usage” data and “Power spike” data regardless of whether the receiver100may be configured to understand the data.

Next, at operation320, the sender190may receive an indication of a version of the data exchange interface used by the receiver100. In various embodiments, this indication may be received from the receiver100in response to a request sent to the receiver100at or near the time of transmission of data to the receiver100. In other embodiments, the receiver100may have previously indicated which version of the data exchange interface it is using. In yet other embodiments, the sender190may assume a version of the data exchange interface; for example, if information cannot be received from the receiver100, the data exchange interface may default to an early version of the data exchange interface. Particular examples of interface negotiation may be described in U.S. Pat. No. 7,853,724, entitled “Automatic Identification, Negotiation, Synchronization, and Update of System Interfaces,” filed Jun. 19, 2008, which is hereby incorporated by reference in its entirety. Next, at operation330, the serializer150may send adapted data according to the version of the data exchange interface used by the receiver100. Particular examples of this operation are described below with reference to process400ofFIG. 4. The process may then end.

FIG. 4illustrates an example adapted data sending process400, in accordance with various embodiments. In various embodiments, the process may include one or more implementations of operation330of process300. While process400lists various actions in a particular order, in various embodiments, one or more actions of process400may be repeated, changed in order, combined, or omitted entirely. The process may begin at operation420, where the serializer150may obtain a piece of data to send to the receiver100. Next, at operation430, the serializer150may compare the obtained piece of data to the version of the data exchange interface used by the receiver100. Next, at decision operation435, the serializer150may determine if the piece of data can be understood by the receiver based on the version of the data exchange interface used by the receiver100. In some embodiment, the serializer150may make this determination by determining whether the piece of data is described in an interface definition (or other description of the version of the data exchange interface used by the receiver100. In some embodiments, the serializer150may also determine at decision operation435whether the piece of data is permitted in a current context according to the interface definition or description. If the data can be understood, then at operation440, the serializer150may write the piece of data as adapted data to the communication medium for receipt by the receiver100. If not, then at operation450, the serializer150may omit the data that cannot be understood from being written to the communication medium. Particular examples of this operation are described below with reference to process500ofFIG. 5. The process may then end.

FIG. 5illustrates an example data omission process500, in accordance with various embodiments. In various embodiments, the process may include one or more implementations of operation450of process400. While process500lists various actions in a particular order, in various embodiments, one or more actions of process500may be repeated, changed in order, combined, or omitted entirely. In various embodiments, the serializer150may perform different operations to omit data from being written, depending on a manner in which an end for the to-be-omitted piece of data is indicated. Thus, at decision operation505, different operations may be performed depending on how the end is indicated. If the data is represented using a format with explicit end delimiters, such as XML or JSON, then at operation510, the serializer may omit data until a corresponding end delimiter for the to-be-omitted data is reached, and the process may then end. By contrast, if the end of the data is indicated according to a length value for the data that is encoded in the data (such as in binary encoded data) then at operation520the serializer150may obtain the length value. Then, at operation530, the serializer150may omit data until this length is reached and the process may then end.

If at operation505the serializer determines instead that there is neither an end delimiter nor a data length value to use to determine the end of the to-be-omitted data, the serializer150may not be able to determine, based solely on the generated data, how long to omit data from being written to the communication medium. Thus, at operation540, the serializer150may consult a description of the version of the data exchange interface that is being used by the generator140. For example, the serializer140may consult the version V3130in the example ofFIG. 1. As discussed above, in various embodiments, the interface description may include one or more types of interface description that may be used to determine where a piece of data starts and ends, such as by providing a formal definition of the interface. These interface descriptions may include, but are not limited to, a grammar, an interface definition, an automaton, or other forms of description. Then, at operation550, the serializer150may omit data until the end of the to-be-omitted data is reached according to the description of the data in the version of the data exchange interface used by the generator140. The process may then end.

FIG. 6illustrates, for one embodiment, an example computer system600suitable for practicing embodiments of the present disclosure. As illustrated, example computer system600may include control logic608coupled to at least one of the processor(s)604, system memory612coupled to system control logic608, non-volatile memory (NVM)/storage616coupled to system control logic608, and one or more communications interface(s)620coupled to system control logic608. In various embodiments, the one or more processors604may be a processor core.

System control logic608for one embodiment may include any suitable interface controllers to provide for any suitable interface to at least one of the processor(s)604and/or to any suitable device or component in communication with system control logic608.

System control logic608for one embodiment may include one or more memory controller(s) to provide an interface to system memory612. System memory612may be used to load and store data and/or instructions, for example, for system600. In one embodiment, system memory612may include any suitable volatile memory, such as suitable dynamic random access memory (“DRAM”), for example.

System control logic608, in one embodiment, may include one or more input/output (“I/O”) controller(s) to provide an interface to NVM/storage616and communications interface(s)620.

NVM/storage616may be used to store data and/or instructions, for example. NVM/storage616may include any suitable non-volatile memory, such as flash memory, for example, and/or may include any suitable non-volatile storage device(s), such as one or more hard disk drive(s) (“HDD(s)”), one or more solid-state drive(s), one or more compact disc (“CD”) drive(s), and/or one or more digital versatile disc (“DVD”) drive(s), for example.

The NVM/storage616may include a storage resource physically part of a device on which the system600is installed or it may be accessible by, but not necessarily a part of, the device. For example, the NVM/storage616may be accessed over a network via the communications interface(s)620.

System memory612and NVM/storage616may include, in particular, temporal and persistent copies of interface-adaptive data exchange logic624. The interface-adaptive data exchange logic624may include instructions that when executed by at least one of the processor(s)604result in the system600practicing one or more of the operations described above for generator140and/or serializer150. In some embodiments, the interface-adaptive data exchange logic624may additionally/alternatively be located in the system control logic608.

Communications interface(s)620may provide an interface for system600to communicate over one or more network(s) and/or with any other suitable device. Communications interface(s)620may include any suitable hardware and/or firmware, such as a network adapter, one or more antennas, a wireless interface, and so forth. In various embodiments, communication interface(s)620may include an interface for system600to use NFC, optical communications (e.g., barcodes), BlueTooth or other similar technologies to communicate directly (e.g., without an intermediary) with another device.

For one embodiment, at least one of the processor(s)604may be packaged together with system control logic608and/or interface-adaptive data exchange logic624(in whole or in part). For one embodiment, at least one of the processor(s)604may be packaged together with system control logic608and/or interface-adaptive data exchange logic624(in whole or in part) to form a System in Package (“SiP”). For one embodiment, at least one of the processor(s)604may be integrated on the same die with system control logic608and/or interface-adaptive data exchange logic624(in whole or in part). For one embodiment, at least one of the processor(s)604may be integrated on the same die with system control logic608and/or interface-adaptive data exchange logic624(in whole or in part) to form a System on Chip (“SoC”).

Computer-readable media (including non-transitory computer-readable media), methods, systems and devices for performing the above-described techniques are illustrative examples of embodiments disclosed herein. Additionally, other devices in the above-described interactions may be configured to perform various disclosed techniques.