oxidecomputer / oxidecomputer/maghemite
bgp: consider using local variables to encode FSM timers
Open
Nobody has claimed this yet.
bgp
Idea
mgd
rust
- Dominant language
- Rust
- Stars
- 94
- Forks
- 6
- Avg merge
- 1d 8h
- Merged PRs (30d)
- 12
Description
While spending a lot of time on the FSM lately, I had some thoughts on how we store and manage FSM timers:
HoldTimer/KeepaliveTimerare specific to a connection, so they could stay in theConnectionClock.IdleHoldTimeris specific toIdle, so that could be state local toFsmState::Idle.DelayOpenTimeris specific toActive/Connectand doesn't need to persist outside that state, so it could also be local state.ConnectRetryTimerreally only starts/stops inActive/Connectso it could also be state local to that FsmState (technically it's started inIdleimmediately before moving into active/connect, but we could just start it upon entry of the next state)
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing the FSM states and the lifecycle of HoldTimer, KeepaliveTimer, IdleHoldTimer, DelayOpenTimer, and ConnectRetryTimer. Compare each timer's current scope with the states named in the issue; done means agreeing on and implementing a clear state-local or connection-local ownership model.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- networking
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100