Instead of storing an array of RpcStub, we now store an array of the underlying StubHooks.

This will make it easier to add support for new types like streams, which aren't RpcStubs, but they will wrap / be wrapped in StubHooks.

(Flow control is left for a future commit.)

Written using Claude+Opencode: https://share.opencode.cloudflare.dev/share/gJU0pT8p

(I cleaned some stuff up manually.)

As described in protocol.md, the basic idea here is that whenever we want to send a ReadableStream, we first send a message to the other side creating a "pipe". We pump our ReadableStream to the pipe's WritableSteam end, and we deliver the pipe's ReadableStream end to the remote peer. This way, we can begin pushing bytes immediately upon sending a ReadableStream, without waiting for the remote end to call back asking for the bytes (which would be an unnecessary round trip).

Written using Claude+Opencode: https://share.opencode.cloudflare.dev/share/ctbbBnOu

If more than 256kb of writes are in flight, we pause writes until past writes complete so that the number drops back below 256kb.

Future commits will expand the window size.

Written using Claude+Opencode: https://share.opencode.cloudflare.dev/share/D1bqkx2K

This was not the best Claude session. I could probably have done it faster by hand.

We add a new "stream" message to the protocol which skips these. See protocol.md for explanation.

(Since this is only used for streams, which were just introduced in this PR, this is not a breaking change.)

Written using Claude+Opencode: https://share.opencode.cloudflare.dev/share/OfY838e7

With this change, we'll automatically update a stream's window size based on the observed bandwidth-delay product, in order to fully saturate the stream with minimal additional buffer bloat.

The algorithm works by observing when each stream chunk is sent and acknowledged (via return from the RPC), allowing us to calculate:
1. Minimum round trip time.
2. Running average bandwidth over the last RTT.

From that we calculate bandwidth-delay product and adjust the window to match. We actually set the window a bit bigger than the calculated BDP during startup (2x) and steady-state (1.25x) so that we can observe if the actual bandwidth is greater than expected, and thus update the window accordingly.

I worked with Claude+Opencode to design the algorithm and implement, although I significantly refactored almost everything it wrote as the code was pretty meh: https://share.opencode.cloudflare.dev/share/rGV0SKLW

…sposal

blocked-write-lost-wakeup: windowResolver in createWritableStreamFromHook
never settled when all pending writes error. Error handler (streams.ts:359)
calls fc.onError() and sets pendingError but doesn't settle windowResolver.
Write blocked on flow control window hangs forever. Affects await
writer.write(), pipeTo(), and abort() (which waits for pending write per
WritableStream spec).

readable-not-tracked-for-disposal: Evaluator ['readable'] case
(serialize.ts:565) doesn't push hook to this.hooks[]. Compare with
['writable'] case (line 553) which does. Disposed RpcPayload containing a
ReadableStream won't cancel the stream.

args-leak-on-throw (not tested): WritableStreamStubHook.call doesn't dispose
args when getState() or path validation throws. Only triggers on peer
misbehavior (disposed hook or malformed wire messages), not normal user
actions. Skipped.