Am Donnerstag, 28. Mai 2015, 18:51:52 schrieb Giuseppe Scrivano: > Hubert Tarasiuk <[email protected]> writes: > > W dniu 28.05.2015 o 10:26, Giuseppe Scrivano pisze:> Hubert Tarasiuk > > > >> I wouldn't even have an option for --tcp-fast-open and avoid adding such > >> low level details to the command line. I would rather go for an env > >> variable like TCP_FAST_OPEN=1, that wget might honor or not and not > >> worry where it is not supported. > > > > What do you specifically mean by "not worry where it is not supported"? > > I was just thinking loudly. We are not going to support it on all > platforms and I would like that the wget configurations work more or > less portably. An alternative would be to just warn the user if it is > not supported (or even silently skip it). > > After looking at the code, I think we should consider some performance > numbers before we decide to include TFO in wget, to counter-balance > the cost of the increased code paths we have to deal with.
Performance numbers: https://reproducingnetworkresearch.wordpress.com/2014/06/03/cs244-14-tcp-fast-open-2/ In short: the faster the servers are, the higher the bandwidth is and the longer the distance (client<->server) is, the more does TFO matter. At least the servers are getting faster with time, also the bandwidth increases with time. BTW, an alternative might be QUIC (http://en.wikipedia.org/wiki/QUIC). QUIC approaches the same problem (RTT). But it seems far from being standardized though there seems support in Apache and Nginx. >> I would leave away the configure option --enable-tcp-tfo. Instead just use the >> constants defined in <sys/socket.h>, as Hubert already does. > Why would you prefer to leave away that option from configure? I said this because i couldn't imagine that someone wants to compile without TFO support, when TFO is supported. But I can't deny Giuseppe's above argument, so I am fine with a configure option. It really doesn't hurt. Regards, Tim
signature.asc
Description: This is a digitally signed message part.
