ros2_medkit_beacon_common
This section contains design documentation for the ros2_medkit_beacon_common library.
Overview
The ros2_medkit_beacon_common package is a shared C++ library used by the
beacon discovery plugins (ros2_medkit_topic_beacon and ros2_medkit_param_beacon).
It provides the data model, hint storage, entity mapping, validation, and response
building that both beacon transports rely on. It is not a plugin itself - it is
linked as a static library by the two beacon plugin packages.
Architecture
The following diagram shows the beacon common components and their relationships.
Beacon Common Library Architecture
Main Components
BeaconHint - Core data structure representing a discovery hint from a ROS 2 node
entity_idis the only required field (identifies the app)Identity fields:
stable_id,display_namefor human-readable labelingTopology fields:
function_ids,depends_on,component_idfor entity relationshipsTransport fields:
transport_type,negotiated_formatfor DDS introspectionProcess fields:
process_id,process_name,hostnamefor runtime contextmetadatamap for arbitrary key-value pairsreceived_attimestamp in steady_clock domain for TTL computation
BeaconHintStore - Thread-safe TTL-based storage for beacon hints
update()inserts or refreshes a hint; returns false if capacity is full for new entity IDsevict_and_snapshot()atomically removes expired hints and returns a consistent snapshotThree-state lifecycle: ACTIVE (within TTL), STALE (past TTL but before expiry), EXPIRED (evicted)
Configurable: TTL (default 10s), expiry (default 300s), max capacity (default 10,000 hints)
Protected by
std::shared_mutexfor concurrent reads duringget()
BeaconEntityMapper - Maps stored hints to gateway IntrospectionResult
Takes a snapshot from
BeaconHintStoreand the currentIntrospectionInputBuilds per-entity metadata JSON from hint fields
Applies function membership: if a hint declares
function_ids, the mapper updates the corresponding Function entities’ host listsOptionally allows new entity creation (
allow_new_entitiesconfig flag)
BeaconValidator - Input sanitization for incoming beacon hints
Validates
entity_idformat (required, max length, allowed characters)Truncates oversized string fields rather than rejecting the entire hint
Enforces limits on collection sizes (function_ids, depends_on, metadata entries)
Returns
valid=falseonly whenentity_iditself is invalid
BeaconResponseBuilder - Builds JSON responses for beacon metadata HTTP endpoints
Constructs the response payload served by
x-medkit-beaconvendor extension endpointsIncludes hint data plus status (active/stale) and last-seen timestamp
Design Decisions
Three-State Hint Lifecycle
Hints transition through ACTIVE, STALE, and EXPIRED states rather than using a simple present/absent model. The STALE state allows the gateway to report that a node was recently seen but is no longer actively sending beacons - useful for distinguishing temporary network hiccups from actual node departures.
Capacity Limits
The store enforces a hard cap on the number of tracked hints (default 10,000) to prevent memory exhaustion from misbehaving nodes or DDoS scenarios. When capacity is reached, new entity IDs are rejected while existing hints can still be refreshed.
Validation Strategy
The validator is lenient by design: only an invalid entity_id causes rejection.
Other fields are sanitized (truncated, pruned) so that partially malformed beacons
still contribute useful discovery information rather than being silently dropped.