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

Expand UDP Single Port mode (UDPMux) to all Candidate types #400

Open
braginini opened this issue Dec 3, 2021 · 1 comment
Open

Expand UDP Single Port mode (UDPMux) to all Candidate types #400

braginini opened this issue Dec 3, 2021 · 1 comment
Labels
enhancement New feature or request mux UDP and TCP Mux related issues

Comments

@braginini
Copy link
Contributor

braginini commented Dec 3, 2021

To start off :)
A big thank you to the Pion contributors and especially to @Sean-Der for supporting us on this topic.

Summary

Expand Candidate gathering mechanism allowing UDPMux for all the candidate types.

Motivation

We use Pion ICE implementation in Wiretrustee to negotiate direct connections between peers.
The connections are then used to establish Wireguard tunnels.

  • For each of the Wiretrustee peers, we create a new ice.Agent.
  • There can be hundreds or even thousands of peer connections on a single machine.

Using the ICE package with a large number of agents may cause a "Too Many Open files" issue due to the number of open ports for different types of candidates. This may cause issues on systems with default limits configuration. Also, this is kind of wasteful in our case.
We also understand that our use case is not a traditional WebRTC case, probably most of the library users won't have such an issue.

We have discovered that PIon supports a single UDP port. This is achieved by using UDPMux.
However, it only works for host candidates, srflx and relay candidates are working traditionally.

We would like to propose the extension of the candidate gathering mechanism to support all types of candidates when using UDPMux.
We also think it won't harm the existing functionality but instead might be very helpful for the use cases like ours.

Describe alternatives you've considered

We considered terminating the open port from unselected candidates as well, which seems to be a good option to minimize the problem when not using single-port mode.
However, we will still end up having N sockets for N peers connected which is also not the best option for our use case.

Any help on this is highly appreciated!

Additional context

UPDMux usage when gathering local candidates

Default Srflx Candidates gathering with creating a new listener

Relates to netbirdio/netbird#163

@braginini
Copy link
Contributor Author

I also guess it relates to this one #76

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request mux UDP and TCP Mux related issues
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants