New Reflector binaries available for 4.00B3 (It works again!)

David O. Bundy (dbundy@wpine.com)
Mon, 25 Sep 95 16:18:07 EDT


Reflector news!

4.00B3 is now available on the Cornell and White Pine web pages and
ftp servers.

White Pine:
follow the links from

http://www.wpine.com/cu-seeme.html

or directly

http://www.wpine.com/reflector.html

or with ftp

ftp://ftp2.wpine.com/pub/product/demo/reflector/4.0B3

Cornell:

ftp://cu-seeme.cornell.edu/pub/cu-seeme/reflector/...

This has fixes for the things that 4.0B1 and 4.0B2 broke.
Namely the BCC, NV/VAT and MC options now work again. Please use these
reflector binaries going forward and remove 4.0B1 and 4.0B2.

Please see the release notes below for other changes/fixes.

NOTE: Not all the Binaries are there yet, we are working on that this
week. Keep checking the web and ftp sites for them. PS: the sunos version
will work on Solaris until we get that binary made.

************************************************************************
CU-SeeMe (tm) Reflector Version 4.00B3 September 25, 1995

Reflector ReadMe File by Richard Cogger, Tim Dorcey, John Lynn
(Additions by David Dworkin, David Bundy)

This is a BETA version of the newest release of the CU-SeeMe
reflector program, version 4.00B3.

---------------- Overview ------------------------

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. Also, audio is given priority and becomes much more robust.

These changes operate with the current Mac and Windows desktop apps.
However, the control dynamics and accuracy are limited because of the
form of the current loss reports. A new version of the Mac app will
be out (in alpha) in about a week, and beta in another week or so,
which will work much better and also have a bunch of new goodies. The
corresponding Windows version should be just a few days behind. The
reflector will probably be updated (perhaps more than once) at this
time too.

--------------- New in 4.00B3 ------------------

1) Fix bug where changes in client settings for min/max reception rate
were being ignored while a connection was in progress.

2) Fix bug where a few incoming and outgoing packets were not being
counted in data rates.

3) Updated outgoing data rate control to be consistent with new packet
formats for RateControlPacket and RateReplyPacket. Incremented internal
VERSION_NUM to 4 (so clients will know). Moved generation of
RateControlPacket's to clock rather than OC trigger.

4) Implemented incoming data rate control (using new packet formats), with
feedback to source on max of its data that is being forwarded.

5) Fixed so that ADMIT-GENERAL-BCC, NV, VAT, NV-MC, VAT-MC and MC-IN, MC-OUT
work. Problem was generated by new bandwidth control processing. All
options now work as stated in the documentation.

6) Added "-broadcast" option on starting the reflector. This forces the
reflector to generate OpenContinue packets for all the CLIENTS connected to a
reflector. This will then allow other reflectors chained in with BCC or MC
to be able to see all the user's sending video/audio to the main reflector.

** Please note: Only use this if you want to force all video/audio to be
sent from all on the reflector as it forces all senders to be broadcast.
This should be used when a large broadcast with chained reflectors with
BCC and MC is contrived with only one sender.

7) Upped the compiled in maximum number of CU-SeeMe users attached to a
reflector to be 100, so those who have a large LAN broadcast and have higher
Lurker's allowed etc.

8) Bug not fixed yet: You can not use MC-OUT and NV-MC-OUT on one reflector.
There is a bug which only lets the NV send multicast and the CU-SeeMe
multicast data is not sent. To get around this set up the main reflector to
do one of the MC's and a second chained reflector to do the other MC.

--------------- New in 4.00B2 -------------------

1) Fix bug in audio with new clients; since we have audio controls for
each lurker now, we had to change the logic for the processing of audio
to and from that lurker.

2) Fix bug on 64-bit systems, such as DEC Alpha. The use of 'long' variables
is prevalent throughout the code, but the clients would pass data which ends
up being 32-bit in network packets. This data was thought to be 64-bit on the
reflector, and a connection could not be established.

3) Fix bug for systems that are bit-swapped (such as Linux); was not being
compiled with the LITTLE_BITFIELDS flag. Now we auto-detect if we need that
flag. (Among other things, this was preventing NV clients from connecting).

