@Joe-von-Habsburg said in Take message only 1 port by UDP socket receive:

How can I ignore ?

Look at the QHostAddress and don't process it - there is no other chance except you add some filtering on OS level but Qt can't do anything against it.

@Sajjad-Ali Start here: https://doc.qt.io/qt-6/qudpsocket.html
You will also find links to example applications there.

@timob256 this work

QString data_str = QString::number(data_x)+ " "+QString::number(data_y); out << data_str; qDebug() <<data_str ;

введите сюда описание изображения

@timob256

Perhaps it was necessary to connect
#include <QtNetwork>

previously, the header was without

#include <QtNetwork>

now it looks like this

#include <QMainWindow> #include "qcustomplot.h" #include <QtNetwork> #include <QHostInfo> #include <QNetworkInterface> #include <QUdpSocket> #include <QAbstractSocket> #include <QHostAddress> #include <QTime> #include <QTimer> #include <QVector> #include <QtMath>

However, he does not transmit much data yet ж_ж

If something else sends a UDP datagram to the sub-net IP broadcast address (e.g. 192.168.1.255 on IP subnet 192.168.1.0/24) then any device connected to, and configured for, that IP sub-net should receive the datagram. You need to know the port that the UDP datagram was sent to also.

Assuming your listeneing device is connected to the relevant physical network and has suitable IP address/subnet mask, then all you should need is to QUdpSocket::bind() to your IP and port.

Hi,
@SGaist
@Kent-Dorfman

I tried to google "QUdpsocket priority",
I got many result that discribe my problem but without soultion.

Many peopele have the same problem.

My felling is there is some problem. But i dont have enough knowledge to debug it.

@Lior said in Signal inside readyread of QUdpsocket:

why the UI main thread stoped to respond ? the msleep is in anthor thread.

Because you do it wrong (and I would guess the msleep is not in the thread but in the gui thread) but without code...

Why do you want to "display it in my map using one MapQuickItem only"? You will need to create multiple MapQuickItem instances to display multiple markers on map at once. You can create them statically (if their number is known in advance) or dynamically (if not).

@JonB you might be right.
http://www.informit.com/articles/article.aspx?p=1405552&seqNum=4
in fact I could see that if there is pending datagram, read it, and then again, and as well process after each if statement. Ok. I understand it now.

@Xando On windows, this did not work for me, even fixing the socket options to the windows equivalent. What did work was:

udpSocket = new QUdpSocket(this); groupAddress4 = QHostAddress(multicastAddr); bool result = udpSocket->bind( QHostAddress::AnyIPv4, port, QUdpSocket::ShareAddress | QUdpSocket::ReuseAddressHint);

@gsharma Ok, I forgot to mention my test environment, sorry about that.
Well, maybe it's a good reason to update your Qt version...
Best regards.

@Diracsbracket I think it should, let me try it, thanks you so much for your time!

@ambershark Thank you very much for your help, now it's working, it seems like I was passing the IP argument incorrectly, now I know that I have to send this parameter inside a QT function. thanks!

@juanki sí, de hecho al final encontre que mi error era porque la IP la tenia que mandar dentro de un método de la librería, igual gracias por tu post :)

@M4RZB4Ni said:

Hi
When you dont have
uSocket = new QUdpSocket(this) ;
then
uSocket->writeDatagram(xx
will crash.
as uSocket just point to random location. (dangling pointer)

Next:
QByteArray *priPackNuser; <<< also just a pointer.
You should do ( as @SGaist mention)
QByteArray priPackNuser;
( no *, means its real bytearray, not a pointer to one)
So you change it from heap allocation to stack allocation.

If you dont change to non pointer then you need
QByteArray *priPackNuser = new QByteArray ;
as else its a dangling pointer too!
But no need for pointer to QByteArray here.

@kshegunov said:

I advise benchmarking the code. For one a datagram will always arrive whole (not like with TCP where you can have the message chopped in pieces), but there's a maximum size to it. Also there's no reception notification (like with TCP) as UDP is a "connectionless" protocol. These two things in mind you either send the datagram or not, you can't have anything else returned for the written bytes.

I suspected as much. Good to know.

QByteArray datagram; // ... Insert size checks here as well! PendingCompressedFrame & frame = *reinterpret_cast<PendingCompressedFrame *>(datagram.data()); // No copying, valid while the byte array is still there.

As of yet, the receiver's processing time hasn't been a bottleneck so I haven't looked into optimizing it (it completes in around 0-1ms). Thank you for the suggestion though.

Additionally, why the mutex? What are you protecting with it exactly?

The mutex is not needed there. There's some other data that is being accessed from a DLL from a separate thread, but I should have removed the mutex from the simplified receiver.

One good way to deal with such throughput is to have a dedicated thread for the reception that'll put the received datagrams (no processing) into a thread safe queue (or you can also use a signal-slot connection). From there you can have another thread that orders them (they may not come in the order of sending) and ultimately preparing them for display.

That's a good idea. Keep readyRead() as minimal as possible to get data out of the socket's buffer, allowing more data in.

The biggest question I'm still wondering is the performance of writedatagram. I've been looking into the assorted socket options, but it will take some reading to really understand what's going on with each flag.

OK, I use two sockets now.
On App A I have one socket for sending the broadcast message, and a second one on another port for receiving the answer.
Same on App B. One socket for receiving the broadcast message and a second one for sending the answer on a different port.

Still would be very happy if someone can find a solution for this using only one udp socket.