Fast-forwarding Binary Data through a Distributed Microservice Architecture

The present disclosure generally relates to networking and computing systems. More particularly, the present disclosure relates to systems and methods for bypassing Serialization/Deserialization (SerDes) stages, among other common processing stages, for fast-forwarding binary data from one end of a microservice chain to the other.

Many schemas support data encoding strategies that can convert an internal data structure to a format that can be sent on the wire. Encoding formats like JavaScript Object Notation (JSON), eXtensible Mark-up Language (XML), protobuf, Google's Remote Procedure Call (gRPC) Network Management Interface (gNMI), flat buffers, and others are typically intended to be used for a messaging layer only and once received, the entire message is consumed and is converted to an internal format. Some schemas allow binary data to be encoded, but there are limitations on how raw binary data can be represented in the data formats. For example, Yet Another Next Generation (YANG) Requests for Comments (RFCs) have a binary data type which involves serializing and deserializing the data in Base64 encoding, which is not a fast encoding process. Other methods can be used to send binary data as files or other encoded data, but it is rare that systems are designed to accept opaque binary data on a messaging interface and allow it to flow undecoded through the entire system. Also, binary encoding schemes, like protobuf, can encapsulate raw binary data in an internal Type-Length-Value (TLV) format, but the data must be copied into the internals of a buffer on the sending side, and copied out of the received buffer on the receiving side. As a result, Base64 encoding is less efficient than raw binary data, as there are computing resources and time involved in converting back and forth between a messaging-compatible and non-compatible format. Also, normal data encoding does not allow for opaque binary data to be easily encoded and embedded in a message. References to binary data (e.g., filename, URL, etc.) can be sent and the data transferred via a separate message, but this is less efficient than sending the raw data in the message itself. The embedding of binary data in the contents of a binary encoding schema also forces copies into and out of the buffer when the data is translated.

The present disclosure relates to systems and methods for “fast-forwarding” binary data through a chain of microservices. Methods may be executed by various components that may be arranged in the chain of microservices, where the components may include processors, computers, servers, Network Elements (NEs), nodes, etc. In particular, the methods may be performed by a “provider microservice” that is arranged at one end of the chain and that is configured to receive a request for binary data from a “requester microservice” at the other end of the chain. In addition to returning the requested binary data, the provider microservice is also configured to at least apply a tag that indicates to intermediate microservices up the chain merely forward the binary data to the next microservice while avoiding extra processing steps, such as memory allocation, copying, etc.

One process, according to various implementations, may include a step of receiving a request from a requester microservice to obtain binary data formatted in a specific data format. The process may further include a step of converting the binary data from a native data format to the specific data format as requested by the requester microservice. Also, the process may include a step of adding a tag with the binary data, the tag being configured to instruct each intermediate microservice along the microservice chain to bypass a Serialize/Deserialize (SerDes) stage therein while forwarding the binary data to a next microservice in the microservice chain.

According to some embodiments, the tag may be further configured to instruct each intermediate microservice along the microservice chain to bypass one or more steps associated with at least one of a binary-to-text decoding stage, a text-to-binary re-encoding stage, a memory allocation stage, and a data copying stage therein. In some embodiments, each microservice of the microservice chain may include a microprocessor and may be associated with an embedded system, node, or NE that is part of a distributed system. Also, in alternative embodiments, the microservice chain may be configured in a system having a single processor and shared memory address space, wherein the tag may be related to a pointer that points to locations within the shared memory address space.

Furthermore, according to various implementations, the native format and the specific data format may be categorized as flexible, schema-agnostic formats used for transmitting management information in a control plane. The flexible, schema-agnostic formats, for example, may include JSON, XML, YAML, and/or other various formats. Alternatively, the native format and the specific data format may be categorized as inflexible, firmly structured formats for transmitting data traffic in a data plane. The inflexible, firmly structured formats, for example, may include JPEG, GIF, protobuf, TCP, IP, IEEE 802.3 Ethernet packets, and/or other various formats.

