Repository navigation
5.4 Canonical Wire v1 Encoding
Deterministic, validated encoding for wire-version-1 IpcMessage envelopes. Public API: encode_canonical_ipc_message → Result<Vec<u8>, CanonicalEncodeError>. Normative spec (also in the crates.io package): docs/wire-encoding.md. Helpers live in src/canonical_ser.rs.
This is the corpus-ipc project wire profile. It is not RFC 8785 / JCS.
-
message.validate()— fail closed (CanonicalEncodeError::Validation); non-finite floats never become JSONnull. - Wrap in
WireEnvelopewithwire_version = WireCompatibility::CURRENT(1). - Serialize via
serialize_f32_as_f64so finitef32values are emitted as widenedf64decimals (stable under consumerserde_jsonarbitrary_precisionunification). -
Value::sort_all_objects()— recursive byte-wise key sort at every nesting depth (correct even if a consumer enablespreserve_order). - Compact
serde_json::to_vec(no insignificant whitespace).
Envelope shape (keys sorted, so payload precedes wire_version):
{"payload":<payload>,"wire_version":1}Struct variants are externally tagged objects; unit variants are JSON strings ("Ping", "Shutdown", "TrainingComplete").
ConfigValue stays Float-first on the wire: Integer(42) round-trips as Float(42.0); integers above 2^24 can lose identity on an f32 round-trip. Documented in the wire spec and locked by normalization goldens / properties.
| Variant | Meaning |
|---|---|
CanonicalEncodeError::Validation(ValidationError) |
Validate failed before serialization |
CanonicalEncodeError::Json(...) |
serde_json failure after validation |
Decode path remains decode_ipc_message_json / decode_ipc_message_value (see 5.3). Prefer the canonical encoder for new fixtures; never regenerate legacy / negative vectors through it.
tests/canonical.rs- 7.2.1 Wire-v1 Golden Test Vectors
- 7.2.2 Property-Based Wire Tests
-
ci/ap-check— proves encoding stays stable whenserde_json/arbitrary_precisionis unified
- Home
- 1. Overview
- 1.1. Getting Started
- 1.2. Architecture Overview
- 1.3. Crate Exports and Module Map
- 2. Core Abstractions
- 2.1. IpcBackend Trait
- 2.2. HybridFlowBackend Trait
- 2.3. BackendFactory and BackendType
- 2.4. Error Handling
- 3. Backend Implementations
- 3.1. RustBackend
- 3.2. ZmqIpcBackend
- 3.3. ZMQ Readout Parsing and Golden Frames
- 3.4. Structured ZeroMQ IpcMessage Transport
- 4. IPC Protocol and Data Models
- 4.1. IpcMessage Protocol
- 4.2. Batch Data Types
- 4.3. NeuromodulatorSnapshot and Neuromodulator Packet
- 4.4. StimulusBatch and Runtime Ingress
- 4.5. Deserialization Hooks and Model Compat Aliases
- 5. Validation and Wire Compatibility
- 5.1. Validation Framework and ProtocolLimits
- 5.2. ValidationError and ValidationKind
- 5.3. WireCompatibility and Envelope Decoding
- 5.4. Canonical Wire-v1 Encoding
- 6. corpus_ipc_server HTTP Server
- 6.1. REST API Endpoints
- 6.2. Server Configuration and Deployment
- 7. Build, Dependencies, and Quality Gates
- 7.1. Cargo Features and Dependency Isolation
- 7.2. Testing Strategy
- 7.2.1. Wire-v1 Golden Test Vectors
- 7.2.2. Property-Based Wire Tests
- 7.3. CI, Coverage, and Release Qualification
- 8. Project History and Licensing
- 8.1. Naming History and Completed Renames
- 8.2. Licensing
- 9. Glossary