4) Fix bug where newest Mac client would crash reflector on SunOS and Solaris
(structures were not falling on longword boundary)

--------------- New in 4.00B1 -------------------

1) New facilities allow customized outgoing data rates for each
CLIENT. In this version, the adaptation is achieved by dropping
random video packets, which is not ideal, but better than letting it
happen in the net. There are 2 basic forms of rate control, one
designed to work with existing versions of CU-SeeMe (0.80b2 or earlier
on Mac; 0.65 or earlier on PC) and one designed for updated versions
of the application, which have better loss reporting and new user
interface items for reception rate control.

The basic operation for the newer applications is that clients report
minimum and maximum rate values, within which they would like their
actual reception rate to be bounded. The reflector then chooses a
rate within these bounds, based upon observed packet loss on traffic
from the reflector to that client. Options are provided so that
reflector operators can police acceptable values for the minimum and
maximum parameters (MAX-MIN-RECV and MAX-MAX-RECV options) and also to
tune the rate adaptation algorithm (RATE-ADAPT option).

The operation is similar for older clients, except that the reflector
sets the minimum and maximum rate bounds (DEFAULT-MIN-RECV &
DEFAULT-MAX-RECV options). Also, the reflector operator may specify
an initial rate (DEFAULT-INIT-RECV), which serves as a starting point
until loss information can be gathered.

2) In conjunction with the rate reporting necessary to implement 1),
new clients also now report minimum and maximum bounds on their own
transmission rate. Reflector operators can now police acceptable
values for those parameters, in effect, controlling how responsive
client transmission rates are to packet loss (MAX-MIN-SEND and
MAX-MAX-SEND options).

3) New Distribution:

* We no longer provide sources to the reflector code except under
license (i.e., the reflector sources are provided the same way as the
sources to the desktop apps). We will provide binaries for most Unix
platforms.

* 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 at White Pine, our Master Licensee, and posted there and at
Cornell. For platforms that support IP multicast, two binaries are
provided, one compiled for multicast and one without the multicast
support.

* Copyright notices (end of this readme) are updated to permit, as
before, unrestricted use and copying, but now they will restrict
redistribution to "whole and unmodified" and for non-commercial
purposes only.

* 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 mods back to Cornell and White Pine. Both of
these licenses will be free or nominal-cost (administrative charge).
You can also get a commercial license from White Pine.

------------CU-SeeMe Desktop Videoconferencing System--------------------

CU-SeeMe, a desktop videoconferencing system, for Macintosh and PC,
is available free from Cornell University under copyright of Cornell
and its collaborators. CU-SeeMe provides a one-to-one conference, or
by use of a reflector, a one-to-many, a several-to-several, or a
several-to-many conference depending on user needs and hardware
capabilities.

CU-SeeMe is intended to provide useful conferencing at minimal cost.
Receiving requires only a PC with a screen capable of displaying 16
grays and a connection to the Internet. PC's require audio hardware
to receive audio. Sending requires the same plus a camera and
digitizer (see specs below) which can cost as little as $100 to add
on.

WARNING: Although being improved with each version, CU-SeeMe is not
mature production software--USE AT YOUR OWN RISK. And also, PLEASE
TREAT THE INTERNET KINDLY--Reflector operators have an extra
responsibility to ensure that users connecting will not grossly
overload the network. Many, many folks connected to the Internet can
use CU-SeeMe with default settings and cause no problem to anyone
else; but unfortunately, not everyone. The default parameters for the
reflector will work well in many circumstances but not all. Please
think it through as you set up.

------------ History -----------------------------

CU-SeeMe was initially written for the Macintosh by Tim Dorcey with
design assistance and sponsorship by Richard Cogger of the Advanced
Technology group in the Network Resources division of Cornell
University's Information Technology department (CIT). Important early
contributions came from: Cornell University Medical Colleges (CUMC)
and Scott Brim. Steve Edgar at Cornell created the first Windows
version, and Rich Kennerly carried on during the past year and a half;
Steve has recently rejoined the team. Larry Chace did the AuxData
transport for the Mac and is now porting it to Windows. John Lynn has
done most of the work on the reflector. Much of the nv and vat
compatibility code was added by Mike Grafton. Tim Dorcey did the code
for customizing bw to each participant.

