Port the call + channels architecture documentation from the alknet mono-repo into docs/architecture/, renumbered as alkcall ADR-001..045. Renumbering map (alknet -> alkcall): Core: 001,002,004,006,007,011,065,070,092,014,050,091 -> 001-012 Call: 005,064,012,023,015,022,024,016,049,017,028,029,030,032,066,069,067,068 -> 013-030 Shared: 003,009,013 -> 031-033 Channels: 071,093,072,073,074,075,076,094,079,080,081,089 -> 034-045 3 superseded/reversed ADRs kept for historical trail: - ADR-013 (irpc foundation, superseded by ADR-014) - ADR-023 (peer-scoped filtering, superseded by ADR-024) - ADR-077 (TTY inside channels, reversed by ADR-035 — not ported, TTY-only) Ported docs (11 spec files + README + open-questions): - call-README.md, call-protocol.md, operation-registry.md, client-and-adapters.md - channels-README.md, channels-overview.md, channels-wire.md, channels-connection.md, channels-adapter.md, channel-operations.md, channel-client.md - README.md (index with doc table, ADR table grouped by category, key principles) - open-questions.md (lean — 30 OQs, renumbered OQ-01..030; includes new OQ-22 for the pub/sub gap) Cross-reference rewriting: - All ADR-NNN references rewritten single-pass (no chaining bug) - Markdown link paths fixed - Title lines aligned with filenames - Non-ported ADR refs (052, 082, 086, etc.) left as-is with README note The open-questions.md includes OQ-22 (new): the call protocol pub/sub gap — subscribe exists but pub does not, needed for channels channel/resources/subscribe fan-out. This is the next ADR to write (alkcall ADR-046).
66 lines
4.2 KiB
Markdown
66 lines
4.2 KiB
Markdown
# ADR-002: ProtocolHandler Trait
|
|
|
|
## Status
|
|
|
|
Accepted
|
|
|
|
## Context
|
|
|
|
The previous architecture had two separate interface traits: `StreamInterface` (for byte-stream protocols like SSH, raw TCP) and `MessageInterface` (for message-based protocols like DNS, HTTP). This split created complexity — each interface type needed its own listener configuration, its own dispatch path, and its own framing assumptions. The `ListenerConfig` enum had three variants. The server accept loop handled three different listener types.
|
|
|
|
In practice, the distinction between "stream" and "message" protocols is artificial at the handler level. SSH starts as a byte stream but internally multiplexes channels and messages. DNS over QUIC is message-based but arrives as a stream of frames. HTTP/2 is both — bidirectional streams with message semantics. Every protocol can be modeled as "receive a byte stream, manage your own wire format."
|
|
|
|
iroh's `ProtocolHandler` trait demonstrates this: it takes a bidirectional QUIC stream and the handler is responsible for its own protocol. One trait, one dispatch point.
|
|
|
|
## Decision
|
|
|
|
A single `ProtocolHandler` trait replaces both `StreamInterface` and `MessageInterface`:
|
|
|
|
> **Note**: The signature below was revised by ADR-005. The `handle()` method
|
|
> now receives a `Connection` (not a `BiStream`) — see ADR-005 for the
|
|
> current authoritative signature. The original signature is retained here
|
|
> for historical context.
|
|
|
|
```rust
|
|
#[async_trait]
|
|
pub trait ProtocolHandler: Send + Sync + 'static {
|
|
/// The ALPN string this handler claims (e.g. b"alknet/ssh")
|
|
fn alpn(&self) -> &'static [u8];
|
|
|
|
/// Handle an incoming connection (revised by ADR-005 to receive
|
|
/// `Connection` instead of `BiStream`)
|
|
async fn handle(&self, connection: Connection, auth: &AuthContext) -> Result<(), HandlerError>;
|
|
}
|
|
```
|
|
|
|
- `alpn()` returns a static byte string — the handler's ALPN identifier
|
|
- `handle()` receives a `Connection` (revised by ADR-005 from the original
|
|
`BiStream`) and an `AuthContext` carrying the authenticated identity, and
|
|
returns `HandlerError` on failure
|
|
- Every handler manages its own wire format — no shared framing, no StreamInterface/MessageInterface split
|
|
- The `ListenerConfig` enum is eliminated — ALPN advertisement configuration replaces it
|
|
|
|
**AuthContext resolution is hybrid** (see ADR-003, OQ-02 resolution): the endpoint resolves what it can before calling `handle()` (e.g., TLS client certificate fingerprint), and the handler resolves what it must inside `handle()` (e.g., AuthToken in the first frame of a call stream). The `AuthContext` passed to `handle()` may contain partial identity information — the handler is responsible for completing authentication if the endpoint didn't have enough information.
|
|
|
|
## Consequences
|
|
|
|
**Positive:**
|
|
- One trait, one dispatch point — eliminates the StreamInterface/MessageInterface split and ListenerConfig enum
|
|
- Each handler owns its wire format — no shared framing assumptions that constrain protocol design
|
|
- Adding a new protocol is implementing one trait with two methods
|
|
- Testable in isolation — give a handler a mock BiStream and AuthContext
|
|
- WASM-compatible in principle — handlers that don't need tokio runtime features compile to WASM
|
|
|
|
**Negative:**
|
|
- Every handler must implement its own framing — no shared "read a length-prefixed message" utility (mitigated: common utilities can live in alknet-core without mandating their use)
|
|
- Handlers that want message semantics must build them (mitigated: alknet-call provides this as a handler, not a mandatory layer)
|
|
- AuthContext resolution is hybrid — the endpoint resolves what it can (TLS-level auth), but handlers that need protocol-level credential extraction must do so inside handle(). This means AuthContext may be partial when handle() is called. Handlers must not assume AuthContext is fully resolved.
|
|
|
|
## References
|
|
|
|
- Pivot proposal: `docs/research/pivot/alpn-service-architecture.md`
|
|
- ADR-001: ALPN-based protocol dispatch
|
|
- ADR-003: Auth as shared core (IdentityProvider)
|
|
- ADR-005: BiStream type definition (revised this ADR's signature from BiStream to Connection)
|
|
- iroh ProtocolHandler pattern: `docs/research/references/iroh/`
|
|
- Replaces StreamInterface, MessageInterface, and ListenerConfig |