Explain request-channel in Spring RSocket: how the handler is shaped, how backpressure flows both ways, and when to choose it over request-stream.

**Request-channel** is the richest of RSocket's four interaction models: a single logical stream where **both** peers send a stream of payloads — *N-in, N-out* — with independent backpressure in each direction. It is the natural fit for interactive, long-lived exchanges. **Handler shape on the responder.** With `@MessageMapping`, Spring recognizes request-channel by a **streaming input parameter**: ``` @MessageMapping("telemetry") Flux<Ack> telemetry(Flux<Reading> readings) { return readings .buffer(Duration.ofSeconds(1)) .map(batch -> new Ack(batch.size())); } ``` The `Flux<Reading>` parameter *is* the inbound stream from the client; the returned `Flux<Ack>` is the outbound stream to the client. The two are wired to different halves of the same RSocket stream. Contrast with **request-stream**, whose handler takes a *single* payload and returns a `Flux`. **Client side.** The client supplies a `Flux` as the request data and retrieves a `Flux`: ``` Flux<Ack> acks = requester.route("telemetry") .data(readingFlux) // outbound stream .retrieveFlux(Ack.class); // inbound stream ``` The same terminal method (`retrieveFlux`) serves both request-stream and request-channel; the difference is whether `data(...)` was handed a `Flux`/`Publisher` (channel) or a single value (stream). **Backpressure — both ways.** RSocket implements Reactive Streams demand over the wire using **REQUEST_N** frames. Each direction is an independent flow-controlled pipeline: the *receiver* of a direction issues demand, and the *sender* only emits up to that demand. So if the server consumes client readings slowly, its demand upstream (via REQUEST_N to the client) throttles the client's producer; symmetrically, a slow client consumer throttles the server's `Flux<Ack>`. This end-to-end backpressure avoids unbounded buffering and is a core reason to use RSocket over naive streaming. **Lifecycle & edge cases.** - The inbound `Flux` parameter is a **single-subscription** stream: subscribe to it once (or compose operators onto it). Subscribing twice, or never subscribing while also not returning a derived stream, breaks or stalls the channel. - **Errors** on either leg terminate *that* leg with an onError; Spring surfaces responder errors to the client per RSocket error frames. Design for partial termination (e.g., a failing outbound doesn't automatically drain inbound cleanly unless composed). - **Completion** of the outbound `Flux` sends a completion frame; the inbound completes when the client stops sending. A channel stays open as long as both sides have activity/demand. - Cancellation propagates: cancelling the client's subscription to `acks` cancels the outbound stream via a CANCEL frame. **Request-channel vs request-stream — when to choose.** - **Request-stream**: client makes one request, then only *consumes* a server stream (server push, subscriptions, tailing). Simpler; no inbound Flux. - **Request-channel**: client must keep *sending* while receiving — flow-controlled/large uploads split into chunks with per-chunk acks, interactive bidirectional sessions (chat, collaborative editing), or adaptive streams where server output continuously depends on live client input (e.g., client adjusts a subscription in-flight). If you find yourself opening a second request-stream just to feed input back, a channel is the right model. **Gotchas.** - Treating the inbound `Flux` as replayable/multi-subscriber. - Blocking inside the pipeline, defeating backpressure. - Assuming ordering/coupling between the two directions — they are independent; don't rely on an Ack corresponding positionally to a Reading unless you enforce it. - Overusing channel where request-stream suffices adds complexity for no benefit.