Since Oct. 1, 1993, the CU-SeeMe Project receives funding from the
National Science Foundation. A very significant collaborative effort at
Cornell University Medical Colleges (CUMC) is contributing substantial
expertise and code.

This material is partially based on work sponsored by the National
Science Foundation under Cooperative Agreement No. NCR-9318337. The
Government has certain rights in this material.

Since June 1, 1995, White Pine Software of Nashua NH is Cornell's Master
Licensee for commercial development and marketing of CU-SeeMe
technology. They will provide both end-user products and source
code licensing to OEM customers. Cornell will continue to develop
and distribute freeware versions .

Copyright 1993, 1994, 1995, Cornell University
See Copyright notices at the end of this document.

-------------- Reflector change-history ------------------

Changes between 3.00B3 and 3.00B6

1) Fixed a bug that caused the reflector to run out of slists. This resulted
in the reflector exiting with the message "No more free slists".

2) Added a kill-client command to refmon. Using refmon you can now type

kill 132.236.100.200 Please go away

The message "Please go away" will appear on the clients screen and he
will be disconnected from the reflector. Note there is nothing that
prevents him from reconnecting.

3) Added some casts to eliminate some compiler complaints.

4) Added an ALLOW parameter to the configuration file. This is used to always
allow the specific IP address to connect to the reflector. This allows the
specified IP address to always connect even after the maximum # of participants
limit is reached.

5) Fixed a bug that caused the reflector to crash when receiving an unknown
message type from a vat client.

6) Added some ifdefs so that the reflector should now compile under LINUX.

7) No-local-senders now also applies to audio and aux data.

8) Fixed a bug in refmon so that it no longer crashes if started with no or
bad arguments.

9) Fixed a bug that was trashing memory when opening the log file.

10) Added network masks for restrict, admit, deny, and allow configuration IP address.
In the config file one can now say

deny 132.235:16 This network is not allowed access to the reflector
//

This will cause all IP addresses with the first 16 bits equal to 132.235 to be
denyed access to the reflector.

11) Allow the user to enter a different deny message for each denyed address

12) Fixed some bugs having to do with the transmission rate CAP.

13) If the reflector is configured with a conference ID greater then 32768 (high bit
on) clients that don't know the correct ID are still allowed to connect, but are
not allowed to send video, audio, or aux data - these clients are called observers.
If the reflector is configured with no-local-senders, all clients not on the
ADMIT-SENDER list are also considered to be observers. Reflectors will now no
longer pass information along to other reflectors for those participants which are
labeled as observers.

14) If a reflector crashed while a refmon was connected, the reflector would no be able to
immediately restart, an error message reffering to socket already in use would appear.
This has now been fixed.

-----------

Changes between 3.00B2 and 3.00B3

1) Added default reflector messages for max-lurkers and
max-senders.

2) fixed several bugs having to do with supporting VAT
clients.

-----------

Changes between 3.00B1 and 3.00B2

All of the changes between versions B1 and B2 have been
bug fixes - no new features have been added. There are
still some outstanding bugs that haven't been corrected in
B2 and you should anticipate another bug fix version B3
to be out in a week or two.

1) The conference id feature was basically broken

2) The MAX-SENDERS and MAX-LURKERS configuration
features had some problems.

3) When using the Mbone tools vat and nv there
was a problem if a client went from being
a vat and nv client to just a vat client.

4) The correct version number was not always being
set for nv clients, so sometimes when looking at
the version information on the CUSM window, it
would not say nv client.

fix a bug in the conference id

fix a couple of bugs with the max senders and max lurkers when the
client made a transition without disconnecting

fix a bug in the calculation of the client count

fix a bug in that when a client is both nv and
vat and the nv session disappears then the vat
session keeps the guys window up on the CUSM
screan because the seq numing in the make OCP
for vat clients routine was never being incremented.

1/6 set the right version # in the OCP for vat OCP's