In some embodiments, the tag may be configured as metadata and stored or encapsulated in a header or footer. The tag may be configured to instruct the intermediate microservices to fast-forward the binary data in an opaque manner, avoid conversion to Base64 format, and bypass a plaintext serialization stage. The binary data, for example, may include a data file, a picture file, pre-serialized data, generated data, performance logs, a word processing document, and/or other types of data. Upon adding the tag, the process may further include a steps of performing a pre-serialization of the binary data and passing the pre-serialized binary data and tag to a neighboring microservice in the microservice chain. In some embodiments, the tag may enable the neighboring microservice and/or intermediate microservices to reduce overhead, reduce CPU cycles, reduce memory allocation actions, reduce copying actions, reduce pointer freeing actions, reduce comparison actions, reduce filtering actions, reduce logging actions, and/or reduce debugging actions.

Furthermore, according to some embodiments, the request is a binary version of a get command that is passed along the microservice chain from the requester microservice to the provider microservice. The process may further include a step of pre-formatting the binary data in a binary buffer with a reference pointing to a shared memory address space, wherein the reference may be stored as metadata and included as a footer or header with respect to a payload related to the binary data to be transmitted through the microservice chain. The metadata, for example, may include an indication of at least what portions of a message contain the binary data, where the binary data is contained in the message, and a number of bytes of the binary data.

The process, in some embodiments, may further include steps of a) sending gNMI data, b) configuring the resource owner as a modem to generate a constellation, c) sending the binary data transparently without encoding, and/or d) encrypting the binary data that intermediate microservices cannot access but can only forward the binary data opaquely, whereby the requester microservice is able to decrypt the encrypted binary data. The binary data, in some cases, can include multiple chunks or blobs of data concatenated together, wherein the process may further include a step of incorporating metadata with the binary data to define each chunk or blob.

In software engineering, “microservices” can be configured is an architectural pattern that arranges an application as a collection of loosely coupled, fine-grained services. Communication through a chain of microservices may involve the user of flexible and/or lightweight protocols. A distributed microservice-based architecture enables software development teams to generate and deploy their services independently. Also, such an architecture reduces code interdependencies and increases readability and modularity within a codebase and can reduce complexity. Consequently, organizations can develop software with rapid growth and scalability, as well as implement off-the-shelf services more easily. These benefits come with the cost of needing to maintain a decoupled structure within the codebase.

In some examples, embedded systems may be configured with a microservice architecture. Embedded systems, including processing and memory capabilities, can transmit data between endpoints for messaging. In particular, the transmitted data typically follows a rigid structure or schema. Messaging with schemas, in some cases, is not recommended for transmitting different types of binary, which may be referred to herein as “arbitrary binary data.” Examples of arbitrary binary data may include, but are not limited to, pictures, pre-serialized data, performance logs, documents, and the like. It should be noted that the content of arbitrary binary data may quite varied, whereby inserting this content directly in the body or payload of a message can cause problems for the decoder at the receiving end. Also, for plaintext serialization, binary data must be converted to escaped and encoded data that can exist as a string (e.g., in Base64), where escaped and encoded data may be identified using characters such as backslashes and quotes in software code.

(1) The converted data can be readily transmitted over the network, and (2) The converted data can be consistently converted back to a usable format once the data arrives on the receiving end. As such, specific data formats for the binary data can be selected and used. Data formats may exhibit at least the following two characteristics:

(1) schema-resistant (or schema-agnostic) “compatible” (or flexible) formats, such as JSON, XML, YAML, etc. These data formats, for example, may be used with respect to transmit management information traffic, such as in a control or management plane. This first category of data formats may be considered to be “compatible” or “flexible” because there are no requirements for a schema to exist in order to send or receive data. (2) firmly structured (or schema-following) “incompatible” (or inflexible) formats, such as Google-designed protobuf, or industry-standardized formats, such as JPEG, GIF, IEEE 802.3 Ethernet packets, etc. These data formats, for example, may sacrifice flexibility for speed in some cases. Also, data formats exhibiting these characteristics generally fall into two categories:

