Update CmdDispatcher routing algorithm

[kubiak-jpl]

Issue

Currently CmdDispatcher uses an array to map command opcodes to Component ports. When CmdDispatcher receives a command to walks this array looking for a corresponding entry. If the opcode is found it is then forward the the appropriate component and handled there. This approach has a few disadvantages

1. This approach does not scale well to multi-deployment scenarios. Sub-deployments need to do one of the following to handle commands

• Route CmdReg port calls across a hub. This may take a non-trivial amount of time during setup
• Register commands via a proxy component on the primary deployment. Ie. CmdReg port calls are generated on the primary deployment, but CmdDisp and CmdResp ports are routed over the hub. This approach is complex and fpp does not currently handle it gracefully
• A higher level router component needs to route commands between specific deployments

2. The map structure is large and grows linearly with the number of opcodes. This structure may take up a significant amount of RAM on microcontroller deployments

• Many of these entries are nearly identical, all pointing to the same port

3. Opcode lookups current walk the list and are O(n) with the number of opcodes in the system. I have not profiled opcode lookups or noticed this causing performance issues in my experience, but it is an inefficiency

• This could be improved with the current approach as well. Eg. Performing a binary search on the opcode with a sorted opcode list

Suggested Fix

Instead of mapping individual opcodes to ports, act more like a router. CmdDisplatcher could store IdBases and OpCode ranges on a per-component bases. This would have a number of benefits

• Significantly reduce the size of opcode map. The opcode map would now grow O(n) with the number of components in the system. This addresses issue 2 above
  • Further, this opcode table could be generate a compile time from the fpp model and would not require any RAM at runtime. CmdReg ports could go away
    • This might be possible with the current approach as well
• Primary deployments could use the new CmdDispatcher to route commands to a CmdDispatcher on a sub-deployment. This addresses issue 1 above
• Since the size of the opcode table is significantly smaller, opcode looks should be faster as well

Additionally, I think many ideas from IP network routing and topologies could be applied to this new approach as well. Although these may be overkill for routing opcodes to components.

Diagrams

Current Approach

Proposed Approach

Proposed Approach - Multi-Deployment system

Potential Issues

• This approach is more complex overall
• Overriding the default routing should still be possible, but again, is more complex
• CmdDispatcher no longer has a list of all valid opcodes in the system. It would now be up to components to reject invalid opcodes