Re: Announcement: Multicast WWW (MCWWW) BOF at Memphis IETF

 >I try to multicast Java Applet. But there is a problem because of java
 >langage class structure.

there are two seperate problems

data and code

for (web) data dissemination:
if you are distributing media "near-on-demand" from web servers by
server push to multicast, you can use unrelaible (but hopefully
congestion controlled/rate limited) UDP multicast of HTTP
ranges.....this would then allow local clients or mirror/>cache
servers to unicast fetch in the normal manner any missing pieces....

for (java) code dissemination:
you need a reliable multicast protocol - this is the subject of the
new research group of the IRTF which was announced at the last
IETF....

it may also be addressing the "semi-reliable" problem for data too
since there may be generic solutions better than the simple minded
approach i sketch above...especially since packet loss with multicast
is typically correlated for receivers, which typically means  that any
unciast request for missing pieces is still a burden (and may still
cause the  nicely named "flash crowds", albeit only on partial pages
ratehr than the whole ones, but it would be nice to elimainate the
whole problem properly and so on...
 
 >A sender could send its applet, but this applet will have dependency class.
 >If a receiver have this class in his path, there is no problem (maybe).
 >But if he have not: how this receiver ask the sender for the remainding class?
 >	Unicast or Multicast?
 >	If Multicast, How?
 
 >It is just a question.

its a good one - so you want to distribute code as well as data by
multicasting - well, there is a binary representation for java objects
so you can send them (instead of just applet/class .class files)
but you still need the aforesaid reliable protocol......

for the depending classes, you need a way of naming the classes and
their location i na distributed fashion - the class hierarchy is part
of the solution - you then need a name serveice that maps a piece of
the class hierarchy onto a code repository tree (with a possible
second service mapping the code location onto an appropriate cache
server that hold copies....).......very interesting......afs had some
of the pieces of the solution.......

 jon

Received on Thursday, 3 April 1997 05:43:40 UTC