On 6/13/12 4:00 PM, "ext [email protected]" <[email protected]> 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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
