Repository navigation
4 IPC Protocol and Data Models
Relevant source files
The following files were used as context for generating this wiki page:
corpus-ipc serves as the authoritative owner of the wire protocol and data schemas used for communication between Rust-based services and external compute engines src/models/mod.rs:3-5. Since #68 (18a5a29, LIM-1547) the shipped README and rustdoc name no sibling repositories; only the contributor notes in CLAUDE.md still name thalamic-relay and brainstem-daemon as the producer and consumer. This page provides a high-level overview of the IpcMessage envelope, typed batch payloads, metadata structures, and configuration types defined in src/models/ src/models/mod.rs:3-46.
For implementation details, refer to the following child pages:
- IpcMessage Protocol
- Batch Data Types
- NeuromodulatorSnapshot and Neuromodulator Packet
- StimulusBatch and Runtime Ingress
- Deserialization Hooks and Model Compat Aliases
The top-level wire protocol is encapsulated by the IpcMessage tagged enum src/models/message.rs:32-57. It organizes traffic into input messages sent to compute engines, output messages received from compute engines, and control signals src/models/message.rs:13-18.
The enum implements validation via the Validate trait, recursively delegating protocol limit checks down to its variants src/models/message.rs:59-73.
For detailed coverage of serde tagging, session correlation, and variant stability, see IpcMessage Protocol.
Sources: [src/models/message.rs:13-73]()
Data flows across the IPC boundary in structured batches designed for efficient multi-stream routing and session isolation src/models/mod.rs:6-24. These wire types are distinct from in-memory training batches that other libraries also call SpikeBatch / TraceBatch (spike-train arrays, unstructured e-prop traces), and the two definitions must not be merged src/models/mod.rs:6-24. CLAUDE.md names SynapticDistill.jl as the library in question; the rustdoc no longer does.
The following diagram maps high-level conceptual entities to their corresponding Rust implementations in src/models/.
graph TD
subgraph "NaturalLanguageSpace"
A["NeuralPulse"]
B["FeatureVector"]
C["LearningSignal"]
D["SystemConfig"]
end
subgraph "CodeEntitySpace_src_models"
A --> B1["SpikeBatch / SpikeEvent"]
B --> B2["EmbeddingBatch"]
C --> B3["GradientBatch / TraceBatch"]
D --> B4["ConfigPayload / ConfigValue"]
end
B1 -- "batch_id" --> M["BatchMetadata"]
B2 -- "batch_id" --> M
B3 -- "batch_id" --> M
Sources: [src/models/mod.rs:6-46]()
For field semantics, JSON key stability, and type definitions, see Batch Data Types.
Sources: [src/models/mod.rs:6-46]()
Biological global regulation signals (such as dopamine, cortisol, acetylcholine, and tempo) are transmitted via the NeuromodulatorSnapshot payload src/models/mod.rs:42. This replaces unstructured float tails with a typed ingress structure that parses specific byte offsets from binary packets src/models/message.rs:42-44.
For byte layout offsets, value ranges, and biological significance, see NeuromodulatorSnapshot and Neuromodulator Packet.
Sources: [src/models/message.rs:42-44], [src/models/mod.rs:42]()
Continuous runtime stimuli are handled by the domain-neutral StimulusBatch wire type src/models/message.rs:38-41. It supports variable-width channels and optional valid_mask semantics, replacing consumers' ad-hoc payloads such as a flat UDP JSON message or a private ingress packet struct src/models/stimulus.rs.
For structural details and valid-mask behaviors, see StimulusBatch and Runtime Ingress.
Sources: [src/models/message.rs:38-41], [src/models/mod.rs:44]()
To maintain strict input bounds and backward compatibility, src/models/de.rs wires protocol validation directly into serde deserialization routines using TryFrom shadow types src/models/mod.rs:27. Additionally, src/models/compat.rs preserves legacy type aliases and serialized identifiers src/models/mod.rs:47-48.
For validation hooks and compatibility layers, see Deserialization Hooks and Model Compat Aliases.
Sources: [src/models/mod.rs:27-48]()
- 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