QTcpServer - how to refuse incomming connection

[ChrisW67]

Perhaps call QTcpServer::setMaxPendingConnections() to the number of free slots initially (i.e. 10), reducing the number every time you accept a connect, and increasing the number every time you close a connection.

[atomic]

Yes, this blocks new incoming connection on server, but new clients still gets connected state and connected signal, this is strange.

[anda_skoa]

You can delete the QTcpServer object and thus stop if from listening.

Cheers,
_

[atomic]

No, I can not delete QTcpServer, because I must operate with other accepted connections.
I want only say to the next incomming connection, that they should wait because server is overloaded, maybe something like this:

void Server::incomingConnection(int socketId)
{
 
    if( canAcceptConnection() )
        addClient(socketId);
    else {
        QTcpSocket *socket = new QTcpSocket(this);
        socket->setSocketDescriptor(socketId);
        socket->write("Server is overloaded, try again later...\r\n");
        socket->close();
        socket->deleteLater();
    }
 
}

void Server::incomingConnection(int socketId)
{

    if( canAcceptConnection() )
        addClient(socketId);
    else {
        QTcpSocket *socket = new QTcpSocket(this);
        socket->setSocketDescriptor(socketId);
        socket->write("Server is overloaded, try again later...\r\n");
        socket->close();
        socket->deleteLater();
    }

}

To copy to clipboard, switch view to plain text mode 

that is a good idea?

[anda_skoa]

No, I can not delete QTcpServer, because I must operate with other accepted connections.

The QTcpServer is not involved in already accepted connections, so if you reparent the QTcpSockets to a different object they won't be affected by the server's deletion.

I want only say to the next incomming connection, that they should wait because server is overloaded, maybe something like this:

This is of course something entirely different than not accepting connections.
In comment #3 you complained about clients getting connected.

that is a good idea?

If you have a protocol between server and client then it might even make sense to specify such a "return later" exchange.
E.g. HTTP's 503 status

Cheers,
_