[Private email being brought back on-list.] Alain Knaff wrote: I understand the command just fine. I didn't understand the *reponse*. This is completely unclear, fwiw. 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. 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. 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? I noted that in the documentation. It will be a while before these machines are shipped out. I'm still in the evaluation phase. [...which appear to be dead ports on a switch...] 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