In both format categories, an arbitrary collection of binary bytes is usually converted to a transmittable format. For flexible formats, such as JSON, this conversion process takes time and computing resources are often encoded into a format such as Base64, which allows for the correct representation of the binary data in pure ASCII text characters. For inflexible formats, such as Google protobuf, the data is copied, and a simple protobuf-unique header is prepended to the data to signify that the upcoming data is a series of bytes having length X. This formatting saves encoding time compared to Base64, but still requires data to be copied, a relatively computationally expensive operation if done frequently. One detail is that both formats typically require a memory allocation, in addition to compatible formats needing to perform an encoding operation while incompatible formats perform a copy operation.

1 FIG. 10 12 1 12 2 12 3 12 12 1 12 2 12 3 12 14 1 14 2 14 3 14 12 16 1 16 2 16 3 16 16 10 12 1 12 12 1 12 10 n n n n n n is a block diagram illustrating an example of a microservice chainhaving a plurality of microservices-,-,-, . . . ,-. Each microservice-,-,-, . . . ,-may be associated with a corresponding database-,-,-, . . . ,-. Also, the microservicesmay include a corresponding Serializer/Deserializer (SerDes)-,-,-, . . . ,-, respectively. Each SerDesincludes a serializing portion and a deserializing portion. In this example, the microservice chainincludes a number (n) of microservices, wherein the first microservice-is arranged at a first endpoint and the last microservice-is arranged at a second endpoint. According to various implementations, the first microservice-may be considered to be a “requester microservice” for requesting binary data and the last microservice-may be considered to be a “provider microservice” for providing the requested binary data through the microservice chainto the requester microservice.

12 1 14 12 10 12 12 10 16 12 10 12 12 12 12 14 12 n n n n Thus, in operation, a “get” command may be received at the first microservice-for obtaining binary data that is stored in the database-of the last microservice-. In addition, the get command may include instruction for converting the binary data, if necessary, to a specific data format (e.g., JSON, XML, YANG, etc.). However, according to conventional systems, information regarding the requested data format is not passed through the microservice chain. Instead, according to typical strategies of conventional systems, each microserviceis configured to deserialize and serialize data in order to enable communication with its adjacent microservice. That is, each microservice, at each level along the microservice chain, will utilize its respective SerDesbased on the format in which the data was received and based on the format that enables communication to the next microservice. Therefore, in the conventional systems, the get command is forwarded through the microservice chain(from top to bottom) until it reaches the last microservice-. Then, the last microservice-is configured to retrieve the requested binary data and serialize it for transport to the next higher microservice. Again, the microserviceat each level deserializes and serializes the data, along with copying steps involving its respective databaseand other steps, before passing the data along to the next microservice.

16 10 12 1 12 12 14 16 12 12 16 16 14 10 n n n n n However, according to the embodiments of the present disclosure, the SerDesstage can be bypassed at most levels of the microservice chain. That is, information regarding the requested data format, which is received in the original get command at the first microservice-, can be passed with the get command down to the last microservice-. Then, the last microservice-can retrieve the requested binary data from database-and utilize the serialize component of its SerDes-to serialize the data according to the requested data format. In addition, the microservice-is configured to add a tag (or flag) to the binary data, whereby the tag can be considered as a “fast-forward” flag that indicates to each intermediate microserviceto simply forward the data while bypassing its SerDesstage. Thus, bypassing the SerDesreduces the number of times that the data is deserialized, re-serialized, copied into the database, allocated into memory, among other procedures. The data can be quickly and more efficiently transported back to the top of the microservice chain. Note, while the term tag is used herein, those skilled in the art will recognize this can be any identifier used to denote the desire to “fast-forward” the associated binary data.

According to various embodiments, the present disclosure aims to improve upon the two format categories (i.e., flexible and inflexible formats) by eliminating most memory allocation, encoding, and copy operations. The feature of “fast-forwarding” references how binary data can skip the normal serialization process of a format and be directly transmitted and used as a pointer combined with a length value. The feature of “fast-forwarding” is “fast” in comparison to the normal serialization process, namely taking less time and/or resources to perform. For microservices, which may act solely as routers or proxies for other services, this means that the binary data can be directly extracted from a message, passed through the system in an internal format, and sent to an external client without decoding the contents of the binary encoded data, and copying the data as little as possible in the process.

