Reduce number of packets sent if a device is not responding

[bytedreamer]

• 3 tries of same command at normal poll rate
• continue sending polling commands at every second for 8 second
• After 8 seconds of no response, the reader is marked offline. A poll is sent out every 5 seconds.

[bytedreamer]

@claude triage this

[github-actions]

Claude finished @bytedreamer's task in 2m 11s —— View job

---

Triaging Issue #161

Task: Analyze requirements for reducing packet sending when device is not responding

Todo List

• Read repository guidelines (CLAUDE.md)
• Understand current polling mechanism
• Analyze command retry logic
• Identify device offline/online tracking
• Review poll interval configuration
• Provide triage assessment and implementation breakdown

---

Current Implementation Analysis

Existing Retry/Timeout Behavior

Current retry logic (src/OSDP.Net/DeviceProxy.cs:14):

• Maximum 2 retries per command (RetryAmount = 2)
• Retries occur at the normal poll rate (default 200ms between attempts)
• After retries are exhausted, the system continues polling

Current offline detection (src/OSDP.Net/DeviceProxy.cs:63):

• Device marked offline after 8 seconds of no valid reply
• When offline in polling mode, applies 1 second delay between polls (Bus.cs:285)
• No graduated retry strategy exists

Current poll intervals:

• Default: 200ms between polls (Bus.cs:32)
• On connection failure: 5 second retry (Bus.cs:225)
• On device offline: 1 second delay (Bus.cs:285)

Gap Analysis

The current implementation lacks the three-tier progressive backoff strategy requested:

Tier	Requested Behavior	Current Behavior	Gap
Tier 1	3 tries at normal poll rate	✅ 2 retries at normal rate	❌ Only 2 retries, not 3
Tier 2	Continue at 1-second intervals for 8 seconds	❌ Immediate backoff to 1-second	⚠️ Partially implemented but not time-bound
Tier 3	After 8 seconds, poll every 5 seconds	❌ Only 1-second polling continues	❌ No 5-second offline polling

---

Implementation Requirements

Changes Needed

1. DeviceProxy.cs - Enhanced Retry State Machine

Current state: Simple retry counter (0-2)

Required state: Multi-tier retry tracking

• Tier 1: Normal retries (3 attempts at normal poll rate)
• Tier 2: Degraded mode (1-second polling for 8 seconds)
• Tier 3: Offline mode (5-second polling indefinitely)

Key modifications:

// Add new fields
private enum RetryTier { Normal, Degraded, Offline }
private RetryTier _currentTier = RetryTier.Normal;
private DateTime _degradedModeStartTime;
private int _normalRetryCount = 0;
private const int NormalRetryAmount = 3;
private const int DegradedModeDurationSeconds = 8;

New logic:

• Track when degraded mode starts
• Calculate if 8 seconds have elapsed in degraded mode
• Expose current tier to Bus for poll interval adjustment
• Reset tiers on successful reply

2. Bus.cs - Dynamic Poll Interval

Current: Fixed 1-second delay for offline devices (line 285)

Required: Tier-based delay calculation

• Tier 1 (Normal): Use configured poll interval (default 200ms)
• Tier 2 (Degraded): Force 1-second interval
• Tier 3 (Offline): Force 5-second interval

Key modification (around line 285):

// Replace fixed 1-second delay with tier-based logic
if (!device.IsConnected)
{
    var delayInterval = device.GetRetryInterval(); // Returns 1s or 5s based on tier
    device.RequestDelay = DateTime.UtcNow + delayInterval;
}

3. IsConnected Property - Update Logic

Current (DeviceProxy.cs:63):

public bool IsConnected => _lastValidReply + TimeSpan.FromSeconds(8) >= DateTime.UtcNow && ...

Required: Should consider tier state

• Normal/Degraded tiers: Device attempting connection
• Offline tier: Device marked as offline (affects ConnectionStatusChanged event)

---

Implementation Complexity Assessment

Complexity: Medium 🟡

Effort Estimate: 2-4 hours of focused development + testing

Why Medium?

• ✅ Changes are localized to 2 files (DeviceProxy.cs, Bus.cs)
• ✅ Clear requirements with well-defined behavior
• ⚠️ Requires careful state management (tier transitions)
• ⚠️ Must preserve backward compatibility
• ⚠️ Need comprehensive testing for all tier transitions
• ⚠️ Must handle edge cases (rapid connect/disconnect, tier resets)

Files to Modify

1. src/OSDP.Net/DeviceProxy.cs

   • Add retry tier enum and tracking fields
   • Modify RetryCommand() to handle tier progression
   • Add GetRetryInterval() method for Bus consumption
   • Update ValidReplyHasBeenReceived() to reset tiers
   • Adjust IsConnected property logic

2. src/OSDP.Net/Bus.cs

   • Update offline delay logic (line ~285) to use tier-based intervals
   • Ensure ConnectionStatusChanged event fires correctly for tier changes

Testing Requirements

Unit tests needed (test/OSDP.Net.Tests):

• Tier 1: Normal retry behavior (3 attempts at poll rate)
• Tier 2: Degraded mode activation after Tier 1 exhausted
• Tier 2→3: Transition to offline after 8 seconds in degraded mode
• Tier reset: Successful reply resets to Tier 1
• Edge case: Rapid connect/disconnect during tier transitions
• Verify poll intervals: 200ms → 1s → 5s progression

Integration testing:

• Actual device communication under various failure scenarios
• Verify ConnectionStatusChanged events fire at appropriate tier transitions

---

Architectural Considerations

Benefits of This Approach

✅ Reduces network traffic: Progressive backoff minimizes packet flooding
✅ Responsive recovery: Fast initial retries catch transient failures
✅ Resource efficient: 5-second polling for truly offline devices
✅ Clear state management: Three well-defined tiers

Potential Concerns

⚠️ Backward compatibility: Existing code expects fixed behavior
⚠️ Configuration: Should tier thresholds be configurable?
⚠️ Event timing: ConnectionStatusChanged timing may change
⚠️ Multi-device: Ensure each device tracks tiers independently

Recommendations

1. Make thresholds configurable (optional enhancement)

   • Allow customization of: retry counts, degraded duration, offline interval
   • Default values match requirements (3, 8s, 5s)

2. Add logging for tier transitions

   • Help diagnose connection issues
   • Track how often devices enter offline mode

3. Consider ConnectionStatusChanged semantics

   • Should event fire when entering degraded mode?
   • Or only when entering offline tier?
   • Current behavior: fires when IsConnected changes

4. Thread safety

   • Verify tier state changes are thread-safe
   • DeviceProxy accessed from polling task

---

Summary

This issue requests a three-tier progressive backoff strategy to reduce excessive packet sending to non-responsive devices:

1. Normal Mode: 3 quick retries at normal poll rate (currently 2 retries)
2. Degraded Mode: 1-second polling for 8 seconds (partially exists, needs time-bound logic)
3. Offline Mode: 5-second polling indefinitely (new behavior)

Implementation: Medium complexity, requires state machine in DeviceProxy.cs and dynamic interval handling in Bus.cs. Changes are localized and well-defined, but require careful testing of all tier transitions and edge cases.

Ready to implement: The requirements are clear and the implementation path is well-understood. I can proceed with implementation if requested.

---

| Branch: claude/issue-161-20260204-0022