> Why? Poor client support springs to mind. I've always wanted to
> have someone throw together a web page that downloads a Java applet
> equivalent to vic/vat/rat/etc., joins the right group, and puts content
> into the face of the clicker, perhaps for a fee. However, in the absence
> of compelling content (sadly we don't have Vint to strip for us :) ), I
> haven't suggested that this be a priority.
I often thought of the same, but the current Java Applet security model
prevents applets from joining mcast groups; or at least did last I looked.
Greg
> Also, not all routers at/near the edge can even do native multicast...
>
> Sean.
>
> P.S.: A long time ago there was a very interesting discussion (probably
> on NANOG) involving Vadim Antonov and many others; the argument
> advanced by Vadim's side (include me here) is, roughly, that if you consider
> multicast to be a degenerate form of caching, where the cache is purged
> immediately after servicing the implicit cache requests made by the
> listeners who have joined below the current router, then native multicast,
> particularly reliable native multicast, is being approached in fundamentally
> the wrong fashion. In other words, rolling (maybe short term) content
> caching into (some) routers is likely to be a more useful generalized
> service than deploying actual native multicast, all while being able
> to reuse some join/prune, SA and RPF state handling to optimize the
> "network-based Content Distribution Network" (to use a set of buzzwords).
>