2 FIG. 2 5 FIGS.- 2 FIG. 20 22 24 26 22 28 30 20 26 32 34 20 36 38 30 34 20 28 32 36 32 12 12 1 12 n. is a block diagram illustrating an example of a procedurefor processing data within a microservice for converting the data to a particular data format. The term “Internal Data,” as shown inis meant to refer to examples of data in an internal format belonging to the specific microservice. This internal data is also configured to reference a binary chunk or blob of data. In, the internal dataincludes a referenceto binary data. The internal datais converted in a conversion stepto JSON. In this procedure, the binary datais also encoded in an encoding stepto Base64 data. The procedurealso includes a combining stepto arrive at a final JSON stringby combining JSONwith the Base64 data. Thus, in total, the procedureincludes (costs) three separate memory allocations (i.e., associated with the conversion step, encoding step, and combining step) and one encoding operation (i.e., encoding step). However, as described in the embodiment of the present disclosure, the number of memory allocation steps and encoding steps can be reduced, particularly in the intermediate microservicespositioned between the first microservice-and the last microservice-

3 FIG. 1 FIG. 40 40 10 40 is a block diagram illustrating an embodiment of a procedurefor improving upon conventional systems that abide by various protocols that normally include multiple memory allocation steps, encoding steps, etc. In contrast to the conventional systems, the procedurecan use strategies that allow a reduction in the number of costly (e.g., with respect to time, CPU utilization, power consumption, etc.) actions performed at each level of a microservice chain, such as microservice chainof. As such, the proceduremay be considered to be one embodiment of the fast-forwarding strategy described in the present disclosure and may be implemented at any microservice level within a microservice chain.

40 42 44 46 42 48 50 50 52 54 52 54 50 54 Specifically, the procedureincludes internal data, which contains a referenceto binary data. The format of the internal datais converted in a conversion stepto JSON, which can be configured as payload and/or may contain any suitable format that is readable and machine parsable. However, the JSONcontains only a referenceto the binary data. The referencecan merely be copied to the binary datato prepare the data to be ready for transmission. Thus, the data is never encoded nor is it copied in a database, saving at least two memory allocation operations, an encoding operation, and a copy operation. The JSONis simultaneously configured as a footer for the binary data, which represents its location in the model, as well as a container for any other internal data present.

4 FIG. 60 60 62 64 64 66 68 62 70 74 68 72 74 74 76 78 68 80 82 78 60 64 68 72 74 68 78 is a block diagram illustrating an embodiment of a procedurefor processing data and converting data formats by any suitable microservice at any level within a microservice chain. In this embodiment, the procedureincludes starting with binary datawith JSONas a footer. The JSONmay include a memory allocationto internal data. Also, the binary datamay be forwardedto binary dataat the next operational level. At this level, the internal datacontains a referenceto the binary data. The binary datais forwardedto binary dataat the next operational level. Also, the internal dataincludes a memory allocationto XML, which may be configured as a footer to the binary data. Thus, this proceduredemonstrates how the JSONcan be unpacked to the internal dataformat, while keeping the referenceto the binary data. Also, the internal dataformat can be serialized to XML, again keeping the reference to the binary data.

2 4 FIGS.- It should be noted that the formats of JSON and XML in the embodiments ofare not meant to be limited to merely these formats. Instead, these formats are shown and described merely for illustration purposes only. However, according to other embodiments, the formats can be any arbitrary formats and can be incorporated in the body of the data string as a footer (or header) as long there is an indication of what data in the message is binary, where the data is in the message, and how big the binary data is.

