[openib-general] SDP: BUG 2034 workaround

[Libor Michalek]

On Tue, Feb 22, 2005 at 12:14:45PM +0200, Michael S. Tsirkin wrote:
> 
> sdp_inet.c, inside _sdp_inet_listen, we have:
> 
> #if 0                           /* BUG 2034 workaround. */
>         conn->backlog_max = backlog;
> #else
>         conn->backlog_max = 1024;
> #endif
> 
> What gives? what would be the proper fix as opposed to a work-around?

  The Linux TCP listen uses two seperate values to control the listner
backlog, so I ignored the backlog parameter to get closer to the default
Linux behavior, until a really solution is devised.
 
  Basically TCP uses a two stage backlog to defend against SYN attacks.
When a SYN is received a small amount of state is kept until the full
handshake is completed, at which point a full socket is created and
queued onto the listen sockets accept queue. The second stage uses the
listen() backlog parameter to manage the accept queue. The first stage
queue size is managed using a sysctl, (net.pv4.tcp_max_syn_backlog)
which on a lot of systems defaults to 1024.

  SDP on the other hand creates the full socket on the REQ request, and
places it directly into the listen sockets accept queue. So the full
depth of the queue is governed by the listen backlog parameter. Worse
still the socket layer listen, above TCP and SDP, limits the listen()
backlog that is passed to the protocol to 128, and only recently did this
become adjustable using net.core.somaxconn. 

   Using just the backlog parameter to manage this queue, results in a
few programs that use a high connection volume to get rejected connection,
casued by a full backlog queue, even when upped to the full 128 that the
socket layer allows by default.


-Libor