Subject: Re: comments on simple multicast

From: "Michael D. Myjak" <[email-masked]>
Date: Fri, 01 Jan 1999 12:46:01 -0500

Mark Handley wrote:

> >On Tue Dec 22 15:57:26 1998 Ken Carlberg wrote
> >
> >> in very general terms, MASC (and the other complimentary protocols) involves
> >> the allocation/distribution of multicast addresses.  during this process,
> >> there is a delay and a best-guess engineering incured in this schema.
> >> granted, the delay is small, and the engineering will probably be adequate
> >> for today's commonly used mcast applications.  but there are other
> >> applications that may need to (and indeed do) bypass this process.
>
> Yes, one of the intentions behind the architecture is that those rare
> applications with special needs can bypass
> the-protocol-formerly-known-as-MDHCP and actually be be MAAS's and
> speak AAP directly.  Then, within *very* broad bounds set my MASC,
> they can do their own address management.

Mark,

In a large distributed (perhaps object oriented) immersive  environment, perhaps
hundreds of different mcast addresses would be used.  The organization and usage of
these streams would change dynamically, as the application scenario would dictate.
I can see why these should  be managed by some underlying middleware layer.
However, I would have thought that MAASs would have to be "well known" and perhaps
even registered with the NIC.  This does not strike me as the same kind of service
where an application might request a block of mcast addresses (for some duration),
use, manage and deprecate them.

--
best regards -
Michael D. Myjak, Vice President R&D
The Virtual Workshop, Inc., P.O. Box 98   Titusville  Florida  32781
email: <[email-masked]>  voice&fax:  407.264.0440