LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

UDP Write : overpass the 8192 bytes limit

Hi,

 

UDP Write in LabVIEW returns an errors of we try to send a datagram larger than 8192 bytes.

The LV help for this function explicitly says that this an ethernet restriction.

 

However, according to Wikipedia (https://en.wikipedia.org/wiki/User_Datagram_Protocol), the max theoretical limit for a UDP datagram is 8 bytes for header + 65,527 bytes of data (65,535 bytes in total). However, "the practical limit for the data length which is imposed by the underlying IPv4 protocol is 65,507 bytes (65,535 − 8 byte UDP header − 20 byte IP header)"

 

So why is LabVIEW limited to 8192 bytes ? Is it linked to the winsock library which runs behind the scene?

 

Is it possible to overpass this 8292 bytes limit?

CLA, CTA

View Cyril Gambini's profile on LinkedIn
0 Kudos
Message 1 of 6
(139 Views)

That is a very theoretical limit and only will work on local subnets and even then only sometimes. Most routers and switches will cut those buffers in much smaller packets anyways and while that is no problem for TCP traffic, there is a problem for UDP datagrams as there is no TCP layer to help reassemble those smaller fragments and request resends for missing ones. 

 

https://stackoverflow.com/questions/29055971/change-max-udp-packet-size#:~:text=is%20not%20useful-,S...

 

LabVIEW does not impose that limit itself AFAIK but it is a limit of the underlying WinSock layer.

Rolf Kalbermatter
Averna BV
0 Kudos
Message 2 of 6
(105 Views)

Hi Rolf,

 

Thank you for your input.

I'm currently working on a protocol (read here 'specific data packaging') that can push a lot of data at once (directly linked to the number of signals to share across a distributed network).

So having to write datagrams later than 8192 bytes may happen.

 

We've made some tests with datagrams overpassing the MTU (1500 bytes on most networks). And it seems that the datagrams are cut and reassembled correctly automatically. But I realize now that our tests were performed locally on the same computer. So the MTU is maybe not even respected in that case.

 

So if follow the idea of avoiding a datagram to be cut, it's maximum size should not over the MTU, right ?

CLA, CTA

View Cyril Gambini's profile on LinkedIn
0 Kudos
Message 3 of 6
(91 Views)

If you did only do tests on the same computer with a localhost address, those data packages never even hit the wire but were directly routed in the socket driver through shared memory between your apps. As such no limits whatsoever apply from your network adapter or intermediate routers unless WinSock decides to put arbitrary limits on it to better try to simulate real world conditions. It might do so but I doubt it as the localhost traffic is an inherent feature of any socket library implementation and meant to be as fast as possible since it is often used as local interprocess communication layer, with the additional benefit of simply being able to remote it by supplying a different target address.

 

Only 508 byte package size is actually guaranteed to not cause fragmentation when going over the internet which has an accepted MTU of 576 bytes. This is because an IP header can include so called options and make it take up up to 60 bytes, plus the 8 bytes for the UDP header. In reality there are seldom many options in an IP frame if any so the practical size is more often assumed to be between 508 and 548 bytes since the IP header takes up at least 20 bytes plus the UDP header of 8 bytes.

But higher sizes usually work to, and without fragmentation up to the MTU of your hardware or any intermediate router/switch/modem on the path. Note that the MTU for dialup connection interfaces was usually lower than the 1500 bytes used usually for directly wired network ports (for the IP level frame, raw frame is 1518 bytes).

 

X.25 or ISDN for instance only had an MTU of 576 bytes and if you used a SLIP protocol over a dialup connection it was actually only 296 bytes. PPPoE which is another protocol used for dialup connections but also in the various DSL types of connections has a maximum MTU of 1492 bytes but the effective MTU can be actually much smaller.

 

UDP was not designed to be reliable but fast, by omitting much of the transmission guarantees of TCP. If you happen to send larger packages than what the smallest MTU on the entire transmission link is, you are basically playing roulette as to if the datagram ever arrives at the other side. It still arrives as a whole or not at all, but there is no retry request for missing fragments. The receiver simply throws away any datagram it can not reassemble from the incoming data. That is the (dis)advantage of UDP. If you want to have guaranteed data delivery you need to use the streaming characteristic of TCP. The datagram characteristic of UDP won't give you that.

Rolf Kalbermatter
Averna BV
0 Kudos
Message 4 of 6
(84 Views)

The purpose of the protocol is to share data with the minimum latency possible.

Loosing data is accepted for the moment since the protocol include a sequence number. Lost data can be detected afterwards (without the possibility to retrieve the data, I know). Same thing for message reordering in case packets arrive

 

In loopback mode (localhost), the UDP write really returns an error if the datagram is bigger than 8192 bytes. So indeed I guess winsock do not distinguish localhost and 'network' destination. It just has limit of 8192 bytes internally and applies it.

If I believe the stack overflow link you shared, this is OS related and cannot be changed.

 

So more generally, if I get it correctly, I need to find a way to break the datagrams myself in smaller pieces (settable threshold) to reduce the loss probability.

CLA, CTA

View Cyril Gambini's profile on LinkedIn
0 Kudos
Message 5 of 6
(75 Views)

@CyGa wrote:

 

In loopback mode (localhost), the UDP write really returns an error if the datagram is bigger than 8192 bytes. So indeed I guess winsock do not distinguish localhost and 'network' destination. It just has limit of 8192 bytes internally and applies it.

If I believe the stack overflow link you shared, this is OS related and cannot be changed.


Ohhh it sure does distinguish. But it seems that that 8192 byte limit is a hardwired limit in Winsock for datagrams. And in good Windows manner most likely changeable by setting some registry value somewhere (and the location very possibly can change between Windows versions just to keep it fun).

 

WinSock simply refuses datagrams bigger than that since there is a reasonable chance that it won't arrive fully anyways. As long as you operate on a local subnet this is not such a high chance as you have relatively large MTU of 1500 bytes (or possibly even 9000 bytes with enabled Jumbo frames) but once it hits the big wild internet, odds are generally bad.

 

Adding sequence numbers to your message to at least be able to detect datagram losses after the fact is one reasonable approach. Trying to do your own retransmit request scheme is however likely a waste of time. You basically simply would reimplement TCP light on top of UDP and I can imagine a zillion more satisfying things to do than trying to hack TCP logic.

Rolf Kalbermatter
Averna BV
Message 6 of 6
(59 Views)