[mclueppers]

Reticulum::loop() runs Transport::jobs() every Type::Reticulum::JOB_INTERVAL (60 s), and announce rebroadcasts, link/receipt timeouts and path-request handling all live there. Applications that bridge interfaces on the same device therefore saw announces forwarded up to a minute late, with no way to change it short of calling Transport::jobs() themselves.

Add Reticulum::jobs_interval() getter/setter (seconds); the default stays JOB_INTERVAL = 60 so existing behaviour is unchanged. Reference RNS runs its equivalent every 0.25 s; 1 s is a good value on an ESP32.

Tested 1s interval on ESP32-S3 bridging announcement packets between LoRa and WiFi without any issues.

Closes #83

[attermann]

Thanks for the PR and for filing #83 first.

Before this goes further I think we need to check the premise. On current master, JOB_INTERVAL (60 s) only gates Reticulum::jobs() in Reticulum::loop(), which handles cache cleaning, data persistence and the time-offset write. Announce retransmission, link and receipt timeouts and resource watchdogs run in Transport::jobs(). That is driven by Transport::loop(), which Reticulum::loop() already calls, and it runs every Transport::_job_interval = 0.25 s, matching reference RNS.

So I don't think this change would make announces cross your ESP32-S3 node any faster. A few questions:

1. Which microReticulum version or commit did you see the 0–60 s forwarding delay on? Does it still reproduce on current master?
2. If it does, can you show which timer is responsible (e.g. a log of when the announce is received versus when it is retransmitted)? The fix may belong in Transport rather than Reticulum.
3. If you do want to tune the Reticulum::jobs() cadence, what's the use case? If it stays, please also add a CHANGELOG entry (§5.7), say which platforms and builds you tested (§5.5), and clarify the name and docs so it isn't confused with the transport job interval.

Happy to continue the discussion in #83.

[mclueppers]

You're right, and thanks for checking the premise. I re-read current master and the July commit this branch was cut from. In both, Reticulum::loop() calls Transport::loop() on every pass, and that runs Transport::jobs() every _job_interval (0.25 s). Announce retransmission and the link, receipt and resource timeouts were never on the 60 s timer. JOB_INTERVAL only paces Reticulum::jobs(), and cache cleaning, persistence and the time-offset write each have their own longer interval inside it, so making it configurable changes nothing useful.

The announce forwarding stall we saw was the one fixed in #86 (queued announces were never sent, so an interface that queued one stopped forwarding). I'm withdrawing this PR and closing #83.