|
RTE RBC 2oo2 Reference Application 0.1.0 build 0006685
SIL 4 2oo2 Dual-Site Fault-Tolerant ERTMS Radio Block Centre Reference Architecture
|
Checkpoint rte_channel OSAdapter adapter over the A<->B peer link. More...
#include "ab_gp_channel_checkpoint.h"#include "rte/oal/log/rte_log.h"#include "rte/oal/timer/rte_timer.h"#include "../../common/common_config.h"#include "ab_gp_channel_types.h"#include "ab_gp_channel_util.h"#include "ab_gp_channel_negotiate.h"#include "ab_gp_sibling_state.h"Go to the source code of this file.
Functions | |
| static void | ab_gp_channel_checkpoint_note_peer_frame (ab_gp_channel_context_t *ctx) |
| Records that a CHECKPOINT_REQUEST/REPLY was just seen from the peer, for the lookback check in ab_gp_channel_checkpoint_backend_recv(). | |
| static bool | ab_gp_channel_checkpoint_peer_recent (const ab_gp_channel_context_t *ctx) |
| True if the peer exchanged a checkpoint frame with us within the last RTE_EXAMPLE_AB_CHECKPOINT_LOOKBACK_CYCLES cycles. | |
| rte_status_t | ab_gp_channel_checkpoint_backend_send (void *channel, const void *data, size_t data_size) |
| rte_channel_send_fn for the checkpoint transport: wraps the given rte_vital_message_t in a PEER_MSG_KIND_CHECKPOINT_REQUEST frame and sends it on the peer link. The matching reply is NOT waited for here - ab_gp_channel_io.c's peer rx task auto-responds to the peer's own REQUEST with a REPLY on its side, and ab_gp_channel_checkpoint_backend_recv() below is what waits for OUR REQUEST's REPLY to come back. | |
| static rte_status_t | poll_for_checkpoint_frame (ab_gp_channel_context_t *ctx, void *data, size_t data_size, uint32_t timeout_ms) |
| Step 3: last-ditch live poll for whatever remains of this round's budget. | |
| rte_status_t | ab_gp_channel_checkpoint_backend_recv (void *channel, void *data, size_t data_size, uint32_t timeout_ms) |
| rte_channel_recv_fn for the checkpoint transport: waits (bounded by timeout_ms) for a PEER_MSG_KIND_CHECKPOINT_REPLY to arrive in ctx->checkpoint_reply_slot - written by ab_gp_channel_io.c's peer rx task, the only thread that ever calls rte_netlink_receive() on the peer link. | |
Checkpoint rte_channel OSAdapter adapter over the A<->B peer link.
The built-in AppManager checkpoint (ADR-019/ADR-034) is a synchronous A->B->A rendezvous run as the LAST per-cycle stage. The peer can only answer it from its OWN next pre_execute(), so a fresh round trip needs >= one full RTE_EXAMPLE_AB_CYCLE_PERIOD_MS - longer than RTE_EXAMPLE_AB_CHECKPOINT_MAX_DELAY_MS's steady-state budget. It only ever completed in-window when host scheduling jitter was low enough to keep A's and B's cycle phases aligned; on a loaded CI runner / VM the phase drifts and the rendezvous times out -> SAFE-state -> reboot loop. Widening the budget was tried and reverted repeatedly (see RTE_EXAMPLE_AB_CYCLE_PERIOD_MS's revert history).
backend_recv() therefore confirms this cycle when EITHER a real matching peer frame is on hand (retained by the per-cycle pump, or live-polled), OR the peer exchanged any checkpoint frame with us within the last RTE_EXAMPLE_AB_CHECKPOINT_LOOKBACK_CYCLES cycles ("lookback" - a local cycle-counter check, immune to sub-cycle phase). A genuinely silent peer still fails the rendezvous after N+1 checkpoint-quiet cycles, preserving REQ-CHECKPOINT-003's bounded reaction, just measured in cycles. Same-program-path divergence (vs. mere liveness) is caught every cycle by the cross-comparator (ab_gp_channel_crosscompare.c), not here. See docs/TIMING_AND_DATA_LOSS_ANALYSIS.md finding 10.
Definition in file ab_gp_channel_checkpoint.c.
|
static |
Records that a CHECKPOINT_REQUEST/REPLY was just seen from the peer, for the lookback check in ab_gp_channel_checkpoint_backend_recv().
Local functions
Definition at line 42 of file ab_gp_channel_checkpoint.c.
|
static |
True if the peer exchanged a checkpoint frame with us within the last RTE_EXAMPLE_AB_CHECKPOINT_LOOKBACK_CYCLES cycles.
Definition at line 49 of file ab_gp_channel_checkpoint.c.
| rte_status_t ab_gp_channel_checkpoint_backend_send | ( | void * | channel, |
| const void * | data, | ||
| size_t | data_size ) |
rte_channel_send_fn for the checkpoint transport: wraps the given rte_vital_message_t in a PEER_MSG_KIND_CHECKPOINT_REQUEST frame and sends it on the peer link. The matching reply is NOT waited for here - ab_gp_channel_io.c's peer rx task auto-responds to the peer's own REQUEST with a REPLY on its side, and ab_gp_channel_checkpoint_backend_recv() below is what waits for OUR REQUEST's REPLY to come back.
Global functions
| channel | This ab_gp_channel_context_t, as void* (rte_channel's own opaque-handle convention). |
| data | The rte_vital_message_t to send. |
| data_size | Must be exactly sizeof(rte_vital_message_t). |
Definition at line 64 of file ab_gp_channel_checkpoint.c.
|
static |
Step 3: last-ditch live poll for whatever remains of this round's budget.
Polls ctx->com.peer_channel in <= 20ms slices until a matching CHECKPOINT_REQUEST/REPLY frame arrives, the deadline passes (RTE_STATUS_TIMEOUT), or a hard read error occurs. A SITE_STATE frame seen along the way is stored into ctx->peer_site_state and handed to rte_site_role by the sibling source, same as the per-cycle peer pump (pre_execute's on_peer_frame_received()).
Definition at line 98 of file ab_gp_channel_checkpoint.c.
| rte_status_t ab_gp_channel_checkpoint_backend_recv | ( | void * | channel, |
| void * | data, | ||
| size_t | data_size, | ||
| uint32_t | timeout_ms ) |
rte_channel_recv_fn for the checkpoint transport: waits (bounded by timeout_ms) for a PEER_MSG_KIND_CHECKPOINT_REPLY to arrive in ctx->checkpoint_reply_slot - written by ab_gp_channel_io.c's peer rx task, the only thread that ever calls rte_netlink_receive() on the peer link.
| channel | This ab_gp_channel_context_t, as void*. |
| data | Destination for the received rte_vital_message_t. |
| data_size | Must be exactly sizeof(rte_vital_message_t). |
| timeout_ms | Maximum time to wait for a NEW reply. |
Definition at line 173 of file ab_gp_channel_checkpoint.c.