QUdpSocket missing packets when connected to local switch to rasberry pi

sasanka

Hello Everyone,

I have made a Qt desktop application that receives Udp datagrams locally from a network switch that is directly connected to a raspberry pi that transmits Udp data-grams at higher rate. What i observe is my Qt application periodically misses the packets when i scroll my mouse over the application or in some cases for unknown reasons just misses the packets.

I also used wireshark on the receiving port and i see that i receive all packets from raspberry Pi. I also included a counter in the data packet to check if i missed any packet and it reports packet missing every 2 seconds or 5 seconds randomly. Is there any efficient way to design the code for my Udp Datagrams thanks. I am also sharing my code below.

/The code used to create socket and connect to readyread/
bool UdpComm::createSocket(QString portNo)
{
bool success=udpSock->bind(QHostAddress::AnyIPv4,portNo.toUShort());
if(!success)
{
qDebug()<<"Unable to bind address with port";
return success;
}
udpSock->setSocketOption(QAbstractSocket::ReceiveBufferSizeSocketOption,4000);
connect(udpSock,SIGNAL(readyRead()),this,SLOT(readDatagrams()),Qt::DirectConnection);
return success;
}

/Code used to read datagrams/
void UdpComm::readDatagrams()
{
while(udpSock->hasPendingDatagrams())
{
QByteArray buffer;
buffer.resize(udpSock->pendingDatagramSize());

QHostAddress sender;
quint16 senderPort;
udpSock->readDatagram(buffer.data(), buffer.size(),&sender, &senderPort);

if(!buffer.isEmpty())
	{
        parseData(buffer);
	}
}

}

jsulm

@sasanka UDP actually doesn't guarantee that all datagrams arrive.

JonB

@sasanka
As @jsulm has written, the point of UDP is precisely to allow clients (conceptually, actually servers!) to miss packets, for whatever reason. If you want reliable, non-drop connections that's what TCP/IP is for.

Having said that: remove your parseData() call from readDatagrams(). Any difference in how many it loses?

sasanka

@JonB i tried removing it and append the buffer to a QList called dataGrams.
if(!buffer.isEmpty())
{
mutex.lock();
dataGrams.append(buffer);
mutex.unlock();
}
Parallely i run a thread that takes in data from this list and see if any datagram is missing.
The strange thing i find is, if i click with mouse on the title bar of my application, the data loss happens.
It also happens when i scroll my mouse continuously on a web browser(Chrome).

JonB

@sasanka
You have not stated whether it does not lose datagrams under whatever circumstances.

Anyway, I don't know, maybe your Qt app is too busy servicing events when you perform certain UI operations.

Either way, as I said, UDP is not the way to go if you cannot afford dropped packets.

sasanka

@JonB Thanks for the info. Yeah probably TCP is the only way that would workout for reducing packet loss.
Though i tried an exercise using threads. I sent the operations performing under UDP and queuing the datagrams to a separate thread. Also i use another thread to handle this queue. This way i could at-least avoid packet loss due to mouse clicks on the title bar of application.

What i observe is when the mouse pointer changes its icon while i scroll, there are one or more UdpDatagrams missing. If i don't do any movement with mouse(since the icon does not change) packet loss is not observed.

sasanka

I also tried to create a Qt console application. Using the same method of threads, just to see if it makes any difference without the UI part of the application. But to my surprise the packet loss is observed exactly at the movement when the mouse pointer changes its icon when i scroll the mouse. Do you think i need to explicitly disable any feature that handles this mouse pointer in my application so that i don't see this behavior.
Thanks in advance.

sasanka

Finally found the solution. I modified the udp buffer to a very large value as mentioned here... http://thewowza.guru/how-to-increase-udp-buffers-under-windows-os/ using setsocketoption to about 1250000 and voila! it works with out any packet drops. Finally relieved :)...