[Udpcast] updating video files via UDP cast???

[aknaff at lll.lgl.lu]

Quoting Jeff Gladnick <jeff at 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:
> 
> 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)

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.
 
> 2) 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/