3 4 FIGS.and 2 FIG. 12 1 (1) The transmitted data structure passed up to microservice code can simply be a pointer to the received message. The binary data can be directly readable and useable, which can save an additional copy operation and free operation, whereby the free operation may refer to freeing a pointer when a reference count reaches zero. (2) The transmitted data structure used by microservice code can be readily passed around as normal, where the pointers may be freed when no references are left. (3) The transmitted data structure can be serialized and deserialized back and forth with no additional memory allocation penalty for the binary data portion. In some cases, the binary data portion can be quite large. Therefore, the embodiments ofmay have some immediate benefits with respect to the embodiment ofat the receiving end (i.e., the “requester microservice,”microservice-, etc.):

5 FIG. 90 90 is a block diagram illustrating an embodiment of a procedurefor processing data as performed by any suitable microservice at any level within a microservice chain. Data represented in this proceduremay implement a performance-oriented fast-forwarding format, which may “flow” within a microservice and support all the normal things that messages and data need to support. Functions like copy, free, comparison, filtering, logging, debugging, etc. may all be supported for content that contains binary data for fast forwarding.

Of these functions, copy and free operations are the most common and the most resource intensive, especially if the binary data is large (as would normally be the case in many fast-forwarding use cases). To support copy and free operations, two implementations are proposed that can be made for this internal representation, as described below.

In a first implementation, the metadata's relative position to the binary data may be important. In some embodiments, the position as a footer may be selected. In this respect, because allocated memory cannot be freed from within a block of memory, the metadata is able to be detached and discarded without re-allocating and copying the binary data. Allocated memory can be shortened to a smaller block of memory. Also, once the metadata (in the footer) is processed from the data-format on the wire to an internal representation, the address obtained from the message may be the same address as the one used in the internal representation. This will avoid separate copy or free operations to move the data from the messaging layer to the internal representation. Similarly, when the internal representation is being converted to a format usable in a messaging layer (where the footer is converted from an internal structure to a data format on the wire), the address used in the message to be sent can be the same as the address used in the internal representation, which again can save another copy (i.e., reduce the number of copy operations by one).

In a second implementation, copy/free operations can be reduced as much as possible. Since the data may be large and it is beneficial to avoid doing large copy operations and free operations of the data as it moves throughout the system, one approach is to use a reference counter for the binary data that can be incremented every time a block is “copied” and decremented every time the block is “freed.” When there are no outstanding references to the data, the data block can be freed.

90 92 94 96 1 96 2 96 98 100 102 104 106 100 104 96 1 96 2 96 106 5 FIG. x x This approach, according to these two implementations, can be extended to messages containing references to multiple chunks of binary data, as shown in the procedureof. Internal datacan include referencesto multiple chunks of binary data-,-, . . .-. The multiple chunks can be combinedand configured as concatenated binary data. The internal can be formattedas XML(or another suitable format). Also, at this second level of operation in the respective microservice, metadatacan be prepended to the concatenated binary dataand XML. When converted to an over-the-wire format, the chunks of binary data-,-, . . . ,-can be sent concatenated with each other, with the metadatadescribing each chunk.

104 108 110 106 112 114 118 114 110 120 114 118 The XMLmay be forwarded in a forwarding stepto internal datain the next level. Also, the metadatamay be forwarded in a forwarding stepin the next level to metadataand arranged as a header. Also, when converted back to an internal format, the chunks of binary data are not split up due to the requirement of avoiding copies and memory allocations. Instead, they may be kept in one single chunk (e.g., concatenated binary data) with the metadata(newly encoded) pointing to all potential chunks and reference counts that keep track of the single chunk as opposed to individual chunks. The internal datamay include a referenceto the body of data including the metadataand concatenated binary data.

6 FIG. 6 FIG. 130 130 132 134 136 138 140 130 132 134 136 138 140 142 142 142 142 132 134 136 138 140 is a block diagram illustrating an embodiment of a computing systemassociated with any node, NE, or microservice that may be arranged in a microservice chain for transmitting data from one end of the chain to the other. In the illustrated embodiment, the computing systemmay be a digital computing device that generally includes a processing device, memory, Input/Output (I/O) devices, a network interface, and a data storage device. It should be appreciated thatdepicts the computing systemin a simplified manner, where some embodiments may include additional components and suitably configured processing logic to support known or conventional operating features. The components (i.e.,,,,,) may be communicatively coupled via a local interface. The local interfacemay include, for example, one or more buses or other wired or wireless connections. The local interfacemay also include controllers, buffers, caches, drivers, repeaters, receivers, among other elements, to enable communication. Further, the local interfacemay include address, control, and/or data connections to enable appropriate communications among the components,,,,.

