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.