[lkml]   [1997]   [Dec]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: networking / web perf probs
    Date (Larry McVoy) writes:

    > Another part of the fix is to have
    > listen(sock, 0)
    > work like normal, but
    > listen(sock, >0)
    > should be changed (in the kernel) to be something like
    > listen(sock, sizeof(input queue length))

    I started a implementation of this (you'll see that newer 2.1 kernels
    contain some code #ifdefed to NEW_LISTEN in net/ipv4/tcp_ipv4.c).
    That implements exactly what you describe. It's not extensively tested
    though. To manage larger queues efficiently requires so more work though
    - currently the TCP connection requests are kept in a single linked list.
    I have some experimental patches to solve this problem (and a few
    others - including zero overhead timers for TIME_WAIT sockets), but
    they are not ready for release yet.

    Note that there are really two input queues involved here. The
    packet input queue (which is only limited by free memory and later
    by the socket rcvbuf settings) and the TCP connection request queue
    (basically TCP SYN_RECV sockets). Incoming data packets could block
    out incoming SYNs of course, when Linux runs out of memory, but
    there is nothing that could be really done against it. In the
    TCP open request queue only incoming SYNs are handled, never
    other data packets. Because of this separation really big listen
    backlog queues are only needed to defend against TCP SYN flood attacks
    (together with random drop or tail drop on the syn queue). Linux
    offers a nice alternative to these big queues though - syncookies.


     \ /
      Last update: 2005-03-22 13:40    [W:0.018 / U:22.676 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site