Streaming

A daemon-managed broker for bidirectional streams that sit alongside (rather than inside) gRPC calls. Used by the transfer service to send progress events and by the CRI plugin for exec/attach stdio.

Purpose

• Provide a way for two endpoints to negotiate a long-running stream that's outlived by the originating gRPC call.
• Avoid forcing every plugin to embed its own streaming protocol on top of gRPC.

Pieces

Piece	File	Role
Stream manager interface	core/streaming/streaming.go	Manager, Stream
Built-in manager	plugins/streaming/	Registers a StreamingPlugin
Streaming proto	api/services/streaming/v1/	Bidirectional gRPC method Stream
Service registration	plugins/services/streaming/	Wires the gRPC handler

Model

A producer asks the manager to register a stream with a randomly generated id. The id is delivered to the consumer (typically as a field in the originating gRPC response). The consumer then opens a bidirectional gRPC Stream call with that id; the daemon connects the two ends and proxies bytes both directions.

Streams are short-lived (one operation each) but can carry arbitrary protobuf messages. The transfer service uses them to push ProgressEvents while a long pull is happening; CRI uses them for exec stdio.

Why not just gRPC streaming inside the original call?

• The CRI exec path needs to be redirectable to a separate streaming HTTP server (for kubelet → kubectl proxying), so its stdio can't be tied to the original CRI gRPC call.
• Transfer wants to stream progress that may continue across reconnects.
• Some clients want the manager to record the stream so the daemon can clean it up if the consumer disappears.

Entry points for modification

• Replace the manager: implement core/streaming/streaming.go and register a new StreamingPlugin.
• Add a new stream type: nothing to do at the streaming layer; the producer/consumer just send their own typeurl-tagged messages.