1/6 fix a bug in the calculations of # of lurkers and
# of senders

------------ Reflector Operations and Configuration------------

If you are connecting reflectors together, make sure that all
the reflectors are using the same version.

Reflector Operation

The reflector is started with a single optional parameter,
the configuration file name. If no configuration file is
specified, the reflector tries to open the default
configuration file called reflect.conf. If that file is not
found, then no configuration information is specified and the
default values for all configuration parameters are used.
The configuration file is an ASCII text file. Each line
begins with a keyword which specifies the parameter
configured. Some of the keywords are followed by arguments
that specify the value(s) for that configuration parameter.
Any line which begins with a semicolon (;) is a comment line
and is ignored by the reflector.

The following are the configuration keywords and their
parameters if any exist.

The keywords RESTRICT, ADMIT, DENY, and ALLOW take either
a standard IP address or an IP address mask. The format of
the mask is some portion of an IP address followed by a
colon followed by the length of the mask. For example,
132.236.101:24 would refer to any address in which the
first 24 bits were 132.236.101.

DEBUG

Specifying DEBUG causes the reflector to print out a large
amount of debugging information. This information is
probably not particularly meaningful to anyone but the
reflector programmer and will slow down the operation of the
reflector, so DEBUG in general should not be added to the
configuration.

SELF-REFLECT

SELF-REFLECT causes the reflector to send your own CU-SeeMe
stream back to you. This also is a sort of debugging aid,
allowing you to make sure your reflector is up and running.

REFMON ip-addr

REFMON is used to specify the IP address of the UNIX
workstation that is allowed to access the reflector using the
refmon application. If no REFMON is specified in the
configuration, then a refmon application running on any
workstation will be allowed access to your reflector. If the
IP address is specified as 0.0.0.0, then no refmon anywhere
will be granted access. The refmon application is documented
later on As refmon can be used to kill the reflector, it's
probably best to include this parameter in all configuration
files.

CONF-ID conference-id msg-string
//

Specifying CONF-ID allows you to have a measure of privacy on
a public reflector. In any Mac version of CU-SeeMe above
0.70 or any PC version above 0.34, the application will allow
the user to optionally specify a conference id when opening a
connection. The default conference id is 0 which is also the
reflector's default conference id. When the reflector is
configured, defaulted, or set to zero all user conference
ID's are accepted. If the reflector is configured with a
conference ID other then 0, then any incoming CU-SeeMe
conference id must match the conference id in the reflector.
The conference ID is a 16 bit value (range from 0 to 65535).
If the reflector's conference ID is less then 32768 (high bit
not on) and the conference ids do not match, then that
participant is not added to the conference. If the
reflector's conference ID is between 32768 and 65535 (high
bit on) and the conference ids do not match, then that
participant is allowed to join the conference but is
prohibited from sending either audio or video. To have a
private conference, without uninvited participants, you would
pick a random conference id in the appropriate range, add it
to the configuration file, make this number known to all of
your invited guests, and ask them to specify this conference
id when connecting to the reflector. The msg string is an
ascii string terminated by a carriage return followed by two
back slashes. This is the string that will appear on a
participant's screen if he tries to connect with the wrong
conference ID. Maximum length of msg-string is 80 characters
for this and all other msg-strings. Also see CONF-MGR below.

CONF-MGR ip-address

The CONF-MGR ip address, is the ip address of a participant
that is permitted to set the conference id when he connects.
This allows a designated participant to dynamically establish
a restricted conference without having to manually
reconfigure the reflector. When the conference manager
connects to a reflector he can specify a non-zero conference
ID number. All participants currently connected with this
correct ID number will remain connected. All participants
currently connected with the wrong conference ID or zero will
be disconnected and the message string that was specified in
the CONF-ID configuration parameter will appear on their
screen (or they will have their sending halted, for ID >
32768). All future connection attempts will also have to
contain the correct conference ID The conference ID remains
in effect until the conference manager resets it to another
number or perhaps 0 to make it an unrestricted conference.

CAP cap hold-down-time msg-string
//

