45 replies to this topic

[moralyan]

Hi everybody

I hope someone can help me. I'm trying to build a client-server file transfer application. The client reads a file stored on a given working station(PC) and sends it to a server installed on another working station for further usage. I am using UDP as the transport protocol. The problem is that my application works perfectly with files whose size is in the range of kilobytes, however when I try to send files whose seize is in the range of megabytes, the application crashes down and the attached error message shows up

I understood that I have to increase the size of both the UDP sending and receiver buffers, but I don't know how to do so. please if you have any idea on how to do so, just let me know
Best regards

Edited by moralyan, 19 April 2012 - 05:31 PM.

[asbo]

Can you send your data in chunks? You really don't want to set your datagram size to megabytes.

[GregR]

UDP does not guarantee ordering, non-duplication or even delivery of "chunks", so you would need to make sure each write contains enough information to completely identify which part of which file it is. That way you could reassemble them on the other side. Even then you may not get them all, so probably want a way to ask for some part of the file to be resent.

These are things that TCP would take care of for you. Do you really need to use UDP?

[Dan DeFriese]

There's a TFTP example on the NI website: https://decibel.ni.c...t/docs/DOC-8301

No need to reinvent the wheel.

[crossrulz]

Here's a KB article on setting the read buffer. We had to do this because the unit we are testing is sending at Gb speeds and we would loose the packets in Windows. It only speaks of the receive buffer, but I imagine the send buffer is very similar if even needed.
Lost UDP Packets at Fast Transfer Rates

The TFTP example looks promising as well.

[moralyan]

Can you send your data in chunks? You really don't want to set your datagram size to megabytes.

honestly i have never read about chunks, could you give me some details please

UDP does not guarantee ordering, non-duplication or even delivery of "chunks", so you would need to make sure each write contains enough information to completely identify which part of which file it is. That way you could reassemble them on the other side. Even then you may not get them all, so probably want a way to ask for some part of the file to be resent.

These are things that TCP would take care of for you. Do you really need to use UDP?

i have built successfully an aplication that transfer files using TCP, however it is really slow, this is why i need to use a faster protocol like the UDP

There's a TFTP example on the NI website: https://decibel.ni.c...t/docs/DOC-8301

No need to reinvent the wheel.

ok you can ask my teacher about that, he insist on building a new application!!

Here's a KB article on setting the read buffer. We had to do this because the unit we are testing is sending at Gb speeds and we would loose the packets in Windows. It only speaks of the receive buffer, but I imagine the send buffer is very similar if even needed.
Lost UDP Packets at Fast Transfer Rates

The TFTP example looks promising as well.

thanks for the link, i have already tried it and actually it can't give a transfer rate more than 2Mb/s, which is far from my goals!!

[Dan DeFriese]

honestly i have never read about chunks, could you give me some details please


i have built successfully an aplication that transfer files using TCP, however it is really slow, this is why i need to use a faster protocol like the UDP


ok you can ask my teacher about that, he insist on building a new application!!


thanks for the link, i have already tried it and actually it can't give a transfer rate more than 2Mb/s, which is far from my goals!!

Sorry I didn't realize this is a homework assignment. In that case, you can learn about TFTP and implement your own solution by reading RFC 783 and RFC 1350. This will also give you an understanding of what chunks are.

Good Luck!

~Dan

[asbo]

i have built successfully an aplication that transfer files using TCP, however it is really slow, this is why i need to use a faster protocol like the UDP
...
thanks for the link, i have already tried it and actually it can't give a transfer rate more than 2Mb/s, which is far from my goals!!

It's incorrect to say that UDP is a "faster" protocol. It is more lightweight than TCP, but that doesn't inherently make it faster - especially in the use case you have, where you'll basically need to handle everything that TCP does automatically (and at a lower level).

Speeds far in excess of 2Mbps are feasible using TCP, so you probably need to take a look at your implementation and maybe talk to your teacher about what you can do to optimize it.

[moralyan]

Sorry I didn't realize this is a homework assignment. In that case, you can learn about TFTP and implement your own solution by reading RFC 783 and RFC 1350. This will also give you an understanding of what chunks are.

Good Luck!

~Dan

thanks a lot for the help, i'll read what you mentioned even thogh i still think the solution resides in increasing the size of buffers!!

It's incorrect to say that UDP is a "faster" protocol. It is more lightweight than TCP, but that doesn't inherently make it faster - especially in the use case you have, where you'll basically need to handle everything that TCP does automatically (and at a lower level).

Speeds far in excess of 2Mbps are feasible using TCP, so you probably need to take a look at your implementation and maybe talk to your teacher about what you can do to optimize it.

i think you are right, and i'll go back to TCP, but i still want to increase the buffers size, how can i do so??

[ShaunR]

Under windows, the default udp datagram size is 1500 bytes (i.e the default MTU). The maximum it can be is 65535 bytes (you can set it to more than this, but it will still be limited to 65k ). This is because the UDP header field is a U16 and cannot represent more than 65k.
UDP, User Datagram Protocol

Edited by ShaunR, 20 April 2012 - 04:45 PM.

[moralyan]

Under windows, the default udp datagram size is 1500 bytes (i.e the default MTU). The maximum it can be is 65535 bytes (you can set it to more than this, but it will still be limited to 65k ). This is because the UDP header field is a U16 and cannot represent more than 65k.
UDP, User Datagram Protocol

so you wanna say that there is no possibility to go beyond transfer rates of 65Kb/s using UDP!!

