METHODS AND APPARATUS TO IMPROVE INTERPROCESS COMMUNICATION

Abstract

Methods, apparatus, systems and articles of manufacture are disclosed to improve interprocess communication. An example apparatus to improve network transmission efficiency of a sending peer includes an encoder interface to prevent an encoder from encoding data in a native format to a target format associated with a requesting peer in response to a transmission trigger, a composite interface description (CID) engine to generate architecture agnostic metadata of the data in the native format, a composite layout description (CLD) engine to generate architecture specific metadata of the data in the native format, the architecture specific metadata identifying offset values associated with elements of the data in the native format, and a client payload engine to improve the network transmission efficiency by sending unencoded data combined with the architecture agnostic metadata and the architecture specific metadata to the requesting peer having an architecture different than that of the sending peer.

Description

FIELD OF THE DISCLOSURE

This disclosure relates generally to information exchange, and, more particularly, to methods and apparatus to improve interprocess communication.

BACKGROUND

In recent years, server devices have collected information from ubiquitous network client devices, such as mobile telephones, tablets, personal computers, and the like. In some examples, the client devices perform one or more tasks to collect information as instructed by program(s) executing thereon. In response to a request from the client devices, the server devices store the collected information in a particular format for circumstances when requesting entities wish to retrieve the collected information. Because the different client devices, server devices and requesting entities may have different architecture types, the client devices encode their collected task information into one or more particular formats that can be read and/or otherwise processed by the server devices.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A is a schematic illustration of a network environment including a system to improve interprocess communication.

FIG. 1B is a schematic illustration of an example interprocess communication engine of FIG. 1A.

FIG. 2 is a schematic illustration of a sending client device constructed in accordance with the teachings of this disclosure.

FIG. 3A is an example composite interface description (CID) constructed in accordance with the teachings of this disclosure.

FIG. 3B is an example composite layout description (CLD) constructed in accordance with the teachings of this disclosure.

FIG. 4 is a schematic illustration of a receiving server device constructed in accordance with the teachings of this disclosure.

FIG. 5 illustrates example generation of a server-side CID and a server-side CLD constructed in accordance with the teachings of this disclosure.

FIG. 6 illustrates an example CID and an example CLD associated with enumeration data types.

FIG. 7 is an example enumeration resolution table (ERT) constructed in accordance with the teachings of this disclosure.

FIGS. 8-14 are flowcharts representative of example machine readable instructions that may be executed to implement the example sending client device of FIG. 2 and/or the example receiving server device of FIG. 4.

FIG. 15 is a block diagram of an example processor platform structured to execute the example machine readable instructions of FIGS. 8-14 to implement the example sending client device of FIG. 2 or the example receiving server device of FIG. 4.

DETAILED DESCRIPTION

Network applications may exchange data in response to one or more triggers, such as remote procedure calls (RPCs), in which an example first application (e.g., a networked server) sends a request having particular data fields, and expects a response from an example second application (e.g., a networked mobile peer device) including those same data fields. In some examples, the second application may send reports in response to triggers, such as periodic time durations, aperiodic time durations, scheduled time durations, memory storage capacity threshold values, sensor response events, and/or manual triggers. Data collected and/or otherwise acquired by the example second application may be stored on a client device that executes the second application, in which the collected data is stored in a memory and/or other storage in a native format, such as a binary format. Data stored in a binary format is typically architecture specific, in which different architectures utilize different byte sizes (e.g., 8-bits per byte, 16-bits per byte, etc.), different endianness (e.g., big-endian, little-endian, mixed-endian, etc.), and/or different offset alignments.

FIG. 1 is an example interprocess environment 100 having an example sending client device 102 communicatively connected to an example receiving server device 104 via an example network 106. In some examples, the sending client device 102 and the receiving server device 104 reside and/or otherwise operate on a common platform, in which communication therebetween employs a communication bus 188 instead of the example network 106. The example network 106 may employ any type of communication protocol (e.g., TCP/IP, socket communication protocol/interface, interprocess communication via I²C, shared memory, etc.) and include a wired network (e.g., CATS router/switch network), a wireless network (e.g., WiFi), and/or a cell-based network (e.g., GSM, CDMA, etc.). In still other examples, the network 106 is not employed and any other type of communication protocol may be employed within the same platform as a logical communication rather than a hardware-based communication. In operation, the example sending client device 102 performs one or more tasks, such as task process(es) 184, with an example client task engine 103 or a virtual machine (VM) 152 and sends (via an example sending client input/output (I/O) interface 112) collected and/or otherwise generated data (such as task data stored in an example payload storage 108 of the sending client device 102) to the example receiving server device 104 (via an example receiving server I/O interface 114) to be stored in an example server data store 116. While the illustrated example of FIG. 1 includes a single task process 184, examples disclosed herein may include any number of task processes. Prior to sending, traditional applications of the example sending client device 102 invoke an encoder 110 to encode the payload into a format that is compatible with the example receiving server device 104. In particular, the example encoder 110 encodes in a format that is compliant with an example decoder 118 of the example receiving server device 104. As such, in the event of any changes to device architecture and/or data schema, alterations of the corresponding example encoder 110 and example decoder 118 must be addressed to ensure successful communication therebetween. The example sending client device 102 may transmit one or more portions of the data in the example payload storage 108 in response to a request from the example receiving server device 104 and/or in response to any other type of trigger (e.g., time-based triggers managed by the sending client device 102, sensor based triggers managed by the sending client device 102, etc.).

However, because an architecture of the example sending client device 102 may differ from an architecture of the example receiving server device 104, the sending client device 102 includes the example encoder 110 to encode one or more portions of the data from a native binary format into a format that can be processed by the example receiving server device 104. For example, the encoder 110 may convert and/or otherwise encode the native binary (or portions thereof) to an extensible markup language (XML) format, an abstract syntax notation (ASN, e.g., ASN.1) format, a text format (e.g., ASCII), etc. In some examples, encoding the native binary to an alternate format results in a relatively larger data storage footprint. Additionally, the example encoder 110 of the sending client device 102 is unique to a predetermined format of interest that is to communicate with one or more receiving server device(s).

Example sending client devices, such as the example sending client device 102 of FIG. 1, typically have limited processing and/or storage resources. In some examples, the sending client device 102 is a wireless telephone with (a) power consumption capabilities that are limited by battery capacity, (b) storage size capabilities that are limited by on-board memory and/or (c) processing capabilities that are limited by on-board processing device(s). Additionally, when a binary is encoded into an alternate format, the alternate format of the data (e.g., human readable ASCII) is less secure during transmission as compared to the native binary format. Furthermore, in the event the example sending client device 102 and/or the example receiving server device 104 alters a schema for encoding and/or decoding operations, compatibility therebetween is disrupted, thereby requiring additional configuration operations to enable communication.

Example methods, apparatus, articles of manufacture and/or systems disclosed herein facilitate an improved manner of exchanging information between peers (e.g., the example sending client device 102 and the example receiving server device 104) of a network 106 (or within a common platform). As described in further detail below, an example client payload engine 150 facilitates sending data from the example sending client device 102 in a manner that preserves a native binary format that may have been generated by one or more task processes 184 of the example client task engine 103 and/or stored in the payload storage 108.

Such preservation of the native binary format reduces a computational burden of the example sending client device 102 that would otherwise traditionally occur when encoding the native binary to a human-readable format prior to sending to one or more destination peer(s). Furthermore, such preservation of the native binary format reduces a storage capacity requirement of the sending device 102 because native binary formats exhibit a relatively smaller storage footprint than data encoded in a human-readable format. Because transmitting the native binary format reflects a relatively lower bandwidth when compared to encoded versions of the binary into an alternate format, network transmission efficiency is improved. Moreover, by sending data in its native binary format, it exhibits superior security characteristics when compared to human-readable format(s), and consumes less bandwidth during transmission.

Additionally, and as described in further detail below, an example server payload engine 160 facilitates reception of data in the binary format from a sending peer that may exhibit architecture differences of the example receiving server device 104, thereby allowing the network transfer of the binary format to maintain its inherent security as compared to traditional human-readable format(s). An example enumeration engine 170 facilitates mapping of data composite types of ENUM between peers that may not operate with a similar architecture (e.g., different value mappings may be employed for ENUM elements, such as similar names having different values), as described in further detail below. An example translation engine 180 facilitates requests (e.g., translation requests to render data associated with a composite stored on the example receiving server device 104 (the receiving peer)) that may originate from one or more translation request entities 182 and/or the example receiving server device 104, as described in further detail below.

To facilitate the improved manner of exchanging information between peers (e.g., the example sending client device 102 and the example receiving server device 104), the example interprocess environment 100 includes an example metadata engine 136 communicatively connected to the example sending client device 102 and/or the example receiving server device 104 via at least one of the example network 106 and/or the example communication bus 188. In the illustrated example of FIG. 1A, the metadata engine 136, primarily used prior to run time, includes a composite interface description (CID) engine 120, a composite layout description (CLD) engine 126, and a task process compiler 186, discussed in further detail below.

In operation, the example sending client device 102 retrieves and/or otherwise receives one or more task process(es) 184 to be executed in a manner that retrieves and/or otherwise collects payload data to be stored in the example payload storage 108. As described above, the example sending client device 102 may be a device having limited processing and/or storage resources, but able to execute one or more task process(es) 184 to accomplish, for example, data acquisition operations. The example task process(es) 184 may be compiled into an executable format by an example task process compiler 186 of the example metadata engine 136. Payload data generated by the task process(es) 184 includes one or more associated composites. As used herein, a composite reflects a portion of a payload in the example payload storage 108 having data fields and/or data units. An example composite includes a C-structure having variable names, variable types and corresponding variable values (e.g., values for each variable name). One or more payloads stored in the example payload storage 108 may include any number and/or type of composite.

Traditional sending client devices 102 are typically instructed to send and/or otherwise transmit one or more payloads that will invoke the example encoder 110 to encode a native binary of the requested composite to a format expected by the example receiving server device. However, examples disclosed herein improve bandwidth utilization during the sending process by preventing the encoder (e.g., for legacy peers having an encoder) from encoding the composite(s), thereby allowing the sending of data to a peer (e.g., the example receiving server device 104) in its native binary format. Additionally, because the composite is sent in its native binary format, the composite is more secure by preventing a human-readable format from being rendered in the event of interception and/or network sniffing. In some examples, the native binary format, as distinguished from a human-readable format, is considered security by way of obscurity.

FIG. 1B includes additional detail associated with the example metadata engine 136 of FIG. 1A. In the illustrated example of FIG. 1B, the CID engine 120 also includes a CID pointer manager 122 and a CLD file generator 124. Additionally, the example CLD engine 126 also includes an example CLD pointer manager 128, an example CLD file generator 130, and an example payload analyzer 132. In response to the example task process compiler 186 compiling a task process 184, the example CID engine 120 generates a CID associated with the composite to be sent. Generally speaking, and as described in further detail below, composite metadata facilitates shorthand reference to an associated CID and CLD of the composite. As described in further detail below, the CID is an architecture agnostic textual or combined binary and textual description of the composite, which includes a definition of a type of the composite (e.g., a C-structure, etc.), a name of the composite, and a list of composite element names and corresponding types and array dimensions. Additionally, the example CLD engine 126 generates a CLD associated with the composite to be sent. As described in further detail below, the CLD is an architecture specific textual or combined textual/binary description of the composite, which includes a size of the composite (e.g., a number of bytes), a number of elements in the composite, and a byte offset values for respective elements within the binary image.