CAP is used to enforce transmission rate limits for those
participants that connect to your reflector. If a
participant sets his maximum transmission rate above the cap
that you specified he will automatically be disconnected from
the reflector and prohibited to reconnect for the specified
hold-down-time. Cap is specified in kilo bits per second and
hold-down time is specified in minutes. The default value
for cap is 80 kilo bits per second and the default value for
hold-down-time is 1 minute.

ALLOW ip-address msg-string
//
or
ALLOW ip-address-mask:len msg-string
//

ALLOW is used to always allow the specific IP address to connect to
the reflector. This allows the specified IP address to always connect
even after the maximum # of participants limit is reached.

ADMIT ip-address msg-string
//
or
ADMIT ip-address-mask:len msg-string
//

ADMIT is another mechanism you can use to limit the
participants in a conference. By adding an ADMIT IP address
line for each invited participant, the reflector will
restrict the conference to only those participants who have
an IP address which matches one of the IP addresses specified
by an ADMIT line. The msg string is an ascii string
terminated by a carriage return followed by two back slashes.
This is the string that will appear on a participant's screen
if he tries to connect but he is not on the admit list.
Currently, there must be a message string specified with each
ADMIT in the configuration file, but only the message string
associated with the last ADMIT in the configuration file will
be used. For now, that means you should just enter in some
dummy string for each ADMIT in the configuration file except
the last one. In some future version of the reflector all
the message strings will be optional so that this nuisance
will go away.

MAX-PARTICIPANTS maxallowed msg-string
//

MAX-PARTICIPANTS allows you to limit the load on your
reflector to the specified number of participants. The
maxallowed range is 0 to 40, with the default equal to 20.
The msg string is an ascii string terminated by a carriage
return followed by two back slashes. This is the string that
will appear on a participant's screen if he tries to connect
but the maximum number of allowed participants has been
exceeded.

MAX-SENDERS maxsendersallowed msg-string
//

MAX-SENDERS allows you to limit the number of video senders
on your reflector to the specified number of participants.
The maxsendersallowed range is 0 to 40, with the default
equal to 20. The msg string is an ascii string terminated by
a carriage return followed by two back slashes. This is the
string that will appear on a participant's screen if he tries
to connect as a sender but the maximum number of video
sending participants has been exceeded.

MAX-LURKERS maxlurkersallowed msg-string
//

MAX-LURKERS allows you to limit the number of receive only
participants on your reflector to the specified number of
participants. The maxlurkersallowed range is 0 to 40, with
the default equal to 20. The msg string is an ascii string
terminated by a carriage return followed by two back slashes.
This is the string that will appear on a participant's screen
if he tries to connect as a non video sender but the maximum
number of lurkers has been exceeded.

LOG filename

The reflector logs a small amount of information such as each
participants arrival and departure from the conference in a
log file. The default name for this file is reflect.log. To
change the name of this file specify the LOG parameter with a
different file name.

LOG-LIMIT log-file-line-limit

If you have a busy reflector running for several days the log
file can grow quite large. Use LOG-LIMIT to limit the number
of lines in the log file. The default is 10,000 lines of log
information. After the log file line limit is reached the
reflector will erase the log file and start a new one with
the same name. If you specify a log file line limit of 0, no
log file will be created.

MOTD motd-string
//

MOTD is used to specify the message of the day. In any Mac
version of CU-SeeMe above 0.70, or an PC version above 0.34
the application will display any motd messages when a user
first connects to a reflector. The motd can be up to 800
characters in length. The message of the day string is an
ascii string terminated by a carriage return followed by two
back slashes.

ADMIT-BCC-CLIENT ip-address

ADMIT-BCC-CLIENT is used to cause the reflector to send a
blind carbon copy of all of the CU-SeeMe streams to another
reflector. This is used if you are putting on an event where
there are a small number of active participants and a large
number of passive viewers. The primary conference is run off
of the main reflector. This reflector is configured with one
or more ADMIT-BCC-CLIENT lists causing it to send CU-SeeMe
streams to other reflectors. The passive audience then
connects to these other reflectors on the "reflector net" to
watch the main event.

ADMIT-GENERAL-BCC count id

