Cornell Reflector Version 3.00B3 This is a BETA version of the newest release of the CU-SeeMe reflector program, version 3.00B3. 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 screaan because the seq numing in the make OCP for vat clients routine was never being increamented. 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 If you are compiling this code on a machine without a multicast kernel, you will have to remove the -DMULTI definition from the makefile. If you are connecting reflectors together, make sure that all the reflectors are using the same version. Bug reports and or general comments can either be sent to the CU-SeeMe bug list at cu-seeme-bugs@cornell.edu, or directly to me, John Lynn, at John-A-Lynn@cornell.edu. 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. 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. ADMIT ip-address 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 actuall 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 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 // Deny causes the reflector to deny access to the client at the specified IP address. 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