Skip to content
Snippets Groups Projects
Commit 01f4fd6a authored by Tomasz Grabiec's avatar Tomasz Grabiec Committed by Avi Kivity
Browse files

net: always use SOMAXCONN for backlog size


The TCP stack in current form is causing a lot of connection resets
when server running inside OSv is swarmed with connection attempts.
This does not happen on Linux for the same kind of workload.

The scenario is as follows. Client sends SYN to the server which runs
inside OSv. A SYN cache entry is created and SYN+ACK is sent back. The
client sends ACK in response and connect() call exits on its
side. Form now on the client may already start to write() into the
socket. When server receives client's ACK, it looks up the entry in
SYN cache, finds it, removes it, and tries to create a full-blown
connection socket. When it attempts to append it to the listening
socket's backlog it fails to do so because the backlog is full. As a
result the ACK is dropped and there is no longer SYN cache entry for
that connection. The client doesn't know about that. Then the next
client's packet arrives with data. The server cannot find a SYN cache
entry for that and tries to do SYN-cookie check, which fails because
client sequence does not match. As a result the server sends RST to
the client.

We could get more Linux-alike behavior in such situation by applying
the following modifications to our stack:

  * Drop SYN requests when the backlog is full _and_ SYN cache has
    more than one entry. Client will try to resend SYN packet.

  * When backlog is full upon receiving ACK, keep the entry in SYN
    cache. The client will eventually retransmit unacknowledged data
    and the connection state promotion will be retried at later time.

As an interim workaround let's set the socket backlog to SOMAXCONN
(128) regardless of the desired backlog size. Apparently some
benchmarking tools (iperf) set it to a really low value (5). Since OSv
is designated to run only one process, which will typically listen on
only a handful of ports, this should not be a big threat to memory
footprint.

Signed-off-by: default avatarTomasz Grabiec <tgrabiec@cloudius-systems.com>
Signed-off-by: default avatarAvi Kivity <avi@cloudius-systems.com>
parent b829959c
No related branches found
No related tags found
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment