LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

file transfer using UDP protocol

I'd say you do have a race condition between your UDP send and your UDP receive.

 

Your sender is reading the file and banging out the bytes as fast as it can.

 

Your receiver is receiving them and writing them out to a file.  But if that 2nd packet of data comes in before the reader has a chance to write out the first packet and come around to the UDP receive again, that packet is going to be lost.

 

The reason is works with execution highlight turned on in the sender is that you've slowed it down enough that it gives the receiver a chance to write the data and get back around to wait on the next UDP packet.

 

Put a wait statement in the sender and it will probably work better than it is now.

0 Kudos
Message 31 of 42
(1,177 Views)

You really need to prepend the portion size to each sent segment. Currently, the client cannot tell where the file name ends and where the data starts.

 

Prepend a 4byte "size data" to each segment. Make it I32 and for example make it negative for the file name so the server can distiguish it from a data segment. Define some special codes, e.g. "-1" to signal that the end of the file has been reached. On the server side, read four bytes, cast to a I32 number, and read the indicated number of bytes in a second operation. Make the loops stop when the end of the file is reached on both sides. There is no use continuing the loop at that point.

 

You also have the function of client and server reversed. Typically, the server is waiting for a connection and the client is initiating the communication (even though in your case you could argue that the client is "serving" the data. I argue that this is wrong terminology. Your client is simply uploading to the server!).

 

Also, please don't maximize all windows to the screen. This is very annoying and give me tunnel vision. Typically it is much easier to program if you can look at both diagrams at the same time.

 

Again, as I already said numerous times, this is a useless execise, because UDP is the wrong tool. Why waste our time and effort?????

0 Kudos
Message 32 of 42
(1,170 Views)

Now it works, yupi, Thank you all guys 🙂 even though the file reaches the other station corrupted, but it is okey, i consider that as an achievement, this is my first success!! now the size of the recieved file is exactely the same as the sent file, but it is corrupted, and i guess this is due to packets duplication or miss-order, to overcome this problem i tried to use a queue but the results were not what i expected, here is the code i used

Download All
0 Kudos
Message 33 of 42
(1,156 Views)

That queue makes absolutely no sense.

0 Kudos
Message 34 of 42
(1,154 Views)

To use a queue, you would need to have two loops on the receiving end: one to simply read the data from the network and push it into the queue, and a second, independent loop that will read the queue and write it to the file.

0 Kudos
Message 35 of 42
(1,147 Views)

Thank you altenbach for the hint, i will try to do that 🙂

0 Kudos
Message 36 of 42
(1,120 Views)

This is clearly turning out to be WAY easier and more straightforward than TCP. I don't know why people haven't been doing it this way since UDP was first invented. Those fancy-schmanzy engineers coming up with all sorts of protocols. pshaw.

Message 37 of 42
(1,111 Views)
0 Kudos
Message 38 of 42
(1,104 Views)

@MarcoMauri wrote:

There's somebody else trying to achieve the same goal!

 

http://social.msdn.microsoft.com/Forums/eu/netfxnetcom/thread/18bfc1bd-6f39-465e-aae3-f455bfd8d47b

http://stackoverflow.com/questions/7603591/udp-file-transfer-yes-udp

 

 

Marco


Probably same homework problem year after year.

0 Kudos
Message 39 of 42
(1,101 Views)

It is not worthless. It is a good academic discussion and will give the student a solid understading of all the issues involved when trying to transfer a large amount of data, and also an appreciation of the of the geniuses that devised these protocols in the first place. 😄

 

Hopefully, this thread will serve as a good reference so we never need to have this discussion in the future. 😉

0 Kudos
Message 40 of 42
(1,094 Views)