Bidirectional agent: bounded request and response queues

Current snapshot

Follow requests and responses independently

This offline experiment moves named requests through two bounded FIFO queues. The client produces q1 onward; the server removes one request and produces one matching acknowledgement, such as ack:q1. A response is not received merely because the server produced it. The client must read it from the response queue. Both queues have the selected capacity, measured in messages. This is an application scheduling model, not a connection to an ADK agent, gRPC server or language model. Logical ticks explain ordering; the sixty-second presentation is inspection time rather than measured network latency.

Inspect the exact scheduling rule

Each tick first lets the client read one queued response if reading is enabled. Next the server handles at most one request, but only when space exists for its response. Finally the client sends pending requests into available request slots. These phases mean that a request sent on tick one can be processed on tick two and its response read on tick three. The page shows pending, queued, processed, response and received IDs separately. Processed is cumulative history, so do not add it to the current response queue when checking conservation. Pending plus queued requests plus processed plus rejected requests equals the original input count.

Compare backpressure with application rejection

Producer policy either respects queue credit or submits the whole input without waiting. Input size selects three or ten requests. Queue capacity selects one or four slots in each direction. With ten inputs, capacity four, credit and active reading, eight ticks leave no requests pending, three in the request queue, one response queued and six responses received. No requests are rejected. Switching to unchecked submissions rejects q5 through q10 on the first tick; the four accepted requests eventually receive acknowledgements. Rejection here is an explicit application admission rule, not a claim that TCP silently drops delivered messages or that gRPC disables transport flow control.

Reproduce the unread-response stall

Client response reading selects Drain one per tick or Never read responses. Choose ten inputs, capacity one, credit and Never read. At tick two the server produces ack:q1 and the client queues q2. At tick three the response queue is still full, so the server cannot process q2 and the producer cannot send q3. Eight requests remain unsent. The transcript reports blocked by unread responses, rather than successful completion. With capacity four, more work fits before the same stall. Buffers postpone this dependency; they do not remove the need to read. A finite run with no queued request is not called deadlocked merely because unread responses remain.

Use every inspection control

Play reveals eight ticks over sixty seconds and Pause freezes the inspected state. Next event moves to the next tick; Restart rewinds without changing choices. Time seeks and pauses. Speed offers quarter, half, normal and double pace, without changing queue outcomes. Input changes reset playback. Hidden tabs pause automatically. Export events JSON includes the full trace and the inspected prefix. Capture baseline stores choices and the visible result; Replace baseline updates it and Clear baseline removes it. Notebook observations persist in this browser, Export notes downloads them, and Expand experiment toggles full screen. Keyboard users can focus and scroll the event history.

Understand the modeled boundary

The fixture has no bytes, transport acknowledgements, packet loss, reconnect, timeout, cancellation, concurrent threads or authentication. Its ack messages are application responses, not TCP ACK packets or HTTP/2 window updates. One request per tick is a deliberately chosen service rule, not benchmark evidence. The eight-tick horizon can end with valid work still pending; in progress is not data loss. Real bidirectional APIs permit independent reads and writes, and manual flow control can stall if neither side reads. The related articles provide streaming context. Inspect individual IDs and conservation in both directions before interpreting the final status.