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.