-
-
Couldn't load subscription status.
- Fork 99
Implement ICE-TCP #293
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
Implement ICE-TCP #293
Conversation
2e10e4d to
eba7075
Compare
This comment was marked as outdated.
This comment was marked as outdated.
|
OK, this is complicated because the whole library is designed with the assumption that candidates can only be UDP. It would be way simpler to implement TURN TCP. I think you can't realistically implement something on the side running in its own thread. It seems to me the best way to implement this is to add optional TCP sockets for each agent to the thread and poll connectivity backends (I don't think mux mode can have TCP candidates as you would have to create new sockets). TCP sockets would be polled and read by the backend. A lot of functions assume addresses are UDP only, like You would then need to modify the logic to match candidates pairs properly. You would probably need to introduce a function to order the backend to actively connect to a remote TCP address. Again, this is complicated and requires fundamental changes, contrary to TURN TCP (as candidates are still UDP in that case). |
This comment was marked as outdated.
This comment was marked as outdated.
0e78225 to
759663e
Compare
758413a to
4b5850a
Compare
This comment was marked as outdated.
This comment was marked as outdated.
5e1b4e2 to
2e82b30
Compare
f9e1a3e to
e92dcd4
Compare
c92e67b to
60aa54f
Compare
089a0d8 to
8a89802
Compare
|
|
||
| for (int i = 0; i < agent->candidate_pairs_count; ++i) { | ||
| ice_candidate_pair_t *pair = &agent->candidate_pairs[i]; | ||
| if (pair->remote->transport != ICE_CANDIDATE_TRANSPORT_UDP) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here you could check if pair->remote->resolved.addr.ss_family == remote->resolved.addr.ss_family to allow one IPv4 and one IPv6 TCP candidate.
| return; | ||
| } | ||
|
|
||
| } else if (conn_impl->next_timestamp <= current_timestamp()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You also need to handle POLLHUP indicating connection closed and you should also treat POLLERR like connection reset. (They can be set at the same time as POLLIN so it's not an else)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Logic changed to the following. POLLHUP and POLLERR are now fatal.
if (pfd->revents & POLLHUP || pfd->revents & POLLERR) {
agent_conn_fail(agent);
conn_impl->state = CONN_STATE_FINISHED;
return;
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The issue with this logic is that when receiving POLLHUP you discard any data sitting in the buffer. While not a big problem in this context, it should be avoided. I'll fix it after merging.
0509e6a to
0f9ee22
Compare
Co-authored-by: Paul-Louis Ageneau <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, it looks good. There are a couple things I'll fix later but they don't seem blocking to me. Thank you for the work on this!
TODO
assertconn_poll_connectand a callback to notify Agent that candidate is ready