- 17 May, 2014 17 commits
-
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
This is a massive commit that can't be split. We add ice-tcp support into the agent by creating local host tcp-active/tcp-passive candidates. We also need to find the local and remote candidates whenever we discover a peer-reflexive because their data is important to setup the peer-reflexive so a few changes were added to look for the local or remote candidate. For TCP-ACTIVE remote peer-reflexive candidates, we can't add conncheck pairs normally because TCP-PASSIVE (local) do not generate candidate pairs, and we also can't have a connection from any local host, so we can only create a single candidatepair with the local/remote that are connected. The pair->socket of a candidate check pair will hold the connected tcp socket (through connect for ACT or accept for PASS) and we will either have a remote or a local peer-reflexive which will create a new candidate pair, we cannot trigger checks on the initial candidate pair, we must only do it on the new check pairs. but in the case of a tcp-passive, we don't get a new local peer-reflexive candidate, so there is no new candidate with a new NiceSocket, so when we get a triggered check, we need to match it to the candidate check pair or when we select a pair, it will still use the original TCP-PASS socket. We must store the new connected tcp socket in the peer reflexive candidates since they represent that unique peer-reflx candidate's connection
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
In the case of TCP-ACTIVE, we don't have a problem, because the new socket will generate a peer-reflexive candidate with the right sockptr, and all sends will go through it, but for TCP-PASSIVE, there is no peer reflexive candidates, so once the pair is selected, the local candidate will point to the TCP-PASSIVE candidate with the TCP_PASSIVE socket type which will cause all sends to fail, so we need to proxy them to the child connections
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
Data and STUN messages sent over TCP MUST follow the framing method specified in [RFC4571] section 2. We will frame every outgoing packet and split it into 62KB frames when sending, and on reception, we will unframe the rfc4571. For now, we only unframe for udp-turn tcp-act/pass candidates, which means only for MS-TURN over TCP. We still need to do the unframing for real ice-tcp candidates, then add support for reading the data in a serialized way.
-
Youness Alaoui authored
Fixes Issue #1
-
Youness Alaoui authored
-
- 15 May, 2014 23 commits
-
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
The add_to_be_sent was duplicated in http/socks5/pseudossl/tcp-bsd and had some small differences. It's better to factor it out so bug fixes get applied to all of them and code is cleaner.
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
The TURN-TCP RFC is very different from TURN-UDP, the current turn and tcp-turn files were only for UDP TURN RFC and UDP TURN using TCP transport. When we implement TCP-TURN, we'll need a different algorithm, so I renamed the files and API to avoid any confusion.
-
Youness Alaoui authored
-
Youness Alaoui authored
test-fullmode: protect against ready->connected->ready state change and accept data reception on connected state
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
Now we will always give a handicap to UDP candidates, but still give relays the lower priority. We have the following priorities now : In reliable mode : TCP Host : 120 TCP peer-refl : 110 TCP nat-assist : 105 TCP srv-refl : 100 UDP Host : 60 UDP peer-refl : 55 UDP nat-assist : 52 UDP srv-refl : 50 TCP relay : 10 UDP relay : 5 In unreliable mode : UDP Host : 120 UDP peer-refl : 110 UDP nat-assist : 105 UDP srv-refl : 100 TCP Host : 60 TCP peer-refl : 55 TCP nat-assist : 52 TCP srv-refl : 50 UDP relay : 10 TCP relay : 5
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
-
Youness Alaoui authored
-