//// WireProto Specification © 2024 by Brent Saner is licensed under Creative Commons Attribution-ShareAlike 4.0 International. To view a copy of this license, visit https://creativecommons.org/licenses/by-sa/4.0/ //// = WireProto Specification Brent Saner Last rendered {localdatetime} :doctype: book :docinfo: shared :data-uri: :imagesdir: images :sectlinks: :sectnums: :sectnumlevels: 7 :toc: preamble :toc2: left :idprefix: :toclevels: 7 :source-highlighter: rouge :docinfo: shared :this_protover: 1 :this_protover_hex: 0x00000001 //:lib_ver: master //:lib_ver_ref: branch :lib_ver: v1.0.1 :lib_ver_ref: tag [id="license"] == License ++++ include::LICENSE.html[] ++++ In a nutshell, this means any may: * Use it in commercial/proprietary/internal works... * Expand upon/change the specification... ** (As long as it is released under the same Creative Commons license) As long as you attribute the original (this document). This can be as simple as something like: ==== Based on WireProto version as found at https://wireproto.io/. ==== More details certainly helps, though; you may want to mention the exact date you "forked" it, etc. Please see the full text as collapsed above or https://creativecommons.org/licenses/by-sa/4.0/legalcode.en[the online version^] of the license for full legal copy. NOTE: In the event of the embedded text in this document differing from the online version, the online version is assumed to take precedence as the valid license applicable to this work. [id="proto"] == Protocol The WireProto data packing API is a custom wire protocol//message format designed for incredibly performant, unambiguous, predictable, platform-agnostic, implementation-agnostic communication. It is based heavily on the https://github.com/openssh/openssh-portable/blob/master/PROTOCOL.key[OpenSSH "v1" key format^] https://git.r00t2.io/r00t2/go_sshkeys/src/branch/master/_ref/KEY_GUIDE.html#v1_plain_2[(example/details)] packing method. It supports arbitrary binary values, which means they can be anything according to the implementation-specific details; a common practice is to encode ("marshal") a Go struct to JSON bytes, and set that as a WireProto field's value. It supports both static construction/parsing/dissection and stream approaches in a single format, as well as multiple commands per request message/multiple answers per response message. *All* packed uint32 (_unsigned 32-bit integer_) values are a https://en.wikipedia.org/wiki/Endianness[big-endian^] 4-byte sequence (e.g. `3712599402` == `0xdd49c56a`, or [`0xdd`, `0x49`, `0xc5`, `0x6a`]). This specification's <> is `{this_protover}` (`{this_protover_hex}`). For other releases/finalized versions of this specification, see https://git.r00t2.io/r00t2/WireProto/tags[here^]. For in-development versions, drafts, etc. of this specification, see https://git.r00t2.io/r00t2/WireProto/branches[here^]. [id="proto_reqresp"] === Requests/Responses WireProto indicates two types of Messages/communication ends: a _Requester_ (_Requesting End_) and a _Responder_ (_Responding End_). This terminology is intentionally implementation-agnostic. A _Requester_ is any end of a communication that is *requesting data*, and the _Responder_ is any end of a communication that is *providing that data*. A Responder may not always be present (e.g. in the case of using WireProto for local disk serialization/caching, etc.), and a "client" may be a Requester, Responder, or both -- likewise for a "server". [id="lib"] === Reference Library The WireProto specification is accompanied by a reference library for Golang, https://git.r00t2.io/r00t2/go_wireproto["WireProto"^] (https://git.r00t2.io/r00t2/wireproto[_source_^]): ++++

Go Reference

