[Development] Proposed API addition to QTcpServer

[lars.knoll at nokia.com]

On 6/13/12 4:00 PM, "ext shane.kearns at accenture.com"
<shane.kearns at accenture.com> wrote:

>Background:
>If accept() returns an error, QTcpServer may live lock. (QTBUG-24778)
>The problem as described is that accept() returns EMFILE when quota is
>reached.
>On returning to the event loop, select() triggers again because the
>incoming connection is still pending
>This prevents other sockets being handled because the server socket is
>always readable.
>
>Proposal:
>Add a new signal QTcpServer::acceptError
>When the socket engine's accept() returns an error, the QTcpServer
>disables read notifications and emits the error signal.
>
>Add a new function void QTcpServer::resumeAccepting()
>The application can call this to restart the server (e.g. after a client
>disconnects)
>
>Add a new function void QTcpServer::pauseAccepting()
>This allows the application to manually suspend processing of incoming
>connections.
>
>See https://codereview.qt-project.org/28526
>
>Backward compatibility:
>It doesn't need to be "opt in", because where this situation occurs
>previously the application would live lock and need to be closed or
>killed.
>
>5.0 vs 5.1:
>The issue seems like it should be rare under normal circumstances.
>(Qt is not a toolkit for high load servers, and the default quota is ~1k
>file descriptors)
>However the consequences are severe.
>It's also a "denial of service" vulnerability, mitigated by the fact that
>QTcpServer only accepts 30 connections without application interaction
>(by default)

I'd say let's add it for 5.0. It's a small addition and solves a potential
security problem.

Cheers,
Lars