Q: need effective backlog for listen()

Q: need effective backlog for listen()

[Ulrich Windl]

(not subscribed to the list, plese keep me on CC:)

Hi!

I have a problem I could not find the answer. I suspect the problem arises from Linux derivating from standard functionality...

I have written a server that should accept n TCP connections at most. I was expecting that the backlog parameter of listen will cause extra connection requests either
1) to be refused
or
2) to time out eventually

(The standard seems to say that extra connections are refused)

However none of the above see ms true. Even if my server delays accept()ing new connections, no client ever sees a "connection refused" or "connection timed out". Is there any chance to signal the client that no more connections are accepted at the moment?

Regards,
Ulrich Windl

Re: Q: need effective backlog for listen()

[Eric Dumazet]

On Mon, 2014-12-08 at 13:51 +0100, Ulrich Windl wrote:
> (not subscribed to the list, plese keep me on CC:)
> 
> Hi!
> 
> I have a problem I could not find the answer. I suspect the problem
> arises from Linux derivating from standard functionality...
> 
> I have written a server that should accept n TCP connections at most.
> I was expecting that the backlog parameter of listen will cause extra
> connection requests either
> 1) to be refused
> or
> 2) to time out eventually
> 
> (The standard seems to say that extra connections are refused)
> 
> However none of the above see ms true. Even if my server delays
> accept()ing new connections, no client ever sees a "connection
> refused" or "connection timed out". Is there any chance to signal the
> client that no more connections are accepted at the moment?

This 'standard' makes no sense to me, in light of SYNFLOOD attacks.

It actually makes SYNFLOOD attacks very effective.

Have you tried to disable syncookies for a start ?

Antw: Re: Q: need effective backlog for listen()

[Ulrich Windl]

>>> Eric Dumazet <eric.dumazet@gmail.com> schrieb am 08.12.2014 um 16:18 in
Nachricht <1418051901.15618.46.camel@edumazet-glaptop2.roam.corp.google.com>:
> On Mon, 2014-12-08 at 13:51 +0100, Ulrich Windl wrote:
>> (not subscribed to the list, plese keep me on CC:)
>> 
>> Hi!
>> 
>> I have a problem I could not find the answer. I suspect the problem
>> arises from Linux derivating from standard functionality...
>> 
>> I have written a server that should accept n TCP connections at most.
>> I was expecting that the backlog parameter of listen will cause extra
>> connection requests either
>> 1) to be refused
>> or
>> 2) to time out eventually
>> 
>> (The standard seems to say that extra connections are refused)
>> 
>> However none of the above see ms true. Even if my server delays
>> accept()ing new connections, no client ever sees a "connection
>> refused" or "connection timed out". Is there any chance to signal the
>> client that no more connections are accepted at the moment?
> 
> This 'standard' makes no sense to me, in light of SYNFLOOD attacks.
> 
> It actually makes SYNFLOOD attacks very effective.
> 
> Have you tried to disable syncookies for a start ?

No, I tries to temporarily close the listening socket. My priority is not to overload the server with connections. At the sime time I _want_ that the clients see that the server resfuses connections. Before you wonder: The client will actually be a load balancer.

Re: Q: need effective backlog for listen()

[Philippe Troin]

On Mon, 2014-12-08 at 13:51 +0100, Ulrich Windl wrote:
> (not subscribed to the list, plese keep me on CC:)
> 
> I have a problem I could not find the answer. I suspect the problem
> arises from Linux derivating from standard functionality...
> 
> I have written a server that should accept n TCP connections at most.
> I was expecting that the backlog parameter of listen will cause extra
> connection requests either
> 1) to be refused
> or
> 2) to time out eventually
> 
> (The standard seems to say that extra connections are refused)

The argument to listen() specifies how many connections the system is
allow to keep waiting to be accept()ed.
As soon as you accept() the connection, the count is decremented.
So that won't help for your use case.

> However none of the above see ms true. Even if my server delays
> accept()ing new connections, no client ever sees a "connection
> refused" or "connection timed out". Is there any chance to signal the
> client that no more connections are accepted at the moment?

Close the listening socket.  No new connections will be accepted.
When you reopen the socket for accepting new connections, you may have
to use SO_REUSEADDR before bind()ing to the port.

Phil.

Antw: Re: Q: need effective backlog for listen()

[Ulrich Windl]

