[ previous ] [ next ] [ threads ]
 
 From:  Dave Warren <maillist at devilsplayground dot net>
 To:  A dot L dot M dot Buxey at lboro dot ac dot uk
 Cc:  Richard Davis <richard at bizsyscon dot com>, m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] Monowall in the News.
 Date:  Wed, 03 Aug 2005 10:25:53 -0600
A dot L dot M dot Buxey at lboro dot ac dot uk wrote:

>>This is frequently done when ghosting a ton of computers over a LAN. 
>>Unfortunately it's not practical on the internet.
>>    
>>
>hmm, from my experience of ghosting, you set up an image to be ghosted,
>you get all your clients to be ready to receive the image, then you click
>'start' and the whole lot get ghosted in a one-off process. my awareness
>of several multicast papers is that the image could be sent out on continual
>round-robin - and, in fact, due to some extra features the clients could
>start saving the image at ANY point int he stream, not just from the start block
>- allowing massive files to be sent out as simple, continual 1 or 2mbit multicasts.
>if such a mechanism could be accepted by the main carriers (like is done for MBONE
>and BBC) then a single main multicast site could feed the world with all the
>big images which currently cause such wasteful bandwidth usage - or bring sites
>to knees when updates occur. anyway...the problems live higher up the internet foodchain,
>as it were, as plenty of people have proposed such systems
>  
>
I forget the software used, but one place I consulted (Well, mostly I 
was just there to help out a friend -- They needed to reghost the entire 
company in a 4 day weekend), they had a ghost server that would 
multicast the images in a loop as described above. 

When a client comes online it would send a stream request to the server 
for the image required.  If there was already a multicast stream going 
for that image, the server would reply back with the details and would 
ensure that there was at least one full integration scheduled.  If there 
was no steam going at that time, the server would schedule one to start 
in a few moments.

If a client requests the stream when it's 50% through, the server will 
just continue going where it's at now, then start over and go up to 50%

The end result is that virtually no bytes were wasted if there was only 
one client, but when more then one client was listening then it would 
let you ghost the entire LAN without any performance hit.

The entire server would take up a maximum of 5Mb or so, the more images 
requested at any time the slower they all go, so it was important to 
shut down streams that were no longer required (so that the remaining 
images could finish as fast as possible).

The whole thing made it very pleasant to re-ghost hundreds of systems 
simply by going machine to machine with the boot floppy to start the 
ghosts -- By the time you finished getting each machine started you 
could go back to the first one and it would probably be done and ready 
for the next step.

-- 
"Gee, Bill what do you want to do tonight?"
"The same thing we do every night Steve. Try to take over the world!"