How could I rise to UDP speed ?

Joe von Habsburg

I have data with UDP and I HAVE TO USE UDP, I take bytes from another client. Other client send nearly 500KB-1MB in 1 packet but I take 1460B in 1 time. So I take bytes in 300-600 step. That is so slow for me.

Client send packages every 10ms but I could not take. I use gigabit ethernet port.

Is there any advice or opinion?

Joe von Habsburg

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);

Kent-Dorfman

Actually you don't "take" bytes from the client. The client sends them and you read whatever is available...and therein is the problem. extremely large UDP packets stand less chance of being delivered properly because there is no guarantee of delivery.

Joe von Habsburg

@Kent-Dorfman Thank you for your reply

I know bro, I wonder, is there any option? any way ? or should I add like id each package ? that will change my all code setup. If I could that without change code, it is ok for me, but It seen I will change...

SimonSchroeder

@Joe-von-Habsburg said in How could I rise to UDP speed ?:

or should I add like id each package ?

Yes, definitely. Even in perfect condition the packets will arrive in any order. If you need a specific order, you need to make sure that you know the order yourself. TCP on the other hand will take care of exactly this (and also that packets don't come in too fast). Basically, you need to put a protocol on top of UDP.

Joe von Habsburg

@SimonSchroeder said in How could I rise to UDP speed ?:

you need to put a protocol on top of UDP.

Thank you for reply

Joe von Habsburg

@SimonSchroeder I have a question for you bro.

I have a array

QVector<float> list(100);

// count = data.size()
void dataReceive(int startIdx, int count, QVector<float> data){
     for(int i = 0, j = startIdx; i < count; i++, j++){
            list[j] = data[i];
     }
}

// They came several times
dataReceive(0,10,[...]);
dataReceive(10,10,[...]);
dataReceive(20,10,[...]);
dataReceive(40,20,[...]);
dataReceive(60,40,[...]);

But I could not take between 30-40 indexes range may be 20 seconds. Something happend there however I lost data and could not see. What should I do ?

Do you have any advice ?

JonB

@Joe-von-Habsburg
You are aware, aren't you, that using UDP you may always lose data packets? Apart from the crazy time issue, you will never reliably receive all data sent by the other side, does whatever you do with the data not care about this?

Kent-Dorfman

you guys are still skirting around the main issues. OP says single UDP "packet" is 0.5-1MB in length. Of course that is impossible with UDP so we're not getting the strait story.

Does op have control of the code that makes up the sender, to make sure it is "correct"?
Is OP doing the amateurish thing of using timeslice based protocol over IP network?...big no-no!
Is OP relying upon link-layer fragmentation across a network they do not control?...all bets are off!
is the data even suitable for UDP transport?...periodic burst data that is only relevant within that period

There are too many unknowns to do other than WAG.

goldenhawking

If you use windows, REMEMBER Increase UDP Socket Cache for both side ( sender, receiver):

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AFD\Parameters]
"DefaultReceiveWindow"=dword:00100000
"FastSendDatagramThreshold"=dword:00002800
"DefaultSendWindow"=dword:00100000

Turning Ethernet MTU = 9000.
Cut big package to subpacks, with header, less than MTU.

By the way, ZeroMQ may be another choice.

Joe von Habsburg

@JonB said in How could I rise to UDP speed ?:

You are aware, aren't you, that using UDP you may always lose data packets?

Yes I know why everyone repeat that ? I have to use UDP and I need do not miss. Yes I know again, It is impossbile. But I did not choose that (TCP/UDP)...

@JonB said in How could I rise to UDP speed ?:

Apart from the crazy time issue, you will never reliably receive all data sent by the other side

I add crc and some variables like index and count, you can see on my example.

@JonB said in How could I rise to UDP speed ?:

does whatever you do with the data not care about this?

If somewhere updated and somewhere do not, I use same array, code work ok, but when somewhere do not update in array yes I loss some future.

@Kent-Dorfman said in How could I rise to UDP speed ?:

you guys are still skirting around the main issues. OP says single UDP "packet" is 0.5-1MB in length. Of course that is impossible with UDP so we're not getting the strait story.

