Allow for multiple PDs to exist on a single connection

[bytedreamer]

Each device needs to have unique address and security context

[jmic69]

Hello,

I'm looking to develop a test bench to simulate a large number of access on an access control system.
To do this, I'd need this feature to allow multiple PDs to be connected to the same COM port. Do you have any plans to move forward on this? How can we collaborate?

[bytedreamer]

I'm traveling this week. When I return, i defently would want to finish up the PD capabilities for OSDP.Net. Let me know your availability to assist with developing and/or testing. Thanks

[jmic69]

I'll also be traveling for the next two weeks, but I'm up for testing and debugging. I have physical access control equipment and the hardware to sniff and decode frames. I also have a project to parse a csv file to generate a certain number of visits per minute. Since I'm not a very good developer, I don't know how to submit the code to you without introducing bad things into yours, but I'm motivated by this project (I'm not familiar with collaborating on GitHub).

[bytedreamer]

@claude triage this

[github-actions]

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

---

Triaging Issue #157: Multiple PDs on Single Connection

• Read CLAUDE.md and understand repository structure
• Analyze current Device/PD implementation
• Examine connection architecture
• Understand address and security context handling
• Assess feasibility and complexity
• Provide triage recommendations

---

Summary

This feature request is feasible and architecturally sound. It aligns with the OSDP specification where multiple PDs can share a single RS-485 bus, each with a unique address (0x00-0x7E).

Current Architecture Analysis

PD (Device) Side - Current Limitations

Issue Location: /src/OSDP.Net/Device.cs:96-142

The current Device class has a 1:1 relationship between device and connection:

• Each Device instance accepts an IOsdpConnectionListener in StartListening()
• The ClientListenLoop method creates one PdMessageSecureChannel per incoming connection
• The PdMessageSecureChannel is initialized with a single address (line 104) and single security context (lines 101-112)
• When a command arrives, it checks if the address matches (line 119 in PdMessageSecureChannel.cs)

Current flow:

IOsdpConnectionListener → Device → PdMessageSecureChannel (single address + security context)

ACU (Control Panel) Side - Already Supports Multiple Devices

Implementation: /src/OSDP.Net/Bus.cs:122-144

The ACU side already handles multiple devices on a single bus:

• The Bus class maintains a collection of DeviceProxy objects (_configuredDevices)
• Each DeviceProxy has its own address and security context
• The AddDevice() method allows multiple devices per connection
• The polling loop iterates through all configured devices

ACU flow (working correctly):

IOsdpConnection → Bus → Multiple DeviceProxy (each with unique address + security)

Required Changes

To support multiple PDs on a single connection, the PD side needs to mirror the ACU architecture:

1. Introduce a Device Manager/Bus Equivalent (Medium complexity)

• Create a new class (e.g., DeviceManager or DeviceBus) that manages multiple Device instances
• Similar to how Bus manages multiple DeviceProxy on the ACU side
• Each Device would maintain its own address and security context

2. Modify Connection Listener Handling (Medium complexity)

• The connection listener would need to:
  • Read incoming messages from the physical connection
  • Parse the address field from the OSDP message header (byte 1, bits 0-6)
  • Route the message to the appropriate Device instance based on address
• Messages for unregistered addresses should be ignored (per OSDP spec)

3. Update PdMessageSecureChannel (Low complexity)

• The channel currently handles address checking (line 119)
• This logic could remain, but would be invoked per-device
• Each device's channel would only process messages for its configured address

4. Security Context Isolation (Already handled correctly)

• Each Device already has its own DeviceConfiguration with independent SecurityKey
• The PdMessageSecureChannel creates isolated SecurityContext instances
• No changes needed - security is already properly isolated per device

Recommended Architecture

SerialPortConnectionListener (single COM port)
         ↓
   DeviceManager (new class)
         ↓
   Message Router (address parsing)
         ↓
   ┌────────┬────────┬────────┐
Device(0x00) Device(0x01) Device(0x02) ...
   Each with unique address + security context

Implementation Complexity: Medium

Estimated effort: 2-3 days for a developer familiar with the codebase

Why Medium:

• ✅ Security contexts are already isolated (no changes needed)
• ✅ OSDP messages already contain address information in the header
• ✅ The ACU side provides a working reference implementation
• ⚠️ Requires new DeviceManager class
• ⚠️ Requires message routing logic
• ⚠️ Needs updates to Device.StartListening() API or new parallel API

Use Cases Enabled

1. Test bench simulation (mentioned by @jmic69):

   • Multiple virtual PDs on one serial/TCP connection
   • Each PD can simulate different device types (readers, locks, etc.)

2. RS-485 bus emulation:

   • Matches real-world deployments where multiple PDs share one physical bus
   • Useful for integration testing with real ACUs

3. Cost reduction:

   • One physical connection (COM port, TCP socket) serves multiple virtual devices
   • Reduces hardware requirements for testing

Potential Challenges

1. Backward compatibility: Need to maintain the existing Device.StartListening() API

   • Solution: Add new DeviceManager.StartListening(IOsdpConnectionListener, IEnumerable<Device>)

2. Connection ownership: Currently Device owns the connection lifecycle

   • Solution: DeviceManager owns the connection, devices become "logical"

3. Testing: Need comprehensive tests for:

   • Address routing
   • Security context isolation
   • Concurrent access from multiple devices

Recommendations

Priority: Medium-High (valuable feature, reasonable effort)

Approach:

1. Start with a new DeviceManager class that doesn't break existing Device API
2. Implement message routing based on address field
3. Add comprehensive unit tests and integration tests
4. Update PDConsole to demonstrate multiple PDs on one connection
5. Document the new capability in /docs/api-usage-guide.md

Testing Requirements:

• Unit tests for address routing
• Integration tests with multiple devices
• Security isolation tests (ensure one device can't access another's secure channel)
• Real hardware testing on RS-485 (if available)

Next Steps

If @bytedreamer and @jmic69 want to proceed:

1. Confirm the proposed architecture
2. Decide on API design (DeviceManager vs extending Device)
3. Create subtasks for:
   • Implement DeviceManager class
   • Add message routing logic
   • Update connection listener integration
   • Add unit tests
   • Add integration tests
   • Update documentation
   • Add PDConsole demo

---

Triage complete. This is a well-scoped feature request with a clear implementation path. The architecture changes are straightforward since the ACU side already demonstrates the pattern. Happy to assist with implementation once the approach is confirmed.

---