QTcpServer - how to refuse incomming connection

[atomic]

Hi,

I write simply tcpserver and I have problem with incomming connections...



void Server::incomingConnection(int socketId)
{
qDebug()<< "incomming connection";

if( mClients.size() < 10 )
addClient(socketId);
else
qDebug()<< "server is overloaded";
}


so server accept only 10 connections but next clients can connect to server ( its socket state is QAbstractSocket::ConnectedState ).

How I can refuse next connection? I would like advise new clients, that server is overloaded and maybe prepare some timeout for waiting.

How I can do that?
Thanks,

[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();
}

}


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,
_