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

From: Igor Sysoev (is_at_rambler-co.ru)
Date: 10/21/04

  • Next message: Craig Rodrigues: "Re: Removing T/TCP and replacing it with something simpler" 
    Date: Thu, 21 Oct 2004 23:41:47 +0400 (MSD)
To: Sean Chittenden <sean@chittenden.org>

    On Thu, 21 Oct 2004, Sean Chittenden wrote:

    > >> 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 think that TCP_CORK was implemented only for Linux's sendfile()
    to postpone the sending of the HTTP header:

    http://freebsd.rambler.ru/linux/kernel_1999/msg13796.html
    http://freebsd.rambler.ru/linux/kernel_2001/msg61910.html

    Igor Sysoev
    http://sysoev.ru/en/
    _______________________________________________
    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: Craig Rodrigues: "Re: Removing T/TCP and replacing it with something simpler"

    Relevant Pages

    • Re: Problem with writing fast UDP server
      ... UDP packets per second. ... socket and threads. ... I wrote a simple case test: client and server. ... The maximum theoretical limit is 14,880 frames per ...
      (comp.lang.python)
    • RE: *warning* student question
      ... What option is this supposed CRC or hash supposed to be? ... >their shell session you're taking over their network socket. ... Systems will also drop TCP packets with bad checksums. ... We provide Ethical Hacking, Advanced Ethical Hacking, Intrusion ...
      (Security-Basics)
    • Re: [patch 4/10] s390: network driver.
      ... but it seems someone is complaining about some behavior changing? ... network driver discard packets on link-down. ... However this approach doesnt play well if the socket can ... be blocked completely because of /one/ interface having its link ...
      (Linux-Kernel)
    • RE: *warning* student question
      ... >like old shred computer session hacking, ... >their shell session you're taking over their network socket. ... Systems will also drop TCP packets with bad checksums. ...
      (Security-Basics)
    • 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)