[ShaunR]

so you wanna say that there is no possibility to go beyond transfer rates of 65Kb/s using UDP!!

No. I'm saying the payload cannot exceed 65k. If you can send 1 payload (of 65k) every 10ms then that would be 6.5 MB/sec

Attached Thumbnails

• 

Edited by ShaunR, 20 April 2012 - 09:27 PM.

[rolfk]

Under windows, the default udp datagram size is 1500 bytes (i.e the default MTU). The maximum it can be is 65535 bytes (you can set it to more than this, but it will still be limited to 65k ). This is because the UDP header field is a U16 and cannot represent more than 65k.
UDP, User Datagram Protocol

And going beyond 1500 bytes MTU is only an option if you are on a controlled network where you do know about all routers involved between the two parties. Once you go outside of that, such as an internet connection, the maximum MTU is entirely out of your hands and going beyond the default of 1500 bytes is really playing chances that the communication will actually work, unless you do a lot extra work in reassembling the incoming packages into the right order on the receiving end. And that is something that is even on embedded devices usually handled much more efficiently by the TCP protocol level, so why go to the hassle of UDP in that case?

As to data transfer of LabVIEW TCP, it has some overhead in its internal buffer handling but I have in the past reached half the bandwidth of the network without to much trouble, as long as you don't do a two way handshake for every packet send. There used to be some challenges in older LabVIEW versions, with LabVIEW simply loosing data or even crashing on heavy network load (supposedly some rare race conditions in its socket handling), but I haven't seen such things in newer LabVIEW versions.

[Phillip Brooks]

You can increase the udp buffer size under windows by accessing the socket.

See my post from the NI forums...

http://forums.ni.com...ows/td-p/483098

[moralyan]

No. I'm saying the payload cannot exceed 65k. If you can send 1 payload (of 65k) every 10ms then that would be 6.5 MB/sec

Brother, this is exactly what i wanna do, I have a 600Mb TDMS file and i need to transfer it as fast as possible. now i understand that the maximum data packet size is 65Kb, which implies that i must devide my 600Mb file into packets of 65Kb each and then send those packets using UDP. My question is: how can i devide my file into packets??

[ShaunR]

Brother, this is exactly what i wanna do, I have a 600Mb TDMS file and i need to transfer it as fast as possible. now i understand that the maximum data packet size is 65Kb, which implies that i must devide my 600Mb file into packets of 65Kb each and then send those packets using UDP. My question is: how can i devide my file into packets??

Just read 65k bytes (or 1500 bytes is better for the reasons Rolf outlined) from the file at a time and write it using the UDP write. However. As GregR stated. It is not guaranteed to be recieved in the correct order, or indeed a chunk to be received at all! So that's not a lot of good for files, but usually acceptable for audio or video where a lost frame or two doesn't matter too much.

The easy solution, as others are saying, is to use TCPIP where all the ordering and receiving reassembly is handled for you (as well as other things UDP doesn't do out-of-the-box such as congestion control, re-transmission of lost packets etc). If you really must use UDP then you will have to code all that yourself (unless missing or incorrectly ordered file chunks is acceptable-for TDMS it wouldn't be). There are a few examples of reliable UDP (RDP). Noteably UDT and NORM. I am not aware of anyone doing this in Labview however, since it is just easier to use TCPIP.

Edited by ShaunR, 21 April 2012 - 02:49 PM.

[moralyan]

Just read 65k bytes (or 1500 bytes is better for the reasons Rolf outlined) from the file at a time and write it using the UDP write. However. As GregR stated. It is not guaranteed to be recieved in the correct order, or indeed a chunk to be received at all! So that's not a lot of good for files, but usually acceptable for audio or video where a lost frame or two doesn't matter too much.

The easy solution, as others are saying, is to use TCPIP where all the ordering and receiving reassembly is handled for you (as well as other things UDP doesn't do out-of-the-box such as congestion control, re-transmission of lost packets etc). If you really must use UDP then you will have to code all that yourself (unless missing or incorrectly ordered file chunks is acceptable-for TDMS it wouldn't be). There are a few examples of reliable UDP (RDP). Noteably UDT and NORM. I am not aware of anyone doing this in Labview however, since it is just easier to use TCPIP.

I do appreciate, and i am with you for the choice of TCP/IP instead o UDP, but unfortunatly, my teacher doesn't do so. He is insisting on UDP!!. Anyway, i have tried what you have suggested, but i got the same errror, and i think it is logical, if the buffer size is only 65Kb or less, how can it handle 600Mb!! what i want to know is what is the code i should use to devide my file into packets of 65Kb, because wiring the 600Mb file directly to the UDP Read VI didn't work. or shall i use a while loop?

[ShaunR]

shall i use a while loop?

Yes.
This is a similar VI that it used in the "OPP Push File" in the LAVA CR.




It opens a file and reads "chunks" that it then sends (in this case) via bluetooth. You need to do the same except with UDP rather than bluetooth..

Edited by ShaunR, 21 April 2012 - 07:05 PM.

[moralyan]

Yes.
This is a similar VI that it used in the "OPP Push File" in the LAVA CR.




It opens a file and reads "chunks" that it then sends (in this case) via bluetooth. You need to do the same except with UDP rather than bluetooth..

thanks ShaunR, i will try this, but could you provide me with more details about "chunks", what are they exactely??

[ShaunR]

thanks ShaunR, i will try this, but could you provide me with more details about "chunks", what are they exactely??

It means a piece. A bit. A portion.......of the file.