So, here I've got some complex client-server application and some part of it opens port for listening and further network interactions. QTcpServer + QTcpSocket are used (the details will be described below).
This "network layer" of the application worked fine everywhere, except Windows 8.1 Pro. Just don't ask, why our client deсided, that it could be used as a server... It occured, that incorrect restarting of the process, which opened TCP connection on a specific port for listening causes sometimes this port to be unsuitable for any following attempts to bind it. It looks like some sort of magic, but the behavior occured as follows:
- Port 8554 was listened ("conection -- established") by a process
- Process crashes or killed somehow while having clients connected via this socket
- Process restarts and attempts to listen on the port again. It fails with "already in use".
- I stop the server and try to check the port via
netstat -an. It's free. I wait for some time and try to check the port via powershell, like:
$Listener = [System.Net.Sockets.TcpListener]8554 $Listener.Start()No, this leads to the same error like "already in use".
- I can bind socket to the other port, powershell snippet also works on them. But emergency restart of our server "breaks" them as well, scenario is the same.
- Once the port is "broken", windows restart is the only cure to it.
- Binding to "any address", i.e.
0.0.0.0:8554behaves as described. Binding to exact IP, like10.11.12.123:8554is better, checked it while trying to bind FileZilla on the "broken port".
Now goes the coding problem. Providing exact IP for binding looks like a bad idea, a least in our architecture, so I decided to use SO_REUSEADDR on Windows. But looks like I have to set this option before bind/listen calls, which leads to significant QTcpServer usage customizing. Keep in mind that the application is crossplatform (WinSock + sys/socket + some #defines if something other than Qt methods are to be used...). Aaaand there goes my favourite legacy version of QTcpServer customization, take a look:
QTcpServer2.h
#pragma once
#include <QTcpServer>
#include <QMutex>
class QTcpServer2 : public QTcpServer
{
QMutex mConnectionMutex;
QList<qintptr> mSocketDescriptors;
private:
virtual void incomingConnection(qintptr socketDescriptor) override;
public:
bool TakeIncomingSocketDescription(qintptr& socketDescriptor);
public:
QTcpServer2();
};
QTcpServer2.cpp
#include <QMutexLocker>
#include "QTcpServer2.h"
void QTcpServer2::incomingConnection(qintptr socketDescriptor)
{
QMutexLocker lock(&mConnectionMutex);
mSocketDescriptors.append(socketDescriptor);
}
bool QTcpServer2::TakeIncomingSocketDescription(qintptr& socketDescriptor)
{
QMutexLocker lock(&mConnectionMutex);
if (mSocketDescriptors.empty()) {
return false;
}
socketDescriptor = mSocketDescriptors.takeFirst();
return true;
}
QTcpServer2::QTcpServer2()
{ }
Usage:
bool NetServer::DoInitConnection()
{
mNetServer = QSharedPointer<QTcpServer2>(new QTcpServer2);
if (!mNetServer->listen(QHostAddress::AnyIPv4, mPort)) {
Log.Fatal(QString("Listen port fail (port: %1)").arg(mPort), true);
return false;
}
return true;
}
Sigh... Yeah, I know about pending connections mechanism, about signal-slot idea, but that's out code for now. TakeIncomingSocketDescription is used to pass socket descriptor somewhere. And threaded access, yes. Anyway, this piece of... code needs refactoring and I badly need your piece of advice: what's the apropriate way to customize socket binding here? Assume that subclassing stays, list of descriptors is also something not-so-easy to get rid of.
Qt Sources showed me the following:
/*! \internal
*/
void QTcpServerPrivate::configureCreatedSocket()
{
#if defined(Q_OS_UNIX)
// Under Unix, we want to be able to bind to the port, even if a socket on
// the same address-port is in TIME_WAIT. Under Windows this is possible
// anyway -- furthermore, the meaning of reusable on Windows is different:
// it means that you can use the same address-port for multiple listening
// sockets.
// Don't abort though if we can't set that option. For example the socks
// engine doesn't support that option, but that shouldn't prevent us from
// trying to bind/listen.
socketEngine->setOption(QAbstractSocketEngine::AddressReusable, 1);
#endif
}
That's exactly what I want, but there is no access to these internals from the Qt classes interface. QTcpServer performs bind call implicitly, so I cannot pass QAbstractSocket::ReuseAddressHint there.
Possibly, there is some neat solution, possibly not. I would be grateful for any ideas.