Often when setting up an event reflector you don't really
care which reflectors are going to be configured to receive
your feed in addition updating the configuration file becomes
tedious as new reflector sites ask to connect. ADMIT-
GENERAL-BCC allows you the freedom to specify how many feeds
you are willing to send out without having to be concerned
about the actual ip addresses of the connecting reflectors.
The id field is a 16 bit value which you can use to make sure
that only those reflectors with the correct id will be
allowed to connect to yours.

OBTAIN-BCC ip-address

OBTAIN-BCC is used to configure a reflector to receive a
blind carbon copy feed from another reflector which has been
configured with ADMIT-BCC, as explained above.

OBTAIL-GENERAL-BCC ip-address id

OBTAIN-GENERAL-BCC is used to configure a reflector to
receive a blind carbon copy feed from another reflector which
has been configured with ADMIT-GENERAL-BCC, as explained
above.

MC-OUT ttl multicast-addr

MC-OUT and MC-IN (see below) are similar to ADMIT-BCC-CLIENT
and OBTAIN-BCC client, but take advantage of IP Multicasting.
To use any of the multicast capabilities of the reflector,
you must first make sure that your reflector has been
compiled with the -DMULT switch, this causes the multicast
code to be compiled into the reflector. Second, the
reflector host must support multicast. Consult with your
local UNIX guru to find out if your system is multicast
capable or not. MC_OUT will send all CU-SeeMe streams to the
specified multicast address using the specified ttl (time to
live).

MC-IN multicast-addr

MC-IN is used to configure a reflector to receive a multicast
stream put out by another reflector, as explained above. MC-
IN and MC-OUT should not be used together on the same
reflector.

UNICAST-REF ip-address

UNICAST-REF is used to "tie together" two or more reflectors.
This feature is useful if you are running a conference whose
participants are spread out across the country. For example,
if you have some folks on the east coast, another group in
California, and perhaps a third group in the south, each
group can connect to their local reflector and using UNICAST-
REF you can connect all three reflectors together. This
makes for a more efficient use of network bandwidth, rather
than having everyone connect to a single reflector. Each
reflector should have a UNICAST-REF for each other reflector.

MC-GROUP ttl multicast-addr

MC-GROUP is similar to UNICAST-REF, but takes advantage of IP
Multicasting. Two or more reflectors can be "tied together"
using IP multicast. Reflectors configured with MC-GROUP will
send out all CU-SeeMe streams to the specified multicast
address using the specified ttl, in addition they will accept
incoming CU-SeeMe streams from that multicast address.

NO-LOCAL-SENDERS

NO-LOCAL-SENDERS is used in a configuration file that also
contains either OBTAIN-BCC or MC-IN. NO-LOCAL-SENDERS sets
up a reflector that is only used in viewing a conference
taking place on a primary reflector. Since the purpose is to
view the main event, you can disable local interaction among
those who have connected to watch the main event. This will
reduce the load on your secondary reflector.

ADMIT-SENDER ip-address
or
ADMIT-SENDER ip-address-mask:len

ADMIT-SENDER is used in conjunction with NO-LOCAL-SENDERS to
allow the specified ip-address to send video, while
restricting all other participants to receive only. You may
have multiple ADMIT_SENDER entries in your configuration
file.

NV-UC-PORT port-number

Specifies the UDP port number to use when communicating with
nv via a unicast connection.

NV-MC-PORT port-number

Specifies the UDP port number to use when communicating with
nv via a multicast connection.

NV-MC-IN multicast-addr

Specifies a multicast address for receiving CU-SeeMe encoded
video from nv via the Mbone.

NV-MC-OUT ttl multicast-addr

Specifies a ttl and a multicast address for sending CU-SeeMe
video to nv via the Mbone. If both NV-MC-IN and NV-MC-OUT
are specified, then the multicast addresses must be
identical.

NV-STREAMS number-streams

