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