Expand description
Explicit peers: using _to and _from variants.
So far, we’ve used methods like send_request and on_receive_request
without specifying who we’re sending to or receiving from. That’s because
each role type has a default peer.
§Default Peers
For simple role types, there’s only one peer to talk to:
So when you write:
// As a client
cx.send_request(InitializeRequest::new(ProtocolVersion::V1));The request automatically goes to the agent, because that’s the only peer a client can talk to.
§Explicit Peer Methods
Every method has an explicit variant that takes a peer argument:
| Default method | Explicit variant |
|---|---|
send_request | send_request_to(peer, request) |
send_notification | send_notification_to(peer, request) |
on_receive_request | on_receive_request_from(peer, callback) |
on_receive_notification | on_receive_notification_from(peer, callback) |
For simple role types, the explicit form is equivalent:
// These are equivalent for Client:
cx.send_request(req.clone());
cx.send_request_to(Agent, req);§Why Explicit Peers Matter
Explicit peers become essential when working with proxies. A proxy sits between a client and an agent, so it has two peers:
When writing proxy code, you need to specify which direction:
Proxy.builder()
// Receive a request from the client
.on_receive_request_from(Client, async |req: MyRequest, responder, cx| {
// Forward it to the agent
cx.send_request_to(Agent, req)
.forward_response_to(responder)
}, agent_client_protocol::on_receive_request!())
.connect_to(transport)
.await?;See Proxies and Conductors for more on building proxies.
§Available Peer Types
| Peer Type | Represents |
|---|---|
Client | The client direction |
Agent | The agent direction |
Conductor | The conductor (for proxies) |
§Next Steps
- Ordering - Understand dispatch loop semantics
- Proxies and Conductors - Build proxies that use explicit peers