Taken together, the example CID and the CLD represent the composite metadata, which is compiled into the task process 184 or, in the case of virtualized languages like JAVA, the composite metadata is stored in a virtual machine (VM) 152 and/or stored in the example payload storage 108 of the sending client device 102. After the example task process 184 is compiled and the metadata is included therein, the example metadata engine 136 is no longer needed during run time. Generally speaking, after the example CID engine 120 generates the CID associated with the composite and the example CLD engine 126 generates the CLD associated with the composite, any future reference to the composite (and the associated CID and CLD) to be sent may be referenced via the example metadata reference to conserve processing resources of the example sending client device 102. The generated composite metadata, which includes the CID and the CLD, is later retrieved during run time by an example metadata reference manager 134 (in circumstances of a compiled task process 184), or retrieved from the VM 152 and associated with a unique metadata reference (e.g., textual and/or numeric nomenclature to identify the composite metadata), in which other devices using this reference can generate consistent results despite any architecture differences that may exist therebetween. The example metadata reference manager 134 is located in the example client payload engine 150 and described in further detail below.

FIG. 2 is a schematic illustration of the example sending client device 102 of FIG. 1, and includes additional detail related to managing data stored in the example payload storage 108 and/or generated by one or more task process(es) 184 of the example client task engine 103. In the illustrated example of FIG. 2, the sending client device 102 includes the client task engine 103 having one or more executable task process(es) 184, the payload storage 108, the encoder 110 (e.g., a legacy encoder), and the sending client I/O interface 112 communicatively connected to the network 106 and/or communication bus 188, as described above in connection with FIG. 1. Additionally, the example sending client device 102 of FIG. 2 includes the example VM 152, the example client payload engine 150, an example client payload monitor 204, an example encoder interface 208, an example task storage interface 210, and the example metadata reference manager 134.

In operation, the example client payload monitor 204 determines whether the example payload storage 108 includes information that is to be sent and/or otherwise transmitted to the example receiving server device 104. In some examples, the client payload monitor 204 responds to one or more triggers to identify available information in the payload storage 108, such as a request from the receiving server device 104 (e.g., a remote procedure call (RPC), a time-based trigger, a sensor based trigger and/or a trigger based on a threshold capacity of stored information in the payload storage 108. When the example client payload monitor 204 is to send payload information, the example metadata reference manager 134 extracts and/or otherwise retrieves the metadata compiled in the task process 184 to facilitate improved payload transmission between peers that may have architecture differences. In the event non-compiled (virtualized) tasks are invoked (e.g., tasks executed with the example VM 152), the example metadata reference manager 134 extracts and/or otherwise retrieves the associated metadata from the VM 152 or payload storage 108.

FIG. 3A illustrates an example CID 300 generated by the example CID engine 120. In the illustrated example of FIG. 3A, the CID 300 includes a composite type 302 (“struct”), a composite name 304 (“foos1”), composite element names 306, and corresponding composite element types 308. As described above, the CID includes architecture agnostic textual descriptions of the composite, which is a C-structure in the illustrated example of FIG. 3A. Additionally, the example CID 300 may be stored in the example payload storage 108 as a file (e.g., a CID file), which may be a portion of the example composite metadata.

FIG. 3B illustrates an example CLD 350 generated by the example CLD engine 126. In the illustrated example of FIG. 3B, the CLD 350 includes a size identifier 352 of an example composite and a corresponding size value 354, a number of elements identifier 356 and a corresponding elements value 358, and offset identifiers 360 with corresponding binary offset values 362. Additionally, the example CLD 350 may be stored in the example payload storage 108 as a file (e.g., a CLD file), which may be a portion of the example composite metadata. Taken together, the example composite metadata includes the example CID 300 and the example CLD 350.

To build and/or otherwise generate the example CID 300, the example CID pointer manager 122 retrieves a composite associated with the task process 184 that is to be compiled by the task process compiler 186. Generally speaking, composite information, such as variable types, variable names, offset values, and/or size information are available to and/or otherwise resolved by compilers. As such, the example task process compiler 186 is of a type that is consistent and/or otherwise associated with an architecture type for the device on which a corresponding executable will execute. An example CLD structure (binary) definition handled by the example task process compiler 186 is shown below in Table 1.

TABLE 1
typedef struct
{
uint16_t nbr_earfcn;
uint16_t nbr_phys_cell_id;
uint8_t freq_band_ind;
uint8_t nbr_rsrp;
uint8_t nbr_rsrq;
}CellMeasResult;

Additionally, the corresponding textual CID is shown below in Table 2.

TABLE 2
const char* CellMeasResult_cid =
“\
uint16_t nbr_earfcn;\
uint16_t nbr_phys_cell_id;\
uint8_t freq_band_ind;\
uint8_t nbr_rsrp;\
uint8_t nbr_rsrq;\
“

Further, the example task process compiler 186 may compile the binary CLD as shown below in Table 3.

TABLE 3
typedef struct
{
uint32_t size;
uint16_t number_of_elements;
uint16_t offset[5];
} CellMeasResult_CLD8;
CellMeasResult_CLD8 CellMeasResult_info =
{{sizeof(CellMeasResult),5, },{offsetof(CellMeasResult,nbr_earfcn),
offsetof(CellMeasResult,nbr_phys_cell_id), offsetof(CellMeasResult,freq_band_ind),
offsetof(CellMeasResult,nbr_rsrp),
offsetof(CellMeasResult,nbr_rsrq)}}

The example CID file generator 124 generates a CID shell file to populate with architecture agnostic information associated with the composite, and the example CID pointer manager 122 identifies the beginning of the binary composite with a pointer to parse the composite for information for each element contained therein. For each element in the binary composite, the example CID file generator 124 encodes information to the CID 300 as text. When all elements have been encoded to the CID 300, the example CLD pointer manager 128 retrieves the composite associated with the task process 184 that is to be compiled by the task process compiler 186, and the example CLD file generator 130 generates a CLD shell file to populate with architecture specific information associated with the composite. The example payload analyzer 132 identifies a size of the composite and writes it to the CLD shell file and identifies a number of elements of the composite and writes that value to the CLD shell file (see elements 352, 354, 356 and 358) of the example CLD 350). Based on the number of elements of the composite, the example CLD pointer manager 128 increments and/or otherwise parses the composite binary a corresponding number of times to identify each element, identify its corresponding binary offset value, and the example payload analyzer 132 writes that information to the CLD shell file. In some examples, the example payload analyzer 132 determines an endianness value of the example binary composite, if available, and writes the same to the CLD shell file. In the event of any sub-composites within a composite, such sub-composites will have their own similar metadata definition(s) determined in a manner similar to the above.

The example metadata reference generator 134 sends the CID 300 and CLD 350 to the sending client device 102 as composite metadata for future use to facilitate improved data transfer/transmission to a targeted peer (e.g., the example receiving server device 104). In some examples, when the task process 184 of the sending client device is ready to transmit available payload data to a target peer, such transmission may proceed without further involvement by the example metadata engine 136. However, in the event one or more additional and/or alternate task process(es) 184 are to be provided to the example sending client device for payload data collection, then the example metadata engine 136 repeats the above disclosed examples to generate a corresponding executable and one or more instances of composite metadata (e.g., CID, CLD) for corresponding composites.

