SessionPeering

The live wiring of the sessions on other nodes (trove-parts §TPL-5, parity TPX-16).

In the namespace octomy::trove::fleet. Declared in src/libs/libtrove/trove/fleet/SessionPeering.hpp.

Detailed description

One discovery: the batch remote half

The node already knows its paired nodes and what each one offers: the batch remote half asks each executor for its advertisement (NodeBatchRemote, BatchQueueService::refreshExecutors()). This class reads those advertisements and adds no discovery of its own. A node offers the session resources of §TPL-2 item 1 in the same advertisement: attachTo() gives offer() to the executor agent as standing capacity, and capabilitiesOf() reads it back on the other node.

One courier per peer, both ways

For each paired node, refresh() makes one LLMCourier on the node's blob courier. With it:

• The door host serves the sessions that the peer opens here (DoorRemoteSessions::serve()). The `spec.*` calls of those sessions go back to the peer over the control plane of setOpalCaller().
• When the peer offers a session, the door host and the DriverManager of the Trove engines each get a RemoteNodeDriverFactory of the peer, and each engine gets the peer as a session peer (TroveSupervisor::setSessionPeer()). The engine's PlacementSolver then weighs the peer against this node.

A comms session makes a new blob courier. refresh() then makes a new LLMCourier, and moves the factories and the server to it. A peer that unpairs, or that has no courier, goes: its factories, its server and its place in each engine. A peer that stops offering a session keeps its server and leaves the engines.

What this node offers

offer() is fleet::capacityOf() of this node: the Claude Code resource when the door host has a local driver for a remote session, Claude Code is installed and its subscription is not at a usage limit, and the checkout resource when git is on PATH. A node without a door offers no session, because only a door host runs one (§TPL-2 item 4).