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

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:

• the geographical location of the CU-SeeMe reflector
• the organization that owns the reflector
• the name of reflector operator
• the email address of operator
• the URL of a web site that contains more information about this reflector site
• the maximum data transmission rate and the consequences should you send at a higher rate
• the earliest version of CU-SeeMe you can use to connect to this CU-SeeMe reflector
• the VAT port number

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

Release	Parameter
7.0b1	12
7.0b12	18
7.0b13	19
7.0b14	22
7.0b15	25

MIN-PC-VERSION version-number message-string

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.

Release	Parameter
0.34	2

Flow Control directives

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

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

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

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

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

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

The complementary directive is DEFAULT-MAX-RECV.

DEFAULT-MAX-RECV 300

DEFAULT-INIT-RECV default-init-recv

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

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

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:

• UNIX: almost all support multicast

• Macintosh: Open Transport 1.1 is scheduled to support multicast

• Windows: several options support multicast

  • Windows for Workgroups with Microsoft's TCP32 stack

    FTP Software's PC/TCP and OnNet for Windows and DOS

  • WatTCP for Windows and DOS

  • Windows NT built-in TCP/IP

  • Windows 95 built-in TCP/IP

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 Chapter 6, The CU-SeeMe User's Guide, 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:

• Who: Who are you, and how can we get in touch with you? At a very minimum, we need your email address.

• What: What are you going to be sharing with us?

• Where: What reflector (or reflectors) will be used for your presentation? (If you want to solicit reflector operators to help you in preparation or presentation, use the CU-SeeMe Reflector Operators List.)

• When: When should we sit down at our computers to see your presentation? Please give us the time relative to someplace we know; I don't offhand know my offset from Universal Coordinated Time (UCT), but I can convert from any time in the USA. Here's an example that covers the USA, Europe, Australia, and Asia:

  Here's when you can see our show:

  San Francisco: Tue 25 July 1995, 1000 local time (UCT-7)
  New York City: Tue 25 July 1995, 1300 local time (UCT-4)
  Paris: Tue 25 July 1995, 1800 local time (UCT+2)
  Perth: Wed 26 July 1995, 0200 local time (UCT+8)
  Tokyo: Wed 26 July 1995, 0300 local time (UCT+9)
  

• Why: Give us some background, some context. A few paragraphs of history and notes will put us in the right frame of mind for your presentation.

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