>>> Philippe Troin <phil@fifi.org> schrieb am 08.12.2014 um 17:35 in Nachricht
<1418056540.384.5.camel@niobium.home.fifi.org>:
> On Mon, 2014-12-08 at 13:51 +0100, Ulrich Windl wrote:
>> (not subscribed to the list, plese keep me on CC:)
>> 
>> I have a problem I could not find the answer. I suspect the problem
>> arises from Linux derivating from standard functionality...
>> 
>> I have written a server that should accept n TCP connections at most.
>> I was expecting that the backlog parameter of listen will cause extra
>> connection requests either
>> 1) to be refused
>> or
>> 2) to time out eventually
>> 
>> (The standard seems to say that extra connections are refused)
> 
> The argument to listen() specifies how many connections the system is
> allow to keep waiting to be accept()ed.
> As soon as you accept() the connection, the count is decremented.
> So that won't help for your use case.
> 
>> However none of the above see ms true. Even if my server delays
>> accept()ing new connections, no client ever sees a "connection
>> refused" or "connection timed out". Is there any chance to signal the
>> client that no more connections are accepted at the moment?
> 
> Close the listening socket.  No new connections will be accepted.
> When you reopen the socket for accepting new connections, you may have
> to use SO_REUSEADDR before bind()ing to the port.

This is what I had done, but those connections who are waiting to be accepted: If I close the listening socket, will the clients see a connection abort, or will they see a connection refused?
Connection aborts could confuse clients.

Ulrich

Re: Antw: Re: Q: need effective backlog for listen()

[Philippe Troin]

On Tue, 2014-12-09 at 08:01 +0100, Ulrich Windl wrote:
> >>> Philippe Troin <phil@fifi.org> schrieb am 08.12.2014 um 17:35 in Nachricht
> <1418056540.384.5.camel@niobium.home.fifi.org>:
>
> > The argument to listen() specifies how many connections the system is
> > allow to keep waiting to be accept()ed.
> > As soon as you accept() the connection, the count is decremented.
> > So that won't help for your use case.
> > 
> >> However none of the above see ms true. Even if my server delays
> >> accept()ing new connections, no client ever sees a "connection
> >> refused" or "connection timed out". Is there any chance to signal the
> >> client that no more connections are accepted at the moment?
> > 
> > Close the listening socket.  No new connections will be accepted.
> > When you reopen the socket for accepting new connections, you may have
> > to use SO_REUSEADDR before bind()ing to the port.
> 
> This is what I had done, but those connections who are waiting to be
> accepted: If I close the listening socket, will the clients see a
> connection abort, or will they see a connection refused?
> Connection aborts could confuse clients.

The clients that completed the 3-way handshake and are waiting for their
(server-side) socket to be accept()ed will see connection reset I
believe.

You may be able to work something out by having no listen backlog
(listen(0)) and closing and reopening the socket when needed.

Phil.

Re: Antw: Re: Q: need effective backlog for listen()

[Ulrich Windl]

>>> Philippe Troin <phil@fifi.org> schrieb am 09.12.2014 um 16:07 in Nachricht
<1418137657.384.17.camel@niobium.home.fifi.org>:
> On Tue, 2014-12-09 at 08:01 +0100, Ulrich Windl wrote:
>> >>> Philippe Troin <phil@fifi.org> schrieb am 08.12.2014 um 17:35 in Nachricht
>> <1418056540.384.5.camel@niobium.home.fifi.org>:
>>
>> > The argument to listen() specifies how many connections the system is
>> > allow to keep waiting to be accept()ed.
>> > As soon as you accept() the connection, the count is decremented.
>> > So that won't help for your use case.
>> > 
>> >> However none of the above see ms true. Even if my server delays
>> >> accept()ing new connections, no client ever sees a "connection
>> >> refused" or "connection timed out". Is there any chance to signal the
>> >> client that no more connections are accepted at the moment?
>> > 
>> > Close the listening socket.  No new connections will be accepted.
>> > When you reopen the socket for accepting new connections, you may have
>> > to use SO_REUSEADDR before bind()ing to the port.
>> 
>> This is what I had done, but those connections who are waiting to be
>> accepted: If I close the listening socket, will the clients see a
>> connection abort, or will they see a connection refused?
>> Connection aborts could confuse clients.
> 
> The clients that completed the 3-way handshake and are waiting for their
> (server-side) socket to be accept()ed will see connection reset I
> believe.
> 
> You may be able to work something out by having no listen backlog
> (listen(0)) and closing and reopening the socket when needed.

I think I'd feel happier if listen() would implement the old semantics by default, and a new ioctl() (or such) would change to the "Linux accept all connections (3-way handshake) mode" on demand... Wishful thinking...

Ulrich