No I did not say like that. I take from client 0.5-1MB data yes but, it is splitted.
@Joe-von-Habsburg said in How could I rise to UDP speed ?:

I take 1460B in 1 time. So I take bytes in 300-600 step.

@goldenhawking

Thank you for reply.

Thanks everyone for try help. I know, I want imposible thing, but that it is not my choose.
@goldenhawking @JonB @Kent-Dorfman @SimonSchroeder <3

Topic has been closed.

JonB

@Joe-von-Habsburg said in How could I rise to UDP speed ?:

Apart from the crazy time issue, you will never reliably receive all data sent by the other side

I add crc and some variables like index and count, you can see on my example.

How does that help? If you understand UDP you know that makes no difference. You use UDP when you don't care about losing some data. So long as that is acceptable you are OK.

J.Hilk

There were many valid answers given to your topic and it's rather rude to the people who took the time and answered and rude to potential future visitors to simply delete this topic.

therefore I restored it.

You're essentially trying to put diesel into a petrol engine — UDP and TCP exist for fundamentally different reasons, and fighting that is working against the protocol, not with it.

UDP is designed to be fast and fire-and-forget. It deliberately has no delivery guarantee, no ordering, and no flow control. That's not a bug — it's the entire point.

What you're trying to achieve — receiving lossless megabytes of data reliably — is exactly what TCP was designed for. The moment you start thinking "I need to ask the sender to retransmit missing datagrams", you are reinventing TCP on top of UDP, and you will do it worse than the OS already does it for you.

SimonSchroeder

@J.Hilk said in How could I rise to UDP speed ?:

you are reinventing TCP on top of UDP, and you will do it worse than the OS already does it for you.

Well, it totally makes sense to reinvent TCP on top of UDP. The major problem of TCP is that it starts with really slow speeds and then gets faster until one of the two sides cannot handle the speed anymore. And then it drops back to the really slow initial speed and the whole game repeats. This is why QUIC was invented which is based on UDP. You can definitely do better than TCP (at least for speed).

J.Hilk

@SimonSchroeder Sadly I have 0 experience with QUIC, so I take your word for it ^^
A quick google search shows it was "invented" in 2012, which is already 14 years ago... dear god I'm getting old!

Joe von Habsburg

@SimonSchroeder said in How could I rise to UDP speed ?:

Well, it totally makes sense to reinvent TCP on top of UDP.

I do not want to like that but, I have to.. I have to use Udp, I have to use like tcp because, I have to know each datagram what... Because I receive list, every datagram carry some part of list, where is that start end end. So, I have to use like tcp...

@SimonSchroeder said in How could I rise to UDP speed ?:

QUIC

I have not no idea for that.

@J.Hilk said in How could I rise to UDP speed ?:

dear god I'm getting old!

me too brother

JonB

@Joe-von-Habsburg said in How could I rise to UDP speed ?:

I have to use Udp

OK, then why is it so hard for you to confirm (or deny) what we have been saying: is your "client" program OK with missing/losing some packets? If you want reliable --- no packets lost --- then you are going to have problems using UDP.

Pl45m4

@Joe-von-Habsburg

If your point / use case is data streaming / data distribution... maybe look into some middleware like MQTT or DDS...
AFAIK both are able to send via TCP and UDP, but most libraries/implementations have their own QoS, which will handle lost packages for you (and resend them) even if you chose UDP transport.

Joe von Habsburg

@JonB said in How could I rise to UDP speed ?:

why is it so hard for you to confirm (or deny)

I know man, you are right, just, I need take without losing. I wondered is there any way. If I give bad feeling to you, I am sorry.

@JonB said in How could I rise to UDP speed ?:

have problems using UDP.

yes

@Pl45m4 said in How could I rise to UDP speed ?:

ome middleware like MQTT or DDS...

Thank you for your reply.

JonB

@Joe-von-Habsburg said in How could I rise to UDP speed ?:

I know man, you are right, just, I need take without losing. I wondered is there any way. If I give bad feeling to you, I am sorry.

It's OK. Just according to me if you are only offered UDP (no TCP) you cannot guarantee to "take without losing". That is my understanding. So I do not think there is a way, if it is only offering UDP it is intended to allow for losing. I will say no more. Good luck.

Pl45m4

@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)