10-22-2008 10:26 AM
10-22-2008 10:31 AM - edited 10-22-2008 10:32 AM
At least you know that UDP packets can easily get lost in transmission.
As for your file question:
I would treat all file as binary files.
You could open the file, set file pointer to start, read e.g. 1.5k bytes from the file, encapsulate bytes in a small protocol (e.g. "source ID" "Counter" "DataSize" "Data" ) and send via mUDP.
10-22-2008 12:53 PM
II would advise using TCP if possible. If the problem is that you don't know which devices will be available, you can use UDP in a separate loop to detect other devices in the network. Once a device is detected, it should open a connection to the server and start the file transfer.
If you still want to use your idea, you will need to manage the data transfer and the file writing in each client. Then, if a client misses a packet (e.g. it was lost, the client connected after the transfer started, etc.), it will need to request it from the server.
As for how to actually do it, as Andre mentioned, you can use the file functions to read and write binary files (represented as strings, since that's what you'll use in the UDP functions). Note that in each of the client, you should probably initialize the file to its final size using null chars and then go over it and fill it as the data comes in.
P.S. I'm not a network expert by far, but I'm not sure this will actually reduce the traffic, as a UDP multicast might put more strain on the network than a directed TCP connection.
10-22-2008 01:23 PM
Cross posted to LAVA - http://forums.lavag.org/UDP-multicasting-t12222.html
10-30-2008 05:19 AM
tst wrote:II would advise using TCP if possible. If the problem is that you don't know which devices will be available, you can use UDP in a separate loop to detect other devices in the network. Once a device is detected, it should open a connection to the server and start the file transfer.
If you still want to use your idea, you will need to manage the data transfer and the file writing in each client. Then, if a client misses a packet (e.g. it was lost, the client connected after the transfer started, etc.), it will need to request it from the server.
As for how to actually do it, as Andre mentioned, you can use the file functions to read and write binary files (represented as strings, since that's what you'll use in the UDP functions). Note that in each of the client, you should probably initialize the file to its final size using null chars and then go over it and fill it as the data comes in.
P.S. I'm not a network expert by far, but I'm not sure this will actually reduce the traffic, as a UDP multicast might put more strain on the network than a directed TCP connection.
I've tried to make a VI that reads in any sort of file (binary) and convert it to a string (that I will use for UDP transport later on). But offcourse at the receiver I need to make a new file with this received string.
I can't seem to make this new file. As attachment you'll find a test VI that converts a file to a string, and tries to write that string back into another file on the same computer. For some reason (maybe the null values) the new file is corrupt (I've tried it with .jpg, .docx,...). Maybe I did something completely wrong, but I'm not into file manipulation with LV (yet).
Thanks in advance!
Niels
10-30-2008 05:35 AM
What the message format that you currently use?
You will have to like tst wrote initialise a file on the remote side with NULL values of the same size as the original.
Make sure that the message contains the file pointer at which the data chunck needs to be inserted.
Make sure that when reading and writing the file the LV file IO functions don't append a size.
The first message should be sending the file properties like size.
10-30-2008 05:56 AM
Andre's third point is probably the source of your problem - the write primitive has an input for prepending the size to the data, which defaults to T. You need to wire F into it.
Also, note that by default the binary primitives work with strings. There is no reason to use the array of bytes.
10-30-2008 07:29 AM
Andre's third point indeed was the problem. I've wired it to false and it works fine.
I'll try cutting out the conversion to byte arrays and see if it still works.
Thanks for your help guys, now I can start with the real work !
Greets,
Niels