You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Aside from the mechanics of connecting webrtc with signaling, the main function of tx5 is connection pooling. This task is complicated greatly by the connection cryptography state tracked by the sbd crypto client, even after the cooldown fix.
A suggestion for a more ideal architecture.
Keep the cryptographic logic in the sbd client, but move the tracking responsibility out to the implementer. I.e. send and receive would require references to Encryptors and Decryptors that would be managed as a connection in a layer above. Something like:
Make tx5 "Connections" pool agnostic, their logic only focused on talking to a single remote peer, and deciding if they are able to upgrade to webrtc. Something at a higher layer will need to take the EncSbdMsg instances and route them to the correct connection for processing.
Finally add the pool layer responsible for the complexity of routing EncSbdMsg instances, queueing messages while waiting for connections to be opened and ensuring parallel async processes don't open multiple connections to the same peer. I suspect this logic will be more maintainable if it is not mixed in with all the webrtc establishment logic.
add explicit api connection activity hints so kitsune can mark connection relevance for LRU connection closing
start with only libdatachannel to see if we don't need golang anymore
Current Tx5 LOC
$ for c in tx5-core tx5-connection tx5-go-pion-sys tx5-go-pion tx5-signal tx5; do
> echo $c $(wc -l $(find $c -name "*.rs") | grep total);
> done
tx5-core 753 total
tx5-connection 2970 total
tx5-go-pion-sys 1126 total
tx5-go-pion 1843 total
tx5-signal 461 total
tx5 3444 total
Could all be potentially replaced by a single tx5 crate if we don't have to keep the golang implementation.
The text was updated successfully, but these errors were encountered:
Aside from the mechanics of connecting webrtc with signaling, the main function of tx5 is connection pooling. This task is complicated greatly by the connection cryptography state tracked by the sbd crypto client, even after the cooldown fix.
A suggestion for a more ideal architecture.
EncSbdMsg
instances and route them to the correct connection for processing.Other Optional Things
Current Tx5 LOC
Could all be potentially replaced by a single
tx5
crate if we don't have to keep the golang implementation.The text was updated successfully, but these errors were encountered: