Re: Multicast
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Multicast



Okay, so signed applets work? Good.

Thanks,
Greg

On Wed, 7 Mar 2001, Marshall Eubanks wrote:

> Greg;
> 
> The multicast test button we wrote :
> 
> http://www.multicasttech.com/mt/
> http://www.on-the-i.com/mt/test_ns.html
> 
> is a Java applet, and it joins a group.
> 
> The secret was in getting the right certificates and authorizations. This
> seems to still be the problem with the Mac.
> 
> Marshall
> 
> Greg Shepherd wrote:
> > 
> > > 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).
> > >
> 
> -- 
> 
>    Multicast Technologies, Inc.
>    10301 Democracy Lane, Suite 410
>    Fairfax, Virginia 22030
>    Phone : 703-293-9624          Fax     : 703-293-9609     
>    e-mail : tme at on-the-i.com     http://www.on-the-i.com
> 




Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.