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.
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.
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 https://github.com/wiretrustee/wiretrustee/issues/163