I am writing Qt TCP/IP client. I want to check the connection state with server before send data to sever.
As far my knowledge I can do this by following methods
Use a bool 'ConnectionState', set this variable when connected with
sever and reset this variable on disconnected() signal. Now before
sending data to server (client->write()) check the value of this
variable.
use this 'client->state() == QTcpSocket::ConnectedState' way to check the connection state.
Which is good practice. Or any other method to this.
Thanks In advance.
QTCPSocket is derived from QAbstractSocket, which provides a state() function. This returns one of the following enums: -
enum SocketState { UnconnectedState, HostLookupState, ConnectingState, ConnectedState, ..., ListeningState }
So, assuming m_pSocket is a QTcpSocket, you would simply do this to check if it is connected:-
bool connected = (m_pSocket->state() == QTcpSocket::ConnectedState);
You could add a boolean and keep track of the state, but if a network error occurs you need to ensure that it is always in-sync with the actual connection state.
You can use errorOccurred signal and It's just enough for this signal define a slot in client. when an error occurs, a signal trigger and you can receive notify in slot function.
In client.h
/* define a slot for client */
public slots:
void errorOccurred(QAbstractSocket::SocketError error);
In client.c
/*client constructor*/
Client::Client(QObject *parent) {
/*some other code here*/
connect(socket, SIGNAL(errorOccurred(QAbstractSocket::SocketError)),
this, SLOT(errorOccurred(QAbstractSocket::SocketError)));
/*and maybe some other code here*/
}
and in client.c write implementation for errorOccurred:
void Client::errorOccurred(QAbstractSocket::SocketError error) {
qDebug() << "error in connection: " << socket->errorString();
}
OUTPUT:
error in connection: "Connection refused"
Related
PROBLEM DEFINITION: I have an external application called runSensor that communicates with a sensor. The sensor sends its data over UDP. Using the terminal, runSensor has two arguments to communicate with the sensor for data acquisition:start and stop.
Once at the terminal I call: $ runSensor start, a sample output is as follows:
[Time 07:20:11:000]: Device PoweredOn.
[Time 07:20:11:010]: x=1.231, y=-0.022, z=0.001
[Time 07:20:11:015]: x=1.235, y=-0.024, z=0.001
[Time 07:20:11:020]: x=1.241, y=-0.024, z=0.002
[Time 07:20:11:025]: x=1.258, y=-0.027, z=0.002
I need to call start and stop using a QT-UI. For that, I have a QDialog as follows:
Dialog::Dialog(QWidget *parent) :
QDialog(parent),
ui(new Ui::Dialog)
{
ui->setupUi(this);
this->socketHandler = std::make_shared<udpHandler>();
this->runSensorStartProcess = std::make_shared<QProcess>();
this->runSensorStopProcess = std::make_shared<QProcess> ();
//--------------------------
// SIGNAL - SLOT
//--------------------------
connect(ui->startButton, SIGNAL(clicked()), this, SLOT(onStartButtonClicked()));
connect(ui->stopButton, SIGNAL(clicked()), this, SLOT(onStopButtonClicked()));
connect(this->socketHandler.get(), SIGNAL(sendUdpContent(QString)), this, SLOT(updateMessageBrowser(QString)));
connect(this->runSensorStartProcess.get(), SIGNAL(readyReadStandardError()), this, SLOT(printError()));
}
I use QProcess to call the start and stop of runSensor application. When I push the GUI's start button, data acquisition starts, but the the GUI freezes and I cann't click on the stop button.
CODE EXTRACTS: Here is how I implemented the start button click:
void Dialog::onStartButtonClicked()
{
this->runSensorStartProcess->start("start");
//this->runSensorStartProcess->waitForFinished(-1);
//--------------------------
// udp socket handler starts picking data and write it into a file
//--------------------------
if (!this->runSensorStartProcess->waitForStarted())
{
qWarning() << "Warning: Cannot start Cygwin process!";
}
}
stop button click implementation is similar:
void Dialog::onStopButtonClicked()
{
if(this->runSensorStartProcess.get() != NULL)
{
this->runSensorStartProcess->close();
}
this->runSensorStopProcess->start("stop");
if (!this->runSensorStopProcess->waitForStarted())
{
qWarning() << "Warning: Cannot stop Cygwin!";
}
}
Question:
How can I keep th GUI responsive after runSensorStartProcess starts?
How can I stop that process on demand (in fact by starting runSensorStartProcess)?
Do I need a separate thread for runSensorStartProcess?
Don't use any of the waitForXxx methods. That's all. Yes, it's that simple.
Note that for every waitForXxx method there's a signal you can attach to and thus react to the event you're looking for.
Aren't QProcess::kill and QProcess::terminate what you need?
Never. See also answer 1 and answer 2.
I have a function who sending ack into the icinga / nagios server.
Function - sendAcknowledge
void MNetworkConnector::sendAcknowledge(QString service, QString host)
{
QNetworkAccessManager *ackmanager;
ackmanager = new QNetworkAccessManager();
QString ackcommand = "http://nagioscore.demos.nagios.com/nagios/cgi-bin/cmd.cgi?cmd_typ=34&cmd_mod=2&host=#host#&service=#service#&com_author=nagiosadmin&com_data=Sent:+mMonitor&btnSubmit=Commit";
service = service.replace(" ", "+");
ackcommand = ackcommand.replace("#host#", host).replace("#service#", service);
connect(ackmanager, SIGNAL(finished(QNetworkReply*)),this, SLOT(replyFinished2(QNetworkReply*)));
QNetworkRequest myReq;
QUrl myUrl(ackcommand);
myUrl.setUserName("nagiosadmin");
myUrl.setPassword("nagiosadmin");
myReq.setUrl(myUrl);
myReq.setRawHeader("Referer", "http://nagioscore.demos.nagios.com/nagios/cgi-bin/cmd.cgi");
ackmanager->get(myReq);
}
Function - replyFinished2
void MNetworkConnector::replyFinished2(QNetworkReply *r)
{
qDebug() << "reply output:" << r->readAll();
}
System returned several errors.
If I test this source on my corporate icinga server, I have error:
Not all commands could be send off successfully - Not Authorized
If I test it manualy on my corporate icinga server, I have error: Error: This appears to be a CSRF attack! The command wasn't issued via Classic-UI itself!
If I test it manualy on nagios test site, I have no error. Set service ack is Ok.
If I test this source I have error:Sorry, but you are not authorized to commit the specified command.
What's wrong? Thank you for all your ideas. At first I need solved problem in Icinga, the nagios test page I used only as alternative tests.
When the website requests authentication QNetworkAccessManager will emit the authenticationRequired() signal. Try connecting the signal with a slot and then set the username and password on the QAuthenticator object passed as argument to the slot.
Connection:
connect(ackmanager, SIGNAL(authenticationRequired(QNetworkReply *, QAuthenticator *)), this, SLOT(authenticationRequired(QNetworkReply *, QAuthenticator *)));
Slot:
void MNetworkConnector::authenticationRequired(QNetworkReply *r, QAuthenticator *authenticator)
{
authenticator->setUser("nagiosadmin");
authenticator->setPassword("nagiosadmin");
}
The problem was sensitive to uppercase and lowercase letters in the HOST.
I'm trying to connect to a D-Bus signal this way:
bool result = QDBusConnection::systemBus().connect(
"foo.bar", // service
"/foo/bar", // path
"foo.bar", // interface
"SignalSomething",
this,
SLOT(SignalSomethingSlot()));
if( !result )
{
// Why!?
}
QDBusConnection::connect() returns a boolean, how do I get extended error information? If a check QDBusConnection::lastError() it returns no useful information (as QDBusError::isValid() is false).
I had the same issue and it turned out that the slot I connected to had the wrong parameter types. They must match according to Qt's documentation and it looks like connect() verifies that, despite not explicitly mentioned.
Warning: The signal will only be delivered to the slot if the parameters match.
I suggest d-feet to list signals and check their parameter types. dbus-monitor does list signals, paths and such too, but not always the exact type of parameters.
One important observation though: I fixed the issue in my particular case by using different slot parameters than the actual signal has!
I wanted to connect to a com.ubuntu.Upstart0_6 signal mentioned here to detect when the screen in Ubuntu is locked/unlocked. dbusmonitor prints the following and d-feet shows parameters (String, Array of [String])
// dbusmonitor output
signal time=1529077633.579984 sender=:1.0 -> destination=(null destination) serial=809 path=/com/ubuntu/Upstart; interface=com.ubuntu.Upstart0_6; member=EventEmitted
string "desktop-unlock"
array [
]
Hence the signal should be of type
void screenLockChangedUbuntu(QString event, QVector<QString> args) // connect() -> false
This however made connect() return false. The solution was to remove the array parameter from the slot:
void screenLockChangedUbuntu(QString event) // works
I am aware that the array parameter was always empty, but I cannot explain why it only worked when removing it.
You could try these tricks:
1) Set QDBUS_DEBUG environment variable before running your application.
export QDBUS_DEBUG=1
2) Start dbus-monitor to see what's happening on the bus. You may need to set a global policy to be able to eavesdrop system bus depending on your distro.
Update:
Are you sure connecting to the system bus succeeded? If it fails you should probably check system.conf policy and possibly create own conf in system.d. This post might be helpful.
You could first connect to the system bus with QDBusConnection::connectToBus and check if it succeeded with QDBusConnection::isConnected. Only after that you try to connect to the signal and check if that succeeded.
QDBusConnection bus = QDBusConnection::connectToBus(QDBusConnection::systemBus, myConnectionName);
if (bus.isConnected())
{
if(!bus.connect( ... ))
{
// Connecting to signal failed
}
}
else
{
// Connecting to system bus failed
}
When the socket times out while waiting for a read it occasionally fails. But when it does fail, it continuously fails, and the log message in slotDisconnected never gets reported despite mpSocket's disconnected signal being connected to slotDisconnect(). It's as if the return statement in slotConnected isn't being hit and it's going round in a continous loop.
void Worker::slotDisconnected()
{
// Attempt to reconnect
log("Disconnected from Server. Attempting to reconnect...");
// fires mpSocket's connect signal (which is connected to slotConnected)
connectToServer();
}
void Worker::slotConnected()
{
// Loop forever while connected and receiving messages correctly
while(1)
{
if(mpSocket->bytesAvailable())
{
// A message is ready to read
}
else if(!mpSocket->waitForReadyRead(mSocketTimeOut))
{
// waitForReadyRead returned false - instead of continuing and trying again, we must disconnect as sometimes
// (for some unknown reason) it gets stuck in an infinite loop without disconnecting itself as it should
log("Socket timed out while waiting for next message.\nError String: " + mpSocket->errorString());
msleep(3000);
mpSocket->disconnect();
return;
}
}
}
The signals/slots are connected like so:
connect(mpSocket, &QAbstractSocket::disconnected, this, &TRNGrabberWorker::slotDisconnected);
connect(mpSocket, &QAbstractSocket::connected, this, &TRNGrabberWorker::slotConnected);
Anyone have any idea's what's going on? Would be much appreciated
To disconnect from server use mpSocket->disconnectFromHost(); instead of mpSocket->disconnect();.
Actually mpSocket->disconnect(); disconnects all signals/slots of object mpSocket.
Perhaps I'm being over-ambitious, but I'm trying to write a server program which can accept connections over both QLocalSockets and QTcpSockets. The concept is to have a 'nexus' object with both a QLocalServer and QTcpServer listening for new connections:
Nexus::Nexus(QObject *parent)
: QObject(parent)
{
// Establish a QLocalServer to deal with local connection requests:
localServer = new QLocalServer;
connect(localServer, SIGNAL(newConnection()),
this, SLOT(newLocalConnection()));
localServer -> listen("CalculationServer");
// Establish a UDP socket to deal with discovery requests:
udpServer = new QUdpSocket(this);
udpServer -> bind(QHostAddress::Any, SERVER_DISCOVERY_PORT);
connect(udpServer, SIGNAL(readyRead()),
this, SLOT(beDiscovered()));
// Establish a QTcpServer to deal with remote connection requests:
tcpServer = new QTcpServer;
connect(tcpServer, SIGNAL(newConnection()),
this, SLOT(newTcpConnection()));
tcpServer -> listen(QHostAddress::Any, SERVER_COMMAND_PORT);
}
... and then separate slots which establish a server object, whose constructor takes a pointer to a QIODevice. In theory, this ought to work because both QLocalSocket and QTcpSocket inherit QIODevice. Here is the newLocalConnection slot, for example:
void Nexus::newLocalConnection()
{
// Create a new CalculationServer connected to the newly-created local socket:
serverList.append(new CalculationServer(localServer -> nextPendingConnection()));
// We don't allow more than one local connection, so stop listening on the server:
localServer -> close();
}
The problem is that this won't compile, giving an error:
error C2664:
'CalculationServer::CalculationServer(QIODevice
*,QObject *)' : cannot convert parameter 1 from 'QLocalSocket *' to
'QIODevice *' 1> Types pointed
to are unrelated; conversion requires
reinterpret_cast, C-style cast or
function-style cast
Now the types pointed to are clearly not unrelated, and elsewhere in my code I have no problems at all with actions like:
QLocalSocket *socket = new QLocalSocket;
QIODevice *server = new QIODevice;
server = socket;
... so can anyone tell me why the compiler has a problem with this? Is there a way that I can make the constructor accept the QLocalServer*? I suppose there is the nuclear option of getting the constructor to take a void pointer plus an extra variable to tell it what it's being sent, so it can then recast the void pointer to either a QLocalSocket or QTcpSocket, but I feel uncomfortable resorting to reinterpret_cast on what looks like it ought to be a straightforward bit of C++ polymorphism.
Regards,
Stephen.
The most likely reason is that you have forgotten to #include <QLocalSocket> in the source file where the error occurs.