[Udpcast] Reliable multifile transfer over slow links, downed hosts

Dave King daveking at aspsys.com
Sat Oct 18 01:36:00 CEST 2003


On Fri, 2003-10-17 at 16:39, Christopher Curtis wrote:
> Alain Knaff wrote:
> > On Friday 17 October 2003 02:37, Christopher Curtis wrote:
> > 
> >>scenario is basically this:  I need to reliably transfer large files
> >>(large as in >2GB) to multiple hosts over a slow WAN.
> >>
> >>What I would ideally want is something like the following:
> >>   'N' clients, each running a daemon (or inetd...)
> >>     Server Process connects via TCP to each client
> >>     Server tells client "Listen on Multicast port <foo>"
> >>         "I am going to send you XXXX bytes"
> >>         "Save this in a file called <bar>"
> > 
> > 
> > You could set up something like this with ssh starting udp-receivers
> > at the various "clients":
> > 
> >  ssh udp-receiver -p 9002 -f bar ... >stdout.log 2>stderr.log
> 
> I didn't understand this response at all, so I reread the documentation 
> and dug around the sources some.  I am correct in stating that udpcast 
> does not guarantee delivery by requesting resends for missed packets 
> through the return communication channel, yes?  Your comment made about 
> not binding to the multicast address would indicate further problems 
> with guaranteed delivery.

	Alain was describing an easy method for you to try out UDPcast by
starting the receiver on your multiple clients and logging the results
for analysis.

	Yes, UDPcast is suited to your application. The default bidirectional
mode will retransmit missing data, and is reliable and
bandwidth-efficient. The unidirectional mode with FEC may be more
time-efficient in your WAN if you tune it. UDPcast is not hard to use
but will require patience with the documentation. I would definitely try
it for your application, but it sounds like you may be happier with your
own implementation.




More information about the Udpcast mailing list