|Andre Oppermann||Oct 21, 2004 7:33 am|
|Poul-Henning Kamp||Oct 21, 2004 7:41 am|
|Andre Oppermann||Oct 21, 2004 7:46 am|
|Richard Wendland||Oct 21, 2004 7:59 am|
|Mike Silbersack||Oct 21, 2004 8:23 am|
|Andre Oppermann||Oct 21, 2004 8:37 am|
|Bruce M Simpson||Oct 21, 2004 8:40 am|
|Andre Oppermann||Oct 21, 2004 9:23 am|
|Garrett Wollman||Oct 21, 2004 9:27 am|
|Mark Allman||Oct 21, 2004 10:31 am|
|Andre Oppermann||Oct 21, 2004 10:56 am|
|Matt Emmerton||Oct 21, 2004 11:31 am|
|Sean Chittenden||Oct 21, 2004 11:31 am|
|Mark Allman||Oct 21, 2004 11:32 am|
|David O'Brien||Oct 21, 2004 11:51 am|
|Andre Oppermann||Oct 21, 2004 11:56 am|
|Julian Elischer||Oct 21, 2004 11:59 am|
|Garrett Wollman||Oct 21, 2004 12:02 pm|
|Andre Oppermann||Oct 21, 2004 12:02 pm|
|Andre Oppermann||Oct 21, 2004 12:04 pm|
|Sean Chittenden||Oct 21, 2004 12:24 pm|
|Marco Molteni||Oct 21, 2004 12:34 pm|
|Igor Sysoev||Oct 21, 2004 12:41 pm|
|Craig Rodrigues||Oct 21, 2004 6:46 pm|
|Russell L. Carter||Oct 21, 2004 7:02 pm|
|Julian Elischer||Oct 21, 2004 8:24 pm|
|SUZUKI Shinsuke||Oct 22, 2004 12:47 am|
|Dag-Erling Smørgrav||Oct 22, 2004 5:06 am|
|Dag-Erling Smørgrav||Oct 22, 2004 5:47 am|
|Andre Oppermann||Oct 22, 2004 8:14 am|
|Andre Oppermann||Oct 22, 2004 8:17 am|
|Brian Fundakowski Feldman||Oct 22, 2004 8:44 am|
|Andre Oppermann||Oct 22, 2004 8:55 am|
|Mark Allman||Oct 22, 2004 11:24 am|
|Peter Lei||Oct 22, 2004 5:59 pm|
|Randall Stewart||Oct 23, 2004 6:07 am|
|Randall Stewart||Oct 23, 2004 6:16 am|
|Randall Stewart||Oct 23, 2004 6:17 am|
|Randall Stewart||Oct 23, 2004 6:20 am|
|Andre Oppermann||Oct 23, 2004 7:16 am|
|Randy Bush||Oct 23, 2004 9:01 am|
|SUZUKI Shinsuke||Oct 25, 2004 10:18 pm|
|Randall Stewart||Oct 26, 2004 3:41 am|
|Peter Lei||Oct 26, 2004 7:44 am|
|Karim Fodil-Lemelin||Nov 4, 2004 9:52 am|
|Andre Oppermann||Nov 4, 2004 10:50 am|
|Julian Elischer||Nov 4, 2004 12:52 pm|
|Matt Sealey||Nov 4, 2004 12:58 pm|
|Karim Fodil-Lemelin||Nov 5, 2004 8:08 am|
|Karim Fodil-Lemelin||Nov 5, 2004 8:39 am|
|Andre Oppermann||Nov 5, 2004 8:45 am|
|Karim Fodil-Lemelin||Nov 5, 2004 9:12 am|
|Andre Oppermann||Nov 5, 2004 9:31 am|
|Karim Fodil-Lemelin||Nov 5, 2004 1:45 pm|
|Andre Oppermann||Nov 5, 2004 2:16 pm|
|Mark Allman||Nov 8, 2004 8:08 pm|
|Andre Oppermann||Jul 3, 2005 12:08 am|
|Andre Oppermann||Jul 3, 2005 11:43 am|
|Randall Stewart||Jul 3, 2005 11:44 am|
|Subject:||Removing T/TCP and replacing it with something simpler|
|From:||Andre Oppermann (and...@freebsd.org)|
|Date:||Oct 22, 2004 8:14:36 am|
Sean Chittenden wrote:
However something like T/TCP is certainly useful and I know of one special purpose application using it (Web Proxy Server/Client for high-delay Satellite connections).
Actually, there are two/three programs that I know of that use it. memcached(1), which found a fantastic decrease in its benchmarks. Here's an excerpt from the following link:
I think you got something wrong here. T/TCP is never ever mentioned in this. Memcached is not using T/TCP as far as I can see.
It's not, but I thought setsockopt(2) w/ TCP_NOPUSH enabled the use of T/TCP in that there was no 3WHS performed on a TCP_NOPUSH'ed connection.
No, it is not. T/TCP will only be used if you use sendto(), have T/TCP globally enabled on the machine and the server supports it too.
TCP_NOPUSH was introduced together with or some time after T/TCP to change the behaviour how tcp_output() pushes non-full packets on the wire. It pretty closely related to the same purpose as TCP_CORK.
and an internal reverse proxy server/modified apache that I've hacked together (reduces latency in a tiered request hierarchy a great deal, on order of the benchmarks from above).
What syscall do you use to get to the other side in your reverse proxy?
On the client, sendto()/read(). On the server, setsockopt() + write().
Ok, then you are indeed using T/TCP (provided you have enabled it on both machines). The setsockopt() optimizes packet sending on the server but otherwise doesn't have anything to do with T/TCP.
I'm not sure if I can follow you here. TCP_CORK deals with the different behaviour of connections with Nagle vs. TCP_NODELAY. TCP_CORK allows to avoid the delays of Nagle by corking (sort of blocking) the sending of packets until you are done with write()ing to the socket. Then the connection is uncorked and all data will be sent in one go even if it doesn't fill an entire packet. Sort of an fsync() for sockets. There are no security implications with TCP_CORK as far as I am aware.
Isn't that what NOPUSH does? Or is it that CORK uses a fully established TCP connection, but blocks sending data until the connection has been uncorked/flushed? I thought that TCP_CORK had the same security implications that NOPUSH does (ie, the lack of a hand shake).
None of it. Neither NOPUSH nor CORK have any security implications. Those are only with the specification of T/TCP. Blocking the data is independend of 3WSH. Normally you have Nagle enabled (default) and when you don't fill an entire packet worth of data it will wait up to 200ms to send the packet in anticipation of more data from the socket. This screws the responsiveness of your connection. The first solution is to turn off Nagle (with TCP_NODELAY) but now you get a packet for every single write() you do. Fine for telnet and ssh but not the right thing for a database server. There you don't want the delay but at the same time you want several successive write()s that will go in one packet on the wire. Here NOPUSH and CORK come into play.
I was under the impression that by default NOPUSH would prevent a connect() until there was a full packet to be sent or the socket had been closed/flushed. The first/only packet from the client to the server would contain a SIN+PUSH+FIN + the data for the request, then the server would come back with a SIN+PUSH+FIN+ACK. Essentially UDP, but with checksums and packet retransmission built in.
More or less correct. However the SYN+FIN+Data is caused by T/TCP and not NOPUSH. NOPUSH is used as an optimization as I have described above usually on the server side.