![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
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.