QSslSocket::readyRead() never triggered with Python server
-
@SGaist Yes I did,
I see all of the TLS Handshake being done successfully.
The server then sends data to the client after a client request and it looks like the client acknowledges those packets.
The IP .19 is the client and the .103 is the server. There are many SSH packets since my client has an ssh session opened with the server. The ports are the right ones.
There's a fourth screenshot of the packets,but I'm not sure it is relevant.
-
@SGaist Yes I did,
I see all of the TLS Handshake being done successfully.
The server then sends data to the client after a client request and it looks like the client acknowledges those packets.
The IP .19 is the client and the .103 is the server. There are many SSH packets since my client has an ssh session opened with the server. The ports are the right ones.
There's a fourth screenshot of the packets,but I'm not sure it is relevant.
Just being nitpicky, but technically it's not an ethernet receiver. There is no requirement that it have anything to do with ethernet. The SSL connection is over TCP (layer 4) and ethernet is a layer (1/2) service. IP need not be carried over ethernet.
I think you may be making it too complicated by using threads...and I question the need for mutex locks if you get rid of the threads.
If you need to service multiple connections, the long standing UNIX way is to fork a new instance of your program for each connection.
If you meet the AI on the road, kill it.
-
Just being nitpicky, but technically it's not an ethernet receiver. There is no requirement that it have anything to do with ethernet. The SSL connection is over TCP (layer 4) and ethernet is a layer (1/2) service. IP need not be carried over ethernet.
I think you may be making it too complicated by using threads...and I question the need for mutex locks if you get rid of the threads.
If you need to service multiple connections, the long standing UNIX way is to fork a new instance of your program for each connection.
@Kent-Dorfman said in QSslSocket::readyRead() never triggered with Python server:
the long standing UNIX way is to fork a new instance of your program for each connection
The Qt way is to use assynchronous nature of Qt with signals/slots :-)
-
@Kent-Dorfman said in QSslSocket::readyRead() never triggered with Python server:
the long standing UNIX way is to fork a new instance of your program for each connection
The Qt way is to use assynchronous nature of Qt with signals/slots :-)
@jsulm said in QSslSocket::readyRead() never triggered with Python server:
The Qt way is to use assynchronous nature of Qt with signals/slots :-)
SPOILER!
Haven't you heard of making the student to it by brute force before showing them the easy way?
If you meet the AI on the road, kill it.
-
@jsulm said in QSslSocket::readyRead() never triggered with Python server:
The Qt way is to use assynchronous nature of Qt with signals/slots :-)
SPOILER!
Haven't you heard of making the student to it by brute force before showing them the easy way?
@Kent-Dorfman said in QSslSocket::readyRead() never triggered with Python server:
@jsulm said in QSslSocket::readyRead() never triggered with Python server:
The Qt way is to use assynchronous nature of Qt with signals/slots :-)
SPOILER!
Haven't you heard of making the student to it by brute force before showing them the easy way?
Well, I am not a fan of teaching the youngster about the screwdriver after they broke their fingers with a sledgehammer.
Interested in AI ? www.idiap.ch
Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct -
@Kent-Dorfman said in QSslSocket::readyRead() never triggered with Python server:
@jsulm said in QSslSocket::readyRead() never triggered with Python server:
The Qt way is to use assynchronous nature of Qt with signals/slots :-)
SPOILER!
Haven't you heard of making the student to it by brute force before showing them the easy way?
Well, I am not a fan of teaching the youngster about the screwdriver after they broke their fingers with a sledgehammer.
@SGaist said in QSslSocket::readyRead() never triggered with Python server:
Well, I am not a fan of teaching the youngster about the screwdriver after they broke their fingers with a sledgehammer.
Eh, I wouldn't consider that to be a fair analogy. fork() is easier to implement, and teaches more fundemental theory, while being less efficient.
If you meet the AI on the road, kill it.
-
@SGaist said in QSslSocket::readyRead() never triggered with Python server:
Well, I am not a fan of teaching the youngster about the screwdriver after they broke their fingers with a sledgehammer.
Eh, I wouldn't consider that to be a fair analogy. fork() is easier to implement, and teaches more fundemental theory, while being less efficient.
@Kent-Dorfman agreed, but when you use a framework, learn the framework and what it provides rather than try to make it fit your habits.
Since it's Qt, the networking stuff rarely needs any threading or forking. -
Just being nitpicky, but technically it's not an ethernet receiver. There is no requirement that it have anything to do with ethernet. The SSL connection is over TCP (layer 4) and ethernet is a layer (1/2) service. IP need not be carried over ethernet.
I think you may be making it too complicated by using threads...and I question the need for mutex locks if you get rid of the threads.
If you need to service multiple connections, the long standing UNIX way is to fork a new instance of your program for each connection.
@Kent-Dorfman
Agreed, it could be used with any Data-Link Layer protocol, but in this specific project, it is only used over Ethernet, hence the name choice.I've decided to thread the Sender as a personal challenge, but I understand it's more complicated than it could be, I'm totally fine with it.
As for the Receiver, all messages are received asynchronously (at any given moment, the Rock Pi E, the server, could send a new message on the socket). That is why I decided to thread this bit. The Rock Pi can also send big payloads (100MB) separated in many smaller messages (as it should). Parsing them is too much of load for the signal's thread, so I implemented my own Producer-Consumer structure, which I think is fair enough in this case.
As for the forks, I don't think they're totally appropriate for what I'm trying to achieve. The app's main goal is efficiency and lightness. I will explore this avenue, but I doubt it's the easiest/fastest way to achieve my goals since the app must be usable on Windows and Linux.
Thanks for the advice!
-
I've dig up a little more and found that using the QSslSocket::waitForReadyRead() method 5 secs after sending the message actually returns true. I then read the socket with socket->readAll() and messages have been received (they're valid!). The signal still isn't being triggered though... Must waitForReadyRead be called for the signal to be triggered? I've read that these are separate, but I'm not sure about their behavior...
-
One of the issue is that you have while loop that will block Qt's event loop processing. Don't use such a loop as Qt is an event driven framework. You should implement proper signal and slot handling so that you trigger the next command sending after the last one. You can use a 0 based QTimer for example.
-
One of the issue is that you have while loop that will block Qt's event loop processing. Don't use such a loop as Qt is an event driven framework. You should implement proper signal and slot handling so that you trigger the next command sending after the last one. You can use a 0 based QTimer for example.
@SGaist I'm not totally sure which while loop you are refering to. There's one in the EthernetReceiver::processData() method and one in the EthernetSender::processCommand() method. Both of these methods are called in a separate thread which is woke previously in the EthernetSender::sendCommand(Command) and the EthernetReceiver::socketReadyRead() methods. In both case, the loops are not affecting the return time of the readyRead() signal.
I'm not sure I've understood fully what you're proposing, but let me know if this comment is relevant or not.
-
@SGaist I'm not totally sure which while loop you are refering to. There's one in the EthernetReceiver::processData() method and one in the EthernetSender::processCommand() method. Both of these methods are called in a separate thread which is woke previously in the EthernetSender::sendCommand(Command) and the EthernetReceiver::socketReadyRead() methods. In both case, the loops are not affecting the return time of the readyRead() signal.
I'm not sure I've understood fully what you're proposing, but let me know if this comment is relevant or not.
@ArtiFAS That's one of the issue with the code sample you gave. There's not enough context to fully understand how it is working.
Now the question is: why do you need a separate thread to handle your network connection ? Most of the time there's no need for that as Qt is asynchronous.
