How could I rise to UDP speed ?
-
@Joe-von-Habsburg said in How could I rise to UDP speed ?:
I need take without losing.
Who said that? People demand a lot of bs, when they have no idea how things work. Using UDP without losing packages is like trying to cross a desert without touching any sand...
Either use TCP and accept some drawbacks in performance (due to handshake, flow control etc.) or add your own layer / protocol on top of UDP in your program where you number and count your packages etc etc.
(same is done when using RTPS Wire-Protocol in middleware like DDS. Sender and receiver have internal counters and packages are numbered and much more)@Pl45m4 said in How could I rise to UDP speed ?:
Who said that? People demand a lot of bs, when they have no idea how things work. Using UDP without losing packages is like trying to cross a desert without touching any sand...
yes... I could not explain them.
-
Hello, I'm back again. I have a problem. I'm told that there shouldn't be any packet loss when connecting directly via cable. They say the packet loss is due to me not receiving it. Is this even possible?
-
Hello, I'm back again. I have a problem. I'm told that there shouldn't be any packet loss when connecting directly via cable. They say the packet loss is due to me not receiving it. Is this even possible?
@Joe-von-Habsburg
You could investigate what people have to say about this by a Google search likeis udp still lossless when connected directly by cable:No, UDP is not inherently lossless, even when connected directly by a cable (point-to-point).
While a direct cable connection removes the risks of network congestion from external routers and switches, it does not change the core design of the User Datagram Protocol (UDP). UDP is "fire-and-forget," meaning it provides no mechanisms for error correction, retransmission of lost packets, or flow control
Application-Level Issues: If the application on the receiving end is not reading from the socket fast enough, packets will be lost, regardless of how good the cable is.
Summary
A direct connection makes packet loss highly unlikely, but it does not guarantee it will be lossless. If your application absolutely requires all data to arrive in order, you must implement your own reliability layer on top of UDP or use TCP.
Per some people's comments you may find your situation is pretty reliable, though I would not necessarily count on 100.0%.
If you suspect your (Qt) application is failing to keep up when it should, it would not take you long to knock together a standalone, non-UI, non-Qt C++ application using sockets which is tiny and runs as fast as possible. You could then compare that against your Qt implementation --- even running at the same time as each other or whatever --- to see whether your Qt version keeps up.
-
Hello, I'm back again. I have a problem. I'm told that there shouldn't be any packet loss when connecting directly via cable. They say the packet loss is due to me not receiving it. Is this even possible?
@Joe-von-Habsburg said in How could I rise to UDP speed ?:
I'm told that there shouldn't be any packet loss when connecting directly via cable. They say the packet loss is due to me not receiving it. Is this even possible?
To catch the lost packages, you need to place a funnel and a bucket below your cable so all the data that leaks out is caught in the bucket.
/s
For real:
You lose packages not only because of your transport medium (cable, air, etc...). Adapters, sockets, and other endpoint bottle necks also matter. There is a protocol that takes care of that, your choice (UDP) does not. -
@Joe-von-Habsburg
You could investigate what people have to say about this by a Google search likeis udp still lossless when connected directly by cable:No, UDP is not inherently lossless, even when connected directly by a cable (point-to-point).
While a direct cable connection removes the risks of network congestion from external routers and switches, it does not change the core design of the User Datagram Protocol (UDP). UDP is "fire-and-forget," meaning it provides no mechanisms for error correction, retransmission of lost packets, or flow control
Application-Level Issues: If the application on the receiving end is not reading from the socket fast enough, packets will be lost, regardless of how good the cable is.
Summary
A direct connection makes packet loss highly unlikely, but it does not guarantee it will be lossless. If your application absolutely requires all data to arrive in order, you must implement your own reliability layer on top of UDP or use TCP.
Per some people's comments you may find your situation is pretty reliable, though I would not necessarily count on 100.0%.
If you suspect your (Qt) application is failing to keep up when it should, it would not take you long to knock together a standalone, non-UI, non-Qt C++ application using sockets which is tiny and runs as fast as possible. You could then compare that against your Qt implementation --- even running at the same time as each other or whatever --- to see whether your Qt version keeps up.
@JonB said in How could I rise to UDP speed ?:
If you suspect your (Qt) application is failing to keep up when it should, it would not take you long to knock together a standalone, non-UI, non-Qt C++ application using sockets which is tiny and runs as fast as possible. You could then compare that against your Qt implementation --- even running at the same time as each other or whatever --- to see whether your Qt version keeps up.
Hello, I tested with vanilla C++, again I lost some packages.
@Pl45m4 said in How could I rise to UDP speed ?:
data that leaks out is caught in the bucket.
:D
@JonB @Pl45m4 thank you for try help again.
I have a question. I ask because I do not know why. I can see the lost package in wireshark. why ?
-
@JonB said in How could I rise to UDP speed ?:
If you suspect your (Qt) application is failing to keep up when it should, it would not take you long to knock together a standalone, non-UI, non-Qt C++ application using sockets which is tiny and runs as fast as possible. You could then compare that against your Qt implementation --- even running at the same time as each other or whatever --- to see whether your Qt version keeps up.
Hello, I tested with vanilla C++, again I lost some packages.
@Pl45m4 said in How could I rise to UDP speed ?:
data that leaks out is caught in the bucket.
:D
@JonB @Pl45m4 thank you for try help again.
I have a question. I ask because I do not know why. I can see the lost package in wireshark. why ?
@Joe-von-Habsburg said in How could I rise to UDP speed ?:
I have a question. I ask because I do not know why. I can see the lost package in wireshark. why ?
Did you ever play „Chinese whispers“ ?
If you're the 10th in line, the data is more likely to be scrambled, especially if the 9th person before you is 100% busy spinning in place.
If you listen in, via wire shark, when the data is first whispered, chances are higher you overhear everythingWireshark taps the network stack before the socket receive buffer, there's a whole truck load of software before your program comes into play. OS Buffers, drivers etc
-
@JonB said in How could I rise to UDP speed ?:
If you suspect your (Qt) application is failing to keep up when it should, it would not take you long to knock together a standalone, non-UI, non-Qt C++ application using sockets which is tiny and runs as fast as possible. You could then compare that against your Qt implementation --- even running at the same time as each other or whatever --- to see whether your Qt version keeps up.
Hello, I tested with vanilla C++, again I lost some packages.
@Pl45m4 said in How could I rise to UDP speed ?:
data that leaks out is caught in the bucket.
:D
@JonB @Pl45m4 thank you for try help again.
I have a question. I ask because I do not know why. I can see the lost package in wireshark. why ?
@Joe-von-Habsburg said in How could I rise to UDP speed ?:
Hello, I tested with vanilla C++, again I lost some packages.
I should actually have said you only need C not C++ for a sockets program, so you can keep it minimal. But this is probably not a C++ issue in itself.
I would actually briefly try your standalone test as a Python script, using whatever package they tell you to use for UDP. Python does sometimes have packages which do/know more than you might. If that keeps up while your C++/Qt efforts do not you have a problem which can be addressed; if it fails to keep up with Python and a suitable UDP package then you presumably have no hope.... You can explain your efforts to boss/stakeholder/client sender.
-
I have some good news for now. I think I've solved the problem on a large scale. I changed receive buffer size in socket option. It works for me.
// From _udpSocket.setSocketOption(QAbstractSocket::ReceiveBufferSizeSocketOption, 16 * 1024 * 1024); // To _udpSocket.setSocketOption(QAbstractSocket::ReceiveBufferSizeSocketOption, 1024 * 1024 * 1024); -
J Joe von Habsburg has marked this topic as solved
-
I have some good news for now. I think I've solved the problem on a large scale. I changed receive buffer size in socket option. It works for me.
// From _udpSocket.setSocketOption(QAbstractSocket::ReceiveBufferSizeSocketOption, 16 * 1024 * 1024); // To _udpSocket.setSocketOption(QAbstractSocket::ReceiveBufferSizeSocketOption, 1024 * 1024 * 1024);@Joe-von-Habsburg Ah ha! One of us should have mentioned this when you said about sender packet size :(
-
Hello, I'm back again. I have a problem. I'm told that there shouldn't be any packet loss when connecting directly via cable. They say the packet loss is due to me not receiving it. Is this even possible?
This post is deleted!
