Explain scatter/gather I/O with channels (read into / write from an array of buffers). What problem does it solve?

## The problem: data has structure Network and file formats are rarely one flat blob. A typical message is **header + body**, e.g. a fixed 20-byte header (length, type, flags) followed by a variable-length payload. With a single buffer you'd read everything into one `ByteBuffer` and then manually slice it into header and body — fiddly and copy-prone. Conversely, to *send* a message you'd have to concatenate your header buffer and payload buffer into one buffer before writing. Scatter/gather removes both chores. ## The two operations Channels that support this implement: - **ScatteringByteChannel**: `long read(ByteBuffer[] dsts)` — a **scattering read**. It fills the buffers **in array order**: it pours bytes into `dsts[0]` until that buffer is full (no remaining), then continues into `dsts[1]`, and so on. "Scatter" = one incoming stream is *scattered* across multiple destination buffers. - **GatheringByteChannel**: `long write(ByteBuffer[] srcs)` — a **gathering write**. It writes the bytes of `srcs[0]` (from position to limit), then `srcs[1]`, etc., as **one** logical write to the channel. "Gather" = multiple source buffers are *gathered* into one outgoing stream. Both return the total number of bytes transferred across all buffers, and there are overloads taking an `offset`/`length` to use a sub-range of the array. ## Why it maps cleanly to messages Scattering read example — read a fixed header and the rest of the body in one call: ``` ByteBuffer header = ByteBuffer.allocate(20); ByteBuffer body = ByteBuffer.allocate(1024); ByteBuffer[] bufs = { header, body }; channel.read(bufs); // fills header fully, then body header.flip(); body.flip(); ``` The header lands neatly in `header`, overflow goes to `body` — no manual offset math. Gathering write example — emit a constant header plus a payload without concatenating: ``` ByteBuffer[] bufs = { headerBuf, payloadBuf }; channel.write(bufs); // sends header then payload as one write ``` ## The benefits in concrete terms 1. **Fewer system calls**: one `read`/`write` instead of one per segment. The OS exposes this as **vectored I/O** — `readv(2)` and `writev(2)` — which take an array ("iovec") of buffer descriptors. Java's scatter/gather is a thin mapping over these. 2. **No intermediate concatenation/copy**: you don't allocate a big combined buffer just to split or join. 3. **Buffer reuse**: a constant header buffer can be `rewind()`-reused across many writes. 4. **Atomicity of layout**: gathering write submits the whole vector to the kernel together, so the segments are contiguous on the wire (subject to the usual partial-write rules). ## Caveats - **Fill order matters and is sequential**: a scattering read only spills into the next buffer once the current one is *full*. If `dsts[0]` has 20 bytes remaining and you read 25, the first 20 go to `dsts[0]` and 5 to `dsts[1]`. This is exactly why fixed-size header buffers work, but it means a partially-full earlier buffer captures all subsequent bytes up to its limit first. - **Partial transfers still apply**: the total returned can be less than the sum of all `remaining()`s (non-blocking sockets, full send buffers). You may need to retry, tracking which buffers still have remaining. - **flip each buffer** before reading the data out, as always. ## Mental model Scatter = a sorting machine dropping an incoming stream into labeled bins in order; gather = stapling several pages together and mailing them as one envelope.