CU-SeeMe and the Multicast backbone

  Locations of visitors to this page
be notified of website changes? subscribe
CU-SeeMe

 

CU-SeeMe Home

Frequently Asked Questions

User's Guide

Internet TV with CU-SeeMe

Email Lists

Reflector List

Firewalls

Troubleshooting Macintosh

Troubleshooting Macintosh Audio

Troubleshooting Windows

Reflector FAQ

Video FAQ

Macintosh Configurations

Windows Configurations

MBONE

Add My Reflector

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

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:

  • Two-way connectivity via the reflector.
  • nv-to-Mac/PC and Mac/PC-to-nv.
  • VAT-to-Mac/PC and Mac/PC-to-VAT.
  • Mac/PC direct participation in the MBONE. (The Macintosh is waiting on Apple releasing a MacTCP with multi-cast capability. "Open Transport" is scheduled to be released in 1Q96.)
  • Multi-party conference without a reflector (or perhaps having the reflector functionality on the Mac/PC).
  • Getting the reflector to work with VAT (and other stuff) as it now works with Maven. (Recently it was announced that the reflector would work with another audio encoding method.)

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.)

Scott Brim said:

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 ftp://parcftp.xerox.com/net-research/. 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. Happy reading!

Question: Where may I find more MBONE information?

Answer: Here are some pointers. Don't forget to search for more.

previous   next

Questions about CU-SeeMe? help Ask the readers of the CU-SeeMe Mailing Lists.

Have you found errors nontrivial or marginal, factual, analytical and illogical, arithmetical, temporal, or even typographical? Please let me know; drop me email. Thanks!
 

What's New?  •  Search this Site  •  Website Map
Travel  •  Burning Man  •  San Francisco
Kilts! Kilts! Kilts!  •  Macintosh  •  Technology  •  CU-SeeMe
This page is copyrighted 1993-2008 by Lila, Isaac, Rose, and Mickey Sattler. All rights reserved.