On Wednesday 21 January 2015 21:39:30 Yawning Angel wrote:
On Wed, 21 Jan 2015 15:26:56 -0500
David Goulet dgoulet@ev0ke.net wrote:
+/*
- Using TCP Fast Open (TFO) uses sendto() instead of connect()
with 'flags'
- set to MSG_FASTOPEN. Without this code, using TFO simply
bypasses TOR
- without letting the user know.
- This solution simply ignores TFO and falls back to connect().
- At the time the TOR server supports TFO, socks5.c (client code)
could
- implement it in send_data() and connect_socks5().
Could you simply clarify this for me meaning what's needed in socks5 code for TFO to be supported? (no need for an extra comments, just how would I do that :)
This doesn't really make sense when a proxy is in the picture. What would you include as the TFO payload? The "VER | NMETHODS | METHODS" SOCKS5 handshake?
In the vast majority of the deployed configurations, the client code talks to tor over a loopback interface, so cutting out 1xRTT isn't worth the added code (There's a case to be made for using TFO for inter-relay traffic, but that's entirely orthogonal to this.).
Right, TFO doesn't make much sense in a loopback scenario (on the other hand there is no impact). Adding the code is only worth if someone really asks for it and verifies a benefit.
TFO comes into play for short-time connections or more exactly when RTT matters (as you mentioned).
But to answer David's request (in short):
TFO has to be globally enabled on your (Linux) system: # echo 1 > /proc/sys/net/ipv4/tcp_fastopen
On the server side it is easy: // bind() setsockopt(sockfd, SOL_TCP, TCP_FASTOPEN, &qlen, sizeof(qlen)); // listen()
On the client side it is sendto(fd, buffer, buf_len, MSG_FASTOPEN, ...); send() recv() instead of connect() send() recv()
But you need a fallback to connect() if the above sendto() fails (e.g. due to TFO not enabled via /proc/).
see http://edsiper.linuxchile.cl/blog/2013/02/21/linux-tcp-fastopen-in-your-sock...
Regards,
Tim