1

I'm really going crazy over this and I hope somebody has an answer... I do encounter a strange problem with QUdpSockets and the Signal and Slot Connection. I'm receiving small data packets (64 bytes) at 3 different UdpSockets with 100Hz without any processing afterwards. The Signal<-> Slot Connection for reading out the data seams to work completly fine on different laptops, but not on the pc it is supposed to run in the end, which has way more processing power than the laptops.

I'm running the same code on every machine with the same setup. The Problem is, the recvEvents are somehow being queued and delayed up to several seconds on the pc, but not on the laptops. At first I thought It would be a network issue, but I already tried different network cards/switches etc.. and several other things. The only thing that helped is changing the receive code from signal<->slots to another thread with std::thread, so it definitely has to do something with the connection from the readyRead signal.Some Code: 

connect(&udpSocket, &QUdpSocket::readyRead, this, &DataController::handleData);// Called with 100Hz
void handleData(){     //This function call is beeing delayed/queued....
    udpSocket.readDatagram(&data,datasize);    
}

My Question:

  1. Is there any limit of Events/seconds which can be handled?
  2. Do you have any suggestion where I can look for errors or how to speed up the QEventLoop?

Im Running: Win10 Pro, VS 2017 64bit,Qt 5.11.2

BR mike

nick_g
  • 489
  • 1
  • 7
  • 15
jmg
  • 33
  • 1
  • 6

1 Answers1

1

Obviously, with slower computers you always have only one datagram waiting for reading. With faster computer you may have received more than one by the time you are in your slot reading. You should always read all pending datagrams when you receive readyRead signal. You can use QUdpSocket::hasPendingDatagrams for that.

void handleData(){
    while (udpSocket.hasPendingDatagrams()) {
        // clear data buffer
        udpSocket.readDatagram(&data,datasize);
        // process received datagram before reading next...
    }
}
talamaki
  • 5,324
  • 1
  • 27
  • 40
  • hi! thanks for your answer! You are right I didn't include the check for pending datagrams in this part of the code and this could be a reason for the delay, I'll update the code tomorrow and hope that this caused the delay! But for me your answer is counter intuitve. I don't understand why the slower computer only has one datagram waiting for reading, since I would espect that the data is piling up in the socket which should not be happening on the faster machine since it is checking the slot more frequently? – jmg Oct 15 '18 at 19:02
  • I think the reason is you only get readyRead signal again when you have read all datagrams that were available at the time of previous readyRead. So faster computer is waiting for you to read, you are just lucky slower computer stays in sync – talamaki Oct 15 '18 at 19:09