It will be appreciated that some embodiments described herein may include or utilize one or more generic or specialized processors (“one or more processors”) such as microprocessors; Central Processing Units (CPUs); Digital Signal Processors (DSPs): customized processors such as Network Processors (NPs) or Network Processing Units (NPUs), Graphics Processing Units (GPUs), or the like; Field-Programmable Gate Arrays (FPGAs); and the like along with unique stored program instructions (including both software and firmware) for control thereof to implement, in conjunction with certain non-processor circuits, some, most, or all of the functions of the methods and/or systems described herein. Alternatively, some or all functions may be implemented by a state machine that has no stored program instructions, or in one or more Application-Specific Integrated Circuits (ASICs), in which each function or some combinations of certain of the functions are implemented as custom logic or circuitry. Of course, a combination of the aforementioned approaches may be used. For some of the embodiments described herein, a corresponding device in hardware and optionally with software, firmware, and a combination thereof can be referred to as “circuitry configured to,” “logic configured to,” etc. perform a set of operations, steps, methods, processes, algorithms, functions, techniques, etc. on digital and/or analog signals as described herein for the various embodiments.

Moreover, some embodiments may include a non-transitory computer-readable medium having instructions stored thereon for programming a computer, server, appliance, device, at least one processor, circuit/circuitry, etc. to perform functions as described and claimed herein. Examples of such non-transitory computer-readable medium include, but are not limited to, a hard disk, an optical storage device, a magnetic storage device, a Read-Only Memory (ROM), a Programmable ROM (PROM), an Erasable PROM (EPROM), an Electrically EPROM (EEPROM), Flash memory, and the like. When stored in the non-transitory computer-readable medium, software can include instructions executable by one or more processors (e.g., any type of programmable circuitry or logic) that, in response to such execution, cause the one or more processors to perform a set of operations, steps, methods, processes, algorithms, functions, techniques, etc. as described herein for the various embodiments.

130 144 134 132 144 134 132 144 144 12 n Furthermore, the computing systemmay include a microservice fast-forwarding program, which may be configured in any suitable combination of software or firmware and implemented in the memory, either in physical or virtual memory, and/or hardware implemented in the processing device. In some embodiments, the microservice fast-forwarding programmay be stored in non-transitory computer-readable media (e.g., the memory) and may include logic code and/or instructions that enable or cause the processing deviceto perform certain actions, such as those described in the present disclosure for requesting and responding to requests in a microservice chain. The microservice fast-forwarding programmay be configured to execute the various functions described in the present disclosure for forwarding binary data in various data formats from one microservice to another. In some embodiments, the microservice fast-forwarding programmay be executed by any of the microservices in the chain, while in other embodiments, the actions may be performed by the “provider microservice” (i.e., microservice-) for adding a tag that instructs the intermediate microservices to simply forward the data without performing the normal (yet extra) operations of memory allocation, copying, freeing, etc.

7 FIG. 150 150 150 is a flow diagram illustrating an embodiment of a processfor transmitting data in a “fast-forward” manner within a microservice chain. The processmay be performed by a processor, computer, microservice, NE, node, etc. that has at least the same or greater processing and computing capabilities compared with the other processors, computers, microservices, NEs, nodes, etc. in the microservice chain. Also, the process, in particular, may be performed by the “provider microservice” that is arranged at one end of the chain and is configured to receive a request for binary data from a “requester microservice” at the other end of the chain. In addition to returning the requested binary data, the provider microservice also applies a tag that indicates to intermediate microservices up the chain to leave the data alone and merely forward it to the next microservice, thereby avoiding extra steps of memory allocation, copying, etc.

