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:
impl EncSbdMsg {
pub fn decrypt(self, dec: &mut Decryptor) -> ...;
}
impl SbdClientCrypto {
pub async fn recv(&self) -> EncSbdMsg;
pub async fn send(&self, enc: &mut Encryptor, ...);
}
- 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.
Other Optional Things
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.
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.
EncSbdMsginstances and route them to the correct connection for processing.Other Optional Things
Current Tx5 LOC
Could all be potentially replaced by a single
tx5crate if we don't have to keep the golang implementation.