CU-SeeMe and the Multicast backbone
CU-SeeMe and the Multicast backbone
From the MBONE FAQ: the MBone is a virtual network that has been in existence since early1992.
It was named by Steve Casner of the University of Southern California Information Sciences Institute and originated from an effort to multicast audio and video from meetings of the Internet Engineering Task Force. The MBone shares the same physical media as the Internet.
It uses a network of routers (mrouters) that can support multicast.
These mrouters are either upgraded commercial routers, or dedicated workstations running with modified kernels in parallel with standard routers.
Given adequate network bandwidth, you next need a designated MBone network administrator.
Working part-time, it typically takes one to three weeks for a network-knowledgeable person to establish MBone at a new site. Setup is not for the faint of heart, but all the tools are documented, and help is available from the MBone list.
Expect to spend some time if you want to be an MBone user.
It is time-consuming because learning and fixing are involved and because it is lots of fun! You should read the FAQ a few times, ensure that software tools and multicast-compatible kernels are available for your target workstations, and subscribe to the mail list in advance to enable you to ask questions and receive answers.
Question: Can I connect the CU-SeeMe reflector to MBONE broadcasts?
Answer: Yes, but only to send the reflector activity (a “CU-SeeMe stream”) to the MBONE, not to receive MBONE streams (at least not with version 9 of the CU-SeeMe reflector).
Only nv (Network Video) is able to receive the CU-SeeMe stream from the MBONE.
(nv can also receive a CU-SeeMe stream directly from a CU-SeeMe reflector.)
The CU-SeeMe reflector works with Maven audio participants, and it may work for VAT as well.
The CU-SeeMe development team has expressed an interest in being able to provide the following capabilities:
The CU-SeeMe development teams says: “one area of recent progress is to allow a reflector to receive as well as send CU-SeeMe streams to the mbone between reflectors to provide for conferences with larger numbers of observers.”
(Details are in the (post-version 20b2) reflector documentation and will be added to the web when someone prods me.)
For multicast routing, a good place to start is Steve Deering’s thesis, which is highly readable and covers all the basics.
Look on gregorio.stanford.edu, or perhaps in . Once you’re done there, look at the IDMR (Inter-Domain Multicast Routing) internet drafts (draft-ietf-idmr-*), and also at the Nimrod architecture draft (draft-ietf-nimrod-*).
Those will let you know where things are currently.
Multicast routing is not a solved problem by any means when you go beyond LAN environments.
We’ve got enough pieces nailed down to deploy, but I honestly don’t think that what we are doing now will scale to millions of simultaneous groups.
An important idea, which hasn’t been followed up on recently, is localized dynamic changes in algorithm in response to changing conditions.
For example if a source only sends out one message a week, it’s economical for routers just to send it everywhere and let the end networks throw the message away, rather than maintaining a lot of state information about where it shouldn’t go (useless 99.99% of the time).
If the same source starts sending out a message every 10 minutes, then some (but not necessarily all) parts of the Internet might want to start maintaining state information to make sure it only goes where it should.
And so on with similar tradeoffs.
Question: Where may I find more MBONE information?
Answer: Here are some pointers. Don’t forget to
Questions about CU-SeeMe?
Ask the readers of the .
Have you found errors nontrivial or marginal, factual, analytical and illogical, arithmetical, temporal, or even typographical? Please let me know; drop me . Thanks!
1993-2006 by ,
via the Creative Commons License. Questions and comments? Send
to the Geek Times Webmaster. (Domain and web content hosting at .)