Skip to main content

Module peers

Module peers 

Source
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:

Role TypeDefault Peer
ClientThe agent
AgentThe client

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 methodExplicit variant
send_requestsend_request_to(peer, request)
send_notificationsend_notification_to(peer, request)
on_receive_requeston_receive_request_from(peer, callback)
on_receive_notificationon_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:

  • Client - the client (or previous proxy in the chain)
  • Agent - the agent (or next proxy in the chain)

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 TypeRepresents
ClientThe client direction
AgentThe agent direction
ConductorThe conductor (for proxies)

§Next Steps