[Q] multicasting product ?

[Dave Dykstra]

I see this has just been announced on freshmeat.net as "multi-rsync" and
the program is called "mrsync".  Perhaps if it incorporated use of the
--write-batch and --read-batch options of rsync (once they're fixed) it
could do the rsync-algorithm based transfers that way.  My first
impression, though, is that this program would be useful independent of
rsync and that it would make more sense to keep them separate and to have a
script that ties the two together.  Oh, I see that by default the program
uses rsync to find which files need to be copied; that doesn't seem
necessary because again I would think that could be easily done with a
script and a -f option, but maybe there's some advantage that I'm
overlooking.

I was envisioning a user interface that had rcp-like or rsync-like command
line syntax but which could list multiple host sources or destinations,
perhaps comma-separated.  I suppose that could be pretty easily written
with a script too, but it seems to me like an intuitive default user
interface.

Also, hopefully somebody will turn this into a full-blown traditional open
source project based on configure, man pages, a home page, etc.   A home
on sourceforge.net or something like that might be a good idea.

- Dave Dykstra

On Thu, Dec 20, 2001 at 03:51:49PM -0500, HP Wei wrote:
> 
> >> But, as this send whole files, I'm a little bit irritated about the name
> >> "mrsync" - wouldn't mrcp or mtftp be better?
> >Or "mrdist".  
>    
>     I agree that mrcp (or mrdist)
>     is perhaps a name that more adequately
>     captures the functionality of this code at this moment.
>     
>     If this code is really useful in general, 
>     and it depends on where the code might be going,
>     I will wait for the next
>     major revision to use a more appropriate name.
>     
> >Maybe they hoped to put in the rsync algorithm into
> >eventually, but it seems to me that it would be very difficult to robustly
> >implement the rsync algorithm over multicast, because each receiver could
> >conceivably require different blocks to be sent. 
> 
>   Yes, this is indeed not easy.
> 
> > In practice, however,
> >this will be mostly be used for mirroring so all the receivers should
> >normally have the same files to begin with, and maybe they could optimize
> >it for that case and just have reduced performance for the unusual case.
> 
>   This is one direction this code can be going, at least at our site.
>   (Our machines, except the master machine,
>    are supposed to be in the same state all the time!)
>    
>   So, incorporating the rsync algorithm will improve the performance.
> 
> > but I think there'd need to be some way of detecting and
> >supporting the receivers that aren't identical.
>  
>    This will be a good problem to think about! 
> 
> >> But otherwise this could be exactly what I need.
> >> Please let me know as soon as this is available somewhere as GPL or BSD or
> >> similar license!
> 
>    As soon as our manager clarifies certain copyright issues, 
>    I can put the codes somewhere.
>    He just informed me that
>    we are looking at around next week or Jan 1.
>   
> Happy holidays,
> HP