++++ Additional reference libraries may be available in the future. [id="ytho"] === Why Yet Another Message Format? Because existing methods of serializing data in a structured way (e.g. JSON, XML, YAML) are slow/bloaty, inaccurate, and/or inflexible. They struggle with binary or abritrary data (or in e.g. XML's case requiring intermediate conditional encoding/decoding). If it can be represented as bytes (which all digital data can), WireProto can send and receive it. Additionally: * https://protobuf.dev/[*Protobuf*^] has performance issues (yes, really; protobufs have large overhead compared to WireProto) and is restrictive on data types for future-proofing. * https://go.dev/blog/gob[*Gob*^] is very language-limiting and does not support e.g. nil pointers and cyclical values. * https://capnproto.org/[Cap'n Proto^] has wide language support and excellent performance but is terribly non-idiomatic, requiring the code to be generated from the schema and not vice versa (which is only ideal if you have only one communication interface and is, in the author's opinion, the entirely incorrect approach). * https://en.wikipedia.org/wiki/JSON_streaming[JSON streams^] have no delimiters defined which makes it an inconvenience if using a parser that does not know when the message ends/is complete, or if it is expecting a standalone JSON object (e.g. native vanilla Golang JSON parsing). [TIP] ==== WireProto is only used for binary packing/unpacking; this means it can be used with any e.g. https://pkg.go.dev/net#Conn[`net.Conn`^] (and even has helper functions explicitly to facilitate this), storage on-disk, etc. As such it is transport/storage-agnostic, and can be used with a https://pkg.go.dev/net#Dial[TCP socket, UDP socket, IPC (InterProcess Communication)/UDS (UNIX Domain Socket) handle,^] https://pkg.go.dev/crypto/tls#Dial[TLS-tunneled TCP socket^], etc. See the <> for details. ==== [id="msg"] == Message Format [TIP] ==== Throughout this document, you may see references to things like `LF`, `SOH`, and so forth. These refer to _ASCII control characters_. You will also see many values represented in hex. You can find more details about this (along with a full ASCII reference) https://square-r00t.net/ascii.html[here^]. Note that the specification fully supports UTF-8 (or any other arbitrary encoding) -- just be sure that your <> are aligned to the *byte count* and not *character count* (as these may not be equal depending on encoding). ==== Each *message* is composed of: * The <>footnote:responly[Response messages only.] * A <>footnote:optreq[Optional for Request.]footnote:reqresp[Required for Response.] * A <> * A <> * A <> * A <> <> * A <> <> * One (or more) <>(s), each of which contain: ** One (or more) <>(s), each of which contain: *** One (or more) <>(s), each of which contain: **** A <> **** A <> *** A <>footnote:responly[] * A <> * A <> [id="msg_respstatus"] === Response Status For response messages, a speciall "summary byte" is prepended; a status indicator. This allows requesting ends to quickly bail in the case of an error if no further parsing is desired. The status will be indicated by one of <>: an ASCII `ACK` (`0x06`) for all requests being returned successfully or an ASCII `NAK` (`0x15`) if one or more errors were encountered across all records. [id="proto_ver"] === Protocol Version The protocol version is a packed uint32 that denotes which version of this protocol specification is being used. It is maintained seperately from the *library* version/repo tags. The current protocol version (as demonstrated in this document) is `{this_protover}` (`{this_protover_hex}`). NOTE: Version `0` is reserved for current `HEAD` of the `master` branch of this specification and should be considered experimental, not conforming to any specific protocol message format version. [id="msg_grp"] === Record Group A record group contains multiple related <>. It is common to only have a single Record Group. Its structure is: . <> <> . <> <> . One (or more) <> [id="msg_grp_rec"] ==== Record A record contains multiple related <> and, if a Response Record, a copy of the original reference Request Record it is responding to. Its structure is: . <> <> . <> <> .. One (or more) <> . <> <>footnote:responly[] [id="msg_grp_rec_kv"] ===== Field/Value Pair (Key/Value Pair) A field/value pair (also referred to as a key/value pair) contains a matched <> and its <>. Its structure is: . <> <> . <> <> . A single <> . A single matching <> [IMPORTANT] ==== Unlike most/all other <> for other sections/levels, the field name and value allocators are consecutive <>! This is because there is *only one* field name and value per <>. ==== [id="msg_grp_rec_kv_nm"] ====== Field Name The field name is usually from a finite set of allowed names. The <>, while written as bytes, often contains data defined by the field name. (That is, the parsing of <> often depends on its Field Name.) It is recommended that the field name be a UTF-8-compatible string for simplified serializing and https://www.wireshark.org/[on-the-wire debugging^]. While there is no technical requirement that a field name be unique per-<>, it is generally recommended (unless emulating/encoding arrays of data in separate <>). Its structure is: . A name/identifier in bytes [id="msg_grp_rec_kv_val"] ====== Field Value A field's value is, on the wire, just a series of bytes. The actual content of those bytes, including any structure or encoding, is likely to/probably depends on the paired <>. Its structure is: . A value in bytes [id="msg_grp_recresp"] ===== Copy of Original Record This contains a "copy" of the original/request's <> that this record is in response to. It is only present in Response message and must not be included in Request messages. It is a complete <> from the request embedded inside the responding Record. For example, if a record contains multiple <> specifying a query of some data then the response record will contain a copy of that record's query data. [NOTE] ==== While *not recommended*, it *is* within specification/permissible to "alias" a request record via a session-unique identifier (e.g. https://datatracker.ietf.org/doc/html/rfc4122[UUIDv4^]), *provided* the promise that the requesting end retains an identifiable copy of/can lookup or associate its original record based on that identifying alias. For example, a requesting end may specify _its own_ provided identifier as an <> (e.g. `identifier:f18231973d08417e877dd1a2f8e8ab74`) along with additional data. The returning Response Record may then include *only* an original/request record with an FVP of `identifier:f18231973d08417e877dd1a2f8e8ab74` along with the requested data. Alternatively for another example, a responding end may return a Response Record with an original/request record of a single FVP such as `ref_id:46823da27f8749df9dee8f0bded8cce9` or the like. The requesting end *must* then be able to retrieve the full copy of the original request record as a standalone Response Record based on that `ref_id`. Responding ends *may* enforce lifetimes for request record lookup in this case but they must be promised. ==== [id="cksum"] == Checksums Checksums are optional for the requesting end but the responding end *must* send them. *If present* in the request, the responder *must* validate to ensure the checksum matches the message body (<> to <>, inclusive). If the checksum does not match, an error *must* be returned. They are represented as a big-endian-packed uint32. The checksum must be prefixed with a <>. If no checksum is provided in a request, this prefix *must not* be included in the sequence. [TIP] ==== A responder can quickly check if a checksum is present by checking the first byte in requests. If it is <>, a checksum is provided. If it is <>, one was *not* provided. ==== The checksum method used is the https://users.ece.cmu.edu/~koopman/crc/crc32.html[IEEE 802.3 CRC-32^], which should be natively available for all/most implementations/languages as it is perhaps the most ubiquitous of CRC-32 variants (e.g. https://docs.python.org/3/library/zlib.html#zlib.crc32[Python^], https://pkg.go.dev/hash/crc32[Golang^], https://github.com/gcc-mirror/gcc/blob/master/libiberty/crc32.c[GNU C/glibc^](?), https://crates.io/keywords/crc32[Rust^], etc.). (Polynomial `0x04c11db7`, reversed polynomial `0xedb88320`.) If one needs to implement the appropriate CRC32 implementation, there is extensive detail at the https://en.wikipedia.org/wiki/Cyclic_redundancy_check[CRC Wikipedia article^]. To confirm the correct CRC32 implementation is being used (as there are *many* "CRC-32" algorithms/methods/functions/libraries), the following validations may be used: .CRC-32 Validations [cols="^.^2m,3m,^.^1m,^.^2m,^.^2m",options="header"] |=== | String ^.^| Bytes | Checksum (integer) | Checksum (bytes, little-endian) | Checksum (bytes, big-endian) | WireProto | 0x5769726550726f746f | 815806352 | 0x30a03790 | 0x9037a030 | FooBarBazQuux | 0x466f6f42617242617a51757578 | 983022564 | 0xe4bb973a | 0x3a97bbe4 | 0123456789abcdef | 0x30313233343536373839616263646566 | 1757737011 | 0x33f0c468 | 0x68c4f033 |=== [id="hdrs"] == Headers Certain sections are wrapped with an identifying header. Those headers are included below for reference. [id="hdrs_respstart"] === `RESPSTART` Indicator Responses have a <>.footnote:responly[] It is either an `ACK` (`0x06`) or `NAK` (`0x15`). [id="hdrs_cksum"] === `CKSUM` Header Prefix A <>, if providedfootnote:optreq[]footnote:reqresp[], will have a prefix header of `ESC` (`0x1b`). [id="hdrs_msgstart"] === `MSGSTART` Header Prefix The message start header indicates a start of a "message". It is used to delineate operational headers from specification information (e.g. <>) and data. It is an `SOH` (`0x01`). [id="hdrs_bodystart"] === `BODYSTART` Header Prefix The body start header indicates that data/records follow. All bytes between `BODYSTART` and <> are to be assumed to be directly pertinent to the request/response rather than operational. It is an `STX` (`0x02`). [id="hdrs_bodyend"] === `BODYEND` Sequence The body end prefix indicates the end of data/records. All bytes between <> and `BODYEND` are to be assumed to be directly pertinent to the request/response rather than operational. It is an `ETX` (`0x03`). [id="hdrs_msgend"] === `MSGEND` Sequence The message end prefix indicates that a message in its entirety has ended, and if no further communication is necessary per implementation the connection may be disconnected. It is an `EOT` (`0x04`). [id="alloc"] == Allocators There are two type of allocators included for each following sequence of bytes: `count allocators` and `size allocators`. <> can be used by receiving ends to efficiently pre-allocate buffers and for sending ends to indicate the amount of remaining data expected. They are usually preceded with a <> to allow for pre-allocating e.g. slice/array sizes, but not always (e.g. <> have two <>). All allocators are unsigned 32-bit integers, big-endian-packed. [id="alloc_cnt"] === Count Allocator Count allocators indicate *how many* children objects are contained. [id="alloc_size"] === Size Allocator Size allocators indicate *how much* (in bytes) all children objects are combined as one block. They include the allocators themselves of child objects, etc. as well. [id="ref"] == Reference Model and Examples For a more visual explanation, given the following e.g. Golang structs from the <> (`wireproto.Request{}` and `wireproto.Response{}`): [id="ref_single"] === Single/Simple [id="ref_single_req"] ==== Single/Simple Request [%collapsible] .Example Message Structure (Simple Request) ==== [source,go] ---- include::https://git.r00t2.io/r00t2/go_wireproto/raw/{lib_ver_ref}/{lib_ver}/test_obj_simple_req.go[] ---- ==== Would then serialize as (in hex): [%collapsible] .Annotated Hex ==== [source,text] ---- include::docs/data/request.simple.txt[] ---- ==== Or, non-annotated: [source,text] ---- include::docs/data/request.simple.hex[] ---- [id="ref_single_resp"] ==== Single/Simple Response [%collapsible] .Example Message Structure (Simple Response) ==== [source,go] ---- include::https://git.r00t2.io/r00t2/go_wireproto/raw/{lib_ver_ref}/{lib_ver}/test_obj_simple_resp.go[] ---- ==== Would then serialize as (in hex): [%collapsible] .Annotated Hex ==== [source,text] ---- include::docs/data/response.simple.txt[] ---- ==== Or, non-annotated: [source,text] ---- include::docs/data/response.simple.hex[] ---- [id="ref_multi"] === Multiple/Many/Complex Multiple records, record groups, etc. can be specified in one message. [id="ref_multi_req"] ==== Complex Request [%collapsible] .Example Message Structure (Multiple/Many Requests, Single Message) ==== [source,go] ---- include::https://git.r00t2.io/r00t2/go_wireproto/raw/{lib_ver_ref}/{lib_ver}/test_obj_multi_req.go[] ---- ==== Would then serialize as (in hex): [%collapsible] .Annotated Hex ==== [source,text] ---- include::docs/data/request.multi.txt[] ---- ==== Or, non-annotated: [source,text] ---- include::docs/data/request.multi.hex[] ---- [id="ref_multi_resp"] ==== Complex Response [%collapsible] .Example Message Structure (Response to Multiple/Many Requests, Single Message) ==== [source,go] ---- include::https://git.r00t2.io/r00t2/go_wireproto/raw/{lib_ver_ref}/{lib_ver}/test_obj_multi_resp.go[] ---- ==== Would then serialize as (in hex): [%collapsible] .Annotated Hex ==== [source,text] ---- include::docs/data/response.multi.txt[] ---- ==== Or, non-annotated: [source,text] ---- include::docs/data/response.multi.hex[] ----