7 FIG. 150 152 150 154 150 156 As illustrated in, the processincludes a step of receiving a request from a requester microservice to obtain binary data formatted in a specific data format, as indicated in block. The processfurther includes a step of converting the binary data from a native data format to the specific data format as requested by the requester microservice, as indicated in block. Also, the processincludes a step of adding a tag with the binary data, as indicated in block, wherein the tag is configured to instruct each intermediate microservice along the microservice chain to bypass a Serialize/Deserialize (SerDes) stage therein while forwarding the binary data to a next microservice in the microservice chain.

156 According to some embodiments, the tag (described in block) may be further configured to instruct each intermediate microservice along the microservice chain to bypass one or more steps associated with at least one of a binary-to-text decoding stage, a text-to-binary re-encoding stage, a memory allocation stage, and a data copying stage therein. In some embodiments, each microservice of the microservice chain may include a microprocessor and may be associated with an embedded system, node, or Network Element (NE) that is part of a distributed system. Also, in alternative embodiments, the microservice chain may be configured in a system having a single processor and shared memory address space, wherein the tag may be related to a pointer that points to locations within the shared memory address space.

Furthermore, according to various implementations, the native format and the specific data format may be categorized as flexible, schema-agnostic formats used for transmitting management information in a control plane. The flexible, schema-agnostic formats, for example, may include JSON, XML, YAML, and/or other various formats. Alternatively, the native format and the specific data format may be categorized as inflexible, firmly structured formats for transmitting data traffic in a data plane. The inflexible, firmly structured formats, for example, may include JPEG, GIF, protobuf, TCP, IP, IEEE 802.3 Ethernet packets, and/or other various formats.

150 150 In some embodiments of the process, the tag may be configured as metadata and stored or encapsulated in a header or footer. The tag may be configured to instruct the intermediate microservices to fast-forward the binary data in an opaque manner, avoid conversion to Base64 format, and bypass a plaintext serialization stage. The binary data, for example, may include a data file, a picture file, pre-serialized data, generated data, performance logs, a word processing document, and/or other types of data. Upon adding the tag, the processmay further include a steps of performing a pre-serialization of the binary data and passing the pre-serialized binary data and tag to a neighboring microservice in the microservice chain. In some embodiments, the tag may enable the neighboring microservice and/or intermediate microservices to reduce overhead, reduce CPU cycles, reduce memory allocation actions, reduce copying actions, reduce pointer freeing actions, reduce comparison actions, reduce filtering actions, reduce logging actions, and/or reduce debugging actions.

152 150 Furthermore, according to some embodiments, the request (block) is a binary version of a get command that is passed along the microservice chain from the requester microservice to the provider microservice. The processmay further include a step of pre-formatting the binary data in a binary buffer with a reference pointing to a shared memory address space, wherein the reference may be stored as metadata and included as a footer or header with respect to a payload related to the binary data to be transmitted through the microservice chain. The metadata, for example, may include an indication of at least what portions of a message contain the binary data, where the binary data is contained in the message, and a number of bytes of the binary data.

150 150 The process, in some embodiments, may further include steps of a) sending gNMI data, b) configuring the resource owner as a modem to generate a constellation, c) sending the binary data transparently without encoding, and/or d) encrypting the binary data that intermediate microservices cannot access but can only forward the binary data opaquely, whereby the requester microservice is able to decrypt the encrypted binary data. The binary data, in some cases, can include multiple chunks or blobs of data concatenated together, wherein the processmay further include a step of incorporating metadata with the binary data to define each chunk or blob.

The tag in the schema data may be used to indicate that a field should be serialized as binary data. Serialization that detects these tags and generates serialized data with raw pointers to the binary data is considered to be novel with respect to conventional systems. Also, messaging layers that can send and receive the buffers with serialized data are considered to be novel. Furthermore, the present disclosure includes a buffer that is organized to reduce or eliminate the need for copy operations in the same address space. Also, deserialization that detects this format and regenerates language specific code with references to this binary data, as described herein, is also regarded as novel. Hooks that allow for copy/free/comparison operations on the binary data that reduce or eliminate copy operations within the same address space are further aspects that separate the embodiments of the present disclosure from conventional systems.

