On Sunday 15 June 2003 20:31, Gianni Minetti wrote:

Hi to everybody.

I understand that udpcast guarantees the integrity of the transmitted data through FEC redundancy code model but how can one be assured , beside integrity, also of consistency of the transmitted data, defining consistency as the property the all the hosts being part of the multicast group have received the data?

In its default mode (LAN), every "slice" is acknowledged by all hosts, which allows the server to be sure that all data has been received. If data has been missed, it is retransmitted.

If a receiver is _very_ slow to answer, or still hasn't got all packets after the umpteenth retrial by the server, the server will "drop" him, in order to allow the transmission to go on for the others. This is useful for cases where one receiver is crashed. In that case, the dropped receiver will miss all data transmited from that point on (however, the timeout is several minutes...)

There is no CRC included at the application level, thus integrity need to be enforced by the lower level protocols (IP, Ethernet). However, in serveral years of operation of udpcast, there is no known incident where data got corrupted during an udpcast transfer (on 100 Mbps or 10 Mbps Ethernet).

In FEC mode, there are no acknowledgements. In the event of packet loss, the FEC packets allow to reconstruct any lost packet (if less packets have been lost than there are FEC packets). If more packets are lost than there are FEC packets, the same thing happens as with a "dropped" receivers in LAN mode: the receiver misses all the rest of the transmission. Hence it is important to tune the FEC parameters in such a way as to cover the physical packet drop characteristics of the medium used. These parameters can either be found out by trial and error, or by probabilistic calculations.

In FEC mode as well, there is no CRC. FEC only recovers lost packets, not corrupted packets. It relies on CRC's being implemented by the lower level protocols. FEC mode has been used much less than LAN mode, and hence I won't make any bold claim on how well this "no corruption" hypothesis holds up in practice in FEC mode...

I mean, if my multicasting model is composed of N host and I schedule to send a different file every T minutes, how can I detect the condition of D hosts not reachable for a time >T (tahr result in data copied only on N-D hosts)? Should I check the 'health' of all my N hosts before to run udpcast using icmp?

If you have a return channel (such as on a LAN), I'd suggest not using asynchronous mode. In that case, all slice of data needs to be acknowledged before the next is send. If your hosts are only unreachable for short amount of time (less than a minute), this should work out ok. If more, the receivers could be dropped due to the timeout mechanism.

If you have no return channel (such on a satellite transmission), asynchronous FEC mode is appropriate. But in such situation, you wouldn't have icmp either...

For the application I've in mind it's very important to know what has or hasn't been delivered to whom so, I would like to encourage everyone who has had a similar problem or has some idea how to cope with.

It might be useful to implement some after the fact checking of file reception (i.e. periodically all receivers are polled to send back a list of files they received with their sizes; and if some have not been received or are too short, retransmit them using udpcast)

Thanks a lot in advance for your suggestions.

Regerds,

Gianni

Regards,

Alain