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

From: Sean Chittenden (sean_at_chittenden.org)
Date: 10/21/04

  • Next message: Marco Molteni: "Re: Removing T/TCP and replacing it with something simpler"
    Date: Thu, 21 Oct 2004 12:24:50 -0700
    To: Andre Oppermann <andre@freebsd.org>
    
    

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

    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.

    >> 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().

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

    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).

    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.

    -sc

    -- 
    Sean Chittenden
    _______________________________________________
    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: Marco Molteni: "Re: Removing T/TCP and replacing it with something simpler"

    Relevant Pages

    • Re: Removing T/TCP and replacing it with something simpler
      ... T/TCP will only be used if you use sendto, ... The setsockoptoptimizes packet sending on the server ... >> connection is uncorked and all data will be sent in one go even if it ... > Isn't that what NOPUSH does? ...
      (freebsd-arch)
    • Re: peer to peer messaging
      ... attempts to open a connection to port 80 of the server at that IP address. ... For example a packet from my machine might have source IP ... Packets from the sever to my laptop would have those reversed. ...
      (comp.lang.java.programmer)
    • Re: IPFW Dynamic Rules
      ... > So if the dynamic rule has the same behaviour as the origination ... > rule on the same port with the same protocol, ... If client sends UDP query to DNS on your machine, you get the packet: ... is deleted after connection is inactive for some time. ...
      (FreeBSD-Security)
    • [NEWS] Cisco PIX TCP Connection DoS
      ... Get your security news from a reliable source. ... By crafting a special TCP packet and sending it to a vulnerable Cisco PIX, ... embryonic connection open until the embryonic connection timeout which is ...
      (Securiteam)
    • Re: Nmap questions concering my router
      ... that may have to be fetched) is downloaded as one connection. ... >> all addresses (and may listen using just one interface to receive all ... sends packets to the correct protocol driver ... wire to an IP packet, and hands this to the IP driver which strips off ...
      (comp.security.firewalls)