As described above, one or more task process(es) 184 are associated with virtualized languages (e.g., JAVA®, C#) rather than compiled (e.g., native) languages (e.g., C, C++). In such circumstances, the example CID and CLD are generated by reflection with cooperation from the example VM 152. For example, the metadata reference manager 134 (see the example payload engine 150 of the sending client device 102) queries the VM 152 of the sending client device 102 to determine one or more variable types and/or variable names available for the composites associated with the virtualized task process 184. Additionally, because virtual machine based languages (e.g., JAVA®, C#) do not include offset information, elements are packed back-to-back with or without padding bytes. In some examples, virtualized tasks do not need a CLD, particularly when one or more padding techniques are employed. Still further, VMs in one or more different locations (e.g., the VM 152 of the sending client device 102, the VM 152 of the receiving server device 104) may be synchronized and/or otherwise registered by the example metadata engine 136 to ensure task process consistency between two or more peers.

In response to a trigger (e.g., a request for payload data), the example task storage interface 210 of FIG. 2 determines whether the composite metadata, which includes the example CID 300 and the example CLD 350 and is associated with a particular metadata reference, has been sent to the example receiving server device 104 on a prior occasion. If not, then the example client payload engine 150 sends both (a) the native binary (e.g., a portion of the payload containing the binary composite of interest), (b) the composite metadata, and (c) a metadata reference to be used when making any future reference to the binary composite and/or its associated composite metadata. In some examples, the client payload engine 150 sends (a) the native binary and (b) the metadata reference under the assumption that any receiving peer has already received and/or otherwise has the composite metadata. If not, such as when the composite metadata has not been previously sent, or the receiving peer no longer has the previously received composite metadata, then the example receiving I/O interface 114 generates a request command. When the request command is received by the example client payload engine 150, the composite metadata is sent to the example receiving peer (e.g., the receiving server device 104).

As described in further detail below, sending the composite metadata along with the native binary allows the example receiving server device 104 to decode the native binary upon receipt, which allows computational efficiency improvements of the example sending client device 102 by avoiding encoding effort(s). Additionally, because the example sending client device 102 may send the native binary without expending encoding resources/effort, the example sending client device 102 conserves on-board power (e.g., battery) resources, consumes a lower transmission bandwidth (improves transmission efficiency) and, because native binary formats include a relatively smaller storage footprint than human readable format(s), the example sending client device 102 conserves on-board storage (e.g., on-board memory, RAM, FLASH, etc.) resources. Furthermore, in the event the example sending client device 102 changes its schema related to the composite binaries generated, sending compatibility is not disrupted between sending/receiving peers and, instead, schema updates (e.g., architecture changes, changes in binary offset values associated with composite elements, etc.) may be managed with updated composite metadata.

In some examples, the sending client device 102 has previously sent the composite metadata associated with the composite to the example receiving server device 104. Accordingly, the example receiving server device 104 already has a stored copy of (a) the composite metadata and (b) the metadata reference. Thus, rather than sending all three of the (a) composite metadata, (b) the metadata reference and (c) the composite binary, the example client payload engine 150 sends only the metadata reference and the composite binary, as described above. The example receiving server device references a previously stored copy of the composite metadata to allow the composite binary to be translated (e.g., translated into an alternate format, such as text, XML, an alternate binary associated with the receiving peer architecture, etc.).

FIG. 4 is a schematic illustration of the example receiving server device 104 of FIG. 1A, and includes additional detail related to processing data received by the example sending client device 102. In some examples, processing data includes resolving data, such as a composite binary retrieved by a sending peer that has an architectural format that is different than the receiving peer. In the illustrated example of FIG. 4, the receiving server device 104 includes the example receiving server I/O interface 114 communicatively connected to the example network 106, the example decoder 118, the example server data store 116, and the example VM 152, as described above in connection with FIG. 1A. Additionally, the example receiving server device 104 of FIG. 4 includes the example server payload engine 160, an example server payload monitor 404, an example server metadata manager 406, an example server storage interface 408, an example decoder manager 410, an example enumeration engine 170, an example resolution table manager 414, an example exception generator 416, an example translation engine 180, an example request manager 420, an example format resolver 422, an example translator system 424, the example exception generator 416, and example format encoders 426 to, in part, encode payload data into a desired format of one or more requesting entities, such as one or more requests from the example translation request entities 182.

In operation, the example server payload monitor 404 determines whether a payload has been received via the example receiving server I/O interface 114. As described above, the example sending client device 102 may send payload data in response to a trigger, such as a trigger initiated by the example receiving server device 104. If payload information has been received, then the example server metadata manager 406 determines whether the received payload data also includes a matching composite metadata reference. As described above, when the example sending client device 102 provides composite metadata (e.g., the example CID 300 and the example CLD 350), an associated composite metadata reference is also associated, matched and/or otherwise tagged to the composite metadata for future reference. Assuming for this example that the received payload (e.g., a received binary composite, a received metadata reference, and received metadata composite information) occurs for the first time, then the example server storage interface 408 extracts the received metadata composite information to identify the corresponding CID and CLD. The extracted CID (e.g., the example CID 350 of FIG. 3A) and the extracted CLD (e.g., the example CLD 350 of FIG. 3B) are stored in the example server data store 116 and associated with the extracted metadata reference nomenclature (e.g., “SF1”). As such, in the event another binary composite is sent having the same schema (e.g., composite metadata having the same CID and the same CLD), then the example receiving server device 104 may retrieve that from the server data store 116, which conserves processing resources of the receiving server device 104 during one or more subsequent requests to obtain and/or otherwise render data stored within a requested composite. In effect, when the metadata reference from the example sending client device 102 (e.g., sending peer) matches the metadata reference from the example receiving server device 104 (e.g., receiving peer), efforts to re-build and/or otherwise populate the CID and CLD information are bypassed.

However, because the example sending client device 102 and the example receiving server device 104 may each have a unique and/or otherwise different architecture, the received payload from the sending client device 102 may not be compatible with the receiving server device 104. As such, the example server metadata manager 406 generates its own server-side CID file and server-side CLD file to accommodate for and/or otherwise resolve any architecture differences. In some examples, the server metadata manager 406 includes one or more elements as shown in FIG. 1B to generate the server-side CID file and the server-side CLD file, in which the example task process compiler is capable of compiling task processes for a particular architecture type of the example receiving server device 104. In still other examples, the server metadata manager 406 is communicatively connected to a metadata engine that is compatible with the architecture associated with the example receiving server device 104.

In the illustrated example of FIG. 5, the example CID 300 generated by the example CID engine 120 has been translated by the example translation engine 180 and stored in the example server data store 116. Additionally, the example CLD 350 generated by the example CLD engine 126 has been translated by the example receiving server device 104 and stored in the example server data store 116. Taken together, the example CID 300 and the example CLD 350 produce composite metadata 575 (see dotted line). As described above in connection with FIG. 3A, the example CID 300 includes a composite type 302 (“struct”), a composite name 304 (“foos1”), composite element names 306 and corresponding composite element types 308. While the illustrated example of FIG. 5 includes a composite type of “struct,” examples disclosed herein are not limited thereto. In some examples, the composite may be of type enumeration (ENUM), in which one or more elements are resolved, as described in further detail below.

The server-side CID 500 may have its own unique definition with more or less elements, in which only those matching between peers will allow translating. For those one or more elements that do not include corresponding matches between peers, they may be ignored and/or exception errors may be generated by the example exception generator 416 to convey partial decoding capabilities therebetween. When comparing and/or translation is complete, the example server-side CID 500 will also include a composite type 502, a composite name 504, composite element names 506 and corresponding composite element types 508. Additionally, the example server-side CID 500 will be associated with the same metadata reference nomenclature that was originally established by the example sending client device 102. In the illustrated example of FIG. 5, the CID 300 was associated with a metadata reference “SF1” 310, which is also attributed to the server-side CID 500 (see element 510).

As described above in connection with FIG. 3B, the example CLD 350 includes a size identifier 352 of the composite and a corresponding size value 354, a number of elements identifier 356 and a corresponding elements value 358, and offset identifiers 360 with corresponding binary offset values 362. The example server metadata manager 406 also generates the server-side CLD 550 and populates it with one or more portions of the data that translated from the received CLD 350 by the translation engine 180. In particular, when initial comparing/translation is complete, the example CLD 550 will reflect a degree of parity with the received CLD 350 by including a size identifier 552, a number of elements identifier 556, and offset identifiers 560. If the architecture of the example receiving server device 104 is dissimilar to the architecture of the sending client device 102, the example translation engine 180 determines appropriate values for the size, number of elements and/or binary offsets to be written to the example server-side CLD 550 based on a respective architecture type of the receiving server device 104.

In some examples, a mapping table resolves sender metadata and receiver metadata. In the illustrated example of FIG. 5, the translation engine 180 has determined that, based on the architecture of the receiving server device 104, the size of the binary composite is “74” (rather than a size of “80” from the sending client device 102). Similarly, the example translation engine 180 has identified particular ones of server-side CLD 550 binary offset values 562 that are to be adjusted to conform to requirements of the architecture of the receiving server device 104 (e.g., offset value of element A.sb is “4” on the sending client device 102, but is “2” on the receiving server device 104).

When the binary composite is received and/or otherwise retrieved by the example receiving server device 104 in the future (e.g., when the binary composite contains different payload data, but exhibits the same schema/composite format), then the receiving server device 104 can identify matching metadata and map to correct offset locations. In some examples, the server metadata manager 406 generates side-by-side comparison tables as shown in the illustrated example of FIG. 5 to serve as a metadata resolution table for comparison. The example translation engine 180 obtains the retrieved CID 300 and corresponding metadata reference (e.g., “SF1” 310), and queries the example server data store 116 to identify/compare a matching metadata reference (e.g., “SF1” 510). If found, the example translation engine 180 may bypass any operations to re-populate the server-side CID 500 and/or the server-side CLD 550 and, instead, retrieves the previously stored server-side CID 500 and compares them to verify parity therebetween.

When one or more differences between the retrieved CID 300 and the stored server-side CID 500 are identified, then one or more exceptions may be invoked and/or otherwise generated by the example exception generator 416 of the translation engine 180 to identify data corruption and/or data mismatch. Additionally, the example translation engine 180 obtains the retrieved CLD 350 and corresponding metadata reference (e.g., “SF1” 310), and queries the example server data store 116 to identify a matching metadata reference (e.g., “SF1” 510). If found, the example translation engine 180 retrieves the previously stored server-side CLD 550 and compares it with the retrieved CLD 350 to identify differences in offset values. Knowledge of the offset values in the retrieved CLD 350 permits the example receiving server device 104 to extract stored data within the composite binary that is associated with a particular element, and then store it in the example server data store 116 in a binary format that complies with the particular hardware architecture of the receiving server device 104.

Additionally, in the event the example receiving server device 104 is to perform a translation request that generates an alternate format of the retrieved binary composite for a translation request entity 182 (e.g., third party requestors (e.g., one of the translation request entities 182) that need the binary composite information rendered in XML), then the example server-side CLD 550 allows the example translator system 424 to retrieve the stored binary composite (e.g., in a binary format native to the receiving server device 104 rather than native to the sending client device 102), identify accurate locations within the binary for one or more elements of interest, and invoke an appropriate format encoder 426 to render payload data to the desired alternate format for further transmission/distribution. While the illustrated example of FIG. 1 shows translation request entities 182 outside the receiving server device 182 outside the receiving server device 104, some examples may include one or more translation request entities 182 within the receiving server device 104. In either case, if the translation request entities 182 have their own CID/CLD (metadata), then they are compared to any metadata associated with the sending client device 102 to resolve architectural differences, as described above.

When the request manager 420 identifies a translation request (e.g., a third party request to the example receiving server device 104 to obtain composite data in a particular format), the example format resolver 422 identifies a type of the format desired. The example format resolver 422 queries the example server data store 116 to determine whether the desired format of the requested composite is already available and, if so, the example translation engine 180 retrieves the decoded composite from storage and forwards it to the requestor via the example receiving server I/O interface 114. In some examples, the requested composite is already available because it was saved to the example server data store 116 in response to one or more prior efforts to decode the binary composite into a desired format requested by a third party translation request.

On the other hand, if the desired format of the requested composite is not available in the example server data store 116 (e.g., this is the first time a translation request has been invoked for the composite binary of interest), then the example format resolver 422 identifies a first composite element from the server-side CID 500, and identifies a corresponding composite element from the server-side CLD 550 containing an offset value associated with elements of the composite binary stored in the example server data store 116. Based on respective offset values for elements of the composite binary, the example translator system 424 obtains the data located in the composite binary and invokes a corresponding format encoder 426 to translate the data to a format associated with the requestor (e.g., translation to text, translation to XML, translation to JSON, etc.). The format encoders 426 may include any number of encoder types, each one capable of encoding into a particular format. In some examples, the translator system 424 invokes a format encoder 426 to translate from a native binary into text, a native binary into XML, a native binary into JSON, etc. As the example translation engine 180 translates each element of the target composite binary stored in the example server data store 116, it stores (e.g., in the example server data store 116) aggregated composite elements to an output file having the desired format. The example translation engine 180 then sends the translated file to the requestor via the example receiving server I/O interface 114.

As described above, in some examples the composite is of type ENUM, which requires further resolution between elements to resolve one or more nomenclature disparities of a composite ENUM from the sending peer as compared to a composite ENUM from the receiving peer. FIG. 6 illustrates example CID and CLD tables associated with enumeration (ENUM) composite types. In some examples, the server payload monitor 404 detects a particular payload type and/or a particular type of composite stored in the payload. For example, in the event the example server payload monitor 404 detects that a received composite binary is of type ENUM, then the example enumeration engine 170 facilitates a translation of ENUM data between the received composite binary (from the example sending client device 102), and an ENUM format implemented on the example receiving server device 104. Generally speaking, while the data associated with an ENUM from the example sending client device 102 (e.g., sending peer) may be referencing the same data as an ENUM from the example receiving server device 104 (e.g., receiving peer), each of the devices may implement the ENUM with some differences in reference nomenclature. Enumeration structures represent a list of named values, which are abstracted using corresponding names in which a compiler will resolve the actual value based on the names/nomenclature. However, when communicating in a network of peers (e.g., the example sending client device 102 and the example receiving server device 104) that are not compiled together and/or have different architectures, resolution is not possible unless the ENUM is first translated into a non-binary (e.g., text) format. As discussed above, conversion from binary to one or more alternate formats results in a bloated storage footprint and computational strain during an encoding process. Thus, to allow coordination between the example sending client device 102 and the example receiving server device 104, the example enumeration engine facilitates translation therebetween while avoiding encoding overhead and/or preventing binary translation efforts when resolving one or more disparities.

In the illustrated example of FIG. 6, a CID 600 from a peer (e.g., from the sending client device 102) on the network 600 includes a composite structure of type enumeration (ENUM), as identified by a composite type identifier 602. The example CID 600 also includes an ENUM tag 604 having a name “colors.” In some examples, the ENUM tag 604 is referred to as an ENUM name. The example CID 600 also includes element names 606, in which some of the elements include a corresponding target value (e.g., yellow=900, black=1000). For those elements not including an initial explicit target value (e.g., red, green, blue, etc.), an implicit value is sequentially assigned. For instance, red is assigned zero (0), green is assigned one (1), etc. In some examples, selection and/or identification of an ENUM element may occur by way of reference to an element name (e.g., “yellow”), an element target value (e.g., “900”), or an element binary position within the list of ENUM elements (e.g., “3,” which refers to the fourth element in a zero-based binary list). FIG. 6 also includes a CLD 610 from the peer (e.g., from the sending client device 102), which includes information related to the size of the ENUM composite. In the illustrated example of FIG. 6, the size of the ENUM composite is “2,” which reflects a byte value indicative of sixteen (16) bits. As described in further detail below, the example CID 600 and the example CLD 610 are sent to the example translation engine 180 or ENUM engine 170 in response to an instance of an ENUM composite type to be mapped.

FIG. 6 also includes a CID 612 from a separate peer (e.g., from the receiving server device 104) on the network 600. In the illustrated example of FIG. 6, the CID 612 includes an ENUM type 614 having an ENUM tag 616 named “colors,” thereby indicating a match with any other ENUM composite to be mapped on the example network 600. The example CID 612 includes element names 618, in which some of the elements include a corresponding target value (e.g., green=50, yellow=700, etc.). As described above, those elements without an explicit value are sequentially assigned implicit values (e.g., red is assigned zero (0), grey is assigned one thousand and one (1001), etc.). FIG. 6 also includes a CLD 620 from the separate peer (e.g., from the receiving server device 104), which includes information related to the size of the ENUM composite. In the illustrated example of FIG. 6, the size of the ENUM composite is “4,” which reflects a byte value indicative of thirty-two (32) bits. The example CID 612 and the example CLD 620 are sent to the example decoder 618 in response to an instance of an ENUM composite type to be mapped.

As described above, traditional approaches to mapping and/or otherwise resolving disparities between ENUM composite types required coordination between peers to encode and/or otherwise translate the ENUM into a standard format, which causes an original binary format to be converted into a relatively larger memory storage footprint and causes a corresponding greater bandwidth consumption, requires encoding resources, and decreases data security during a data transfer (e.g., the encoded standard type becomes human readable text). Examples disclosed herein conserve a memory storage footprint, conserve bandwidth consumption, reduce and/or eliminate encoding resources, and improve data security during a data transfer.

The example resolution table manager 114 of the example receiving server device 104 determines whether an enumeration resolution table (ERT) has previously been generated and, if not, an ERT (e.g., an initially blank shell file) is generated based on CID and CLD information sharing a matching composite tag. The example resolution table manager may save the ERT as a file in the example server data store 116. FIG. 7 illustrates an example ERT 700 populated with CID and CLD information from a pair of peers (e.g., the example sending client device 102 and the example receiving server device 104) on the example network 600. In the illustrated example of FIG. 7, the ERT 700 includes a first peer column 702 (e.g., “Peer 1”) and a second peer column 704 (e.g., “Peer 2”). Additionally, for each of the example first peer column 702 and the example second peer column 704, the ERT 700 includes an example composite type identifier 706, an example composite name identifier 708, an example composite size identifier 710, and example composite element(s) identifier(s) 712. For each of the example first peer column 702 and the example second peer column 704, the example composite elements identifiers 712 include an element index column 714, an element name column 716 and an element value column 718 (e.g., a target value). Additionally, the example composite elements identifiers 712 include an element parity column 720 to identify whether composite positions for particular elements of the first and second peers match, and a secondary resolution column 722 to identify whether one or more alternate identifiers (excluding an element index position) can be used to match elements between the example first peer 702 and the example second peer 704. In other words, the example secondary resolution column 722 reflects mapping links between respective ENUM elements between the example first peer 702 and the example second peer 704.

To determine which elements match between ENUMs of the example first peer 702 and the example second peer 704, the example exception generator 416 of the ENUM engine 170 determines whether an element position mismatch occurs. In particular, the example exception generator 416 identifies a first element position of both peers (e.g., the zero “0” bits of the element index position columns 714) and determines whether a corresponding element name (e.g., the element name “red” in the element name columns 716) matches. If so, then the element associated with the evaluated element index position (e.g., index position zero “0”) is deemed to be a match, in which the example resolution table manager 414 sets a value of TRUE in the example element parity column 720.

On the other hand, in the event the example exception generator 416 identifies a mismatch of an element position between peers (see row 724 of FIG. 7), then the example exception generator 416 determines if a secondary resolution parameter indicates a candidate match with a different element (e.g., a separate element having an alternate element index value). In the illustrated example of FIG. 7, index position “2” (row 724) for Peer 1 702 is associated with element name 716 “blue,” but index position “2” for Peer 2 704 is associated with element name 716 “yellow,” thereby indicating a mismatch. As such, the example resolution table manager 414 sets a value of FALSE in the example element parity column 720 associated with index position “2” (row 724). Despite the identified mismatch of index position “2” between the example first peer 702 and the example second peer 704, the example exception generator 416 uses a secondary resolution parameter results in a match. In particular, the example exception generator 416 uses a secondary resolution parameter of the element name “blue” from the example first peer 702 and searches all element names of the example second peer 704 for a matching element name “blue.” In the illustrated example of FIG. 7, no match is identified in the example second peer 704, and the example exception generator 416 invokes an exception for any element associated with the element name “blue.” While the illustrated example employs element names as the secondary resolution approach, examples disclosed herein are not limited thereto. In some examples, the primary technique to identify any differences between peers with ENUMs may employ element names only.

Despite the mismatch between the example first peer 702 and the example second peer 704 associated with the element name “blue,” one or more other elements therebetween may still indicate matches that can be used to resolve differences between the ENUMs of the example first peer 702 and the example second peer 704. For example, the example exception generator 416 also identifies a mismatch of an index position between peers for index position “3” (see row 726 of FIG. 7) because the example element name “yellow” in index position “3” for the first peer 702 does not match the element name “black” in index position “3” for the second peer 704. However, when the example exception generator 416 searches alternate index positions for the element name “yellow,” a match is identified in index position “2” for the second peer 704. As such, the example resolution table manager 414 populates the secondary resolution column 722 for bit position “3” with a mapping indicator that the first peer 702 matches index position “2” of the second peer 704.

When the example ERT 700 has been populated with resolved mapping information, the example enumeration engine 170 stores the ERT in the example server data store 116 in the event one or more future requests for mapping the ENUM “colors” is requested. For example, in the event the example enumeration engine 170 retrieves and/or otherwise receives a binary input query value of “1” associated with an ENUM named “colors” from the example first peer 702, then it invokes the example resolution table manager 414 to retrieve a corresponding target value for the appropriate ENUM named “colors” from the example second peer 704 by referencing the ERT 700. Because the example input query value of “1” is associated with element name “green” from the first peer 702, then a corresponding value from the second peer 704 of “50” is resolved (see row 728 of FIG. 7). While examples disclosed above illustrate a use case where the sending client device 102 is prevented from computationally intensive translations when sending payload data to the receiving server device 104, such examples are limited thereto. In some examples, the receiving server device 104 may send payload data to the sending client device 102 in a similar manner.

While an example manner of implementing the client payload engine 150, the server payload engine 160, the enumeration engine 170 and the translation engine 180 of FIG. 1 is illustrated in FIGS. 2, 3A, 3B and 4-7, one or more of the elements, processes and/or devices illustrated in FIGS. 1, 2, 3A, 3B and 4-7 may be combined, divided, re-arranged, omitted, eliminated and/or implemented in any other way. Further, the example sending client device 102, the example receiving server device 104, the example client task engine 103, the example payload storage 108, the example encoder 110, the example sending client I/O interface 112, the example receiving server I/O interface 114, the example server data store 116, the example decoder 118, the example metadata engine 136, the example task process compiler 186, the example VM 152, the example client payload monitor 204, the example metadata reference generator 134, the example encoder interface 208, the example task storage interface 210, the example CID engine 120, the example CID pointer manager 122, the example CID file generator 124, the example CLD engine 126, the example CLD pointer manager 128, the example payload analyzer 132, the example CLD file generator 130, the example server payload monitor 404, the example server metadata manager 406, the example server storage interface 408, the example decoder manager 410, the example resolution table manager 414, the example exception generator 416, the example request manager 420, the example format resolver 422, the example translator system 424, the example format encoders 426 and/or, more generally, the example client payload engine 150, the example server payload engine 160, the example enumeration engine 170 and the example translation engine 180 of FIGS. 1, 1B, 2 and 4 may be implemented by hardware, software, firmware and/or any combination of hardware, software and/or firmware. Thus, for example, any of the example sending client device 102, the example receiving server device 104, the example client task engine 103, the example payload storage 108, the example encoder 110, the example sending client I/O interface 112, the example receiving server I/O interface 114, the example server data store 116, the example decoder 118, the example metadata engine 136, the example task process compiler 186, the example VM 152, the example client payload monitor 204, the example metadata reference generator 134, the example encoder interface 208, the example task storage interface 210, the example CID engine 120, the example CID pointer manager 122, the example CID file generator 124, the example CLD engine 126, the example CLD pointer manager 128, the example payload analyzer 132, the example CLD file generator 130, the example server payload monitor 404, the example server metadata manager 406, the example server storage interface 408, the example decoder manager 410, the example resolution table manager 414, the example exception generator 416, the example request manager 420, the example format resolver 422, the example translator system 424, the example format encoders 426 and/or, more generally, the example client payload engine 150, the example server payload engine 160, the example enumeration engine 170 and the example translation engine 180 of FIGS. 1, 1B, 2 and 4 could be implemented by one or more analog or digital circuit(s), logic circuits, programmable processor(s), application specific integrated circuit(s) (ASIC(s)), programmable logic device(s) (PLD(s)) and/or field programmable logic device(s) (FPLD(s)). When reading any of the apparatus or system claims of this patent to cover a purely software and/or firmware implementation, at least one of the example sending client device 102, the example receiving server device 104, the example client task engine 103, the example payload storage 108, the example encoder 110, the example sending client I/O interface 112, the example receiving server I/O interface 114, the example server data store 116, the example decoder 118, the example metadata engine 136, the example task process compiler 186, the example VM 152, the example client payload monitor 204, the example metadata reference generator 134, the example encoder interface 208, the example task storage interface 210, the example CID engine 120, the example CID pointer manager 122, the example CID file generator 124, the example CLD engine 126, the example CLD pointer manager 128, the example payload analyzer 132, the example CLD file generator 130, the example server payload monitor 404, the example server metadata manager 406, the example server storage interface 408, the example decoder manager 410, the example resolution table manager 414, the example exception generator 416, the example request manager 420, the example format resolver 422, the example translator system 424, the example format encoders 426 and/or, more generally, the example client payload engine 150, the example server payload engine 160, the example enumeration engine 170 and the example translation engine 180 of FIGS. 1, 1B, 2 and 4 is/are hereby expressly defined to include a tangible computer readable storage device or storage disk such as a memory, a digital versatile disk (DVD), a compact disk (CD), a Blu-ray disk, etc. storing the software and/or firmware. Further still, the example client payload engine 150, the example server payload engine 160 and/or the example enumeration engine 170 of FIG. 1 may include one or more elements, processes and/or devices in addition to, or instead of, those illustrated in FIGS. 1, 1B, 2 and/or 4, and/or may include more than one of any or all of the illustrated elements, processes and devices.

Flowcharts representative of example machine readable instructions for implementing the client payload engine 150, the server payload engine 160 and/or the enumeration engine 170 of FIGS. 1, 1B, 2 and 4 is/are shown in FIGS. 8-14. In these examples, the machine readable instructions comprise one or more programs for execution by a processor such as the processor 1512 shown in the example processor platform 1500 discussed below in connection with FIG. 15. The program(s) may be embodied in software stored on a tangible computer readable storage medium such as a CD-ROM, a floppy disk, a hard drive, a digital versatile disk (DVD), a Blu-ray disk, or a memory associated with the processor 1512, but the entire program(s) and/or parts thereof could alternatively be executed by a device other than the processor 1512 and/or embodied in firmware or dedicated hardware. Further, although the example program(s) is/are described with reference to the flowcharts illustrated in FIGS. 8-14, many other methods of implementing the example client payload engine 150, the example server payload engine 160 and/or the example enumeration engine 170 may alternatively be used. For example, the order of execution of the blocks may be changed, and/or some of the blocks described may be changed, eliminated, or combined.

As mentioned above, the example processes of FIGS. 8-14 may be implemented using coded instructions (e.g., computer and/or machine readable instructions) stored on a tangible computer readable storage medium such as a hard disk drive, a flash memory, a read-only memory (ROM), a compact disk (CD), a digital versatile disk (DVD), a cache, a random-access memory (RAM) and/or any other storage device or storage disk in which information is stored for any duration (e.g., for extended time periods, permanently, for brief instances, for temporarily buffering, and/or for caching of the information). As used herein, the term tangible computer readable storage medium is expressly defined to include any type of computer readable storage device and/or storage disk and to exclude propagating signals and to exclude transmission media. As used herein, “tangible computer readable storage medium” and “tangible machine readable storage medium” are used interchangeably. Additionally or alternatively, the example processes of FIGS. 8-14 may be implemented using coded instructions (e.g., computer and/or machine readable instructions) stored on a non-transitory computer and/or machine readable medium such as a hard disk drive, a flash memory, a read-only memory, a compact disk, a digital versatile disk, a cache, a random-access memory and/or any other storage device or storage disk in which information is stored for any duration (e.g., for extended time periods, permanently, for brief instances, for temporarily buffering, and/or for caching of the information). As used herein, the term non-transitory computer readable medium is expressly defined to include any type of computer readable storage device and/or storage disk and to exclude propagating signals and to exclude transmission media. As used herein, when the phrase “at least” is used as the transition term in a preamble of a claim, it is open-ended in the same manner as the term “comprising” is open ended.

The program 800 of FIG. 8 begins at block 802 where the example interprocess communication engine 136 determines whether a new task is to be compiled. If so, the example CID engine 120 generates a CID associated with the composite binary to be sent (block 814), and the example CLD engine 126 generates a CLD associated with the composite binary to be sent (block 816). When both the example CID and CLD have been generated, the example metadata reference generator 134 generates a metadata reference associated therewith so that one or more future instances of sending the composite binary can occur without the need to re-send the CID and CLD to the target peer (block 818). The client payload monitor 204 determines whether a payload (e.g., one or more composites) is to be sent to one or more requesting devices (peers) on the network 106, such as an example receiving server device 104 (block 814). As described above, the example sending client device 102 may send payload data in response to a request from one or more peers, send payload data in response to a time-based trigger (e.g., periodic, aperiodic, scheduled, etc.), and/or send payload data in response to a condition-based trigger (e.g., threshold storage consumption value of the example payload storage 108). In some examples, an absence of a trigger results in a wait state, while in other examples the client payload engine 202 sends and/or otherwise distributes composite metadata to one or more peers so that they are ready when payload data becomes available.

To conserve computing resources of the example sending client device 102, the example encoder interface 208 interrupts and/or otherwise prevents the example encoder 110 from performing an encoding operation on the composite to be sent (block 804). As such, any composite(s) sent by the example sending client device 102 will remain in a native format (e.g., binary), which consumes a relatively smaller memory storage footprint and preserves an inherent security of the composite that is sent via the example network 106.

The example task storage interface 210 determines whether the metadata reference has been sent to the target peer on a prior occasion (block 808). As discussed above, the example client payload engine may distribute composite metadata as soon as it is available, such as when one or more peers is experiencing a relatively low computational demand. If the metadata reference has not been previously sent, then the example client payload engine 202 sends the payload (e.g., a composite within the payload) with (a) the metadata reference, (b) a CID associated with the composite, (c) a CLD associated with the composite and (d) the composite in its binary format (block 810). On the other hand, in the event the task storage interface 210 determines that the metadata reference has been sent to the target peer on a prior occasion (block 808), which means that the target peer already has received the corresponding CID and CLD associated with the composite, then the example client payload engine 202 sends only the composite in its binary format (block 812). In still other examples, the client payload engine 202 always sends the payload with the metadata reference by default. In the event the receiving peer does not have the corresponding composite metadata, then it sends a request that is acknowledged by and/or otherwise serviced by the client payload engine 202 to send the composite metadata.

FIG. 9 illustrates additional detail for generating the CID of block 814. In the illustrated example of FIG. 9, the CID pointer manager 122 employs a parsing pointer to retrieve the composite and identify a beginning portion of the composite (block 902). The example CID file generator 124 generates a CID shell file to be populated with architecture agnostic data associated with the composite (block 904), and the example CID pointer manager 122 moves the pointer to the first element of the composite (block 906). The example CID file generator 124 encodes element data for the selected composite element to the CID shell file (block 908), and the example CID pointer manager 122 determines whether there are any remaining elements in the composite to be sent (block 910). If so, control returns to block 906 in which the example CID pointer manager 122 advances the pointer to the next element in the binary composite, otherwise the example program 814 exits.

FIG. 10 illustrates additional detail for generating the CLD of block 814. In the illustrated example of FIG. 10, the example CLD pointer manager 128 retrieves the binary composite to be sent (block 1002) and the example CLD file generator 130 generates a CLD shell file to be written to with architecture specific data associated with the composite binary to be sent (block 1004). The example payload analyzer 132 identifies a size of the composite to be sent and writes this information to the example CLD shell file (block 1006), identifies a number of elements in the composite, and writes this data to the CLD shell file (block 1008). The example payload analyzer 132 selects one of the number of elements in the binary composite to determine a corresponding offset value (block 1010) and writes the corresponding offset value to the CLD shell file (block 1012). If the example CLD pointer manager 128 determines that additional elements remain in the binary composite to be analyzed (block 1014), then control returns to block 1010. If all elements have been evaluated to determine their respective offset values (block 1014), then the example payload analyzer 132 identifies additional information associated with the binary composite to be sent (e.g., endianness information, floating point information, complement information, etc.), and writes this value to the CLD shell file (block 1016). The example program 816 then exits.

While the example programs of FIGS. 8-10 illustrate preparation of payload information (e.g., composites within the binary to be sent) by the example sending client device 102, FIG. 11 illustrates a program 1100 for handling of payload information by the example receiving server device 104. In the illustrated example of FIG. 11, the example server payload monitor 404 determines whether payload information (e.g., a binary composite from a network peer) has been received (block 1102). If so, then the example server metadata manager 406 determines whether the received payload information (e.g., a binary composite) includes a matching composite metadata reference (block 1104). If not, then this instance of receiving the payload information may be occurring for a first time, and the example server storage interface 408 extracts and stores the respective CID, CLD and associated metadata reference nomenclature to the example server data store 116 (block 1106).

So that the example receiving server device 104 can process the received payload, which includes a composite binary that may have an architecture format different than that of the example receiving server device 104, the example server metadata manager 406 generates its own server-side CID file and server-side CLD file (block 1108). Generally speaking, the server-side CID file and server-side CLD file stores corresponding metadata information associated with the sending peer (e.g., the sending client device 102) in a manner that permits resolution and mapping for architecture specific requirements of the receiving server device 104. As described above, the example server metadata manager 406 populates the server-side CID and the server-side CLD with the corresponding metadata translated and/or otherwise compared by the translation engine 180 in view of the received CID and CLD from the peer (block 1110). Based on the architecture of the receiving server device 104, the example translation engine 180 resolves architecture discrepancies by assigning each element with an offset value in the server-side CLD (block 1112). Additionally, if the example enumeration engine 170 determines that the composite is of type ENUM (block 1113), then the enumeration engine 170 resolves enumeration nomenclature discrepancies that may exist between the example sending client device 102 and the example receiving server device 104 (block 1150), as described in further detail below. Control then returns to block 1102.

Returning to block 1104, in the event that the example server metadata manager 406 includes a matching composite metadata reference, then the example server storage interface 408 retrieves the previously stored server-side CID and server-side CLD associated with the received metadata reference (block 1114). The example translator system 424 accesses the previously stored server-side metadata (e.g., the server-side CID 500 and the server-side CLD 550) as shown in FIG. 5 (block 1116). In some examples, the example translator system 424 invokes an appropriate format encoder 426 and uses the offset values from the server-side CLD 550 to store the received binary to the example server data store 116 in a format compatible with the receiving server side device 104 (block 1118). This may afford a degree of computational efficiency when repeated requests for a particular format are received by reducing future translation effort(s). On the other hand, some examples may not employ the decoder manager 410 and, instead, store the binary received from the sending client device 102 in an unaltered format for future translations, as needed. As described above, because the received composite binary is now stored in a native binary format associated with the receiving server side device 104, any future requests by one or more peers (e.g., third party clients) for translated data may be rendered via the offset mapping information of the server-side CLD 550. Control then returns to block 1102.

While the example receiving server-side device 104 has been described above with reference to a network peer (e.g., the example sending client device 102) that provides one or more composite binaries for collection, the receiving server-side device 104 also services requests from other peers (e.g., networked peers, same-platform peers, etc.) that demand a translated version of the composite binary (a translation request). As described above, translation requests originate from peer devices that may have varying preferences on the format of the composite data to be retrieved, such as plain text, XML, JSON, etc. As such, the example translation engine 180 includes any number of different format encoders 426 in the example translation engine 180 to accommodate for particular encoding type formats. Returning to block 1102, in the event a payload (e.g., a composite binary) has not been received, the example request manager 420 determines whether a translation request has occurred (block 1120). If not, then the example service payload monitor 404 determines whether an ENUM mapping request has been received (block 1122) and, if so, the example ENUM engine 170 services the ENUM mapping request (block 1420), as described in further detail below. However, in response to detecting a translation request (block 1120), then the example translation engine 180 services the request (block 1124), such as a request from one of the example translation request entities 182.

FIG. 12 includes additional detail regarding servicing the example translation request (block 1124). In the illustrated example of FIG. 12, the format resolver 422 identifies a format request type (e.g., from one of the translation request entities 182) (block 1202), and determines whether the requested format type has already been previously translated and stored in the example server data store 116 (block 1204). For example, while an example first one of the translation request entities 182 may request that a composite be formatted into XML, such translated composite information may also be optionally stored in the example server data store 116 in the event an example second one of the translation request entities 182 also requests that composite in an XML format, thereby preventing duplicative translation efforts on the example receiving server device 104. The example translation engine 180 retrieves the decoded composite from storage (e.g., the example server data store 116) (block 1206), and forwards the decoded composite to the requestor (e.g., via the example receiving server I/O interface 114) (block 1208).

Returning to block 1204, in the event the example format resolver 422 determines that the requested format is not already available in the example server data store 116, which may occur when the binary composite is translated for the first time in response to a request, then the example translator system 424 retrieves the stored binary and associated metadata (e.g., the example server-side CID 500 and server-side CLD 550 of FIG. 5) (block 1210). As described above, the binary composite may be optionally stored in the server data store 116 having a format compatible with the architecture of the receiving server device 104 so that the example translation engine 180 may reference the corresponding server-side CID 500 and server-side CLD 550 when performing translation (encoding) to the requested format type (block 1212).

FIG. 13 illustrates additional detail for performing translation of the binary composite (block 1212). In the illustrated example of FIG. 13, the example translator system 424 identifies one of the composite elements from the server-side CID 500 (block 1302), and identifies the corresponding element from the server-side CLD 550 to determine an offset value of the data related to the element of interest (block 1304). The example translator system 424 forwards such information to a corresponding format encoder 426 to translate the data based on the offset location and format request type (block 1306), which produces data associated with the element of interest having the requested format type. The example format resolver 422 determines whether the server-side CID 500 includes additional elements of interest in the binary composite to be translated (block 1308) and, if so, control returns to block 1302. However, when all elements of the requested binary composite have been translated into the requested format, the example translation engine 180 stores the translated data in the example server data store 116 so that future requests for this binary composite may be provided to one or more requesting peers (e.g., one or more of the example translation request entities 182) without duplicative translation effort (block 1310).

Returning to FIG. 11, in some examples when a payload composite is of type ENUM (block 1113) or when an ENUM mapping request occurs (block 1122A), the example enumeration engine 170 is invoked to resolve ENUM discrepancies (block 1150) or service mapping requests (block 1122A). FIG. 14 illustrates additional detail associated with enumeration resolution of block 1150. In the illustrated example of FIG. 14, the example resolution table manager 414 determines whether an enumeration resolution table (ERT) is already available for peer comparison (block 1402). If not, then the example resolution table manager 414 generates an ERT shell file (block 1104) and populates fields of a first peer and a second peer column of the ERT shell file with CID and CLD data associated with the respective peers (block 1106), as shown in the illustrated example of FIG. 7.

In the event the exception generator 416 of the enumeration engine 170 identifies a mismatch (e.g., an element position mismatch, an element name mismatch, an element value mismatch, etc.) between the peers (e.g., a mismatch between the ENUM element order of the example first peer 702 as compared with the ENUM element order of the example second peer 704) (block 1408), then the example exception generator 416 determines whether secondary (or other) resolution is available (block 1410). As described above, secondary resolution may be based on one or more element parameters (e.g., element names) that are common to both the example first peer 702 and the example second peer 704. If available, then the example resolution table manager 414 establishes corresponding parameters for mapping (block 1412). For example, and as shown in the illustrated example of FIG. 7, if the example first peer 702 references element “3,” then despite an element position mismatch with index “3” of the example second peer 704, the corresponding matching parameter “yellow” is matched to index position “2” of the second peer 704. As such, the ENUM reference of element “3” from the first peer 702 yields a corresponding value of “700” for the second peer 704, as described in further detail below. Such mappings are stored in the example server data storage 116 for future reference (block 1414). On the other hand, in the event secondary resolution is not possible (block 1410), such as when the example first peer 702 does not have a corresponding matching element name with the example second peer 704, the example exception generator 416 invokes an exception for that particular element (block 1416).

In the event the example exception generator 416 determines that there is no mismatch (e.g., element position mismatch) between the ENUM composites of the example first peer 702 and the example second peer 704 (block 1408), then the example resolution table manager 414 establishes corresponding parameters for mapping (block 1418), and stores those mappings in the example server data storage 116 for future reference (block 1414).

While the illustrated example program 1150 of FIG. 14 generates an ERT to resolve discrepancies that may reside between ENUM composites of a first peer and a second peer, the example program 1150 also handles ENUM mapping requests when the ERT has been previously generated. For example, returning briefly to the illustrated example of FIG. 11, when the example server payload monitor 404 determines an ENUM mapping request has occurred (block 1122A), then control advances to block 1420 where the example ENUM engine 170 confirms that an ENUM mapping request is to occur. The example resolution table manager 414 retrieves a source request value for an element of interest (block 1422), such as a request to map element position “1” of the ENUM composite associated with the example first peer 702 (e.g., the example sending client device 102). The example resolution table manager 414 identifies a corresponding target value from the ERT 700 that is associated with the corresponding other ENUM composite associated with the second peer 704 (e.g., the example receiving server device 104) (block 1424). The example decoder 118 returns the target value to the requestor (block 1426), which in the illustrated example of FIG. 7 is the value “50.”

FIG. 15 is a block diagram of an example processor platform 1500 capable of executing the instructions of FIGS. 8-14 to implement the client payload engine 150, the server payload engine 160, the enumeration engine 170, and the translation engine 180 of FIGS. 1, 2 and 4. The processor platform 1500 can be, for example, a server, a personal computer, a mobile device (e.g., a cell phone, a smart phone, a tablet such as an iPad), a personal digital assistant (PDA), an Internet appliance, a DVD player, a CD player, a digital video recorder, a Blu-ray player, a gaming console, a personal video recorder, a set top box, a digital camera, a virtual machine, or any other type of computing device.

The processor platform 1500 of the illustrated example includes a processor 1512. The processor 1512 of the illustrated example is hardware. For example, the processor 1512 can be implemented by one or more integrated circuits, logic circuits, microprocessors or controllers from any desired family or manufacturer. In the illustrated example of FIG. 15, the processor 1512 includes one or more example processing cores 1515 configured via example instructions 1532, which include the example instructions of FIGS. 8-14 to implement the example client payload engine 150, the example server payload engine 160, the example enumeration engine 170, and/or the example translation engine 180 of FIGS. 1, 2 and/or 4.

The processor 1512 of the illustrated example includes a local memory 1513 (e.g., a cache). The processor 1512 of the illustrated example is in communication with a main memory including a volatile memory 1514 and a non-volatile memory 1516 via a bus 1518. The volatile memory 1514 may be implemented by Synchronous Dynamic Random Access Memory (SDRAM), Dynamic Random Access Memory (DRAM), RAMBUS Dynamic Random Access Memory (RDRAM) and/or any other type of random access memory device. The non-volatile memory 1516 may be implemented by flash memory and/or any other desired type of memory device. Access to the main memory 1514, 1516 is controlled by a memory controller.

The processor platform 1500 of the illustrated example also includes an interface circuit 1520. The interface circuit 1520 may be implemented by any type of interface standard, such as an Ethernet interface, a universal serial bus (USB), and/or a PCI express interface.

In the illustrated example, one or more input devices 1522 are connected to the interface circuit 1520. The input device(s) 1522 permit(s) a user to enter data and commands into the processor 1512. The input device(s) can be implemented by, for example, an audio sensor, a microphone, a camera (still or video), a keyboard, a button, a mouse, a touchscreen, a track-pad, a trackball, isopoint, a voice recognition system and/or any other human-machine interface.

One or more output devices 1524 are also connected to the interface circuit 1520 of the illustrated example. The output devices 1524 can be implemented, for example, by display devices (e.g., a light emitting diode (LED), an organic light emitting diode (OLED), a liquid crystal display, a cathode ray tube display (CRT), a touchscreen, a tactile output device, a printer and/or speakers). The interface circuit 1520 of the illustrated example, thus, typically includes a graphics driver card, a graphics driver chip or a graphics driver processor.

The interface circuit 1520 of the illustrated example also includes a communication device such as a transmitter, a receiver, a transceiver, a modem and/or network interface card to facilitate exchange of data with external machines (e.g., computing devices of any kind) via a network 1526 (e.g., an Ethernet connection, a digital subscriber line (DSL) to facilitate exchange of data within a similar machine platform (e.g., a communication bus), a telephone line, coaxial cable, a cellular telephone system, etc.). In the illustrated example of FIG. 15, the interface circuit 1520 is also structured to implement one or more of the example sending client I/O interface 112 and/or the example receiving server I/O interface 114 of FIGS. 1, 2 and/or 4.

The processor platform 1500 of the illustrated example also includes a communication device such as a transmitter, a receiver, a transceiver, a modem and/or network interface card to facilitate exchange of data with external machines (e.g., computing devices of any kind) via a network 1526 and/or the network 106 (e.g., an Ethernet connection, a digital subscriber line (DSL), a telephone line, coaxial cable, a cellular telephone system, etc.).

The processor platform 1500 of the illustrated example also includes one or more mass storage devices 1528 for storing software and/or data. Examples of such mass storage devices 1528 include floppy disk drives, hard drive disks, compact disk drives, Blu-ray disk drives, RAID systems, and digital versatile disk (DVD) drives. In some examples, the mass storage device 1530 may implement the example payload storage 108 and/or the example server data store 116.

The coded instructions 1532 of FIGS. 8-14 may be stored in the mass storage device 1528, in the volatile memory 1514, in the non-volatile memory 1516, in the local memory 1513 and/or on a removable tangible computer readable storage medium such as a CD or DVD 1536.

Although certain example methods, apparatus and articles of manufacture have been disclosed herein, the scope of coverage of this patent is not limited thereto. On the contrary, this patent covers all methods, apparatus and articles of manufacture fairly falling within the scope of the claims of this patent.

Example 1 is an apparatus to improve network transmission efficiency of a sending peer that includes an encoder interface to prevent an encoder from encoding data in a native format to a target format associated with a requesting peer in response to a transmission trigger, a composite interface description (CID) engine to generate architecture agnostic metadata of the data in the native format, a composite layout description (CLD) engine to generate architecture specific metadata of the data in the native format, the architecture specific metadata identifying offset values associated with elements of the data in the native format, and a client payload engine to improve the network transmission efficiency by sending unencoded data combined with the architecture agnostic metadata and the architecture specific metadata to the requesting peer having an architecture different than that of the sending peer.

Example 2 includes the subject matter of example 1, wherein the unencoded data includes a storage footprint lower than that of the data in the native format after encoding by the encoder.

Example 3 includes the subject matter of example 1, wherein the data in the native format includes a binary format.

Example 4 includes the subject matter of example 1, wherein the target format includes at least one of an extensible markup language format, an abstract syntax notation format, or a text format.

Example 5 includes the subject matter of example 1, wherein the data in the native format includes a composite associated with a type.

Example 6 includes the subject matter of example 5, wherein the type includes at least one of a C-structure or an enumeration.

Example 7 includes the subject matter of example 1, further including a pointer manager to identify a first one of the elements in the data in the native format.

Example 8 includes the subject matter of example 7, further including a CID file generator to generate a CID file to store the architecture agnostic metadata.

Example 9 includes the subject matter of example 8, wherein the CID file generator is to encode element data into the CID file.

Example 10 includes the subject matter of example 9, wherein the element data includes at least one of a composite type, a composite name, a composite element name, or a composite element type.

Example 11 includes the subject matter of example 7, further including a CLD file generator to generate a CLD file to store the architecture specific metadata.

Example 12 includes the subject matter of example 11, further including a payload analyzer to identify the offset values associated with the elements of the data in the native format, and write the offset values in the CLD file.

Example 13 includes the subject matter of example 1, further including a metadata reference manager to generate a metadata reference associated with the combined architecture agnostic metadata and the architecture specific metadata.

Example 14 includes the subject matter of example 1, further including a task process compiler to compile the architecture agnostic metadata and the architecture specific metadata into a task executable of the sending peer.

Example 15 is a method to improve network transmission efficiency of a sending peer, including preventing an encoder from encoding data in a native format to a target format associated with a requesting peer in response to a transmission trigger, generating architecture agnostic metadata of the data in the native format, generating architecture specific metadata of the data in the native format, the architecture specific metadata identifying offset values associated with elements of the data in the native format, and improving the network transmission efficiency by sending unencoded data combined with the architecture agnostic metadata and the architecture specific metadata to the requesting peer having an architecture different than that of the sending peer.

Example 16 includes the subject matter of example 15, wherein the unencoded data includes a storage footprint lower than that of the data in the native format after encoding by the encoder.

Example 17 includes the subject matter of example 15, wherein the data in the native format includes a binary format.

Example 18 includes the subject matter of example 15, wherein the target format includes at least one of an extensible markup language format, an abstract syntax notation format, or a text format.

Example 19 includes the subject matter of example 15, wherein the data in the native format includes a composite associated with a type.

Example 20 includes the subject matter of example 19, wherein the type includes at least one of a C-structure or an enumeration.

Example 21 includes the subject matter of example 15, further including identifying a first one of the elements in the data in the native format.

Example 22 includes the subject matter of example 21, further including generating a composite interface description (CID) file to store the architecture agnostic metadata.

Example 23 includes the subject matter of example 22, further including encoding element data into the CID file.

Example 24 includes the subject matter of example 23, wherein the element data includes at least one of a composite type, a composite name, a composite element name, or a composite element type.

Example 25 includes the subject matter of example 21, further including generating a composite layout description (CLD) file to store the architecture specific metadata.

Example 26 includes the subject matter of example 25, further including identifying the offset values associated with the elements of the data in the native format, and writing the offset values in the CLD file.

Example 27 includes the subject matter of example 15, further including generating a metadata reference associated with the combined architecture agnostic metadata and the architecture specific metadata.

Example 28 includes the subject matter of example 15, further including compiling the architecture agnostic metadata and the architecture specific metadata into a task executable of the sending peer.

Example 29 is a tangible computer readable storage medium comprising computer readable instructions which, when executed, cause a processor to at least prevent an encoder from encoding data in a native format to a target format associated with a requesting peer in response to a transmission trigger, generate architecture agnostic metadata of the data in the native format, generate architecture specific metadata of the data in the native format, the architecture specific metadata identifying offset values associated with elements of the data in the native format, and improve the network transmission efficiency by sending unencoded data combined with the architecture agnostic metadata and the architecture specific metadata to the requesting peer having an architecture different than that of the sending peer.

Example 30 includes the subject matter of example 29, wherein the instructions are to cause the processor to transmit the unencoded data in a storage footprint lower than that of the data in the native format after encoding by the encoder.

Example 31 includes the subject matter of example 29, wherein the instructions are to cause the processor to transmit the native format as a binary format.

Example 32 includes the subject matter of example 29, wherein the instructions are to cause the processor to identify a first one of the elements in the data in the native format.

Example 33 includes the subject matter of example 32, wherein the instructions are to cause the processor to generate a composite interface description (CID) file to store the architecture agnostic metadata.

Example 34 includes the subject matter of example 33, wherein the instructions are to cause the processor to encode element data into the CID file.

Example 35 includes the subject matter of example 32, wherein the instructions are to cause the processor to generate a composite layout description (CLD) file to store the architecture specific metadata.

Example 36 includes the subject matter of example 35, wherein the instructions are to cause the processor to identify the offset values associated with the elements of the data in the native format, and write the offset values in the CLD file.

Example 37 includes the subject matter of example 29, wherein the instructions are to cause the processor to generate a metadata reference associated with the combined architecture agnostic metadata and the architecture specific metadata.

Example 38 includes the subject matter of example 29, wherein the instructions are to cause the processor to compile the architecture agnostic metadata and the architecture specific metadata into a task executable of the sending peer.

Example 39 is a system to improve network transmission efficiency of a sending peer, including means for preventing an encoder from encoding data in a native format to a target format associated with a requesting peer in response to a transmission trigger, means for generating architecture agnostic metadata of the data in the native format, means for generating architecture specific metadata of the data in the native format, the architecture specific metadata identifying offset values associated with elements of the data in the native format, and means for improving the network transmission efficiency by sending unencoded data combined with the architecture agnostic metadata and the architecture specific metadata to the requesting peer having an architecture different than that of the sending peer.

Example 40 includes the subject matter of example 39, wherein the unencoded data includes a storage footprint lower than that of the data in the native format after encoding by the encoder.

Example 41 includes the subject matter of example 39, wherein the data in the native format includes a binary format.

Example 42 includes the subject matter of example 39, wherein the target format includes at least one of an extensible markup language format, an abstract syntax notation format, or a text format.

Example 43 includes the subject matter of example 39, wherein the data in the native format includes a composite associated with a type.

Example 44 includes the subject matter of example 43, wherein the type includes at least one of a C-structure or an enumeration.

Example 45 includes the subject matter of example 39, further including means for identifying a first one of the elements in the data in the native format.

Example 46 includes the subject matter of example 45, further including means for generating a composite interface description (CID) file to store the architecture agnostic metadata.

Example 47 includes the subject matter of example 46, wherein the means for generating a CID file is to encode element data into the CID file.

Example 48 includes the subject matter of example 47, wherein the element data includes at least one of a composite type, a composite name, a composite element name, or a composite element type.

Example 49 includes the subject matter of example 45, further including a means for generating a composite layout description (CLD) file to store the architecture specific metadata.

Example 50 includes the subject matter of example 49, further including means for identifying the offset values associated with the elements of the data in the native format, and means for writing the offset values in the CLD file.

Example 51 includes the subject matter of example 39, further including means for generating a metadata reference associated with the combined architecture agnostic metadata and the architecture specific metadata.

Example 52 includes the subject matter of example 39, further including means for compiling the architecture agnostic metadata and the architecture specific metadata into a task executable of the sending peer.

Example 53 is an example apparatus to resolve data retrieved by a receiving peer having an incompatible architectural format, including a server storage interface to retrieve: a composite having the incompatible architectural format, a client-side composite interface description (CID) having architecture agnostic metadata associated with the composite, and a client-side composite layout description (CLD) having architecture specific metadata associated with the composite, a server metadata manager to: encode a server-side CID with the architecture agnostic metadata of the client-side CID, encode a server-side CLD with the architecture specific metadata of the client-side CLD, and a translation engine to generate offset values for respective elements of the server-side CLD based on an architecture type of the receiving peer.

Example 54 includes the subject matter of example 53, further including a request manager to detect a request to render the data having the incompatible architectural format.

Example 55 includes the subject matter of example 54, further including a format resolver to identify a format type of the request.

Example 56 includes the subject matter of example 55, further including a translation engine to translate the respective elements of the data retrieved by the receiving peer based on (a) respective offset values of the respective elements and (b) the format type of the request.

Example 57 includes the subject matter of example 56, wherein the translation engine is to forward the translated respective elements of the data to a requestor of the request.

Example 58 includes the subject matter of example 54, wherein the server storage interface is to reduce a computational demand of the receiving peer during a subsequent request by associating the client-side CID and the client-side CLD with a receiving peer metadata reference.

Example 59 includes the subject matter of example 53, wherein the server storage interface is to associate the server-side CID and the server-side CLD with the receiving peer metadata reference.

Example 60 includes the subject matter of example 59, wherein the server metadata manager is to improve a computational efficiency of the receiving peer by bypassing encoding of the server-side CID and the server-side CLD when the data retrieved by the receiving peer includes a sending peer metadata reference that matches the receiving peer metadata reference.

Example 61 includes the subject matter of example 60, wherein the server metadata manager is to retrieve the server-side CID and the server-side CLD from a local storage when the sending peer metadata reference matches the receiving peer metadata reference.

Example 62 is a method to resolve data retrieved by a receiving peer having an incompatible architectural format, including retrieving a composite having the incompatible architectural format, a client-side composite interface description (CID) having architecture agnostic metadata associated with the composite, and a client-side composite layout description (CLD) having architecture specific metadata associated with the composite, encoding a server-side CLD with the architecture agnostic metadata of the client-side CID, and encoding a server side CLD with the architecture specific metadata of the client-side CLD, and generating offset values for respective elements of the server-side CLD based on an architecture type of the receiving peer.

Example 63 includes the subject matter of example 62, further including detecting a request to render the data having the incompatible architectural format.

Example 64 includes the subject matter of example 63, further including identifying a format type of the request.

Example 65 includes the subject matter of example 64 further including translating the respective elements of the data retrieved by the receiving peer based on (a) respective offset values of the respective elements and (b) the format type of the request.

Example 66 includes the subject matter of example 65, further including forwarding the translated respective elements of the data to a requestor of the request.

Example 67 includes the subject matter of example 63, further including reducing a computational demand of the receiving peer during a subsequent request by associating the client-side CID and the client-side CLD with a receiving peer metadata reference.

Example 68 includes the subject matter of example 62, further including associating the server-side CID and the server-side CLD with the receiving peer metadata reference.

Example 69 includes the subject matter of example 68, further including improving a computational efficiency of the receiving peer by bypassing encoding of the server-side CID and the server-side CLD when the data retrieved by the receiving peer includes a sending peer metadata reference that matches the receiving peer metadata reference.

Example 70 includes the subject matter of example 69, further including retrieving the server-side CID and the server-side CLD from a local storage when the sending peer metadata reference matches the receiving peer metadata reference.

Example 71 is a tangible computer readable storage medium comprising computer readable instructions which, when executed, cause a processor to at least retrieve a composite having the incompatible architectural format, a client-side composite interface description (CID) having architecture agnostic metadata associated with the composite, and a client-side composite layout description (CLD) having architecture specific metadata associated with the composite, encode a server-side CLD with the architecture agnostic metadata of the client-side CID, and encode a server side CLD with the architecture specific metadata of the client-side CLD, and generate offset values for respective elements of the server-side CLD based on an architecture type of the receiving peer.

Example 72 includes the subject matter of example 71, wherein the instructions are to cause the processor to detect a request to render the data having the incompatible architectural format.

Example 73 includes the subject matter of example 72, wherein the instructions are to cause the processor to identify a format type of the request.

Example 74 includes the subject matter of example 73, wherein the instructions are to cause the processor to translate the respective elements of the data retrieved by the receiving peer based on (a) respective offset values of the respective elements and (b) the format type of the request.

Example 75 includes the subject matter of example 74, wherein the instructions are to cause the processor to forward the translated respective elements of the data to a requestor of the request.

Example 76 includes the subject matter of example 72, wherein the instructions are to cause the processor to reduce a computational demand of the receiving peer during a subsequent request by associating the client-side CID and the client-side CLD with a receiving peer metadata reference.

Example 77 includes the subject matter of example 71, wherein the instructions are to cause the processor to associate the server-side CID and the server-side CLD with the receiving peer metadata reference.

Example 78 includes the subject matter of example 77, wherein the instructions are to cause the processor to improve a computational efficiency of the receiving peer by bypassing encoding of the server-side CID and the server-side CLD when the data retrieved by the receiving peer includes a sending peer metadata reference that matches the receiving peer metadata reference.

Example 79 includes the subject matter of example 78, wherein the instructions are to cause the processor to retrieve the server-side CID and the server-side CLD from a local storage when the sending peer metadata reference matches the receiving peer metadata reference.

Example 80 is a system to resolve data retrieved by a receiving peer having an incompatible architectural format, including means for retrieving a composite having the incompatible architectural format, means for retrieving a client-side composite interface description (CID) having architecture agnostic metadata associated with the composite, means for retrieving a client-side composite layout description (CLD) having architecture specific metadata associated with the composite, means for encoding a server-side CLD with the architecture agnostic metadata of the client-side CID, and means for encoding a server side CLD with the architecture specific metadata of the client-side CLD, and means for generating offset values for respective elements of the server-side CLD based on an architecture type of the receiving peer.

Example 81 includes the subject matter of example 80, further including means for detecting a request to render the data having the incompatible architectural format.

Example 82 includes the subject matter of example 81, further including means for identifying a format type of the request.

Example 83 includes the subject matter of example 82, further including means for translating the respective elements of the data retrieved by the receiving peer based on (a) respective offset values of the respective elements and (b) the format type of the request.

Example 84 includes the subject matter of example 83, further including means for forwarding the translated respective elements of the data to a requestor of the request.

Example 85 includes the subject matter of example 81, further including means for reducing a computational demand of the receiving peer during a subsequent request by associating the client-side CID and the client-side CLD with a receiving peer metadata reference.

Example 86 includes the subject matter of example 80, further including means for associating the server-side CID and the server-side CLD with the receiving peer metadata reference.

Example 87 includes the subject matter of example 86, further including means for improving a computational efficiency of the receiving peer by bypassing encoding of the server-side CID and the server-side CLD when the data retrieved by the receiving peer includes a sending peer metadata reference that matches the receiving peer metadata reference.

Example 88 includes the subject matter of example 87, further including means for retrieving the server-side CID and the server-side CLD from a local storage when the sending peer metadata reference matches the receiving peer metadata reference.

Example 89 is an apparatus to prevent binary translation of a sending peer enumeration (ENUM) composite, including a server storage interface to retrieve sending peer metadata associated with the sending peer ENUM composite, a resolution table manager to generate an enumeration resolution table (ERT) to compare the sending peer metadata with receiving peer metadata associated with a receiving peer ENUM composite, and an exception generator to improve receiving peer computation demands by preventing translation of the sending peer ENUM composite by identifying matching elements based on respective element index positions of (a) the sending peer metadata and (b) the receiving peer metadata.

Example 90 includes the subject matter of example 89, wherein the resolution table manager is to identify respective target values of a receiving peer ENUM composite based on a mapping request value associated with the sending peer ENUM composite.

Example 91 includes the subject matter of example 90, wherein the exception generator is to identify a mismatch of one of the respective element index positions between (a) the sending peer metadata and (b) the receiving peer metadata.

Example 92 includes the subject matter of example 91, wherein the exception generator is to identify a secondary resolution parameter in response to identifying the mismatch.

Example 93 includes the subject matter of example 92, wherein the second resolution parameter includes an element name that is common to (a) the sending peer metadata and (b) the receiving peer metadata.

Example 94 includes the subject matter of example 91, wherein the resolution table manager establishes a mapping link between the sending peer ENUM composite and the receiving peer ENUM composite based on the secondary resolution parameter.

Example 95 includes the subject matter of example 91, wherein the exception generator is to invoke an exception for a respective element that includes (a) the mismatch and (b) no available secondary resolution parameter.

Example 96 is a method to prevent binary translation of a sending peer enumeration (ENUM) composite, including retrieving sending peer metadata associated with the sending peer ENUM composite, generating an enumeration resolution table (ERT) to compare the sending peer metadata with receiving peer metadata associated with a receiving peer ENUM composite, and improving receiving peer computation demands by preventing translation of the sending peer ENUM composite by identifying matching elements based on respective element index positions of (a) the sending peer metadata and (b) the receiving peer metadata.

Example 97 includes the subject matter of example 96, further including identifying respective target values of a receiving peer ENUM composite based on a mapping request value associated with the sending peer ENUM composite.

Example 98 includes the subject matter of example 96, further including identifying a mismatch of one of the respective element index positions between (a) the sending peer metadata and (b) the receiving peer metadata.

Example 99 includes the subject matter of example 98, further including identifying a secondary resolution parameter in response to identifying the mismatch.

Example 100 includes the subject matter of example 99, wherein the second resolution parameter includes an element name that is common to (a) the sending peer metadata and (b) the receiving peer metadata.

Example 101 includes the subject matter of example 98, further including establishing a mapping link between the sending peer ENUM composite and the receiving peer ENUM composite based on the secondary resolution parameter.

Example 102 includes the subject matter of example 98, further including invoking an exception for a respective element that includes (a) the mismatch and (b) no available secondary resolution parameter.

Example 103 is a tangible computer readable storage medium comprising computer readable instructions which, when executed, cause a processor to at least retrieve sending peer metadata associated with the sending peer ENUM composite, generate an enumeration resolution table (ERT) to compare the sending peer metadata with receiving peer metadata associated with a receiving peer ENUM composite, and improve receiving peer computation demands by preventing translation of the sending peer ENUM composite by identifying matching elements based on respective element index positions of (a) the sending peer metadata and (b) the receiving peer metadata.

Example 104 includes the subject matter of example 103, wherein the instructions are to cause the processor to identify respective target values of a receiving peer ENUM composite based on a mapping request value associated with the sending peer ENUM composite.

Example 105 includes the subject matter of example 103, wherein the instructions are to cause the processor to identify a mismatch of one of the respective element index positions between (a) the sending peer metadata and (b) the receiving peer metadata.

Example 106 includes the subject matter of example 105, wherein the instructions are to cause the processor to identify a secondary resolution parameter in response to identifying the mismatch.

Example 107 includes the subject matter of example 106, wherein the instructions are to cause the processor to include an element name of the second resolution parameter that is common to (a) the sending peer metadata and (b) the receiving peer metadata.

Example 108 includes the subject matter of example 105, wherein the instructions are to cause the processor to establish a mapping link between the sending peer ENUM composite and the receiving peer ENUM composite based on the secondary resolution parameter.

Example 109 includes the subject matter of example 105, wherein the instructions are to cause the processor to invoke an exception for a respective element that includes (a) the mismatch and (b) no available secondary resolution parameter.

Example 110 is a system to prevent binary translation of a sending peer enumeration (ENUM) composite, including means for retrieving sending peer metadata associated with the sending peer ENUM composite, means for generating an enumeration resolution table (ERT) to compare the sending peer metadata with receiving peer metadata associated with a receiving peer ENUM composite, and means for improving receiving peer computation demands by preventing translation of the sending peer ENUM composite by identifying matching elements based on respective element index positions of (a) the sending peer metadata and (b) the receiving peer metadata.

Example 111 includes the subject matter of example 110, further including means for identifying respective target values of a receiving peer ENUM composite based on a mapping request value associated with the sending peer ENUM composite.

Example 112 includes the subject matter of example 110, further including means for identifying a mismatch of one of the respective element index positions between (a) the sending peer metadata and (b) the receiving peer metadata.

Example 113 includes the subject matter of example 112, further including means for identifying a secondary resolution parameter in response to identifying the mismatch.

Example 114 includes the subject matter of example 113, wherein the second resolution parameter includes an element name that is common to (a) the sending peer metadata and (b) the receiving peer metadata.

Example 115 includes the subject matter of example 112, further including means for establishing a mapping link between the sending peer ENUM composite and the receiving peer ENUM composite based on the secondary resolution parameter.

Example 116 includes the subject matter of example 112, further including means for invoking an exception for a respective element that includes (a) the mismatch and (b) no available secondary resolution parameter.

Claims

1.-25. (canceled)

26. An apparatus to resolve data retrieved by a receiving peer having an incompatible architectural format, comprising:

a server storage interface to retrieve: a composite having the incompatible architectural format; a client-side composite interface description (CID) having architecture agnostic metadata associated with the composite; and a client-side composite layout description (CLD) having architecture specific metadata associated with the composite;

a server metadata manager to: encode a server-side CID with the architecture agnostic metadata of the client-side CID; encode a server-side CLD with the architecture specific metadata of the client-side CLD; and

a translation engine to generate offset values for respective elements of the server-side CLD based on an architecture type of the receiving peer.

27. An apparatus as defined in claim 26, further including a request manager to detect a first request to render the data having the incompatible architectural format.

28. An apparatus as defined in claim 27, further including a format resolver to identify a format type of the first request.

29. An apparatus as defined in claim 28, wherein the translation engine is to translate the respective elements of the data retrieved by the receiving peer based on (a) offset values of the respective elements and (b) the format type of the first request.

30. An apparatus as defined in claim 29, wherein the translation engine is to forward the translated respective elements of the data to a requestor of the first request.

31. An apparatus as defined in claim 27, wherein the server storage interface is to reduce a computational demand of the receiving peer during a second request by associating the client-side CID and the client-side CLD with a receiving peer metadata reference.

32. An apparatus as defined in claim 26, wherein the server storage interface is to associate the server-side CID and the server-side CLD with a receiving peer metadata reference.

33. An apparatus as defined in claim 32, wherein the server metadata manager is to improve a computational efficiency of the receiving peer by bypassing encoding of the server-side CID and the server-side CLD when the data retrieved by the receiving peer includes a sending peer metadata reference that matches the receiving peer metadata reference.

34. An apparatus as defined in claim 33, wherein the server metadata manager is to retrieve the server-side CID and the server-side CLD from a local storage when the sending peer metadata reference matches the receiving peer metadata reference.

35. A method to resolve data retrieved by a receiving peer having an incompatible architectural format, comprising:

retrieving a composite having the incompatible architectural format, a client-side composite interface description (CID) having architecture agnostic metadata associated with the composite, and a client-side composite layout description (CLD) having architecture specific metadata associated with the composite;

encoding a server-side CLD with the architecture agnostic metadata of the client-side CID, and encoding a server side CLD with the architecture specific metadata of the client-side CLD; and

generating offset values for respective elements of the server-side CLD based on an architecture type of the receiving peer.

36. A method as defined in claim 35, further including detecting a first request to render the data having the incompatible architectural format.

37. A method as defined in claim 36, further including identifying a format type of the first request.

38. A method as defined in claim 37, further including translating the respective elements of the data retrieved by the receiving peer based on (a) offset values of the respective elements and (b) the format type of the first request.

39. A method as defined in claim 38, further including forwarding the translated respective elements of the data to a requestor of the first request.

40. A method as defined in claim 36, further including reducing a computational demand of the receiving peer during a second request by associating the client-side CID and the client-side CLD with a receiving peer metadata reference.

41. A method as defined in claim 35, further including associating a server-side CID and the server-side CLD with a receiving peer metadata reference.

42. A method as defined in claim 41, further including improving a computational efficiency of the receiving peer by bypassing encoding of the server-side CID and the server-side CLD when the data retrieved by the receiving peer includes a sending peer metadata reference that matches the receiving peer metadata reference.

43. A method as defined in claim 42, further including retrieving the server-side CID and the server-side CLD from a local storage when the sending peer metadata reference matches the receiving peer metadata reference.

44. A tangible computer readable storage medium comprising computer readable instructions which, when executed, cause a processor to at least:

retrieve a composite having an incompatible architectural format, a client-side composite interface description (CID) having architecture agnostic metadata associated with the composite, and a client-side composite layout description (CLD) having architecture specific metadata associated with the composite;

encode a server-side CLD with the architecture agnostic metadata of the client-side CID, and encode a server side CLD with the architecture specific metadata of the client-side CLD; and

generate offset values for respective elements of the server-side CLD based on an architecture type of a receiving peer.

45. A tangible computer readable storage medium as defined in claim 44, wherein the computer readable instructions are to cause the processor to detect a first request to render data having the incompatible architectural format.

46. A tangible computer readable storage medium as defined in claim 45, wherein the computer readable instructions are to cause the processor to identify a format type of the first request.

47. A tangible computer readable storage medium as defined in claim 46, wherein the computer readable instructions are to cause the processor to translate the respective elements of the data retrieved by the receiving peer based on (a) offset values of the respective elements and (b) the format type of the first request.

48. A tangible computer readable storage medium as defined in claim 47, wherein the computer readable instructions are to cause the processor to forward the translated respective elements of the data to a requestor of the first request.

49. A tangible computer readable storage medium as defined in claim 45, wherein the computer readable instructions are to cause the processor to reduce a computational demand of the receiving peer during a second request by associating the client-side CID and the client-side CLD with a receiving peer metadata reference.

50. A tangible computer readable storage medium as defined in claim 44, wherein the computer readable instructions are to cause the processor to associate a server-side CID and the server-side CLD with a receiving peer metadata reference.