mikael-lovqvists-claude-agent
f3a6be0701
Document that immediate re-announcements go directly to the triggering peer (unicast) rather than to the multicast group, and explain the two conditions that trigger a reply: new peer and restarted peer (site_id change). Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
1.4 KiB
1.4 KiB
discovery_cli
A development tool for testing the discovery layer. Announces a node on the local network via UDP multicast and prints peers as they appear and disappear.
Build
From the repository root:
make cli
The binary is placed in build/cli/.
Usage
discovery_cli <name> <tcp_port> [flags]
| Argument | Description |
|---|---|
name |
Node name in namespace:instance form, e.g. v4l2:microscope |
tcp_port |
The TCP port this node listens on for transport connections |
flags |
Comma-separated role list: source, relay, sink, controller (default: source) |
Example — announce a source node and watch for peers:
./discovery_cli camera:0 8000 source
Example output as peers are found and lost:
found: unnamed:0 192.168.1.42:8001 site=0 flags=source
found: display:0 192.168.1.55:8002 site=0 flags=sink
lost: unnamed:0 192.168.1.42:8001
Run two instances on the same machine (different ports) to verify mutual discovery.
Relationship to the Video Routing System
discovery_cli exercises the discovery module, which the video node uses to find peers on the LAN without configuration. The node starts a discovery listener on startup; controllers use discovered peer tables to locate nodes before connecting.
See also: query_cli.md for a combined discovery + protocol query.