Please check the build logs for more information.
See Builds for ideas on how to fix a failed build, or Metadata for how to configure docs.rs builds.
If you believe this is docs.rs' fault, open an issue.
lnmp-transport
Transport bindings for the LNMP protocol, providing standard mappings between LNMP records with Envelope metadata and various transport protocols (HTTP, Kafka, gRPC).
FID Registry: All examples use official Field IDs from
registry/fids.yaml.
Purpose
lnmp-transport bridges LNMP's in-memory data model to real-world transport layers by:
- Standardizing header/metadata names across all transports
- Preserving observability through W3C Trace Context and OpenTelemetry integration
- Maintaining determinism - does not modify
LnmpRecordorSemanticChecksum - Providing helper functions for bi-directional mapping
This crate does NOT:
- Implement HTTP/Kafka/gRPC clients or servers
- Define a new protocol - it binds existing LNMP to transports
- Handle retry logic, circuit breakers, or other behavioral concerns
Standard Header Mappings
HTTP
| Envelope Field | HTTP Header | Example |
|---|---|---|
timestamp |
X-LNMP-Timestamp |
1732373147000 |
source |
X-LNMP-Source |
auth-service |
trace_id |
X-LNMP-Trace-Id |
abc-123-xyz |
| - | traceparent |
00-abc123xyz...-0123456789abcdef-01 |
sequence |
X-LNMP-Sequence |
42 |
labels["key"] |
X-LNMP-Label-key |
prod |
Body: LNMP binary or text format
Content-Type: application/lnmp-binary or application/lnmp-text
Kafka
| Envelope Field | Kafka Header | Format |
|---|---|---|
timestamp |
lnmp.timestamp |
b"1732373147000" |
source |
lnmp.source |
b"auth-service" |
trace_id |
lnmp.trace_id |
b"abc-123-xyz" |
sequence |
lnmp.sequence |
b"42" |
labels["key"] |
lnmp.label.key |
b"prod" |
Value: LNMP binary format
NATS
Recommended Subject Pattern: lnmp.<domain>.<event>
Examples:
lnmp.llm.request- LLM inference requestslnmp.robot.command- Robot control commandslnmp.sensor.telemetry- Sensor data streams
| Envelope Field | NATS Header | Format |
|---|---|---|
timestamp |
lnmp-timestamp |
"1732373147000" |
source |
lnmp-source |
"auth-service" |
trace_id |
lnmp-trace-id |
"abc-123-xyz" |
sequence |
lnmp-sequence |
"42" |
labels["key"] |
lnmp-label-key |
"prod" |
Payload: LNMP binary format
gRPC
| Envelope Field | gRPC Metadata | Example |
|---|---|---|
timestamp |
lnmp-timestamp |
"1732373147000" |
source |
lnmp-source |
"auth-service" |
trace_id |
lnmp-trace-id |
"abc-123-xyz" |
sequence |
lnmp-sequence |
"42" |
labels["key"] |
lnmp-label-key |
"prod" |
Payload Strategy:
- Embed LNMP binary record inside Protobuf message as
bytesfield - Use LNMP metadata only in headers, send application data in Protobuf message
use grpc;
// Convert envelope metadata to gRPC metadata
let metadata = envelope_to_metadata?;
for in &metadata
Quick Start
use ;
use ;
use http;
// Create an envelope
let mut record = new;
record.add_field;
let mut meta = default;
meta.timestamp = Some;
meta.source = Some;
meta.trace_id = Some;
let env = LnmpEnvelope ;
// Convert to HTTP headers
let headers = envelope_to_headers?;
// Convert back
let parsed_meta = headers_to_envelope_metadata?;
assert_eq!;
W3C Trace Context / OpenTelemetry
lnmp-transport automatically generates W3C-compliant traceparent headers for distributed tracing:
use http;
let env = /* ... */;
let headers = envelope_to_headers?;
// traceparent header is automatically included if trace_id is present
// Format: 00-{trace_id}-{span_id}-{flags}
To extract trace context from incoming requests:
let trace_id = traceparent_to_trace_id?;
Note:
lnmp-transportfocuses on trace ID propagation and does not manage the full W3C Trace Context semantics (span parent relationships, sampling decisions, etc.). For complete OpenTelemetry SDK behavior, uselnmp-transportin conjunction with a dedicated tracing library.
Features
http(default): HTTP header mappingskafka: Kafka header mappingsgrpc: gRPC metadata mappingsnats: NATS header mappingsotel: OpenTelemetry integration helpers
Examples
See examples/ directory:
transport_basic_usage.rs- Simple mapping examplehttp_full.rs- Complete HTTP request/response with body encodingotel_integration.rs- OpenTelemetry context propagation
Testing & CI Guidance
To ensure every optional transport binding stays healthy, run the test matrix locally (and wire the same commands into CI):
| Feature flags | Command |
|---|---|
| none | cargo test -p lnmp-transport --no-default-features |
| http (default) | cargo test -p lnmp-transport --features http |
| kafka only | cargo test -p lnmp-transport --no-default-features --features kafka |
| http + kafka | cargo test -p lnmp-transport --features "http kafka" |
| all bindings | cargo test -p lnmp-transport --features "http kafka grpc nats" |
Benchmarks/examples should also be covered in automation at least once per release:
Tip: Keeping these commands in CI ensures unresolved-import regressions are caught immediately when optional modules change.
Alignment with Industry Standards
This crate follows the same patterns as:
- CloudEvents: Context attributes separate from event payload
- Kafka Headers: Record-level metadata best practices
- W3C Trace Context: Standard distributed tracing propagation
- OpenTelemetry: Seamless telemetry integration
License
MIT