Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider Splitting the Pooling logic out into a separate layer #121

Open
1 task
neonphog opened this issue Jan 22, 2025 · 0 comments
Open
1 task

Consider Splitting the Pooling logic out into a separate layer #121

neonphog opened this issue Jan 22, 2025 · 0 comments

Comments

@neonphog
Copy link
Collaborator

neonphog commented Jan 22, 2025

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.

  1. 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, ...);
    }
  2. 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.
  3. 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant