Internet TV with CU-SeeMe: Appendix B – Reflector Operator’s Guide

    Internet TV with CU-SeeMe: Appendix B – Reflector Operator’s Guide

    B. Operator’s Guide

    ……………………………………

    Internet TV with CU-SeeMe: Appendix B – Reflector Operator’s Guide

    Appendix B

    Reflector Operator’s Guide

    Much of the power of CU-SeeMe videoconferencing is the ability to have group conferences. This is done by having participants, running the Macintosh or Windows CU-SeeMe client software, connecting to a CU-SeeMe reflector, maintained by a reflector operator.

    This chapter is for you, the reflector operator. You are a very important link in the CU-SeeMe chain; it’s the work you do, and the events you choose to broadcast, that give CU-SeeMe its public persona. , showed many of the ways CU-SeeMe reflectors have been used in the past. Many of these uses were innovative, bringing people together in ways heretofore impossible. These uses are also responsible for the flattering press that CU-SeeMe has received. You have some big shoes to fill; this chapter is designed to make sure you have the technical know-how.

    After you read this chapter you’ll know

    So you want to run a reflector in a hurry

    There are times when you’ll be in a (pardon the pun) reflective mood, ready to read documentation, get an entire concept in mind before moving on. At other times you’ll turn to the manual only when several frenzied attempts fail miserably. This section is for those latter times. The following steps will, if you’re extremely lucky, get a reflector up and running on your UNIX box. If it doesn’t, you’ll have to read the remainder of this chapter (which I’ll endevour to make reletively painless).

    Start with a well-connected UNIX box. Reflectors, by their very nature, shuffle around lots of bits and therefore require lots of bandwidth. If you’re running a reflector on your corporate LAN, you’ll need lots of bandwidth there too. You’ll be desconsolate if you try to operate a reflector over a modem or antiquated LAN; don’t try to, and don’t ask me why it won’t work for you. You can’t put ten pounds of manure into a five-pound bag.

    All UNIXes are equal, some are just more equal than others. The CU-SeeMe reflector will work on many versions of UNIX, from Santa Cruz Operations (SCO) UNIX to Linux (far and away the preferred UNIX).

    Obtain the CU-SeeMe reflector software. The current versions of the CU-SeeMe reflector executables are available for you to obtain via FTP from

    You’ll see that the reflector has been compiled for you, for a variety of UNIXes; get the one that corresponds to the UNIX system you’ll be using to run the CU-SeeMe reflector software. If your UNIX kernel supports multicast then get the version with the “MC” extention.

    Edit the reflector configuration file. The reflect.conf file controls the behavior and operation of the CU-SeeMe reflector; it’s very important for you to know how to edit this file to customize your reflector. For starters we’ll provide only the most necessary features; set up your reflect.conf to like this:

    //MOTD Welcome to my reflector.

    //MAX-PARTICIPANTS 8

    //MAX-SENDERS 8

    Fire up the CU-SeeMe reflector. To start the CU-SeeMe reflector in the background, type

    reflect &

    at the UNIX shell prompt.

    That’s it. With luck you’re now up and running. If not, read on.

    What’s a CU-SeeMe reflector?

    CU-SeeMe allows you to initiate and accept point-to-point sessions between one other party and yourself. A reflector provides you with the ability to have multi-party CU-SeeMe sessions between several other participants and yourself. You can all see each other (assuming you’re all using cameras) and talk, wave, or use sign language in real-time.

    Why is a CU-SeeMe reflector needed?

    To date there are no ways of having Windows- or Macintosh-based systems reflect video and audio streams in a way that allows multi-party CU-SeeMe connections. So the CU-SeeMe Development Team wrote a UNIX-based piece of software to do the job – the CU-SeeMe reflector.

    As it turns out, having the CU-SeeMe reflector software running on a separate machine is good thing for us. A high-end Macintosh or Windows machine uses most of its processor time dealing with video and audio digitization and compression; earlier machines are overwhelmed by the burden. Running the reflector on the same machine would make the performance unacceptable.

    For example, one reasonably-satisfying CU-SeeMe connection requires about 80 kbps of bandwidth. For eight people to communicate requires 640 kbps. But that’s just for the reflector to receive everyone’s data – the reflector must also “reflect” that data to every other member. For eight participants the reflector needs 5120 kbps of bandwidth (that is, 5.12 mbps (megabits per second)). That’s only a conservative example; Cornell’s CU-SeeMe reflector typically has over 30 participants!

    Why UNIX?

    Reflecting CU-SeeMe audio and video streams requires lots of processor power and network bandwidth. Historically UNIX boxes have had better network connectivity (a built-in capability in all but the earliest UNIXes) and much more processor power.

    Historically, UNIX machines have been able to stay operational for much longer periods of time than have personal computers. Since it was desirable to have the CU-SeeMe reflector available around-the-clock, UNIX was a logical choice. Historically only UNIX had the ability to multicast (send packets to multiple destinations simultaneously). As multicasting is an integral part of the CU-SeeMe reflector’s operation, this was a deciding factor in the decision to adopt UNIX as the operating system of choice. That UNIX is available for almost every piece of computing hardware only made the choice a better one.

    Modern Macintoshes and Windows machines are capable of being reflectors, what with faster processors and robust network connectivity. Since porting the CU-SeeMe reflector to these operating systems takes time and money, and since the UNIX-based reflectors are quite servicable, it’s not a high priority.

    What can the CU-SeeMe reflector do?

    This chapter explores the many features of the CU-SeeMe reflector. Since there is no graphic front-end available to control the CU-SeeMe reflector, you’ll have to edit the reflect.conf text file to affect changes. This may feel akward to people used to working only on Macintosh or Windows, but I’ll try to provide all the information you’ll need to painlessly control the CU-SeeMe reflector.

    Many-to-Many

    The most common CU-SeeMe reflector configuration is a many-to-many scenario, where many people join a conference (an oasis in cyberspace) at one time. Due to present-day bandwidth and processor limitations of computing systems the CU-SeeMe reflector has artificial limits placed upon its operation: a maximum of 40 people may join a conference and any participant may see only seven others (although you may choose which seven). As network connections and processor speeds evolve you should expect these numbers to grow.

    One-to-Many

    A less common, but still popular, CU-SeeMe reflector configuration is the one-to-many scenario, where the reflector operator selects some information to broadcast to an audience. NASA Select TV is perhaps the best-known one-to-many provider. (Information about NASA Select TV may be found in .)

    The ability to chain reflectors (explained below) and interoperate with MBone (also explained below) affords reflector operators the ability to reach a world-wide audience. While it’s not yet possible to rival the for-profit television networks, it’s a definite improvement over email.

    Multicast-to-Unicast

    The CU-SeeMe reflector can listen to a multicast connection (such as MBone) and reflect those multicast packets onto unicast packets, the form required by current Macintosh and Windows machines. (Multicast capability is forthcoming for both those platforms.) This brings a great deal of video “programming” to an audience that wouldn’t otherwise be able to recieve it.

    Unicast-to-Multicast

    The CU-SeeMe reflector can take a unicast audio and video stream that a Macintosh or Windows user generates and multicast it to many participants (or other reflectors). This is the only way that current Macintosh and Windows users can participate in conferences.

    MBone – the Multicast Backbone

    The Multicast Backbone is a very popular form of videoconferencing sent across the Internet that predates CU-SeeMe. MBone operators set up ad-hoc MBone networks by stringing together reflectors and “tunnelling” each other’s data, broadcasting events to “huge” audiences. MBone is also used to run cross- or inter-continental multiparty conferences.

    Audio-only conferences

    Most of my descriptions are about using audio and video together, but the CU-SeeMe reflector can reflect an audio-only stream. Since not everyone has a system capable of transmitting video, or the budget to purchase a camera (although serial-port cameras now cost less than US$100), we end up with a class of users known as “lurkers”. (, shows how to identify lurkers on a conference.) There are several ways of transmitting an audio-only stream: configuring CU-SeeMe to send only audio, using Maven (software by Charley Kline), and others. Because audio requires far less bandwidth (typically on the order of 10 kbps), it’s possible to have a satisfying conversation via a 14.4 kbps modem.

    Requirements for running the CU-SeeMe reflector

    A UNIX computer

    For reasons listed above, UNIX is the operating system required to run the reflector.

    Native UNIX boxen

    The CU-SeeMe Development team wrote the CU-SeeMe reflector to be portable and run on most UNIXes. The team and White Pine (the commercial licensee of CU-SeeMe) provide the CU-SeeMe reflector as compiled executables for the IBM’s AIX and Sun Microsystem’s SunOS flavors of UNIX. The source code is made available to those who use another UNIX.

    Intel-based UNIX boxen

    If you don’t have a Sun SPARC or IBM RS/6000, you can always have an Intel-based computer run UNIX. There are many UNIXes available, the most notable are Linux and FreeBSD. Both of these are free.

    Linux

    Linux is a cooperative effort by hundreds of programmers all over the world, all being loosely coordinated by Linus Thorvald. Operating system hackers tease, tweak, and torture the best performance out of each facet and then send the improved code back to Linus, who incorporates it into the next release of Linux.

    Linux may be found on the Internet at

    Even though the SlackWare installer does pretty much everything for you, there are many “how-to” documents available that explain the many facets of Linux.

    Linux also is available on a CD-ROM, and as part of a huge book entitled Using Linux: Special Edition.

    FreeBSD

    FreeBSD is an implementation of the Berkeley Software Distribution of UNIX. It’s available on the Internet as well, at

    FreeBSD is one of the UNIXes for which the CU-SeeMe Development team and White Pine provide reflector executables. There are also CD-ROMs that contain FreeBSD and many free applications.

    Windows NT

    Some people have claimed to have compiled the CU-SeeMe reflector on Windows NT, but to date the executabile hasn’t made it back to any site that I’ve found. The rumor is credible, since Windows NT provides multicast capibility and its networking is Berkeley-compliant (what’s required by the CU-SeeMe reflector).

    Until this question is settled, I can best serve by pointing you to the best source-code compilers available, those of the GNU (GNU’s not UNIX) project. These may be found all over the Internet, including

    Here you’ll find the GNU C complier, plus the header files the CU-SeeMe reflector source code requires. (If you don’t know what header files are, buy a local programmer a nice dinner in exchange for assistance in compiling the CU-SeeMe reflector.) You might have to change the networking portion around so it uses WinSock (Windows Socket) instead of the typical UNIX network header files.

    Macintosh

    Because of it’s inherent support for bitmapped graphics and high-quality audio, CU-SeeMe was developed first for Macintosh. While it would be nice to have the CU-SeeMe reflector run on Macintosh, that’s currently not feasible. (Once the multicast-capable version of Open Transport is released expect to see a Macintosh-based CU-SeeMe reflector.) Just as owners of Intel-based computers have UNIXes they can use, so do Macintosh owners. Sadly, however, none of the free UNIXes have been ported to Macintosh.

    A/UX

    A few hardy souls have gotten the reflector complied and operating properly on an Apple Workgroup Server running A/UX (Apple UNIX). Since Apple is no longer supporting A/UX, this may not be the best investment of your time. I’d suggest asking around on USENET newsgroups before trying to reinvent this particular wheel. (Specifically, I recall that changes in the file buffering code is required, and that configuring the CU-SeeMe reflector via the reflect.conf doesn’t work – you’ll have to be satisfied with the default settings. Or you can hack the source code with wild abandon.)

    MachTen

    Tenon MachTen, a commercial version of UNIX, runs on top of the Macintosh operating system (instead of taking over the hardware completely, the canonical way of UNIXes). There have been no claims of getting the CU-SeeMe reflector working on MachTen, but in the interests of completeless I mention it. The MachTen distribution includes the GNU compilers and libraries. Information about MachTen may be found on the Internet at

    A fast network connection

    Earlier in this chapter I touched upon the great amounts of bandwidth CU-SeeMe can use. (CU-SeeMe doesn’t need to be a network hog; you can change its behavior to be more network-friendly, something covered in .) Figure B.1 shows the flow of data in a five-person CU-SeeMe conversation through the CU-SeeMe reflector (the box in the middle).

    {imgFileRef(“ABcus01.gif”, “Figure B.1 – a five-way conversation”), “description

    Each of the thin arrows represents 80 kbps of data, one CU-SeeMe audio/video stream; the thick arrows represent four times that amount (the data each participant receives to see and hear the other four participants). 80 kbps is a typical CU-SeeMe setting, far from its maximum of 500 kbps. The reflector is sending and receiving 400 kbps for each participant, for a total of 2000 kbps (2 mbps). It becomes readily apparent why the processor and network capability of the participant’s computers and the CU-SeeMe reflector’s computer need to be powerful.

    {glossSub(“Internet TV with CU-SeeMe: Chapter 4 – Hardware”, “Chapter 4, Networking Hardware”)}, discusses the capabilities of different networking connection options. We’ve already ruled out running a reflector over a modem connection. Table B.2 summarizes the remainder of this subsection. Please note that B.2 refers to medium and large multi-party conferences. One-way broadcasting and small multi-party groups are quite workable via ISDN.

    Connection

    Bandwidth (kbps)

    Will it Work?

    Considerations

    Modem

    14.4

    No

    Even point-to-point is daunting at this speed.

    Modem

    28.8

    No

    Still not enough throughput.

    ISDN (1 bearer channel)

    64

    No

    You will still be disappointed if you try to have a conference at this rate.

    ISDN (2 bearer channels)

    128

    Sort of

    Depending on cap rates this type of connection has possibilities.

    T1

    1500

    Yes

    Multiple users can be sending 80 kbps comfortably.

    Ethernet

    10000

    Yes

    Unless your Ethernet is saturated with other data, things will work well.

    T3

    45000

    Yes

    Now we have to consider if the reflector machine can handle all the traffic that this bandwidth can throw at it.

    Fast Ethernet

    100000

    Yes

    Now we lament that CU-SeeMe can “only” transmit 500 kbps.

    Table B.2 – connectivity capabilities

    A typical industrial-strength reflector needs a connection that affords at least 1.5 mbps of throughput. If your local area network is connected to the Internet (or your company-wide network, depending upon the intended audience) over a T1 line or better you’ll be able to run a satisfying conference, given a reasonable number of participants who each transmit a reasonable amount of data.

    ISDN is unlikely to support an enjoyable conference since a single bearer channel provides only between 0.056 to 0.064 mbps (56 to 64 kbps). Home ISDN supports two bearer channels, for a total throughput of between 0.112 and 0.128 mbps. (I’m using mbps for the moment for comparison with our target 1.5 mbps.)

    Ethernet is the connection method of choice. A local area network running on Ethernet will flourish in its 10 mbps capacity. Remember that a connection to your reflector is as fast as its slowest link. If you’re on a Fast Ethernet local area network connected into the Internet over ISDN, the Internet participants will only have 56 to 128 kbps to work with. That’s not much of anything in the videoconferencing world.

    The reflector software

    As mentioned before, Cornell University is the definitive source for the latest releases of the CU-SeeMe client software and the CU-SeeMe reflector software. The URL (Uniform Resource Locator) for the reflector software is

    When this book was written the directory containing the latest reflector release (4.0 beta 1) looked like figure B.2.

    Figure B.2 – The reflector directory

    The CU-SeeMe Development Team no longer releases the source code for the reflectors except under license; the reflector sources are provided in the same way as are the sources to the CU-SeeMe clients). When a new reflector version is ready for release, binaries for SunOS 4.x.x, for BSDI, and for AIX will be provided immediately at Cornell. Within a day or so, binaries for other platforms will be compiled by White Pine and posted there and at Cornell. White Pine’s FTP site is at

    If you are using a UNIX for which neither Cornell nor White Pine are making executablse, you will be able to get sources under an Internal Use Only license or under a license that permits free redistribution of modified binaries if you give the modifications back to Cornell and White Pine. Both of these licenses will be free or nominal-cost (administrative charge). You can get a commercial license from White Pine.

    You’ll also find many compiled versions of an earlier CU-SeeMe reflector (version 3.0b3) at:

    This site has executables for platforms not supported by White Pine or the CU-SeeMe Development Team.

    MC or NO MC

    To multicast or not to multicast, that is the question. If your UNIX supports multicast (ask your system or network administrator) then download the “MC” version..

    Source Code

    If you can’t find a CU-SeeMe reflector executable for the UNIX you’re using, you can plead your case with the CU-SeeMe Development Team. They’ve got a policy of releasing the source code if you have a good reason. Compiling it for another UNIX, especially if Cornell can add it to the ftp site, probably qualifies.

    Running the reflector

    Here’s the easy part.

    To actually run the reflector all you need to type is

    reflect

    The reflector will then read the reflect.conf file, echo the parameters to the screen, configure itself, and begin operating. Any errors that are found in reflect.conf will be noted in the on-screen output.

    Once the reflect.conf has been read in, the CU-SeeMe reflector will quietly sit, doing its job. If you’re connected through telnet, and you disconnect at this point, UNIX will stop the reflector (because when you log off all sessions started are discontinued). To have the CU-SeeMe reflector continue operating after you leave, use an ampersand when you invoke the reflector to put the job in the background, as in:

    reflect &

    Configuring the CU-SeeMe reflector

    The directives presented in the remainder of this section are important; they’re how you’ll configure the CU-SeeMe reflector to work its best. The directives are not presented in alphabetical order, they’re presented in the order you’re most likely to use them.

    ***** Begin Note *****

    Multiple Configurations

    You don’t have to use the name reflect.conf for the CU-SeeMe reflector configuration file; that’s just the default name. If you’re playing around with several configuration files, you can give each of them a different name and tell the reflector which file you want it to use, as in:

    reflect config-try-6 &

    ***** End Note *****

    SAMPLE parameter

    Sample directive

    Default values go here

    Each directive will be presented in this format. The directive itself will appear in uppercase, optional parameters appear in lowercase following the directive. The following lines contain the directive’s purpose and default value. Lastly, a paragraph of text will explain how to use the directive.

    General directives

    MOTD message-string

    Message of the day

    Default = Disabled

    The MOTD, the message of the day, is the greeting that participants to a CU-SeeMe conference see when they first connect. The MOTD is important, it sets the tone of conduct for participants. A good MOTD welcomes the participant, makes them feel comfortable, and provides them with vital operating information. A MOTD should present most of the following:

    For example, here’s the MOTD entry that was recently used by one CU-SeeMe reflector site:

    MOTD Welcome to internetRADIO, the first radio station

    dedicated to the internet broadcasting 24 hours/day.

    We’re located in Ann Arbor, MI on a T3 connection.

    You must connect in receive only mode. This reflector

    supports up to 40 lurkers. You can also listen through

    VAT and NV on port 3334.

    If you have any comments or suggestions please email

    internet.RADIO@umich.edu.

    Have a nice internetRADIO!

    //

    Note the two trailing forward-slashes on the last line, appearing all by themselves. This ends the message text. You’ll need to remember to terminate message strings in the directives that use them. (Fortunately, the CU-SeeMe reflector’s error-checking code is quite good at noticing this error.)

    DEBUG

    Debugging messages enabled?

    Default = Disabled

    In debug mode the CU-SeeMe reflector prints out more information during its operation. This directive is invaluable if you are having trouble with a configuration or just wantto see what’s going on behind the scenes.

    SELF-REFLECT

    Reflect your own video stream back at you

    Default = Disabled

    During the initial phases of configuration debugging it’s useful to see what you’re sending to the CU-SeeMe reflector. You’ll see yourself twice, once in the local window and once as a participant. Because of the load each video stream places upon the CU-SeeMe reflector, this directive is rarely used once the CU-SeeMe reflector is put into operation.

    Security directives

    CONF-ID conference-id message-string

    Restrict conference to invited participants

    Default = 0

    You may want to run an invitation-only CU-SeeMe reflector session; perhaps a stockholder’s meeting. You accomplish this by choosing a conference identifier (an integer between 1 and 32768 that you choose at random) which you send to the invited parties. They’ll need to provide the conference identifier when they attempt to connect to the CU-SeeMe reflector.

    Should someone attempt to “crash your party”, or mistype the proper conference identifier, they’ll be greeted by the rejection message string you’ve specified. The directive might appear like this:

    CONF-ID 22222 We are currently holding a private

    session on this reflector.

    Try again later.

    //

    If you choose a conference identifier in the range of 32769 to 65535, users will not be turned away (although they will see the message), they’ll only be allowed to receive audio and video streams. This mode is ideal for broadcast reflectors such as NASA Select TV or internetRADIO.

    CONF-MGR ip-address

    Dynamically set the conference identifier

    Default = Disabled

    Rather than provide a fixed conference identifer, you may choose this directive to give you the ability to change the conference identifier whenever you connect to the CU-SeeMe reflector. This way you can make the reflector private at a moment’s notice.

    You provide your IP address as the parameter to this directive. When you connect to the CU-SeeMe reflector it takes note of the conference identifier you’ve specified and dynamically changes the current conference identifier to that value. Participants that subsequently connect must provide the same conference identifier you just did; any who don’t will be treated to the rejection message specified with the CONF-ID directive.

    To make the conference once again open to all, you must connect with a conference identifier of 0.

    ADMIT ip-address message-string

    Admit participants based upon their IP address

    Default = Disabled

    The conference identifier doesn’t provide particularly strenuous security; an annoying person can break in by trying all 32767 choices. This directive allows you to admit participants based upon their IP address, a much better form of security. The downside of using this directive is that it’s more work to specify each participant’s IP address to the CU-SeeMe reflector configuration file that it is picking a random conference identifier. (Please look at the ALLOW and DENY directives, below.)

    When a participant attempts to connect to your reflector, their IP address will be checked against the list of approved addresses. A match lets them in, otherwise they’re shown the message string specified in the last ADMIT directive found. For example:

    ADMIT 141.211.10.45 Unused but required message string

    //

    ADMIT 141.211.10.46 Unused but required message string

    //

    ADMIT 141.214.10.47 Unused but required message string

    //

    ADMIT 1.2.3.4 We are currently holding a private

    session on this reflector.

    Try again later.

    //

    ALLOW ip-address message-string

    Allow participation based upon an IP address range

    Default = Disabled

    This directive allows you to permit a specific IP address or a range of IP addresses to participate in your CU-SeeMe reflector session. An asterik ‘*’ denotes any value for that address portion. For example:

    ALLOW 128.127.203.72

    ALLOW 204.192.15.*

    DENY ip-address message-string

    Deny participation based upon an IP address range

    Default = Disabled

    This directive allows you to deny a specific IP address or a range of IP addresses to participate in your CU-SeeMe reflector session. An asterik ‘*’ denotes any value for that address portion. For example:

    DENY 128.127.203.72

    DENY 204.192.15.*

    REFMON ip-address

    Which machine will run the Reflector Monitor?

    Default = anyone

    Without this directive in your CU-SeeMe reflector configuration file, anyone may Reflector Monitor program may connect. Because this is a security hole, it’s typical specify the IP address of the reflector operator’s favorite computer, or to disallow all uses by specifying an IP address of 0.0.0.0.

    Reflector and Bandwidth Load directives

    CAP cap penalty-time message-string

    Set the maximum permitted transmission rate

    Default = 80 kbps, 1 minute penalty

    The transmission cap you set will certainly have an effect upon the behavior of your CU-SeeMe reflector. (See the beginning of this chapter for a discussion of reflector load.) A participant that transmits a greater rate than what you’ve set (or by default, 80 kbps) will be thrown off the reflector for penalty-time minutes after being shown message-string. For example:

    CAP 40 2 I only have enough money to afford an ISDN connection wit

    two B channels.

    So you must set your cap rate at less than 40.

    Sorry.

    //

    [Note: on the web this appears as three lines, but all the text must be on the same line as the CAP directive.]

    MAX-PARTICIPANTS number-allowed message-string

    Set the maximum number of participants

    Default = 20

    In order to manage the load on your machine (and your network), use this directive to limit the number of people who congregate on your CU-SeeMe reflector. The reflector has a built-in limit of 40, so to get more you’ll have to string a few reflectors together.

    This directive controls the maximum number of participants, whether they be senders or lurkers. The MAX-SENDERS and MAX-LURKERS directives (below) control the maximum number of each type of participant.

    Rejected participants will be shown message-string. For example:

    MAX-PARTICIPANTS 8 Too many participants now.

    //

    MAX-SENDERS number-allowed message-string

    Set the maximum number of participants that are sending audio and/or video

    Default = 20

    This directive controls the number of participants that are sending audio and/or video. There is a built-in maximum of 40. This setting is only consulted after the MAX-PARTICIPANTS directive has been checked.

    Rejected participants will be shown message-string. For example:

    MAX-SENDERS 8 Too many video senders now.

    //

    MAX-LURKERS number-allowed message-string

    Set the maximum number of lurkers

    Default = 20

    This directive controls the number of participants that are not sending any signal. There is a built-in maximum of 40. This setting is only consulted after the MAX-PARTICIPANTS directive has been checked.

    Rejected participants will be shown message-string. For example:

    MAX-LURKERS 8 Too many lurkers now.

    //

    Log file directives

    LOG filename

    What log file should the reflector use?

    Default = reflect.log

    The CU-SeeMe reflector log file is where rejected entry attempts are noted, etc. To use another log file, you’ll specify a path and filename. For example:

    LOG /usr/guildenstern/logs/whats-up.log

    LOG-LIMIT maximum-lines

    The maximum number of lines in the log file

    Default = 10000

    An unbounded log file would fill up a hard disk. This directive allows you to control the maximum size of the CU-SeeMe reflector log file. The maximum is 65535 lines. A value of 0 prevents the log file from being created. One LOG-LIMIT is reached, the entire log file is deleted and started anew.

    Feed directives

    ADMIT-BCC-CLIENT ip-address

    Link this reflector to another

    Default = Disabled

    This directive is used to link CU-SeeMe reflectors, usually for event broadcasting. The maximum number of total possible participants is increased and the load on the reflectors can be distributed. Each reflector specified will receive a “blind carbon-copy” of all CU-SeeMe streams on this reflector. Any number of “downstream” reflectors may be specified. For example:

    ADMIT-BCC-CLIENT 35.1.1.91

    ADMIT-BCC-CLIENT 10.65.7.9

    OBTAIN-BCC ip-address

    Specify an “upstream” reflector that’s feeding you

    Default = Disabled

    There are times you’ll be asked to use your reflector to help broadcast someone else’s feed. That reflector operator will specify your CU-SeeMe reflector with an ADMIT-BCC-CLIENT directive in its reflect.conf. You, in turn, specify that reflector’s IP address with this directive, which can appear only once in your reflect.conf (you can’t simultaneously receive feeds from multiple reflectors).

    Figure B.3 shows a main CU-SeeMe reflector with two downstream CU-SeeMe reflectors specified with ADMIT-BCC-CLIENT directives and those downstream CU-SeeMe reflectors each specifying the main reflector with OBTAIN-BCC directives.

    Figure B.3 – Chaining reflectors

    ADMIT-GENERAL-BCC max-reflectors conference-id

    A less secure way of chaining reflectors

    Default = Disabled

    Using the ADMIT-BCC-CLIENT directive requires some maintenance of the reflect.conf but affords a higher measure of security. The ADMIT-GENERAL-BCC directive provides lower security but requires less configuration maintenance. You specify the maximum number of reflectors you’re willing to feed and a conference identifier (which you divulge to reflector operators you wish to feed). Any reflector that knows the conference identifier will be given a feed, up to max-reflectors. The maximum number of reflectors is 65535. The conference identifier may range from 1 to 65535.

    ADMIT-GENERAL-BCC 9 222

    OBTAIN-GENERAL-BCC ip-address conference-id

    Specify an upstream ADMIT-GENERAL-BCC reflector

    Default = Disabled

    When someone else’s CU-SeeMe reflector is feeding yours (with the ADMIT-GENERAL-BCC directive) you must use this directive to point back at them. You must also specify the correct conference-id. This directive may appear only once in your reflect.conf (you can’t simultaneously receive feeds from multiple reflectors).

    OBTAIN-GENERAL-BCC 35.1.1.91 222

    Figure B.4 shows a CU-SeeMe reflector hierarchy that’s been assembled with the ADMIT-GENERAL-BCC and OBTAIN-GENERAL-BCC directives.

    Figure B.4 – Chaining reflectors with GENERAL directives

    MC-OUT time-to-live multicast-ip-address

    Feed a multicast broadcast

    Default = Disabled

    If your UNIX kernel and CU-SeeMe reflector executable have multicast capability, you can use this directive to feed a multicast. Multicast, which sends one stream across the Internet instead of multiple streams to specific reflectors, is by far the more efficient way of broadcasting. Each of the client reflectors must have multicast capabilities. CU-SeeMe currently doesn’t, but look to this as a great growth area for future development.

    The time-to-live parameter defines how far the multicast stream will reach, how long it will “live”.

    Get the TTL list from the MBone docs to explain the reach of ttl settings.

    MC-OUT 64 128.127.203.74

    MC-IN multicast-ip-address

    Receive a multicast feed

    Default = Disabled

    Just as you can provide a multicast feed with the MC-OUT directive, you can receive a multicast feed with this directive. These directives are mutually exclusive; you can’t give and take at the same time. Make sure the upstream multicast source has a time-to-live value that’s high enough to ensure its signal “lives” long enough to reach you.

    MC-IN 128.127.203.74

    Figure B.5 shows a multicast reflector hierarchy.

    Figure B.5 – A multicast reflector hierarchy

    NO-LOCAL-SENDERS

    Allow participants only to view, not interact, while on a reflector receiving an MC-IN or OBTAIN-BCC feed

    Default = Disabled

    This directive puts all participants into receive-only mode, which helps to limit the load on the reflector, to obtain better quality, and to prevent disruptive interferences by participants. It’s like setting the CONF-ID between 32768 and 65535, or setting MAX-SENDERS to 0, but this directive is specific to reflectors that are receiving MC-IN or OBTAIN-BCC feeds. Somewhat redundant, it allows flexibility in configuring your CU-SeeMe reflector.

    Figure B.6 shows an MC-IN feed with NO-LOCAL-SENDERS set. Compare this with figure B.5.

    Figure B.6 – The effect of NO-LOCAL-SENDERS

    ADMIT-SENDER ip-address

    Allow certain participants to override NO-LOCAL-SENDERS

    Default = Disabled

    This directive allows you to permit certain local participants to provide a CU-SeeMe stream when all others can’t. This is useful for staging a debate, for example, where only a few participants debate while others watch.

    ADMIT-SENDER 41.21.1.3

    ADMIT-SENDER 35.1.1.92

    Synchronization directives

    UNICAST-REF ip-address

    Specify one or more unicast reflectors to act as peers

    Default = Disabled

    Up to this point I’ve described reflector hierarchies, where upstream reflectors provide feeds and downstream reflectors receive feeds. This directive specifies one or more unicast reflectors that will act as peers; participants on one peer reflector are able to interact with participants on any other peer reflector. CU-SeeMe reflectors are unicast reflectors; use the MC-GROUP directive to specify multicast peer reflectors.

    When participants are spread out across the country or the world, setting up a group of reflectors through this method is much more efficient than having all the participants connecting to one reflector. Only one stream of data is being sent to each reflector from the others, instead of multiple streams to each client. The multicast version of this configuration is more efficient yet.

    Don’t specify your own reflector’s IP address.

    UNICAST-REF 41.21.1.2

    UNICAST-REF 35.1.1.91

    UNICAST-REF 10.6.72.9

    Figure B.7 shows one configuration of peer unicast reflectors.

    Figure B.7 – Unicast peers

    MC-GROUP ip-address

    Specify one or more multicast reflectors to act as peers

    Default = Disabled

    Compare this directive with UNICAST-REF. Participants on one peer multicast reflector are able to interact with participants on any other peer reflector. Since multicast is more bandwidth-efficient, this configuration is preferred to unicast peering.

    All peer multicast reflectors must be on the MBone or on a local area network that is multicast-capable across subnets.

    MC-GROUP 128.127.203.74

    Figure B.8 shows one configuration of peer multicast reflectors.

    Figure B.8 – Multicast peers

    Directives for working with Unix video clients

    NV-UC-PORT port-number

    Specify the unicast UDP port number for NV clients

    Default = Disabled

    NV (Network Video) is a Unix program like CU-SeeMe. The CU-SeeMe reflector can interoperate with NV clients. Because NV doesn’t have a default port that it communicates on, you must specify one. The NV client will need to know what port you choose, so this is something to note on your message of the day. You may choose any port between 1 and 65535.

    NV-UC-PORT 4444

    NV-MC-PORT port-number

    Specify the multicast UDP port number for NV clients

    Default = Disabled

    This directive is the multicast counterpart to NV-UC-PORT. Using multicast to interoperate with NV is preferred because multicast puts less of a load on your network. You may choose a port between 1 and 65535. As ever, you must be on the MBone or have a local area network that is multicast-capable across subnets, and have a UNIX kernel and CU-SeeMe reflector executable that are multicast-enabled.

    NV-MC-PORT 4444

    NV-MC-IN multicast-ip-address

    Receive CU-SeeMe streams from NV clients over multicast

    Default = Disabled

    NV is able to send CU-SeeMe streams (although you must tell your NV client to do this instead of its native encoding). This directive specifies an NV client that is sending you CU-SeeMe streams.

    NV-MC-IN 239.4.4.1

    NV-MC-OUT time-to-live multicast-ip-address

    Send CU-SeeMe streams to NV clients over multicast

    Default = Disabled

    The CU-SeeMe reflector will send CU-SeeMe streams to the NV clients you specify. The time-to-live parameter determines how far your signal will travel (how long the signal will “live”). If you’re using both the NV-MC-IN and NV-MC-OUT directives, both must have the same IP address as parameters.

    NV-MC-OUT 239.4.4.1

    NV-STREAMS number

    Limit the number of video streams sent to NV clients

    Default = 4

    This directive limits the number of streams your CU-SeeMe reflector will send to the NV client specified in the NV-MC-OUT directive, lessening the load on the network and on the computer running the NV client. (You can limit only the number of streams; you can’t pick and choose which streams to send.) You could limit the number of streams you’re sending and choose which streams those are by selecting who may participate in your conference.

    You may select up to 40 streams.

    NV-STREAMS 8

    VAT-UC-PORT port-number

    Specify the unicast UDP port number for VAT clients

    Default = Disabled

    VAT (Video Audio Tool) is a UNIX program like CU-SeeMe. The CU-SeeMe reflector can interoperate with VAT clients. Because VAT doesn’t have a default port that it communicates on, you must specify one. The NV client will need to know what port you choose, so this is something to note on your message of the day. You may choose any port between 1 and 65535.

    VAT-UC-PORT 4444

    VAT-MC-PORT port-number

    Specify the multicast UDP port number for VAT clients

    Default = Disabled

    This directive is the multicast counterpart to VAT-UC-PORT. Using multicast to interoperate with VAT is preferred because multicast puts less of a load on your network. You may choose a port between 1 and 65535. As ever, you must be on the MBone or have a local area network that is multicast-capable across subnets, and have a UNIX kernel and CU-SeeMe reflector executable that are multicast-enabled.

    VAT-MC-PORT 4444

    VAT-MC-IN multicast-ip-address

    Receive audio from VAT clients over multicast

    Default = Disabled

    VAT is able to send some forms of CU-SeeMe audio streams (delta-mod and Linear PCM). This directive specifies an VAT client that is sending you CU-SeeMe audio streams.

    VAT-MC-IN 239.4.4.1

    VAT-MC-OUT time-to-live multicast-ip-address

    Send audio to VAT clients over multicast

    Default = Disabled

    The CU-SeeMe reflector will send CU-SeeMe audio streams to the VAT clients you specify. The time-to-live parameter determines how far your signal will travel (how long the signal will “live”). If you’re using both the VAT-MC-IN and VAT-MC-OUT directives, both must have the same IP address as parameters.

    VAT-MC-OUT 239.4.4.1

    VAT-CONF-ID conference-id

    Set the conference identifier for VAT clients

    Default = Disabled

    This directive performs the CONF-ID function for VAT clients.

    VAT-CONF-ID 222

    Directives for controlling CU-SeeMe clients

    MIN-MAC-VERSION version-number message-string

    Force participants to use certain Macintosh CU-SeeMe clients

    Default = Disabled

    Revisions in CU-SeeMe clients provide better algorithms, better error-checking, and the like. You may want to force conference participants to use a particular CU-SeeMe client. This directive specifies the earliest Macintosh CU-SeeMe client that will be allowed to connect.

    MIN-MAC-VERSION 25

    Table B.2 shows the mapping for some Macintosh CU-SeeMe clients and the value you’ll specify to this directive. The current list is available from the CU-SeeMe Development Team.

    ReleaseParameter

    7.0b112

    7.0b1218

    7.0b1319

    7.0b1422

    7.0b1525

    MIN-PC-VERSION version-number message-string

    Force participants to use certain Windows CU-SeeMe clients

    Default = Disabled

    Revisions in CU-SeeMe clients provide better algorithms, better error-checking, and the like. You may want to force conference participants to use a particular CU-SeeMe client. This directive specifies the earliest Windows CU-SeeMe client that will be allowed to connect.

    MIN-PC-VERSION 2

    Table B.3 shows the mapping for some Macintosh CU-SeeMe clients and the value you’ll specify to this directive. The current list is available from the CU-SeeMe Development Team.

    ReleaseParameter

    0.342

    Flow Control directives

    MAX-MIN-SEND max-min-send penalty-time message-string

    Specify the minimum transmission rate

    Default = 10 1

    This directive is used to control the minimum transmission rate the participant is allowed to request of the CU-SeeMe client software. Participants that set a large value for their minimum are going to force the CU-SeeMe client to send data even when it thinks it’s unnecessary (the send rate cap will not fall below this setting regardless of packet loss).

    If a client has their client’s minimum transmission rate set higher than max-min-send they’ll be thrown off your CU-SeeMe reflector for penalty-time minutes after being shown message-string.

    MAX-MIN-SEND 40 2 Please don’t set your minimum transmission

    rate to more than 40 kbps on this reflector. You’ll be

    disconnected for two minutes until you lower your setting.

    //

    MAX-MAX-SEND max-max-send penalty-time message-string

    Specify the maximum transmission rate

    Default = 90 1

    This directive is used to control the maximum transmission rate the participant is allowed to request of the CU-SeeMe client software. Participants that set a large value for their maximum transmission rate may flood your CU-SeeMe reflector (the send rate cap will not rise above this setting regardless of packet loss).

    If a client has their client’s maximum transmission rate set higher than max-min-send they’ll be thrown off your CU-SeeMe reflector for penalty-time minutes after being shown message-string.

    MAX-MAX-SEND 120 2 Please don’t set your maximum transmission

    rate to more than 120 kbps on this reflector. You’ll be

    disconnected for two minutes until you lower your setting.

    //

    MAX-MIN-RECV max-min-recv penalty-time message-string

    Specify how large the minimum receive rate may be

    Default = 10 1

    The participant sets a minimum receive rate on the CU-SeeMe client software. (The reflector’s rate cap will not fall below this setting regardless of packet loss.) This directive permits the participant to connect to the CU-SeeMe reflector only if that setting is below max-min-recv. If it’s larger they’ll be thrown off your CU-SeeMe reflector for penalty-time minutes after being shown message-string.

    The complementary directive is MAX-MAX-RECV.

    MAX-MIN-RECV 40 2 Please don’t request more than 40 kbps for

    a minimum transmission rate from the reflector.

    You’ll be disconnected

    for two minutes until you lower your setting.

    //

    MAX-MAX-RECV max-max-recv penalty-time message-string

    Specify how large the maximum receive rate may be

    Default = 10 1

    The participant sets a maximum receive rate on the CU-SeeMe client software. (The reflector’s rate cap will not rise above this setting regardless of packet loss.) This directive permits the participant to connect to the CU-SeeMe reflector only if that setting is above max-max-recv. If it’s larger they’ll be thrown off your CU-SeeMe reflector for penalty-time minutes after being shown message-string.

    The complementary directive is MAX-MIN-RECV.

    MAX-MAX-RECV 600 2 Please don’t request more than 600 kbps

    for a maximum transmission rate from the reflector. You’ll be

    disconnected for two minutes until you lower your setting.

    //

    DEFAULT-MIN-RECV default-min-recv

    Control minimum transmission rate for old-style clients

    Default = 14

    This directive controls the minimum transmission rate from the CU-SeeMe reflector to the CU-SeeMe client software. It’s used for older CU-SeeMe clients, which don’t have loss-reporting capability. If you allow clients older than CU-SeeMe for Macintosh 0.80x and CU-SeeMe for Windows 0.65x to connect to your CU-SeeMe reflector then you’ll want to use this directive.

    The complementary directive is DEFAULT-MAX-RECV.

    DEFAULT-MIN-RECV 10

    DEFAULT-MAX-RECV default-max-recv

    Control maximum transmission rate for old-style clients

    Default = 200

    This directive controls the maximum transmission rate from the CU-SeeMe reflector to the CU-SeeMe client software. It’s used for older CU-SeeMe clients, which don’t have loss-reporting capability. If you allow clients older than CU-SeeMe for Macintosh 0.80x and CU-SeeMe for Windows 0.65x to connect to your CU-SeeMe reflector then you’ll want to use this directive.

    The complementary directive is DEFAULT-MAX-RECV.

    DEFAULT-MAX-RECV 300

    DEFAULT-INIT-RECV default-init-recv

    Control initial transmission rate for old-style clients

    Default = 40

    This directive controls the beginning or initial transmission rate from the CU-SeeMe reflector to the CU-SeeMe client software. It’s used for older CU-SeeMe clients, which don’t have loss-reporting capability. If you allow clients older than CU-SeeMe for Macintosh 0.80x and CU-SeeMe for Windows 0.65x to connect to your CU-SeeMe reflector then you’ll want to use this directive.

    DEFAULT-INIT-RECV 80

    RATE-ADAPT no-loss-growth loss-threshold

    Control reflector transmission increase and data loss threshold to back off

    Default = 5 2

    When your CU-SeeMe reflector sends a stream to a client that reports zero data loss, the reflector will increase the data it sends by no-loss-growth percent until the client reports a data loss of loss-threshold percent, at which time the reflector will back off (stop the increase).

    Use the OLD-RATE-ADAPT directive (below) for old-style clients.

    RATE-ADAPT 15 5

    OLD-RATE-ADAPT old-no-loss-growth old-loss-threshold

    Control reflector transmission increase and data loss threshold to back off when dealing with old-style clients

    Default = 5 2

    When your CU-SeeMe reflector sends a stream to a client that reports zero data loss, the reflector will increase the data it sends by no-loss-growth percent until the client reports a data loss of loss-threshold percent, at which time the reflector will back off (stop the increase).

    Use the RATE-ADAPT directive (above) for modern CU-SeeMe clients (CU-SeeMe for Macintosh 0.80x or newer; CU-SeeMe for Windows 0.65x or newer).

    OLD-RATE-ADAPT 15 5

    Refmon, the CU-SeeMe Reflector Monitor

    Refmon is software that you’ll use to monitor the operation of your CU-SeeMe reflector. You can monitor your reflector either locally or remotely. Refmon uses a command-line mode of operation much like the CU-SeeMe reflector itself, and like the reflector, runs on your UNIX box. With Refmon you’ll who is on the reflector, how long its been up for; you can kick people off the reflector, and take the reflector down.

    Starting Refmon

    All Refmon needs to know from you is what machine to monitor. To monitor the CU-SeeMe reflector running on flapdoodle.jungle.com you’d type:

    refmon -s flapdoodle.jungle.com

    You’ll see Refmon trying to connect to the machine you’ve specified:

    Waiting for connection to 141.214.138.248 … Connected

    >

    and then present you with a prompt. The following commands are understood by Refmon.

    Quit

    Refmon ceases operation. Has no effect on the reflector it’s monitoring.

    Version

    Refmon reports what version of the reflector you’re running.

    Who

    Refmon reports the names, IP addresses, and stream settings of the participants. The stream setting will show a combination of ‘C’ (connected), ‘R’ (receive), and ‘V’ (video-send). For example:

    > who

    CLIENT: John Lauer@141.214.138.202 CR

    CLIENT: internetRADIO@141.214.138.249 CRV

    Total # of clients 2

    senders 1

    lurkers 1

    Maven

    Refmon reports the participants connected to the CU-SeeMe reflector via Charley Kline’s Maven audio software.

    Uptime

    Refmon reports what time the CU-SeeMe reflector was started.

    Term

    Refmon terminates operation of the CU-SeeMe reflector without giving any warning to the participants.

    Param

    Refmon reports the current configuration of the CU-SeeMe reflector. Similar to looking at the reflect.conf file, using Refmon is preferable because you’ll see how the reflector interpreted your configuration commands.

    Help

    Refmon reports the command verbs it understands. It’ll look something like:

    > help

    valid commands are: quit version help who term param maven uptime

    The CU-SeeMe reflector’s log file

    The CU-SeeMe reflector generates a log file during its operation. The reflector writes a log entry when a user connects, disconnects, speaks, or is updated. A typical log file looks like:

    client not found and initial message is not Open

    incoming control message new msg_sock is 8

    PARAM received on control socket

    Client at source 130.166.109.137 is opening a connection

    updating client

    client count 0

    seq 0

    updating client Maren Steiner client count 0

    seq 44

    Client at source 141.214.138.249 is opening a connection

    updating client

    client count 0

    seq 0

    internetRADIO is speaking

    Maren Steiner wants to receive audio from John Lauer

    updating client internetRADIO client count 2

    seq 9

    internetRADIO wants to receive audio from John Lauer

    Maren Steiner wants to receive audio from John Lauer

    updating client internetRADIO client count 2

    seq 9

    internetRADIO wants to receive audio from John Lauer

    Maren Steiner wants to receive audio from John Lauer

    updating client internetRADIO client count 2

    seq 9

    internetRADIO wants to receive audio from John Lauer

    maximum # of senders exceeded

    deleting client Carroll Chiou

    Even without using the CU-SeeMe reflector’s debug option, the log file has lots of useful information about its operation. You can search for lines that say “Client at source … is opening a connection” to see connection activity. There are many other ways of parsing the log file, and many other trends and statistics you can derive from it.

    Advanced reflector usage

    This subsection deals with …

    Linking reflectors

    If you’ve followed the chapter this far, reading (or at least skimming) each of the CU-SeeMe reflector directives, you’re aware that CU-SeeMe reflectors can be linked together for huge broadcasts. You’re also aware that CU-SeeMe, VAT, and NV can all interoperate to provide audio and video to participants. Streams can be sent downstream, or can be synchronized with peer reflectors. This subsection is all about different ways of linking reflectors, of making efficient use of bandwidth and distributing the load between machines.

    Unicasting

    The Mulicast Backbone, the MBone, is a series of routers that forward incoming packets to other networks. It’s configured so that streams never traverse any wire on the network twice; it’s a very efficient broadcast system. You can mimic this technique with CU-SeeMe reflectors, which are unicast (if they were multicast the routes would be automatically calculated), and by educating the participants, who must connect to the closest reflector.

    For example, consider a two-reflector setup. One CU-SeeMe reflector is in New York City, the other in San Francisco. Figure B.9 shows a correct arrangement of reflectors and participants.

    Figure B.9 – Mimicing MBone correctly

    All the San Francisco participants connect to the San Francisco CU-SeeMe reflector; all the New York City participants connect to the New York City CU-SeeMe reflector. The data are being sent between the reflectors only once, which is all that’s needed.

    Consider an inefficient variant, shown in figure B.10.

    Figure B.10 – Mimicing MBone incorrectly

    One San Francisco participant has connected to the New York City reflector. Now all of the data are being sent across the Internet twice, a redundent inefficiency that puts quite a load on the network. Earlier in this chapter I showed how a small (five-person) CU-SeeMe videoconference resulted in 2 mbps of data running through the reflector. (It was figure B.1, if you’re thumbing around.) This errant San Francisco participant has, by connecting to the New York City reflector, caused 2 mbps to needlessly travel across the USA. Imagine now a dozen reflectors, with users connecting to them willy-nilly, without regard for flooding the network. Whether on the Internet or on a small-scale campus or corporate LAN, this easy-to-create inefficiency should be taken into consideration. I’m not objecting to inefficiency for it’s own sake, but its results: poor videoconferencing performance, poor network throughput for others sharing the network, and overall dissatisfaction.

    It’s vitally important for reflector operators to educate their audiences to be good net citizens.

    Networks are a shared resource; being able to communicate with others is what makes them attractive. Limiting the load you place on this shared resource is a matter of some concern. The CU-SeeMe clients and the CU-SeeMe reflector use UDP datagrams, which can drown out regular TCP datagrams, such as those used by the World-Wide Web and the File Transfer Protocol. You must know the state of your LAN, and whether it can handle the load that running a CU-SeeMe reflector will place upon it.

    This is true of local campus and corporate networks, but its especially true when you send streams into the Internet. Internet service providers quickly become upset when you flood them; they become irate if they find out you’re doing it unnecessarily. Efficiency is about sharing. Be knowledgeable about your networking environment. Be pro-active; limit the load by properly configuring the reflect.conf file and requiring a low cap rate.

    In the CU-SeeMe reflector 4.00B1 Read Me file, Richard Cogger, Tim Dorcey, and John Lynn write:

    Major changes are aimed at being “kinder to the Internet” by not sending a lot of traffic that the network would lose anyway. Reflector operators will have more control over (and responsibility for) how pushy CU-SeeMe traffic will be compared to other Internet traffic.

    Of course, we recommend everyone be very polite unless you know you are using only your own facilities.

    The effect is that a mix of modem-connected and LAN-connected participants will work much better.

    Earlier versions of the CU-SeeMe reflector send complete streams to participants running the CU-SeeMe clients over a modem, participants who were destined to lose most of that data. Earlier you saw how a full reflector stream could be 500 kbps; imagine that being sent to a client on a 28.8 kbps modem. Clearly less than five percent of the data can make it through.

    Multicasting

    Multicasting is a most powerful tool for making efficient use of bandwidth and distributing the load. The situation portrayed above in are resolved invisibly and automatically with multicast. The design of a multicast network makes redundant data nearly impossible.

    Multicasting capabilities are just starting to become widespread. As it does, expect to see more use of networking technologies for data-intensive tasks such as videoconferencing. Does your operating system do multicast? Here’s a list:

    What is the MBone? The following blurb is taken from the MBone web pages, found at http://www.eit.com/techinfo/mbone/mbone.html

    MBONE stands for the Virtual Internet Backbone for Multicast IP. IP-Multicast is the class-D addressing scheme in IP implemented by Steve Deering at Xerox PARC. It was adopted at the IETF March 1992 meeting and acquired the name MBONE after the July 1992 IETF meeting.

    IP Multicast-based routing facilitates distributed applications to achieve time-critical “real-time” communications over wide area IP networks through a lightweight, highly threaded model of communication. The IP Multicast routers (referred to as “mrouters”) take the responsility of distributing and replicating the multicast data stream to their destinations as opposed to individual IP hosts. The MBone topology of mrouters is designed in such a manner that it facilitates “efficient” distribution of packets without congesting any node inappropriately.

    Multicast Techniques

    So now you’ve got your Mbone feed and you recompiled your kernel on your unix machine. What now? Well, try receiving some multicast reflector feeds with the MC-IN, MC-OUT settings. Then try synchronizing reflectors with the MC-GROUP setting.

    You could potentially transmit a high-quality video stream to the world over a simple ISDN link using multicast; with unicast and a reflector this isn’t possible. THIS IS IMPORTANT FOR ALL YOU HOME ISDN FOLKS.

    Figure B.11 illustrates the problems of trying to use CU-SeeMe in unicast; each participant causes the CU-SeeMe reflector to transmit a duplicate stream, which it can’t do because of the bottleneck – ISDN just isn’t a big enough “pipe”.

    Figure B.11 – An ISDN/unicast bottleneck

    Figure B.12 shows the same network topology, but with participants being fed by multicast. Since the stream is transmitted over the network only once, all participants can join and receive the data being broadcast.

    Figure B.12 – Multicast saves the day

    Showing an event

    Having made it this far in the chapter, it’s time to go public and show an event. You have the capability to send streams to the four corners of the world. Now you can fill in the gaps; what’s local to you that we would appreciate seeing? Once you find something, how do you let us know you’re trying to be a junior Ted Turner?

    Promoting your event

    In , you saw the various mailing lists used by the CU-SeeMe community. Two of those lists, the CU-SeeMe Events list and the CU-SeeMe Discussion List are used for event publicity.

    Remember to include the following essential information when you promote your event:

    {{imgFileRef(“ABcus14.gif”)}

    Figure B.14 – The CU-SeeMe Events Guide form

    In addition to the mailing lists, John Lauer has created a CU-SeeMe Events Guide on the World-Wide Web. (It was this contribution to the CU-SeeMe community that brought John to my attention, leading to John’s considerable contribution to this chapter.) Located at http://www.umich.edu/~johnlaue/cuseeme/ the CU-SeeMe Events Guide has a forms interface (figure B.13) for you to fill out.

    Figure B.14 – The CU-SeeMe Events Guide form

    The information you submit is compiled twice daily into a new events web page. If you’ve entered a one-time event it’ll be listed by date. If you’ve entered an on-going event, it’ll appear in another section. The CU-SeeMe Event Guide doesn’t yet generate a posting to the mailing lists, but we’re hoping.

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

    |

    |

    |

    |

    |

    |

    |

    |

    This page

    is

    1993-2006 by ,

    via the Creative Commons License. Questions and comments? Send

    to the Geek Times Webmaster. (Domain and web content hosting at .)

    Leave a Reply

    Your email address will not be published.

    Internet TV with CU-SeeMe: Appendix B – Reflector Operator’s Guide

    Internet TV with CU-SeeMe: Appendix B – Reflector Operator’s Guide

    B. Operator’s Guide

    ……………………………………

    Internet TV with CU-SeeMe: Appendix B – Reflector Operator’s Guide

    Appendix B

    Reflector Operator’s Guide

    Much of the power of CU-SeeMe videoconferencing is the ability to have group conferences. This is done by having participants, running the Macintosh or Windows CU-SeeMe client software, connecting to a CU-SeeMe reflector, maintained by a reflector operator.

    This chapter is for you, the reflector operator. You are a very important link in the CU-SeeMe chain; it’s the work you do, and the events you choose to broadcast, that give CU-SeeMe its public persona. , showed many of the ways CU-SeeMe reflectors have been used in the past. Many of these uses were innovative, bringing people together in ways heretofore impossible. These uses are also responsible for the flattering press that CU-SeeMe has received. You have some big shoes to fill; this chapter is designed to make sure you have the technical know-how.

    After you read this chapter you’ll know

    So you want to run a reflector in a hurry

    There are times when you’ll be in a (pardon the pun) reflective mood, ready to read documentation, get an entire concept in mind before moving on. At other times you’ll turn to the manual only when several frenzied attempts fail miserably. This section is for those latter times. The following steps will, if you’re extremely lucky, get a reflector up and running on your UNIX box. If it doesn’t, you’ll have to read the remainder of this chapter (which I’ll endevour to make reletively painless).

    Start with a well-connected UNIX box. Reflectors, by their very nature, shuffle around lots of bits and therefore require lots of bandwidth. If you’re running a reflector on your corporate LAN, you’ll need lots of bandwidth there too. You’ll be desconsolate if you try to operate a reflector over a modem or antiquated LAN; don’t try to, and don’t ask me why it won’t work for you. You can’t put ten pounds of manure into a five-pound bag.

    All UNIXes are equal, some are just more equal than others. The CU-SeeMe reflector will work on many versions of UNIX, from Santa Cruz Operations (SCO) UNIX to Linux (far and away the preferred UNIX).

    Obtain the CU-SeeMe reflector software. The current versions of the CU-SeeMe reflector executables are available for you to obtain via FTP from

    You’ll see that the reflector has been compiled for you, for a variety of UNIXes; get the one that corresponds to the UNIX system you’ll be using to run the CU-SeeMe reflector software. If your UNIX kernel supports multicast then get the version with the “MC” extention.

    Edit the reflector configuration file. The reflect.conf file controls the behavior and operation of the CU-SeeMe reflector; it’s very important for you to know how to edit this file to customize your reflector. For starters we’ll provide only the most necessary features; set up your reflect.conf to like this:

    //MOTD Welcome to my reflector.

    //MAX-PARTICIPANTS 8

    //MAX-SENDERS 8

    Fire up the CU-SeeMe reflector. To start the CU-SeeMe reflector in the background, type

    reflect &

    at the UNIX shell prompt.

    That’s it. With luck you’re now up and running. If not, read on.

    What’s a CU-SeeMe reflector?

    CU-SeeMe allows you to initiate and accept point-to-point sessions between one other party and yourself. A reflector provides you with the ability to have multi-party CU-SeeMe sessions between several other participants and yourself. You can all see each other (assuming you’re all using cameras) and talk, wave, or use sign language in real-time.

    Why is a CU-SeeMe reflector needed?

    To date there are no ways of having Windows- or Macintosh-based systems reflect video and audio streams in a way that allows multi-party CU-SeeMe connections. So the CU-SeeMe Development Team wrote a UNIX-based piece of software to do the job – the CU-SeeMe reflector.

    As it turns out, having the CU-SeeMe reflector software running on a separate machine is good thing for us. A high-end Macintosh or Windows machine uses most of its processor time dealing with video and audio digitization and compression; earlier machines are overwhelmed by the burden. Running the reflector on the same machine would make the performance unacceptable.

    For example, one reasonably-satisfying CU-SeeMe connection requires about 80 kbps of bandwidth. For eight people to communicate requires 640 kbps. But that’s just for the reflector to receive everyone’s data – the reflector must also “reflect” that data to every other member. For eight participants the reflector needs 5120 kbps of bandwidth (that is, 5.12 mbps (megabits per second)). That’s only a conservative example; Cornell’s CU-SeeMe reflector typically has over 30 participants!

    Why UNIX?

    Reflecting CU-SeeMe audio and video streams requires lots of processor power and network bandwidth. Historically UNIX boxes have had better network connectivity (a built-in capability in all but the earliest UNIXes) and much more processor power.

    Historically, UNIX machines have been able to stay operational for much longer periods of time than have personal computers. Since it was desirable to have the CU-SeeMe reflector available around-the-clock, UNIX was a logical choice. Historically only UNIX had the ability to multicast (send packets to multiple destinations simultaneously). As multicasting is an integral part of the CU-SeeMe reflector’s operation, this was a deciding factor in the decision to adopt UNIX as the operating system of choice. That UNIX is available for almost every piece of computing hardware only made the choice a better one.

    Modern Macintoshes and Windows machines are capable of being reflectors, what with faster processors and robust network connectivity. Since porting the CU-SeeMe reflector to these operating systems takes time and money, and since the UNIX-based reflectors are quite servicable, it’s not a high priority.

    What can the CU-SeeMe reflector do?

    This chapter explores the many features of the CU-SeeMe reflector. Since there is no graphic front-end available to control the CU-SeeMe reflector, you’ll have to edit the reflect.conf text file to affect changes. This may feel akward to people used to working only on Macintosh or Windows, but I’ll try to provide all the information you’ll need to painlessly control the CU-SeeMe reflector.

    Many-to-Many

    The most common CU-SeeMe reflector configuration is a many-to-many scenario, where many people join a conference (an oasis in cyberspace) at one time. Due to present-day bandwidth and processor limitations of computing systems the CU-SeeMe reflector has artificial limits placed upon its operation: a maximum of 40 people may join a conference and any participant may see only seven others (although you may choose which seven). As network connections and processor speeds evolve you should expect these numbers to grow.

    One-to-Many

    A less common, but still popular, CU-SeeMe reflector configuration is the one-to-many scenario, where the reflector operator selects some information to broadcast to an audience. NASA Select TV is perhaps the best-known one-to-many provider. (Information about NASA Select TV may be found in .)

    The ability to chain reflectors (explained below) and interoperate with MBone (also explained below) affords reflector operators the ability to reach a world-wide audience. While it’s not yet possible to rival the for-profit television networks, it’s a definite improvement over email.

    Multicast-to-Unicast

    The CU-SeeMe reflector can listen to a multicast connection (such as MBone) and reflect those multicast packets onto unicast packets, the form required by current Macintosh and Windows machines. (Multicast capability is forthcoming for both those platforms.) This brings a great deal of video “programming” to an audience that wouldn’t otherwise be able to recieve it.

    Unicast-to-Multicast

    The CU-SeeMe reflector can take a unicast audio and video stream that a Macintosh or Windows user generates and multicast it to many participants (or other reflectors). This is the only way that current Macintosh and Windows users can participate in conferences.

    MBone – the Multicast Backbone

    The Multicast Backbone is a very popular form of videoconferencing sent across the Internet that predates CU-SeeMe. MBone operators set up ad-hoc MBone networks by stringing together reflectors and “tunnelling” each other’s data, broadcasting events to “huge” audiences. MBone is also used to run cross- or inter-continental multiparty conferences.

    Audio-only conferences

    Most of my descriptions are about using audio and video together, but the CU-SeeMe reflector can reflect an audio-only stream. Since not everyone has a system capable of transmitting video, or the budget to purchase a camera (although serial-port cameras now cost less than US$100), we end up with a class of users known as “lurkers”. (, shows how to identify lurkers on a conference.) There are several ways of transmitting an audio-only stream: configuring CU-SeeMe to send only audio, using Maven (software by Charley Kline), and others. Because audio requires far less bandwidth (typically on the order of 10 kbps), it’s possible to have a satisfying conversation via a 14.4 kbps modem.

    Requirements for running the CU-SeeMe reflector

    A UNIX computer

    For reasons listed above, UNIX is the operating system required to run the reflector.

    Native UNIX boxen

    The CU-SeeMe Development team wrote the CU-SeeMe reflector to be portable and run on most UNIXes. The team and White Pine (the commercial licensee of CU-SeeMe) provide the CU-SeeMe reflector as compiled executables for the IBM’s AIX and Sun Microsystem’s SunOS flavors of UNIX. The source code is made available to those who use another UNIX.

    Intel-based UNIX boxen

    If you don’t have a Sun SPARC or IBM RS/6000, you can always have an Intel-based computer run UNIX. There are many UNIXes available, the most notable are Linux and FreeBSD. Both of these are free.

    Linux

    Linux is a cooperative effort by hundreds of programmers all over the world, all being loosely coordinated by Linus Thorvald. Operating system hackers tease, tweak, and torture the best performance out of each facet and then send the improved code back to Linus, who incorporates it into the next release of Linux.

    Linux may be found on the Internet at

    Even though the SlackWare installer does pretty much everything for you, there are many “how-to” documents available that explain the many facets of Linux.

    Linux also is available on a CD-ROM, and as part of a huge book entitled Using Linux: Special Edition.

    FreeBSD

    FreeBSD is an implementation of the Berkeley Software Distribution of UNIX. It’s available on the Internet as well, at

    FreeBSD is one of the UNIXes for which the CU-SeeMe Development team and White Pine provide reflector executables. There are also CD-ROMs that contain FreeBSD and many free applications.

    Windows NT

    Some people have claimed to have compiled the CU-SeeMe reflector on Windows NT, but to date the executabile hasn’t made it back to any site that I’ve found. The rumor is credible, since Windows NT provides multicast capibility and its networking is Berkeley-compliant (what’s required by the CU-SeeMe reflector).

    Until this question is settled, I can best serve by pointing you to the best source-code compilers available, those of the GNU (GNU’s not UNIX) project. These may be found all over the Internet, including

    Here you’ll find the GNU C complier, plus the header files the CU-SeeMe reflector source code requires. (If you don’t know what header files are, buy a local programmer a nice dinner in exchange for assistance in compiling the CU-SeeMe reflector.) You might have to change the networking portion around so it uses WinSock (Windows Socket) instead of the typical UNIX network header files.

    Macintosh

    Because of it’s inherent support for bitmapped graphics and high-quality audio, CU-SeeMe was developed first for Macintosh. While it would be nice to have the CU-SeeMe reflector run on Macintosh, that’s currently not feasible. (Once the multicast-capable version of Open Transport is released expect to see a Macintosh-based CU-SeeMe reflector.) Just as owners of Intel-based computers have UNIXes they can use, so do Macintosh owners. Sadly, however, none of the free UNIXes have been ported to Macintosh.

    A/UX

    A few hardy souls have gotten the reflector complied and operating properly on an Apple Workgroup Server running A/UX (Apple UNIX). Since Apple is no longer supporting A/UX, this may not be the best investment of your time. I’d suggest asking around on USENET newsgroups before trying to reinvent this particular wheel. (Specifically, I recall that changes in the file buffering code is required, and that configuring the CU-SeeMe reflector via the reflect.conf doesn’t work – you’ll have to be satisfied with the default settings. Or you can hack the source code with wild abandon.)

    MachTen

    Tenon MachTen, a commercial version of UNIX, runs on top of the Macintosh operating system (instead of taking over the hardware completely, the canonical way of UNIXes). There have been no claims of getting the CU-SeeMe reflector working on MachTen, but in the interests of completeless I mention it. The MachTen distribution includes the GNU compilers and libraries. Information about MachTen may be found on the Internet at

    A fast network connection

    Earlier in this chapter I touched upon the great amounts of bandwidth CU-SeeMe can use. (CU-SeeMe doesn’t need to be a network hog; you can change its behavior to be more network-friendly, something covered in .) Figure B.1 shows the flow of data in a five-person CU-SeeMe conversation through the CU-SeeMe reflector (the box in the middle).

    {imgFileRef(“ABcus01.gif”, “Figure B.1 – a five-way conversation”), “description

    Each of the thin arrows represents 80 kbps of data, one CU-SeeMe audio/video stream; the thick arrows represent four times that amount (the data each participant receives to see and hear the other four participants). 80 kbps is a typical CU-SeeMe setting, far from its maximum of 500 kbps. The reflector is sending and receiving 400 kbps for each participant, for a total of 2000 kbps (2 mbps). It becomes readily apparent why the processor and network capability of the participant’s computers and the CU-SeeMe reflector’s computer need to be powerful.

    {glossSub(“Internet TV with CU-SeeMe: Chapter 4 – Hardware”, “Chapter 4, Networking Hardware”)}, discusses the capabilities of different networking connection options. We’ve already ruled out running a reflector over a modem connection. Table B.2 summarizes the remainder of this subsection. Please note that B.2 refers to medium and large multi-party conferences. One-way broadcasting and small multi-party groups are quite workable via ISDN.

    Connection

    Bandwidth (kbps)

    Will it Work?

    Considerations

    Modem

    14.4

    No

    Even point-to-point is daunting at this speed.

    Modem

    28.8

    No

    Still not enough throughput.

    ISDN (1 bearer channel)

    64

    No

    You will still be disappointed if you try to have a conference at this rate.

    ISDN (2 bearer channels)

    128

    Sort of

    Depending on cap rates this type of connection has possibilities.

    T1

    1500

    Yes

    Multiple users can be sending 80 kbps comfortably.

    Ethernet

    10000

    Yes

    Unless your Ethernet is saturated with other data, things will work well.

    T3

    45000

    Yes

    Now we have to consider if the reflector machine can handle all the traffic that this bandwidth can throw at it.

    Fast Ethernet

    100000

    Yes

    Now we lament that CU-SeeMe can “only” transmit 500 kbps.

    Table B.2 – connectivity capabilities

    A typical industrial-strength reflector needs a connection that affords at least 1.5 mbps of throughput. If your local area network is connected to the Internet (or your company-wide network, depending upon the intended audience) over a T1 line or better you’ll be able to run a satisfying conference, given a reasonable number of participants who each transmit a reasonable amount of data.

    ISDN is unlikely to support an enjoyable conference since a single bearer channel provides only between 0.056 to 0.064 mbps (56 to 64 kbps). Home ISDN supports two bearer channels, for a total throughput of between 0.112 and 0.128 mbps. (I’m using mbps for the moment for comparison with our target 1.5 mbps.)

    Ethernet is the connection method of choice. A local area network running on Ethernet will flourish in its 10 mbps capacity. Remember that a connection to your reflector is as fast as its slowest link. If you’re on a Fast Ethernet local area network connected into the Internet over ISDN, the Internet participants will only have 56 to 128 kbps to work with. That’s not much of anything in the videoconferencing world.

    The reflector software

    As mentioned before, Cornell University is the definitive source for the latest releases of the CU-SeeMe client software and the CU-SeeMe reflector software. The URL (Uniform Resource Locator) for the reflector software is

    When this book was written the directory containing the latest reflector release (4.0 beta 1) looked like figure B.2.

    Figure B.2 – The reflector directory

    The CU-SeeMe Development Team no longer releases the source code for the reflectors except under license; the reflector sources are provided in the same way as are the sources to the CU-SeeMe clients). When a new reflector version is ready for release, binaries for SunOS 4.x.x, for BSDI, and for AIX will be provided immediately at Cornell. Within a day or so, binaries for other platforms will be compiled by White Pine and posted there and at Cornell. White Pine’s FTP site is at

    If you are using a UNIX for which neither Cornell nor White Pine are making executablse, you will be able to get sources under an Internal Use Only license or under a license that permits free redistribution of modified binaries if you give the modifications back to Cornell and White Pine. Both of these licenses will be free or nominal-cost (administrative charge). You can get a commercial license from White Pine.

    You’ll also find many compiled versions of an earlier CU-SeeMe reflector (version 3.0b3) at:

    This site has executables for platforms not supported by White Pine or the CU-SeeMe Development Team.

    MC or NO MC

    To multicast or not to multicast, that is the question. If your UNIX supports multicast (ask your system or network administrator) then download the “MC” version..

    Source Code

    If you can’t find a CU-SeeMe reflector executable for the UNIX you’re using, you can plead your case with the CU-SeeMe Development Team. They’ve got a policy of releasing the source code if you have a good reason. Compiling it for another UNIX, especially if Cornell can add it to the ftp site, probably qualifies.

    Running the reflector

    Here’s the easy part.

    To actually run the reflector all you need to type is

    reflect

    The reflector will then read the reflect.conf file, echo the parameters to the screen, configure itself, and begin operating. Any errors that are found in reflect.conf will be noted in the on-screen output.

    Once the reflect.conf has been read in, the CU-SeeMe reflector will quietly sit, doing its job. If you’re connected through telnet, and you disconnect at this point, UNIX will stop the reflector (because when you log off all sessions started are discontinued). To have the CU-SeeMe reflector continue operating after you leave, use an ampersand when you invoke the reflector to put the job in the background, as in:

    reflect &

    Configuring the CU-SeeMe reflector

    The directives presented in the remainder of this section are important; they’re how you’ll configure the CU-SeeMe reflector to work its best. The directives are not presented in alphabetical order, they’re presented in the order you’re most likely to use them.

    ***** Begin Note *****

    Multiple Configurations

    You don’t have to use the name reflect.conf for the CU-SeeMe reflector configuration file; that’s just the default name. If you’re playing around with several configuration files, you can give each of them a different name and tell the reflector which file you want it to use, as in:

    reflect config-try-6 &

    ***** End Note *****

    SAMPLE parameter

    Sample directive

    Default values go here

    Each directive will be presented in this format. The directive itself will appear in uppercase, optional parameters appear in lowercase following the directive. The following lines contain the directive’s purpose and default value. Lastly, a paragraph of text will explain how to use the directive.

    General directives

    MOTD message-string

    Message of the day

    Default = Disabled

    The MOTD, the message of the day, is the greeting that participants to a CU-SeeMe conference see when they first connect. The MOTD is important, it sets the tone of conduct for participants. A good MOTD welcomes the participant, makes them feel comfortable, and provides them with vital operating information. A MOTD should present most of the following:

    For example, here’s the MOTD entry that was recently used by one CU-SeeMe reflector site:

    MOTD Welcome to internetRADIO, the first radio station

    dedicated to the internet broadcasting 24 hours/day.

    We’re located in Ann Arbor, MI on a T3 connection.

    You must connect in receive only mode. This reflector

    supports up to 40 lurkers. You can also listen through

    VAT and NV on port 3334.

    If you have any comments or suggestions please email

    internet.RADIO@umich.edu.

    Have a nice internetRADIO!

    //

    Note the two trailing forward-slashes on the last line, appearing all by themselves. This ends the message text. You’ll need to remember to terminate message strings in the directives that use them. (Fortunately, the CU-SeeMe reflector’s error-checking code is quite good at noticing this error.)

    DEBUG

    Debugging messages enabled?

    Default = Disabled

    In debug mode the CU-SeeMe reflector prints out more information during its operation. This directive is invaluable if you are having trouble with a configuration or just wantto see what’s going on behind the scenes.

    SELF-REFLECT

    Reflect your own video stream back at you

    Default = Disabled

    During the initial phases of configuration debugging it’s useful to see what you’re sending to the CU-SeeMe reflector. You’ll see yourself twice, once in the local window and once as a participant. Because of the load each video stream places upon the CU-SeeMe reflector, this directive is rarely used once the CU-SeeMe reflector is put into operation.

    Security directives

    CONF-ID conference-id message-string

    Restrict conference to invited participants

    Default = 0

    You may want to run an invitation-only CU-SeeMe reflector session; perhaps a stockholder’s meeting. You accomplish this by choosing a conference identifier (an integer between 1 and 32768 that you choose at random) which you send to the invited parties. They’ll need to provide the conference identifier when they attempt to connect to the CU-SeeMe reflector.

    Should someone attempt to “crash your party”, or mistype the proper conference identifier, they’ll be greeted by the rejection message string you’ve specified. The directive might appear like this:

    CONF-ID 22222 We are currently holding a private

    session on this reflector.

    Try again later.

    //

    If you choose a conference identifier in the range of 32769 to 65535, users will not be turned away (although they will see the message), they’ll only be allowed to receive audio and video streams. This mode is ideal for broadcast reflectors such as NASA Select TV or internetRADIO.

    CONF-MGR ip-address

    Dynamically set the conference identifier

    Default = Disabled

    Rather than provide a fixed conference identifer, you may choose this directive to give you the ability to change the conference identifier whenever you connect to the CU-SeeMe reflector. This way you can make the reflector private at a moment’s notice.

    You provide your IP address as the parameter to this directive. When you connect to the CU-SeeMe reflector it takes note of the conference identifier you’ve specified and dynamically changes the current conference identifier to that value. Participants that subsequently connect must provide the same conference identifier you just did; any who don’t will be treated to the rejection message specified with the CONF-ID directive.

    To make the conference once again open to all, you must connect with a conference identifier of 0.

    ADMIT ip-address message-string

    Admit participants based upon their IP address

    Default = Disabled

    The conference identifier doesn’t provide particularly strenuous security; an annoying person can break in by trying all 32767 choices. This directive allows you to admit participants based upon their IP address, a much better form of security. The downside of using this directive is that it’s more work to specify each participant’s IP address to the CU-SeeMe reflector configuration file that it is picking a random conference identifier. (Please look at the ALLOW and DENY directives, below.)

    When a participant attempts to connect to your reflector, their IP address will be checked against the list of approved addresses. A match lets them in, otherwise they’re shown the message string specified in the last ADMIT directive found. For example:

    ADMIT 141.211.10.45 Unused but required message string

    //

    ADMIT 141.211.10.46 Unused but required message string

    //

    ADMIT 141.214.10.47 Unused but required message string

    //

    ADMIT 1.2.3.4 We are currently holding a private

    session on this reflector.

    Try again later.

    //

    ALLOW ip-address message-string

    Allow participation based upon an IP address range

    Default = Disabled

    This directive allows you to permit a specific IP address or a range of IP addresses to participate in your CU-SeeMe reflector session. An asterik ‘*’ denotes any value for that address portion. For example:

    ALLOW 128.127.203.72

    ALLOW 204.192.15.*

    DENY ip-address message-string

    Deny participation based upon an IP address range

    Default = Disabled

    This directive allows you to deny a specific IP address or a range of IP addresses to participate in your CU-SeeMe reflector session. An asterik ‘*’ denotes any value for that address portion. For example:

    DENY 128.127.203.72

    DENY 204.192.15.*

    REFMON ip-address

    Which machine will run the Reflector Monitor?

    Default = anyone

    Without this directive in your CU-SeeMe reflector configuration file, anyone may Reflector Monitor program may connect. Because this is a security hole, it’s typical specify the IP address of the reflector operator’s favorite computer, or to disallow all uses by specifying an IP address of 0.0.0.0.

    Reflector and Bandwidth Load directives

    CAP cap penalty-time message-string

    Set the maximum permitted transmission rate

    Default = 80 kbps, 1 minute penalty

    The transmission cap you set will certainly have an effect upon the behavior of your CU-SeeMe reflector. (See the beginning of this chapter for a discussion of reflector load.) A participant that transmits a greater rate than what you’ve set (or by default, 80 kbps) will be thrown off the reflector for penalty-time minutes after being shown message-string. For example:

    CAP 40 2 I only have enough money to afford an ISDN connection wit

    two B channels.

    So you must set your cap rate at less than 40.

    Sorry.

    //

    [Note: on the web this appears as three lines, but all the text must be on the same line as the CAP directive.]

    MAX-PARTICIPANTS number-allowed message-string

    Set the maximum number of participants

    Default = 20

    In order to manage the load on your machine (and your network), use this directive to limit the number of people who congregate on your CU-SeeMe reflector. The reflector has a built-in limit of 40, so to get more you’ll have to string a few reflectors together.

    This directive controls the maximum number of participants, whether they be senders or lurkers. The MAX-SENDERS and MAX-LURKERS directives (below) control the maximum number of each type of participant.

    Rejected participants will be shown message-string. For example:

    MAX-PARTICIPANTS 8 Too many participants now.

    //

    MAX-SENDERS number-allowed message-string

    Set the maximum number of participants that are sending audio and/or video

    Default = 20

    This directive controls the number of participants that are sending audio and/or video. There is a built-in maximum of 40. This setting is only consulted after the MAX-PARTICIPANTS directive has been checked.

    Rejected participants will be shown message-string. For example:

    MAX-SENDERS 8 Too many video senders now.

    //

    MAX-LURKERS number-allowed message-string

    Set the maximum number of lurkers

    Default = 20

    This directive controls the number of participants that are not sending any signal. There is a built-in maximum of 40. This setting is only consulted after the MAX-PARTICIPANTS directive has been checked.

    Rejected participants will be shown message-string. For example:

    MAX-LURKERS 8 Too many lurkers now.

    //

    Log file directives

    LOG filename

    What log file should the reflector use?

    Default = reflect.log

    The CU-SeeMe reflector log file is where rejected entry attempts are noted, etc. To use another log file, you’ll specify a path and filename. For example:

    LOG /usr/guildenstern/logs/whats-up.log

    LOG-LIMIT maximum-lines

    The maximum number of lines in the log file

    Default = 10000

    An unbounded log file would fill up a hard disk. This directive allows you to control the maximum size of the CU-SeeMe reflector log file. The maximum is 65535 lines. A value of 0 prevents the log file from being created. One LOG-LIMIT is reached, the entire log file is deleted and started anew.

    Feed directives

    ADMIT-BCC-CLIENT ip-address

    Link this reflector to another

    Default = Disabled

    This directive is used to link CU-SeeMe reflectors, usually for event broadcasting. The maximum number of total possible participants is increased and the load on the reflectors can be distributed. Each reflector specified will receive a “blind carbon-copy” of all CU-SeeMe streams on this reflector. Any number of “downstream” reflectors may be specified. For example:

    ADMIT-BCC-CLIENT 35.1.1.91

    ADMIT-BCC-CLIENT 10.65.7.9

    OBTAIN-BCC ip-address

    Specify an “upstream” reflector that’s feeding you

    Default = Disabled

    There are times you’ll be asked to use your reflector to help broadcast someone else’s feed. That reflector operator will specify your CU-SeeMe reflector with an ADMIT-BCC-CLIENT directive in its reflect.conf. You, in turn, specify that reflector’s IP address with this directive, which can appear only once in your reflect.conf (you can’t simultaneously receive feeds from multiple reflectors).

    Figure B.3 shows a main CU-SeeMe reflector with two downstream CU-SeeMe reflectors specified with ADMIT-BCC-CLIENT directives and those downstream CU-SeeMe reflectors each specifying the main reflector with OBTAIN-BCC directives.

    Figure B.3 – Chaining reflectors

    ADMIT-GENERAL-BCC max-reflectors conference-id

    A less secure way of chaining reflectors

    Default = Disabled

    Using the ADMIT-BCC-CLIENT directive requires some maintenance of the reflect.conf but affords a higher measure of security. The ADMIT-GENERAL-BCC directive provides lower security but requires less configuration maintenance. You specify the maximum number of reflectors you’re willing to feed and a conference identifier (which you divulge to reflector operators you wish to feed). Any reflector that knows the conference identifier will be given a feed, up to max-reflectors. The maximum number of reflectors is 65535. The conference identifier may range from 1 to 65535.

    ADMIT-GENERAL-BCC 9 222

    OBTAIN-GENERAL-BCC ip-address conference-id

    Specify an upstream ADMIT-GENERAL-BCC reflector

    Default = Disabled

    When someone else’s CU-SeeMe reflector is feeding yours (with the ADMIT-GENERAL-BCC directive) you must use this directive to point back at them. You must also specify the correct conference-id. This directive may appear only once in your reflect.conf (you can’t simultaneously receive feeds from multiple reflectors).

    OBTAIN-GENERAL-BCC 35.1.1.91 222

    Figure B.4 shows a CU-SeeMe reflector hierarchy that’s been assembled with the ADMIT-GENERAL-BCC and OBTAIN-GENERAL-BCC directives.

    Figure B.4 – Chaining reflectors with GENERAL directives

    MC-OUT time-to-live multicast-ip-address

    Feed a multicast broadcast

    Default = Disabled

    If your UNIX kernel and CU-SeeMe reflector executable have multicast capability, you can use this directive to feed a multicast. Multicast, which sends one stream across the Internet instead of multiple streams to specific reflectors, is by far the more efficient way of broadcasting. Each of the client reflectors must have multicast capabilities. CU-SeeMe currently doesn’t, but look to this as a great growth area for future development.

    The time-to-live parameter defines how far the multicast stream will reach, how long it will “live”.

    Get the TTL list from the MBone docs to explain the reach of ttl settings.

    MC-OUT 64 128.127.203.74

    MC-IN multicast-ip-address

    Receive a multicast feed

    Default = Disabled

    Just as you can provide a multicast feed with the MC-OUT directive, you can receive a multicast feed with this directive. These directives are mutually exclusive; you can’t give and take at the same time. Make sure the upstream multicast source has a time-to-live value that’s high enough to ensure its signal “lives” long enough to reach you.

    MC-IN 128.127.203.74

    Figure B.5 shows a multicast reflector hierarchy.

    Figure B.5 – A multicast reflector hierarchy

    NO-LOCAL-SENDERS

    Allow participants only to view, not interact, while on a reflector receiving an MC-IN or OBTAIN-BCC feed

    Default = Disabled

    This directive puts all participants into receive-only mode, which helps to limit the load on the reflector, to obtain better quality, and to prevent disruptive interferences by participants. It’s like setting the CONF-ID between 32768 and 65535, or setting MAX-SENDERS to 0, but this directive is specific to reflectors that are receiving MC-IN or OBTAIN-BCC feeds. Somewhat redundant, it allows flexibility in configuring your CU-SeeMe reflector.

    Figure B.6 shows an MC-IN feed with NO-LOCAL-SENDERS set. Compare this with figure B.5.

    Figure B.6 – The effect of NO-LOCAL-SENDERS

    ADMIT-SENDER ip-address

    Allow certain participants to override NO-LOCAL-SENDERS

    Default = Disabled

    This directive allows you to permit certain local participants to provide a CU-SeeMe stream when all others can’t. This is useful for staging a debate, for example, where only a few participants debate while others watch.

    ADMIT-SENDER 41.21.1.3

    ADMIT-SENDER 35.1.1.92

    Synchronization directives

    UNICAST-REF ip-address

    Specify one or more unicast reflectors to act as peers

    Default = Disabled

    Up to this point I’ve described reflector hierarchies, where upstream reflectors provide feeds and downstream reflectors receive feeds. This directive specifies one or more unicast reflectors that will act as peers; participants on one peer reflector are able to interact with participants on any other peer reflector. CU-SeeMe reflectors are unicast reflectors; use the MC-GROUP directive to specify multicast peer reflectors.

    When participants are spread out across the country or the world, setting up a group of reflectors through this method is much more efficient than having all the participants connecting to one reflector. Only one stream of data is being sent to each reflector from the others, instead of multiple streams to each client. The multicast version of this configuration is more efficient yet.

    Don’t specify your own reflector’s IP address.

    UNICAST-REF 41.21.1.2

    UNICAST-REF 35.1.1.91

    UNICAST-REF 10.6.72.9

    Figure B.7 shows one configuration of peer unicast reflectors.

    Figure B.7 – Unicast peers

    MC-GROUP ip-address

    Specify one or more multicast reflectors to act as peers

    Default = Disabled

    Compare this directive with UNICAST-REF. Participants on one peer multicast reflector are able to interact with participants on any other peer reflector. Since multicast is more bandwidth-efficient, this configuration is preferred to unicast peering.

    All peer multicast reflectors must be on the MBone or on a local area network that is multicast-capable across subnets.

    MC-GROUP 128.127.203.74

    Figure B.8 shows one configuration of peer multicast reflectors.

    Figure B.8 – Multicast peers

    Directives for working with Unix video clients

    NV-UC-PORT port-number

    Specify the unicast UDP port number for NV clients

    Default = Disabled

    NV (Network Video) is a Unix program like CU-SeeMe. The CU-SeeMe reflector can interoperate with NV clients. Because NV doesn’t have a default port that it communicates on, you must specify one. The NV client will need to know what port you choose, so this is something to note on your message of the day. You may choose any port between 1 and 65535.

    NV-UC-PORT 4444

    NV-MC-PORT port-number

    Specify the multicast UDP port number for NV clients

    Default = Disabled

    This directive is the multicast counterpart to NV-UC-PORT. Using multicast to interoperate with NV is preferred because multicast puts less of a load on your network. You may choose a port between 1 and 65535. As ever, you must be on the MBone or have a local area network that is multicast-capable across subnets, and have a UNIX kernel and CU-SeeMe reflector executable that are multicast-enabled.

    NV-MC-PORT 4444

    NV-MC-IN multicast-ip-address

    Receive CU-SeeMe streams from NV clients over multicast

    Default = Disabled

    NV is able to send CU-SeeMe streams (although you must tell your NV client to do this instead of its native encoding). This directive specifies an NV client that is sending you CU-SeeMe streams.

    NV-MC-IN 239.4.4.1

    NV-MC-OUT time-to-live multicast-ip-address

    Send CU-SeeMe streams to NV clients over multicast

    Default = Disabled

    The CU-SeeMe reflector will send CU-SeeMe streams to the NV clients you specify. The time-to-live parameter determines how far your signal will travel (how long the signal will “live”). If you’re using both the NV-MC-IN and NV-MC-OUT directives, both must have the same IP address as parameters.

    NV-MC-OUT 239.4.4.1

    NV-STREAMS number

    Limit the number of video streams sent to NV clients

    Default = 4

    This directive limits the number of streams your CU-SeeMe reflector will send to the NV client specified in the NV-MC-OUT directive, lessening the load on the network and on the computer running the NV client. (You can limit only the number of streams; you can’t pick and choose which streams to send.) You could limit the number of streams you’re sending and choose which streams those are by selecting who may participate in your conference.

    You may select up to 40 streams.

    NV-STREAMS 8

    VAT-UC-PORT port-number

    Specify the unicast UDP port number for VAT clients

    Default = Disabled

    VAT (Video Audio Tool) is a UNIX program like CU-SeeMe. The CU-SeeMe reflector can interoperate with VAT clients. Because VAT doesn’t have a default port that it communicates on, you must specify one. The NV client will need to know what port you choose, so this is something to note on your message of the day. You may choose any port between 1 and 65535.

    VAT-UC-PORT 4444

    VAT-MC-PORT port-number

    Specify the multicast UDP port number for VAT clients

    Default = Disabled

    This directive is the multicast counterpart to VAT-UC-PORT. Using multicast to interoperate with VAT is preferred because multicast puts less of a load on your network. You may choose a port between 1 and 65535. As ever, you must be on the MBone or have a local area network that is multicast-capable across subnets, and have a UNIX kernel and CU-SeeMe reflector executable that are multicast-enabled.

    VAT-MC-PORT 4444

    VAT-MC-IN multicast-ip-address

    Receive audio from VAT clients over multicast

    Default = Disabled

    VAT is able to send some forms of CU-SeeMe audio streams (delta-mod and Linear PCM). This directive specifies an VAT client that is sending you CU-SeeMe audio streams.

    VAT-MC-IN 239.4.4.1

    VAT-MC-OUT time-to-live multicast-ip-address

    Send audio to VAT clients over multicast

    Default = Disabled

    The CU-SeeMe reflector will send CU-SeeMe audio streams to the VAT clients you specify. The time-to-live parameter determines how far your signal will travel (how long the signal will “live”). If you’re using both the VAT-MC-IN and VAT-MC-OUT directives, both must have the same IP address as parameters.

    VAT-MC-OUT 239.4.4.1

    VAT-CONF-ID conference-id

    Set the conference identifier for VAT clients

    Default = Disabled

    This directive performs the CONF-ID function for VAT clients.

    VAT-CONF-ID 222

    Directives for controlling CU-SeeMe clients

    MIN-MAC-VERSION version-number message-string

    Force participants to use certain Macintosh CU-SeeMe clients

    Default = Disabled

    Revisions in CU-SeeMe clients provide better algorithms, better error-checking, and the like. You may want to force conference participants to use a particular CU-SeeMe client. This directive specifies the earliest Macintosh CU-SeeMe client that will be allowed to connect.

    MIN-MAC-VERSION 25

    Table B.2 shows the mapping for some Macintosh CU-SeeMe clients and the value you’ll specify to this directive. The current list is available from the CU-SeeMe Development Team.

    ReleaseParameter

    7.0b112

    7.0b1218

    7.0b1319

    7.0b1422

    7.0b1525

    MIN-PC-VERSION version-number message-string

    Force participants to use certain Windows CU-SeeMe clients

    Default = Disabled

    Revisions in CU-SeeMe clients provide better algorithms, better error-checking, and the like. You may want to force conference participants to use a particular CU-SeeMe client. This directive specifies the earliest Windows CU-SeeMe client that will be allowed to connect.

    MIN-PC-VERSION 2

    Table B.3 shows the mapping for some Macintosh CU-SeeMe clients and the value you’ll specify to this directive. The current list is available from the CU-SeeMe Development Team.

    ReleaseParameter

    0.342

    Flow Control directives

    MAX-MIN-SEND max-min-send penalty-time message-string

    Specify the minimum transmission rate

    Default = 10 1

    This directive is used to control the minimum transmission rate the participant is allowed to request of the CU-SeeMe client software. Participants that set a large value for their minimum are going to force the CU-SeeMe client to send data even when it thinks it’s unnecessary (the send rate cap will not fall below this setting regardless of packet loss).

    If a client has their client’s minimum transmission rate set higher than max-min-send they’ll be thrown off your CU-SeeMe reflector for penalty-time minutes after being shown message-string.

    MAX-MIN-SEND 40 2 Please don’t set your minimum transmission

    rate to more than 40 kbps on this reflector. You’ll be

    disconnected for two minutes until you lower your setting.

    //

    MAX-MAX-SEND max-max-send penalty-time message-string

    Specify the maximum transmission rate

    Default = 90 1

    This directive is used to control the maximum transmission rate the participant is allowed to request of the CU-SeeMe client software. Participants that set a large value for their maximum transmission rate may flood your CU-SeeMe reflector (the send rate cap will not rise above this setting regardless of packet loss).

    If a client has their client’s maximum transmission rate set higher than max-min-send they’ll be thrown off your CU-SeeMe reflector for penalty-time minutes after being shown message-string.

    MAX-MAX-SEND 120 2 Please don’t set your maximum transmission

    rate to more than 120 kbps on this reflector. You’ll be

    disconnected for two minutes until you lower your setting.

    //

    MAX-MIN-RECV max-min-recv penalty-time message-string

    Specify how large the minimum receive rate may be

    Default = 10 1

    The participant sets a minimum receive rate on the CU-SeeMe client software. (The reflector’s rate cap will not fall below this setting regardless of packet loss.) This directive permits the participant to connect to the CU-SeeMe reflector only if that setting is below max-min-recv. If it’s larger they’ll be thrown off your CU-SeeMe reflector for penalty-time minutes after being shown message-string.

    The complementary directive is MAX-MAX-RECV.

    MAX-MIN-RECV 40 2 Please don’t request more than 40 kbps for

    a minimum transmission rate from the reflector.

    You’ll be disconnected

    for two minutes until you lower your setting.

    //

    MAX-MAX-RECV max-max-recv penalty-time message-string

    Specify how large the maximum receive rate may be

    Default = 10 1

    The participant sets a maximum receive rate on the CU-SeeMe client software. (The reflector’s rate cap will not rise above this setting regardless of packet loss.) This directive permits the participant to connect to the CU-SeeMe reflector only if that setting is above max-max-recv. If it’s larger they’ll be thrown off your CU-SeeMe reflector for penalty-time minutes after being shown message-string.

    The complementary directive is MAX-MIN-RECV.

    MAX-MAX-RECV 600 2 Please don’t request more than 600 kbps

    for a maximum transmission rate from the reflector. You’ll be

    disconnected for two minutes until you lower your setting.

    //

    DEFAULT-MIN-RECV default-min-recv

    Control minimum transmission rate for old-style clients

    Default = 14

    This directive controls the minimum transmission rate from the CU-SeeMe reflector to the CU-SeeMe client software. It’s used for older CU-SeeMe clients, which don’t have loss-reporting capability. If you allow clients older than CU-SeeMe for Macintosh 0.80x and CU-SeeMe for Windows 0.65x to connect to your CU-SeeMe reflector then you’ll want to use this directive.

    The complementary directive is DEFAULT-MAX-RECV.

    DEFAULT-MIN-RECV 10

    DEFAULT-MAX-RECV default-max-recv

    Control maximum transmission rate for old-style clients

    Default = 200

    This directive controls the maximum transmission rate from the CU-SeeMe reflector to the CU-SeeMe client software. It’s used for older CU-SeeMe clients, which don’t have loss-reporting capability. If you allow clients older than CU-SeeMe for Macintosh 0.80x and CU-SeeMe for Windows 0.65x to connect to your CU-SeeMe reflector then you’ll want to use this directive.

    The complementary directive is DEFAULT-MAX-RECV.

    DEFAULT-MAX-RECV 300

    DEFAULT-INIT-RECV default-init-recv

    Control initial transmission rate for old-style clients

    Default = 40

    This directive controls the beginning or initial transmission rate from the CU-SeeMe reflector to the CU-SeeMe client software. It’s used for older CU-SeeMe clients, which don’t have loss-reporting capability. If you allow clients older than CU-SeeMe for Macintosh 0.80x and CU-SeeMe for Windows 0.65x to connect to your CU-SeeMe reflector then you’ll want to use this directive.

    DEFAULT-INIT-RECV 80

    RATE-ADAPT no-loss-growth loss-threshold

    Control reflector transmission increase and data loss threshold to back off

    Default = 5 2

    When your CU-SeeMe reflector sends a stream to a client that reports zero data loss, the reflector will increase the data it sends by no-loss-growth percent until the client reports a data loss of loss-threshold percent, at which time the reflector will back off (stop the increase).

    Use the OLD-RATE-ADAPT directive (below) for old-style clients.

    RATE-ADAPT 15 5

    OLD-RATE-ADAPT old-no-loss-growth old-loss-threshold

    Control reflector transmission increase and data loss threshold to back off when dealing with old-style clients

    Default = 5 2

    When your CU-SeeMe reflector sends a stream to a client that reports zero data loss, the reflector will increase the data it sends by no-loss-growth percent until the client reports a data loss of loss-threshold percent, at which time the reflector will back off (stop the increase).

    Use the RATE-ADAPT directive (above) for modern CU-SeeMe clients (CU-SeeMe for Macintosh 0.80x or newer; CU-SeeMe for Windows 0.65x or newer).

    OLD-RATE-ADAPT 15 5

    Refmon, the CU-SeeMe Reflector Monitor

    Refmon is software that you’ll use to monitor the operation of your CU-SeeMe reflector. You can monitor your reflector either locally or remotely. Refmon uses a command-line mode of operation much like the CU-SeeMe reflector itself, and like the reflector, runs on your UNIX box. With Refmon you’ll who is on the reflector, how long its been up for; you can kick people off the reflector, and take the reflector down.

    Starting Refmon

    All Refmon needs to know from you is what machine to monitor. To monitor the CU-SeeMe reflector running on flapdoodle.jungle.com you’d type:

    refmon -s flapdoodle.jungle.com

    You’ll see Refmon trying to connect to the machine you’ve specified:

    Waiting for connection to 141.214.138.248 … Connected

    >

    and then present you with a prompt. The following commands are understood by Refmon.

    Quit

    Refmon ceases operation. Has no effect on the reflector it’s monitoring.

    Version

    Refmon reports what version of the reflector you’re running.

    Who

    Refmon reports the names, IP addresses, and stream settings of the participants. The stream setting will show a combination of ‘C’ (connected), ‘R’ (receive), and ‘V’ (video-send). For example:

    > who

    CLIENT: John Lauer@141.214.138.202 CR

    CLIENT: internetRADIO@141.214.138.249 CRV

    Total # of clients 2

    senders 1

    lurkers 1

    Maven

    Refmon reports the participants connected to the CU-SeeMe reflector via Charley Kline’s Maven audio software.

    Uptime

    Refmon reports what time the CU-SeeMe reflector was started.

    Term

    Refmon terminates operation of the CU-SeeMe reflector without giving any warning to the participants.

    Param

    Refmon reports the current configuration of the CU-SeeMe reflector. Similar to looking at the reflect.conf file, using Refmon is preferable because you’ll see how the reflector interpreted your configuration commands.

    Help

    Refmon reports the command verbs it understands. It’ll look something like:

    > help

    valid commands are: quit version help who term param maven uptime

    The CU-SeeMe reflector’s log file

    The CU-SeeMe reflector generates a log file during its operation. The reflector writes a log entry when a user connects, disconnects, speaks, or is updated. A typical log file looks like:

    client not found and initial message is not Open

    incoming control message new msg_sock is 8

    PARAM received on control socket

    Client at source 130.166.109.137 is opening a connection

    updating client

    client count 0

    seq 0

    updating client Maren Steiner client count 0

    seq 44

    Client at source 141.214.138.249 is opening a connection

    updating client

    client count 0

    seq 0

    internetRADIO is speaking

    Maren Steiner wants to receive audio from John Lauer

    updating client internetRADIO client count 2

    seq 9

    internetRADIO wants to receive audio from John Lauer

    Maren Steiner wants to receive audio from John Lauer

    updating client internetRADIO client count 2

    seq 9

    internetRADIO wants to receive audio from John Lauer

    Maren Steiner wants to receive audio from John Lauer

    updating client internetRADIO client count 2

    seq 9

    internetRADIO wants to receive audio from John Lauer

    maximum # of senders exceeded

    deleting client Carroll Chiou

    Even without using the CU-SeeMe reflector’s debug option, the log file has lots of useful information about its operation. You can search for lines that say “Client at source … is opening a connection” to see connection activity. There are many other ways of parsing the log file, and many other trends and statistics you can derive from it.

    Advanced reflector usage

    This subsection deals with …

    Linking reflectors

    If you’ve followed the chapter this far, reading (or at least skimming) each of the CU-SeeMe reflector directives, you’re aware that CU-SeeMe reflectors can be linked together for huge broadcasts. You’re also aware that CU-SeeMe, VAT, and NV can all interoperate to provide audio and video to participants. Streams can be sent downstream, or can be synchronized with peer reflectors. This subsection is all about different ways of linking reflectors, of making efficient use of bandwidth and distributing the load between machines.

    Unicasting

    The Mulicast Backbone, the MBone, is a series of routers that forward incoming packets to other networks. It’s configured so that streams never traverse any wire on the network twice; it’s a very efficient broadcast system. You can mimic this technique with CU-SeeMe reflectors, which are unicast (if they were multicast the routes would be automatically calculated), and by educating the participants, who must connect to the closest reflector.

    For example, consider a two-reflector setup. One CU-SeeMe reflector is in New York City, the other in San Francisco. Figure B.9 shows a correct arrangement of reflectors and participants.

    Figure B.9 – Mimicing MBone correctly

    All the San Francisco participants connect to the San Francisco CU-SeeMe reflector; all the New York City participants connect to the New York City CU-SeeMe reflector. The data are being sent between the reflectors only once, which is all that’s needed.

    Consider an inefficient variant, shown in figure B.10.

    Figure B.10 – Mimicing MBone incorrectly

    One San Francisco participant has connected to the New York City reflector. Now all of the data are being sent across the Internet twice, a redundent inefficiency that puts quite a load on the network. Earlier in this chapter I showed how a small (five-person) CU-SeeMe videoconference resulted in 2 mbps of data running through the reflector. (It was figure B.1, if you’re thumbing around.) This errant San Francisco participant has, by connecting to the New York City reflector, caused 2 mbps to needlessly travel across the USA. Imagine now a dozen reflectors, with users connecting to them willy-nilly, without regard for flooding the network. Whether on the Internet or on a small-scale campus or corporate LAN, this easy-to-create inefficiency should be taken into consideration. I’m not objecting to inefficiency for it’s own sake, but its results: poor videoconferencing performance, poor network throughput for others sharing the network, and overall dissatisfaction.

    It’s vitally important for reflector operators to educate their audiences to be good net citizens.

    Networks are a shared resource; being able to communicate with others is what makes them attractive. Limiting the load you place on this shared resource is a matter of some concern. The CU-SeeMe clients and the CU-SeeMe reflector use UDP datagrams, which can drown out regular TCP datagrams, such as those used by the World-Wide Web and the File Transfer Protocol. You must know the state of your LAN, and whether it can handle the load that running a CU-SeeMe reflector will place upon it.

    This is true of local campus and corporate networks, but its especially true when you send streams into the Internet. Internet service providers quickly become upset when you flood them; they become irate if they find out you’re doing it unnecessarily. Efficiency is about sharing. Be knowledgeable about your networking environment. Be pro-active; limit the load by properly configuring the reflect.conf file and requiring a low cap rate.

    In the CU-SeeMe reflector 4.00B1 Read Me file, Richard Cogger, Tim Dorcey, and John Lynn write:

    Major changes are aimed at being “kinder to the Internet” by not sending a lot of traffic that the network would lose anyway. Reflector operators will have more control over (and responsibility for) how pushy CU-SeeMe traffic will be compared to other Internet traffic.

    Of course, we recommend everyone be very polite unless you know you are using only your own facilities.

    The effect is that a mix of modem-connected and LAN-connected participants will work much better.

    Earlier versions of the CU-SeeMe reflector send complete streams to participants running the CU-SeeMe clients over a modem, participants who were destined to lose most of that data. Earlier you saw how a full reflector stream could be 500 kbps; imagine that being sent to a client on a 28.8 kbps modem. Clearly less than five percent of the data can make it through.

    Multicasting

    Multicasting is a most powerful tool for making efficient use of bandwidth and distributing the load. The situation portrayed above in are resolved invisibly and automatically with multicast. The design of a multicast network makes redundant data nearly impossible.

    Multicasting capabilities are just starting to become widespread. As it does, expect to see more use of networking technologies for data-intensive tasks such as videoconferencing. Does your operating system do multicast? Here’s a list:

    What is the MBone? The following blurb is taken from the MBone web pages, found at http://www.eit.com/techinfo/mbone/mbone.html

    MBONE stands for the Virtual Internet Backbone for Multicast IP. IP-Multicast is the class-D addressing scheme in IP implemented by Steve Deering at Xerox PARC. It was adopted at the IETF March 1992 meeting and acquired the name MBONE after the July 1992 IETF meeting.

    IP Multicast-based routing facilitates distributed applications to achieve time-critical “real-time” communications over wide area IP networks through a lightweight, highly threaded model of communication. The IP Multicast routers (referred to as “mrouters”) take the responsility of distributing and replicating the multicast data stream to their destinations as opposed to individual IP hosts. The MBone topology of mrouters is designed in such a manner that it facilitates “efficient” distribution of packets without congesting any node inappropriately.

    Multicast Techniques

    So now you’ve got your Mbone feed and you recompiled your kernel on your unix machine. What now? Well, try receiving some multicast reflector feeds with the MC-IN, MC-OUT settings. Then try synchronizing reflectors with the MC-GROUP setting.

    You could potentially transmit a high-quality video stream to the world over a simple ISDN link using multicast; with unicast and a reflector this isn’t possible. THIS IS IMPORTANT FOR ALL YOU HOME ISDN FOLKS.

    Figure B.11 illustrates the problems of trying to use CU-SeeMe in unicast; each participant causes the CU-SeeMe reflector to transmit a duplicate stream, which it can’t do because of the bottleneck – ISDN just isn’t a big enough “pipe”.

    Figure B.11 – An ISDN/unicast bottleneck

    Figure B.12 shows the same network topology, but with participants being fed by multicast. Since the stream is transmitted over the network only once, all participants can join and receive the data being broadcast.

    Figure B.12 – Multicast saves the day

    Showing an event

    Having made it this far in the chapter, it’s time to go public and show an event. You have the capability to send streams to the four corners of the world. Now you can fill in the gaps; what’s local to you that we would appreciate seeing? Once you find something, how do you let us know you’re trying to be a junior Ted Turner?

    Promoting your event

    In , you saw the various mailing lists used by the CU-SeeMe community. Two of those lists, the CU-SeeMe Events list and the CU-SeeMe Discussion List are used for event publicity.

    Remember to include the following essential information when you promote your event:

    {{imgFileRef(“ABcus14.gif”)}

    Figure B.14 – The CU-SeeMe Events Guide form

    In addition to the mailing lists, John Lauer has created a CU-SeeMe Events Guide on the World-Wide Web. (It was this contribution to the CU-SeeMe community that brought John to my attention, leading to John’s considerable contribution to this chapter.) Located at http://www.umich.edu/~johnlaue/cuseeme/ the CU-SeeMe Events Guide has a forms interface (figure B.13) for you to fill out.

    Figure B.14 – The CU-SeeMe Events Guide form

    The information you submit is compiled twice daily into a new events web page. If you’ve entered a one-time event it’ll be listed by date. If you’ve entered an on-going event, it’ll appear in another section. The CU-SeeMe Event Guide doesn’t yet generate a posting to the mailing lists, but we’re hoping.

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

    |

    |

    |

    |

    |

    |

    |

    |

    This page

    is

    1993-2006 by ,

    via the Creative Commons License. Questions and comments? Send

    to the Geek Times Webmaster. (Domain and web content hosting at .)

    Leave a Reply

    Your email address will not be published.