Specifies the maximum number of video streams to send to any
nv unicast client. Since nv does not currently provide a
mechanism for pruning unwanted video streams, it's important
to limit the bandwidth sent to nv clients. The default
number of streams sent is 4. Note that if more than the
allowed number are available there is no control over which
will be sent. The same set will be sent to all nv's which
connect. This facility is workable for having a conference
with a known set of nv and CU-SeeMe participants, or for
testing with nv on a public reflector, but not for general nv
participation in open reflector conferences. It is a
temporary arrangement.

VAT-UC-PORT vat-port

Specifies the UDP port number to use when communicating with
vat via a unicast connection.

VAT-MC-PORT port

Specifies the UDP port number to use when communicating with
vat via a multicast connection.

VAT-MC-IN multicast-addr

Specifies a multicast address for receiving vat audio from
the mbone.

VAT-MC-OUT ttl multicast-addr

Specifies a ttl and a multicast address for sending audio to
vat via the Mbone. If both VAT-MC-IN and VAT-MC-OUT are
specified, the the multicast addresses must be identical.

VAT-CONF-ID id

Specifies the conference id to use with vat.

MIN-MAC-VERSION version-number msg-string
//

MIN-MAC-VERSION is used to ensure that all of the Mac clients
connecting to your reflector are at least at some minimum
version number. This is useful if you are running a
conference and there is some feature in a later version of
CU-SeeMe, like audio, that you want to use during the
conference. By setting a minimum version number only those
clients with a version of CU-SeeMe greater or equal to the
one designated, will be allowed to connect to the reflector.
The msg string is an ascii string terminated by a carriage
return followed by two back slashes. This is the string that
will appear on the user's screen if the version he using is
less then the specified version-number. The version numbers
for Mac based CU-SeeMe are as follows: 70b1 is 12, 70b12 is
18, 70b13 is 19, 70b14 is 22, 70b15 is 25.

MIN-PC-VERSION version-number msg-string
//

MIN-PC-VERSION is used to ensure that all of the PC clients
connecting to your reflector are at least at some minimum
version number. This is useful if you are running a
conference and there is some feature in a later version of
CU-SeeMe, like audio, that you want to use during the
conference. By setting a minimum version number only those
clients with a version of CU-SeeMe greater or equal to the
one designated, will be allowed to connect to the reflector.
The msg string is an ascii string terminated by a carriage
return followed by two back slashes. This is the string that
will appear on the user's screen if the version he using is
less then the specified version-number. The current version
number for PC based CU-SeeMe0.34 is 2.

DENY ip-address msg-string
//
or
DENY ip-address-mask:len msg-string
//

Deny causes the reflector to deny access to the client at the
specified IP address.

MAX-MIN-SEND max-min-send hold-down msg-string
//

max-min-send is the maximum allowable value, in kbps, for a client's
minimum transmission rate, the value below which the send rate cap
will not fall, regardless of packet loss. A high value for the minimum
transmission rate allows a client to disregard packet loss. hold-down
is the amount of time, in seconds, before a client is allowed to
reconnect after being booted for a violation of this parameter.
msg-string is the message to be displayed when a client is booted
for this violation. The default value for max-min-send is 10 and
the default hold-down is 1 second.

MAX-MAX-SEND max-max-send hold-down msg-string
//

max-max-send is the maximum allowable value, in kbps, for a client's
maximum transmission rate, the value above which the send rate cap will
not rise, regardless of packet loss. This option functions similarly
to the CAP option, except that the CAP value is measured empirically by
the reflector, whereas the max-send value is set by a user control and
communicated directly to the reflector. hold-down and msg-string
are as described for the MAX-MIN-SEND option. The default value for
max-max-send is 90.

MAX-MIN-RECV max-min-recv hold-down msg-string
//

max-min-recv is the maximum allowable value, in kbps, for a client's
minimum requested reception rate, the value below which the reflector's
rate cap to that client will not fall, regardless of packet loss.
A high value for the minimum reception rate effectively instructs the
reflector to ignore packet loss on the link from the reflector to that
client. hold-down and msg-string work the same as described for the
MAX-MIN-SEND parameter. The default value for max-min-recv is 10.

MAX-MAX-RECV max-max-recv hold-down msg-string
//

