I am doing a little research for an R&D project, and I wanted to see if I could use UDP cast to meet my needs. I just discovered it 15 minutes ago, scoured the site for docs, and read everything i could. So please bear with me :).
I will have to remotely control 15-30 PC's. All will be identical, and each will have a wireless router attached to a lan card (on the computer). Each PC will play video, and may take some basic I/O fuctions in the near future.
The pc's will be located inside of a gondola, like at a ski resort. There will be one computer at the bottom of the gondola line (in the little lift shack) that will be controlling the whole system. This computer will be hooked up to the internet, and can be accessed remotely in order to update the entire system.
It is my impression, that the wifi network may not be able to be completely in touch with each other at all times. Most gondola lines are about 4000-8000 feet in length, but can get as high as 14000 feet long in extreme cases. I understand that I may be limited to a few "hops" over the wifi routers.
Questions:
1) Can UDP facilitate the updating of just certain files (all identical) to all pc's on the network. Say, replace video1.mpg with video1.mpg (a new file)
2) If some pc's are out of range of bottom wifi router, what will happen when the update is attempted?
I don't know if udpcast would fit in your environment in terms of how you hope to remotely control the client PCs. Say if they are running Windows, you would need to reboot them to boot from floppy/cdrom/network to do the update.
Udpcast operates on partitions, not files. But if you wanted to put all of the video in one partition (say E: drive, aka /dev/hda3) it could be updated that way.
Udpcast will timeout after a fixed amount of time if no packets are being acknowledged. Any PCs which are still getting packets will continue after this brief pause to wait for the failing client(s), and the ones failing to get packets will be disconnected from the imaging session. I believe the timeout is 2 minutes, but this is obviously configurable since one can edit the source.
I would have thought people riding in a gondola would look at the marvelous view, not a video?
--Donald Teed
On Mon, 20 Sep 2004, Jeff Gladnick wrote:
I am doing a little research for an R&D project, and I wanted to see if I could use UDP cast to meet my needs. I just discovered it 15 minutes ago, scoured the site for docs, and read everything i could. So please bear with me :).
I will have to remotely control 15-30 PC's. All will be identical, and each will have a wireless router attached to a lan card (on the computer). Each PC will play video, and may take some basic I/O fuctions in the near future.
The pc's will be located inside of a gondola, like at a ski resort. There will be one computer at the bottom of the gondola line (in the little lift shack) that will be controlling the whole system. This computer will be hooked up to the internet, and can be accessed remotely in order to update the entire system.
It is my impression, that the wifi network may not be able to be completely in touch with each other at all times. Most gondola lines are about 4000-8000 feet in length, but can get as high as 14000 feet long in extreme cases. I understand that I may be limited to a few "hops" over the wifi routers.
Questions:
- Can UDP facilitate the updating of just certain files (all identical) to
all pc's on the network. Say, replace video1.mpg with video1.mpg (a new file)
- If some pc's are out of range of bottom wifi router, what will happen when
the update is attempted?
-- Jeff Gladnick
Udpcast mailing list Udpcast@udpcast.linux.lu http://udpcast.linux.lu/mailman/listinfo/udpcast
Quoting Jeff Gladnick jeff@snorhino.com:
I am doing a little research for an R&D project, and I wanted to see if I could use UDP cast to meet my needs. I just discovered it 15 minutes ago, scoured the site for docs, and read everything i could. So please bear with me :).
I will have to remotely control 15-30 PC's. All will be identical, and each will have a wireless router attached to a lan card (on the computer). Each PC will play video, and may take some basic I/O fuctions in the near future.
The pc's will be located inside of a gondola, like at a ski resort. There will be one computer at the bottom of the gondola line (in the little lift shack) that will be controlling the whole system. This computer will be hooked up to the internet, and can be accessed remotely in order to update the entire system.
It is my impression, that the wifi network may not be able to be completely in touch with each other at all times.
This could indeed cause problema. However, it all depends how long those dropouts are.
Most gondola lines are about 4000-8000 feet in length, but can get as high as 14000 feet long in extreme cases. I understand that I may be limited to a few "hops" over the wifi routers.
Questions:
- Can UDP facilitate the updating of just certain files (all identical)
to all pc's on the network. Say, replace video1.mpg with video1.mpg (a new file)
Yes. Udpcast doesn't care what data it sends. These can be whole partitions or disk images, but also other kinds of data: tar or zip files, or even single video files. Booting into the embedded system is only required if you want to clone the OS partition itself. If only a small number of files, that are not critical to the OS need to be updated, you can launch udpcast from the command line, from the currently running system.
- If some pc's are out of range of bottom wifi router, what will happen
when the update is attempted?
If PC's are already out of range when the update is started, the sender will not even be aware of those PCs that are out of range, and happily transfers to the others that are in range.
If could schedule the transmission several time in succession, chances are that you eventually "get" all PC's (they are moving, after all...)
However, a more interesting question is what happens when PCs drop out of range during the transmission. In that scenario, the behavior depends on the mode in which udpcast is being used: 1. In synchronous mode (the default), the sender will just stall the transmission until those PCs come back into range, or until a timeout (several minutes) expires. This could be a problem because by the time the timeout has expired, other PCs may have moved out of range.
2. In asynchronous mode (with forward error correction), there is no feedback from the receivers to the sender. The sender just sends, and those PCs who didn't get the whole transmission will just fail. However, on those PCs, eventually the receiver will time out, and return an error code. With a suitable number of re-transmissions, and with a suitable wrapper scripts, you should be able to manage to get all updated.
Of course, it very much depends on the nature of the outage. Is it like "when the gondolas are near the top station, there is no reception, but it's fine near the valley station", or is it more like "both top and valley have wifi, but there may be some small spots in the middle which don't have coverage". If the latter, there isn't that much of a problem anyways, except for reduced performance. If the former (long stretches without coverage), some planning is required how to schedule the updates.
Maybe the receiver could only be started on those gondolas that are in a suitable position (moving downward toward the valley station) to ensure that they are in range long enough for the transfer. When those are done, another transfer could then be scheduled for the next batch. All of this depends of course on the availability of an easy way to let the software know where the gondola is. Or maybe, wifi coverage itself could be used for this (by registering the time when it became available, and deducing that if it has been available for too long already, it may soon drop out again?)
Alain
------------------------------------------------- This mail sent through IMP: http://horde.org/imp/