In message <5.2.0.9.0.20030709102145.00b81700(a)pele.citylink.co.nz>, Richard Nayl or writes:

Don't get me wrong, I'm not anti-multicast. I agree its the most efficient way of distributing a synchronous event. Its just I don't see a lot of synchronous events......

Which brings me back to where I started -- with a bit of relaxation of the "I must see it NOW" requirement (in the order of a few seconds/minutes) and good client software/hardware, you can turn a bunch of not-quite-synchronous viewings into synchronous events. And thus snatch a multicast win, out of the jaws of a watch-now unicast defeat. This is both with "live" things -- which I agree aren't that common -- and also "near release time" viewings of things which aren't live (where you can expect that something which is recently released, and popular, is most likely to be wanted nearer the release time than later, in some sort of half-bell-curve type model).

Its just as the size of "live" viewer base gets smaller, and bandwidth higher, multicasting doesn't seem worth the effort.

Well I've seen approximately three orders of magnitude (powers of 10) drop in the cost of bandwidth/traffic over the last 10 years or so, and it's still at least two to three orders of magnitude away from the point where I'd be willing to say the "cost" of getting multicasting going isn't worth the value of the saved bandwidth. Generally like RAM space, harddrive space, etc, the uses will expand to fill all the available bandwidth, so using it inefficiently isn't exactly desireable.

If I stream an event for say 10 viewers, why should the rest of the NZ net get it sent to them without asking for it.

Umm, that's not how multicasting works (indeed it's the key difference between multicasting and broadcasting). But I think you know that already. Ewen