Closed jphickey closed 2 years ago
jphickey
commented
2 years ago Ongoing discussion in this area, consensus at this point is that there does need to be a routing table of some sort between the BPLib CLA instance(s) and the application instance(s), which would also support the relay use case.
I'm working toward developing a prototype that demonstrates this capability.
jphickey
commented
2 years ago The addition of a routing table here significantly changes the internal flows, to the point which it is no longer compatible with v6 (at least not without significantly more work to update the v6 channel flows for compatibility as well).
Current approach is to basically fork the library, keeping the BPv6-capable API unchanged for now, while creating a BPv7 API in parallel with the new features. This will likely necessitate a separate development branch, which will be discussed next week.
Initially, BPLib was designed for end node configurations where the payload data was an application of some sort, running in the same processor. This is best shown/described in the documentation:
Put simply, there is a 1:1 relationship between convergence layer and BP channel (application layer) here - so all bundles received via this CLA must go to the same channel, and all data from that channel must go to the same CLA. Notably this does not afford the opportunity to do any "trunking" or combining of several flows into one CLA. While there may be some methods of achieving something like this on the transmit/outgoing side (right), the problem is more complex on the receive/incoming side (left). This is because the "de-bundling" process does not happen until a bundle is delivered to a channel (bplib_process) but that process is necessary (importantly, to determine the destination entity ID) to know which channel to deliver it to.
Addressing this use-case will require some modifications to the organization of services that BPLib provides, specifically to separate out the "CLA side" (bottom) from the "application side" (top) and the storage services (middle). These services will all still need to exist, but they will need to be instantiated separately.
In the future, there will likely need to be some sort of routing table facility that bundles can pass through before being delivered to an entity. Such a solution will need further discussion. In the short term, simply breaking up the notion of a "channel" into its constituent CLA, App, and storage services will better position the code to adapt to these future needs, while still supporting the simple end-node use case where these services are all created together.