-
Notifications
You must be signed in to change notification settings - Fork 317
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
TURN client refactor #75
Conversation
Amazing work @enobufs this code was a joy to read, really impressive how quickly you are getting this done. This will close out a lot of TURN issues, I really appreciate you taking this on! |
Refresh for allocation and permissions are done. What's left is ChannelBind/ChannelData! |
PR looks fantastic! Only minor nits. After this release I am going to take a crack at performance stuff next. Especially with us putting debug/print statements in stuff it worries me. Wish it was compile time a bit :/ Maybe doesn't actually matter though. Really excited to use this, this is a huge relief. I was really worried we were going to be in a bad spot with issues before. |
@Sean-Der, @hugoArregui In addition to solving relay-srflx(symmetric NAT) connectivity issue, we can also improve these things with this effort. Simplified CandiateRelayWith the net.PacketConn interface, we may be able to unify the candidate base. CandidateRelay will be a lot simpler. (I believe, turn.Client will live in CandidateBase) DemultiplexingThis relates to pion/ice#76. All candidate should share their the same "base". We will need to implement how to demultiplex the inbound packet from the same conn. I have a rough sketch in this doc I believe the current implementation would allow us to achieve that with the new TURN client with Client#HandleInbound(). Connectivity check improvementI have not filed an issue for this, but I guess you may have already realized. This new client can also improve the way we do connectivity checking (with the built-in transaction/retransmission timers). |
Codecov Report
@@ Coverage Diff @@
## master #75 +/- ##
===========================================
+ Coverage 41.27% 63.01% +21.74%
===========================================
Files 15 23 +8
Lines 831 1617 +786
===========================================
+ Hits 343 1019 +676
- Misses 449 466 +17
- Partials 39 132 +93
Continue to review full report at Codecov.
|
@enobufs this is an A+ for me! The only thing I would push back on (for now) is sharing sockets between candidate types. I can build a repro via vnet. But right now since we do STUN/TURN via default route it has a much higher chance of not having timed out requests. If we do the request on all interfaces we can send out requests that don’t route. This blocks startup time for ~5 seconds. Chromium doesn’t have this issue, they seem to be smart enough to only do it on some interfaces. So I am for sharing sockets. We just need to be careful about which one outbound STUN/TURN requests happen on I think. Oh and really nice idea with the transaction/timeout stuff! Nice that we can bring down the duplication. I think this is the right place to do it. |
Thanks @Sean-Der , good to know you are comfortable with the direction! Just one thing to make sure we are on the same boat.. (please bear with me) As you mentioned "default interface", I think you are talking about "multi-homed" cases where we have more than one local IP address or NICs. That is a (separate) issue we will need to sort out. What I'd like to address soon is a different one which is mentioned in pion/ice#74. Even there is only one local IP (non-loopback) on one NIC, we are allocating three UDP sockets (conns) for each candidate types when gathering candidates.
This causing more pings, NAT bindings and unnecessary prflx candidates (wasteful in resources). Here is what it looks like today:
We should use the same |
Resolves #74
Resolves #74
I am testing with coturn. It returns 401 error to the refresh request. I'm looking into it. |
* Requested Transport attr was add to non-allocate requests incorrectly * Refresh request was missing username, realm, nonce and integrity Resolves #74
@Sean-Der This is good to go. I am pretty confident because it is working with coturn, too! Let's unblock pion/ice#46! |
@Sean-Der @hugoArregui I think this demonstrates how the new turn.Client's API looks like and works, with a hope that helps your review! Actually, this |
Also, this is my implementation note |
@Sean-Der any suggestion for the version number? (last ver was v1.2.1) |
Resolves #74
Description
Please read the details in #74