Many sockets failing on Windows
-
Hi guys,
I'm wondering if Windows has a problem closing socket or if there is a bug in Qt.
I'm currently using Windows 10 with Qt 5.15 and Qt 6.3.This is the situation:
I have two different softwares which are using TCP/IP sockets to communicate.- The first software (client) communicates with an image processing software (server) in such a way that a connection/socket is opened for each measurement job and remains open until the response arrives. After the response has arrived, the connection is closed by the client. This can happen about 50-200x per second. Don't ask why or discuss about it because this is the only way.
- The second software (client) uses QSqlDatabase within threads to communicate with a database (server). Each thread uses QSqlDatabase::open() and QSqlDatabase close() and QSqlDatabase::removeDatabase(). Internally, a socket is used here to communicate with the database. Multiple threads of a thread pool are used and each thread opens and closes the connection.
In every case the communication stops after a few seconds. I used a programm called cports.exe (https://www.nirsoft.net/utils/cports.html) to display the currently used sockets. And I can see that the number of user defined sockets from port 49152 to 65535 are all occupied. Windows takes some time (about 1 minute) to free the used sockets.
I know that this is something like a ddos attack, but this does not happen with any other software except Qt.
So, is there a bug on Qt using sockets on Windows?Regards,
Oliver -
Hi guys,
I'm wondering if Windows has a problem closing socket or if there is a bug in Qt.
I'm currently using Windows 10 with Qt 5.15 and Qt 6.3.This is the situation:
I have two different softwares which are using TCP/IP sockets to communicate.- The first software (client) communicates with an image processing software (server) in such a way that a connection/socket is opened for each measurement job and remains open until the response arrives. After the response has arrived, the connection is closed by the client. This can happen about 50-200x per second. Don't ask why or discuss about it because this is the only way.
- The second software (client) uses QSqlDatabase within threads to communicate with a database (server). Each thread uses QSqlDatabase::open() and QSqlDatabase close() and QSqlDatabase::removeDatabase(). Internally, a socket is used here to communicate with the database. Multiple threads of a thread pool are used and each thread opens and closes the connection.
In every case the communication stops after a few seconds. I used a programm called cports.exe (https://www.nirsoft.net/utils/cports.html) to display the currently used sockets. And I can see that the number of user defined sockets from port 49152 to 65535 are all occupied. Windows takes some time (about 1 minute) to free the used sockets.
I know that this is something like a ddos attack, but this does not happen with any other software except Qt.
So, is there a bug on Qt using sockets on Windows?Regards,
Oliver@stvokr said in Many sockets failing on Windows:
After the response has arrived, the connection is closed by the client
Make sure they're really closed. You can also give ReuseAddressHint a try.
-
@stvokr said in Many sockets failing on Windows:
After the response has arrived, the connection is closed by the client
Make sure they're really closed. You can also give ReuseAddressHint a try.
And what would that look like?
This is what I get from the stateChanged() signal for every connection:
after connectToHost() ...QAbstractSocket::HostLookupState QAbstractSocket::ConnectingState QAbstractSocket::ConnectedState... and after disconnectFromHost().
QAbstractSocket::ClosingState QAbstractSocket::UnconnectedStateIs thery anything else?
A don't forget the QSqlDatabase. I think there is no way to affect TCP connection.
ReuseAddressHint did not work.
-
Hi, do the 2 flavors of socket i/o cause equal amount of congestion, i.e. is it possible for you to see if the image processing use most of the sockets or if it's the database that has the biggest amount of busy sockets?
If the QSqlDatabase server is some kind of Microsoft product, then chances are that you can communicate with it using something else that sockets, for example named pipes. -
Hi, do the 2 flavors of socket i/o cause equal amount of congestion, i.e. is it possible for you to see if the image processing use most of the sockets or if it's the database that has the biggest amount of busy sockets?
If the QSqlDatabase server is some kind of Microsoft product, then chances are that you can communicate with it using something else that sockets, for example named pipes.@hskoglund said in Many sockets failing on Windows:
Hi, do the 2 flavors of socket i/o cause equal amount of congestion, i.e. is it possible for you to see if the image processing use most of the sockets or if it's the database that has the biggest amount of busy sockets?
This is the same for both softwares. It depends on how fast the sockets are created.
If the QSqlDatabase server is some kind of Microsoft product, then chances are that you can communicate with it using something else that sockets, for example named pipes.
It's a MySQL Database, no MS product.
-
@stvokr said in Many sockets failing on Windows:
This can happen about 50-200x per second. Don't ask why or discuss about it because this is the only way.
Then we can only pass the comment that this is a poor design. Establishing and closing ~100 TCP connections per second is going to tax any non-dedicated environment.
So, is there a bug on Qt using sockets on Windows?
No.
I am going to guess these numerous sockets are all in TIME_WAIT. This is a normal state of affairs for graceful closing of TCP connections.
On Windows the default TIME_WAIT period is 120 seconds. In your design, 100 connections/sec will accumulate ~12000 open ports, and plateau there, in the time it takes the first one to time out. By default Windows only allows ports 49152-65535 to user processes: 16384 ports.
You can adjust the TIME_WAIT period and also change the allowable user port range (more ports). This will affect everything running on the machine.You could consider QTcpSocket::abort() on the client if you are certain the entire conversation is done. This probably sends a RST packet and may free the client-side faster. Cannot say how the other end will handle it.
-
@stvokr said in Many sockets failing on Windows:
This can happen about 50-200x per second. Don't ask why or discuss about it because this is the only way.
Then we can only pass the comment that this is a poor design. Establishing and closing ~100 TCP connections per second is going to tax any non-dedicated environment.
So, is there a bug on Qt using sockets on Windows?
No.
I am going to guess these numerous sockets are all in TIME_WAIT. This is a normal state of affairs for graceful closing of TCP connections.
On Windows the default TIME_WAIT period is 120 seconds. In your design, 100 connections/sec will accumulate ~12000 open ports, and plateau there, in the time it takes the first one to time out. By default Windows only allows ports 49152-65535 to user processes: 16384 ports.
You can adjust the TIME_WAIT period and also change the allowable user port range (more ports). This will affect everything running on the machine.You could consider QTcpSocket::abort() on the client if you are certain the entire conversation is done. This probably sends a RST packet and may free the client-side faster. Cannot say how the other end will handle it.
