Re: Removing T/TCP and replacing it with something simpler

From: Andre Oppermann (andre_at_freebsd.org)
Date: 10/21/04

  • Next message: Julian Elischer: "Re: Removing T/TCP and replacing it with something simpler" 
    Date: Thu, 21 Oct 2004 20:56:50 +0200
To: Sean Chittenden <sean@chittenden.org>

    Sean Chittenden wrote:
    >
    > > I intend to remove T/TCP (transactional TCP) support from our TCP
    > > implementation for the following reasons:
    >
    > The special cases are evil.

    Indeed.

    > > 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:
    >
    > http://lists.danga.com/pipermail/memcached/2003-August/000111.html

    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.

    > 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?

    > That said, I can't stress enough the usefulness of TCP_NOPUSH/ttcp(4).

    Ah, I'm not going to remove TCP_NOPUSH. It can live independ of T/TCP.
    While this option has been introduced together with T/TCP enabling it
    does not make you use T/TCP.

    > However it gets implemented, I don't really care. If ttcp(4) is ready
    > to bite the dust, so be it, but extensions/options like this are
    > fantastically useful to those who know about its existence/usefulness.
    > Good luck with the replacement. :)

    Thanks.

    > In 2001, there was a push to make Linux's TCP_CORK option behave the
    > same as FreeBSD's TCP_NOPUSH. Is maintaining that compatibility still
    > a goal, or are we going to kick this change off to the Linux folk to
    > have them play catchup (to what sounds like a more secure option than
    > Linux's TCP_CORK)?
    >
    > http://seclists.org/linux-kernel/2001/Feb/0993.html

    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. 

    -- 
Andre
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
  • Next message: Julian Elischer: "Re: Removing T/TCP and replacing it with something simpler"

    Relevant Pages

    • Re: Lost data on socket - Can we start over politely?
      ... >> reading from the socket. ... >you are draining them too slow, but the client is sending data anyway. ... to make it keep pace--they were only as big as the packets, ... It handles exactly SOMAXCONN connections. ...
      (comp.lang.perl.misc)
    • netstat -s output: "packets pruned" and "packets collapsed"
      ... 4087 packets pruned from receive queue because of socket buffer ... 362332 active connections openings ...
      (comp.os.linux.networking)
    • TCP Connections, Bluesocket, and Mac OS X
      ... concerning OSX systems and Bluesocket wireless technology. ... due to too many open network connections. ... You can see how many sessions your ... 18908 data packets ...
      (alt.internet.wireless)
    • Re: Improving FreeBSD NFS performance (esp. directory updates)
      ... >> I don't think the network is at fault, nor is the server really going ... 155645171 data packets ... discarded for bad header offset fields ... 790 connections established ...
      (freebsd-questions)
    • Asynchronous Socket Server data
      ... The socket server knows what type of data it expects due to the interface ... I can have 1 databuffer only for each datatype to handle multiple connections? ... int bytesRead = handler.EndReceive; ... packetIndex, bytesRead); ...
      (microsoft.public.dotnet.languages.csharp)