max-max-recv is the maximum allowable value for a client's maximum
requested reception rate, the value above which the reflector's
transmission rate will not rise, regardless of packet loss. A large
value for the maximum reception rate allows a high data rate to that
client when packet loss is low. hold-down and msg-string are as
described for the MAX-MIN-SEND option. The default value for
max-max-recv is 500.

DEFAULT-MIN-RECV default-min-recv

default-min-recv is the lower bound on the reflector's outgoing rate
cap for clients who are not providing new style loss reporting. The
default value is 14.

DEFAULT-MAX-RECV default-max-recv

default-max-recv is the upper bound on the reflector's outgoing rate
cap for clients who are not providing new style loss reporting. The
default value is 200.

DEFAULT-INIT-RECV default-init-recv

default-init-recv is the initial value for the reflector's outgoing
rate cap for clients who are not providing new style loss reporting.
The default value is 40.

RATE-ADAPT no-loss-growth loss-threshold

This option controls 2 parameters of the rate adaptation algorithm.
no-loss-growth is the percent increase in the outgoing rate cap that
is to occur when 0 loss is observed over an interval (provided the
attempted transmission rate in that interval was at least 90% of the
cap). It controls how quickly the cap will climb during periods of
0 packet loss. loss-threshold is the percent data loss that is
required to trigger a reduction in the outgoing rate cap. Whenever
observed loss is higher than this percentage, the rate cap will be
reduced, proportionally to the amount of loss. The default value for
no-loss-growth is 5. The default for loss-threshold is 2.

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

These parameters are identical to that described for RATE-ADAPT, except
that they apply to clients who are not providing new-style loss reports.
The default value for old-no-loss-growth is 5. The default for
old-loss-threshold is 5.

------------------ Reflector Monitor Program ----------------

REFMON Version 1.00

Refmon stands for reflector monitor, it is a program that is
used to monitor the state of your reflector. Currently
refmon has one switch -s which is used to specify the host
name or IP address of the machine running the reflector. For
example

refmon -s hellbat.cit.cornell.edu

will start up a refmon to query the reflector running on
hellbat.cit.cornell.edu. Once refmon is started up it
accepts commands, the commands cause a query to be sent to
the reflector and the reflector's response is printed out on
the screen. The commands are the following:

quit
quits the refmon application.

version
shows the version number of the reflector.

who
shows a list of the participants currently connected to
the reflector.

maven
shows a list of all maven clients currently connected to
the reflector.

uptime
shows the time that the reflector was started.

term
kills the reflector application.

param
prints out the configuration file.

help
prints out this list of commands

kill ip-address text-message
The text-message will appear on the screen of the client with the specified
ip address and that client will be disconnected from the reflector

------------ The fine print ---------------- 7-13-95

Copyright (c) 1993, 1994, 1995, Cornell University

Cornell hereby grants permission to use and copy, for any purpose, and
to redistribute this binary executable version of the CU-SeeMe (tm)
Reflector program (whole and unmodified), all without fee, provided
that (1) any such redistribution shall realize no profit or gain,
direct or indirect, (2) these copyright and permission notices appear
on all copies and supporting documentation, (3) the name of Cornell
not be used in advertising or publicity pertaining to distribution of
the program without specific prior permission, and (4) notice be given
in supporting documentation that copying and distribution is by
permission of Cornell. Cornell reserves the right to modify this
grant of permission in future releases. Decompiling, disassembling,
or reverse engineering this program is not permitted. This notice
makes no grant of permission or access to the source code for this
program; such access is available by specific separate license only.
CORNELL MAKES NO REPRESENTATIONS OR WARRANTEES, EXPRESS OR IMPLIED.
By way of example, but not limitation, CORNELL MAKES NO
REPRESENTATIONS OR WARRANTIES OF MERCHANTABILITY OR FITNESS FOR ANY
PARTICULAR PURPOSE OR THAT THE USE OF THIS SOFTWARE OR DOCUMENTATION
WILL NOT INFRINGE ANY PATENTS, COPYRIGHTS, TRADEMARKS, OR OTHER
RIGHTS. Cornell shall not be held liable for any liability with
respect to any claim by the user or any other party arising from use
of the program.