Some operating principles of the various embodiments described herein may include one aspect that includes adding an element to the schema language to identify an element as “opaque binary.” The present systems can generate metadata for this element that contains address, offset, and length information so its location in an opaque buffer can be tracked as it flows. Also, applications can perform steps of generating binary data and supplying the address and length to the internal structure. The systems herein may also indicate which buffers are freeable and which ones are contained inside a larger structure. In addition, the present systems can also indicate names of objects and formats for decoding on the other side.

Additional operational principles may include metadata that can track the number of references and code in order to increment and decrement references when copy/free is requested. When the number of references drops to zero, the buffer can be freed. Also, the embodiments described herein may include a step of modifying SerDes code for messaging in order to detect this type of data and move/copy the binary data to the serialized buffer with information in a serialized header on where the data resides in the buffer, such as by changing the address in the structure to be an offset in a flat non-addressed buffer instead.

(1) Type of data (e.g., gNMI, JSON, JPEG, GIF, Wiretrace capture, perf data, etc.), (2) Length of data, and (3) Receiver of the data. The operation principles of the present disclosure also allow applications to supply or access additional metadata so that when deserialized on the client, the following can be determined:

Once the buffer is deserialized on the receiver, the embodiment described herein may also be configured to re-use the binary buffer and adjust the offsets in the metadata to refer to real addresses inside the buffer, thereby avoiding a copy if possible. Also, the systems can decode the header to an internal structure and call the handler for this buffer. If processing is needed to recover the binary data, the type (e.g., JPEG, GIF, etc.) can be extracted so the client can properly process it.

Again, some benefits of the various embodiments described in the present disclosure may include a reduction in processing time due to reduced serialization/deserialization time and reduction in copy/free operations. Also, the systems allow for faster telemetry streams since data can be encoded on a different processor in parallel and simply passed as pre-encoded data through a would-be bottleneck. In addition, the systems and methods of the present disclosure can open up possibilities for sending other binary data, such as logs, images, encrypted data in YANG, schema-based APIs, or the like, which might not normally be able to handle this data.

As described in the present disclosure and in the following claims, the phrases “at least one of” or “one or more of” a list of items refer to any combination of those items, including single members. For example, “at least one of: A, B, or C” covers the possibilities of: A only, B only, C only, a combination of A and B, a combination of A and C, a combination of B and C, and a combination of A, B, and C. Additionally, the terms “comprise,” “comprises,” “comprising,” “include,” “includes,” and “including” are intended to be non-limiting and open-ended. These terms specify essential elements or steps but do not exclude additional elements or steps, even when a claim or series of claims includes more than one of these terms.

While the present disclosure has been detailed and depicted through specific embodiments and examples, it is to be understood by those skilled in the art that numerous variations and modifications can perform equivalent functions or yield comparable results. Such alternative embodiments and variations, which may not be explicitly mentioned but achieve the objectives and adhere to the principles disclosed herein, fall within its spirit and scope. Accordingly, they are envisioned and encompassed by this disclosure, warranting protection under the claims associated herewith. That is, the present disclosure anticipates combinations and permutations of the described elements, operations, steps, methods, processes, algorithms, functions, techniques, modules, circuits, etc., in any manner conceivable, whether collectively, in subsets, or individually, further broadening the ambit of potential embodiments.

Although operations, steps, instructions, and the like are shown in the drawings or claims in a particular order, this does not imply that they must be performed in that specific sequence or that all depicted operations are necessary to achieve desirable results. The drawings may schematically represent example processes as flowcharts or flow diagrams, but additional operations not depicted can be incorporated. For instance, extra operations can occur before, after, simultaneously with, or between any of the illustrated steps. In some cases, multitasking and parallel processing are contemplated. Furthermore, the separation of system components described should not be interpreted as mandatory for all implementations, as the program components and systems can be integrated into a single software product or distributed across multiple software products.