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

Christopher Curtis chris.curtis at riptidesoftware.com
Sat Oct 18 21:32:16 CEST 2003


[Private email being brought back on-list.]

Alain Knaff wrote:

> On Saturday 18 October 2003 00:39, you wrote:
>>Alain Knaff wrote:
>>>On Friday 17 October 2003 02:37, Christopher Curtis wrote:
>>>
>>> ssh udp-receiver -p 9002 -f bar ... >stdout.log 2>stderr.log
 >>
>>I didn't understand this response at all,
> 
> This is a Unix command that allows you to "remotely" connect from the

I understand the command just fine.  I didn't understand the *reponse*.

>>I am correct in stating that udpcast
>>does not guarantee delivery by requesting resends for missed packets
>>through the return communication channel, yes?
> 
> No.

This is completely unclear, fwiw.

>> Your comment made about
>>not binding to the multicast address would indicate further problems
>>with guaranteed delivery.
> 
> Huh? Do you mean the --mcast-addr and --mcast-all-addr flags, which
> are necessary for operation in a WAN? Yes, these settings are indeed
> somewhat fiddly, but they do not force you to use the --async mode.

Actually, I was referring to this:

/**
  * Set socket to listen on given multicast address Not 100% clean, it
  * would be preferable to make a new socket, and not only subscribe it
  * to the multicast address but also _bind_ to it. Indeed, subscribing
  * alone is not enough, as we may get traffic destined to multicast
  * address subscribed to by other apps on the machine. However, for
  * the moment, we skip this concern, as udpcast's main usage is
  * software installation, and in that case it runs on an otherwise
  * quiet system.
  */
int mcastListen(int sock, char *ifname, struct sockaddr *addr) {


My systems will not be "quiet", nor are they used for "software 
installation", and picking up random pcakets and inserting them into the 
files I am distributing would be a very bad thing.  This furthered my 
belief that udpcast didn't do any checking for things like out of order 
or retransmits.

> You can make a small script that starts the various udp-receivers (via
> ssh) and then the udp-sender, and then put that script into a cron
> job.

Well, knowing this now, I see that two days' worth of my work was for 
nothing ... unless I can find an alternate use for it like server crash 
recovery.  But even then, unicast is probably best in that case.  Hmm.

> The --nokbd and --autostart flags are useful for such operation.

I chose '--full-duplex --nokbd --min-clients $ready --max-bitrate 1m'.

The max bitrate was so I can roughly simulate the frame.  How does 
udpcast maintain integrity when --full-duplex is chosen, as the 
documentation states that it doesn't wait for an acknowledgement before 
continuing transmission?

> The only difference is a difference in network distance: most current
> users use udpcast on a LAN (traffic needs to cross no routers),
> whereas you seem to plan a usage on a WAN. That is fine, the only
> difference is that in such case some tweaking with the mcast-addr and
> --mcast-all-addr settings might be needed to help the multicast
> traffic traverse the routers.

I noted that in the documentation.  It will be a while before these 
machines are shipped out.  I'm still in the evaluation phase.

>>I'm having (what I hope are) some network problems; the code runs
[...which appear to be dead ports on a switch...]
>>beautifully on my local machine.  However, I'm still looking for
>>something a bit more off-the-shelf, if anyone has any pointers...

udpcast may be the answer.  I'm going to set my client/server code aside 
for the time being.  If I find I need it, I'll enhance it a tad to make 
it more bittorrent-like, since it's so close.

Chris



More information about the Udpcast mailing list