[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