installing the software

mike felder (sliders@airmail.net)
Sat, 23 Dec 95 19:23:44 -800


I do not seem to be able to to get the software to run...Using a 486sx pc with 8megs of ram..Very frustrating..> CU-SeeMe Reflector FAQ
>
> Updated: Thursday 21 December 1995
>
> ------------------------------------------------------------------------
>
> HTML extensions used here. Is your browser up to the job? Find out.
> ------------------------------------------------------------------------
>
>
> On this page
>
> [*] Information about reflectors and MBONE (multi-cast
> backbone).
>
> ------------------------------------------------------------------------
>
>
> Reflectors
>
> A reflector is a piece of software that allows multi-party
> conferencing. Written out of necessity (the current
> Macintosh TCP/IP networking software doesn't support
> multi-cast), a reflector allows more than just
> point-to-point (two-person) connections. The reflector
> available from the CU-SeeMe development team is C language
> code written for UNIX systems. If you're not conversant in
> compiling and installing system-level software, IP networks,
> reflectors, and the like, you'll probably need to consult
> with your system/network administrator or with the members
> of the Reflector List.
>
> ------------------------------------------------------------------------
>
>
> Can I have a multi-party conference if I don't have a UNIX computer
> for the reflector?
>
> Certainly, but you'll have to use someone else's. Here is a
> list of public reflectors worldwide.
>
> ------------------------------------------------------------------------
>
>
> What is good reflector etiquette?
>
> Just as we have etiquette in the real world, and
> "netiquette" on the Internet, there's an desired code of
> conduct on reflectors.
>
> Before you use a public reflector send email to the
> contact person (specified in our public reflector
> list). Tell them how you intend to use their reflector
> and approximately how long it'll take. Remember, they
> may have local rules about (and corporate need of)
> reflector usage.
>
> Stay only a short time, unless invited to "hang out"
> for longer.
>
> Send video. Leaving a still image or a "crawling"
> message is very poor manners and a waste of network
> bandwidth.
>
> Send live video. Broadcasting a videotape (or other
> canned video) transmits information better suited to
> other media. An exception may be to show topical events
> that could not be captured live. The Burning Man
> Extravaganza was recorded to tape and rushed to a
> networked computer. There had been plans to use a
> satellite, but they fell through.
>
> Use the "low" resolution mode. It's sufficient for us
> to admire your haircut. High resolution mode pushes
> much more data across the wire, and should be used for
> very special occasions or your own internal facility
> network.
>
> Use the default transmissions settings. They work for
> most people in most situations. Specifically, keep your
> Maximum Kilobits/Second below 100 kbps and the Change
> Threshold to below 20.
>
> Be mindful of your audience. You're in a
> freely-viewable forum: "inappropriate" content
> generates backlash. Grade-school children connect to
> public reflectors, they shouldn't be exposed to adult
> content. Children need to remember that adults use the
> reflectors: someone's parents may be watching what they
> do!
>
> Be respectful of people trying to run an organized
> conference of a reflector you've connected to. Please
> don't hang around; allow them to get their business
> done. The Events List contains conferences and
> happenings that you're invited to.
>
> ------------------------------------------------------------------------
>
>
> Are reflector sessions private?
>
> Generally CU-SeeMe conferences are open to viewing by anyone
> who connects to the active reflector. There are ways of
> making restricted sessions (by using a session ID) and ways
> of restricting who may transmit (in upcoming versions of
> CU-SeeMe). I'll place more information here as I recieve it.
>
> ------------------------------------------------------------------------
>
>
> Is it true that a reflector works at the speed of the slowest
> participant?
>
> Tim Dorcey (T.Dorcey@cornell.edu) said:
>
> CU-SeeMe automatically adjusts its video transmission rate
> (by varying the frame rate) to adapt to the currently
> available bandwidth, as determined by packet loss reports
> returned by video recipients. Since the current version is
> only capable of generating a single resolution video stream,
> it averages the loss reports and adjusts the rate on that
> basis. Hence, to the extent that they effect the average
> packet loss, video recipients with low capacity network
> connections will slow down the video for everybody.
> Unfortunately, there is a bug in the current release
> (0.60b1) that generates faulty loss reports and makes this
> problem appear much more severe than it should be. The
> version soon to be released fixes this bug and should
> produce more reasonable behavior, particularly if recipients
> on low capacity links close all but 1 or at most 2 video
> windows. Eventually, CU-SeeMe will be capable of generating
> a hierarchially encoded video stream so that the reflector
> can select a different transmission rate for each recipient.
>
> ------------------------------------------------------------------------
>
>
> Why does a reflector sometimes continue to send to me even after I've
> disconnected?
>
> Tim Dorcey (T.Dorcey@cornell.edu) said:
>
> When you close a connection, the applications sends a repetative
> series of "Close Connection" messages. Hopefully, at least one of
> these gets through, but on a bad connection, they might all be lost.
> Hence, the reflector will also kill a connection if it hasn't received
> anything from a participant for some time. Now, it is the nature of
> the CU-SeeMe protocol that the control packets used to maintain a
> connection are indistinguishable from those used to initiate it. So,
> when an application closes a connection, it ignores anything from that
> same address for some period of time, to prevent any left-over
> (maintenance) packets from the original connection from being
> interpreted as initiation of a new connection. The different time-out
> parameters are chosen so that, in theory, the reflector time-out
> should occur before the application begins accepting packets from that
> address again. With a bad connection or a bogged down reflector, this
> logic apparently fails, and we need to re-examine it. As a work-around
> you can:
>
> 1. Connect immediately to some other reflector, or
> 2. Quit the application
>
> A similar problem that occurs with bad connections is that video
> windows that you close keep popping back open. What happens here is
> you close a window, but then, as a result of packet loss, you hear
> nothing from that participant for some time and "time them out." When
> something does happen to get through from them, it is treated as a new
> participant and their window is automatically opened (as it is for all
> "new" participants). In the recently released version 0.70b1, there is
> a preferences item where you can set the maximum number of windows
> that you want displayed at any time. With a low capacity connection,
> this should be set to a very low number. You can then select the
> partipant(s) you want to watch from the Participants menu. Note that
> the packet-loss/time-out phenomenon will still occur, but the
> participants will be coming and going from the menu instead of your
> monitor.
>
> Another source of reflector mis-behavior to look for is a full file
> system where the reflector is writing its log file. This generates a
> system error each time the reflector tries to update the log and slows
> it down enough to disrupt the connection protocol. If you don't
> specify a LOG-LIMIT in the reflector configuration file, the default
> is 10,000 lines. Make sure you have room for it on your system.
>
> ------------------------------------------------------------------------
>
>
> What about setting up a reflector?
>
> On Fri, 9 Dec 94 chi@nb.rockwell.com (Calvin Chi) said:
>
> I just got my reflector set up and successfully tested with
> CU-SeeMe on both Mac and PC...
>
> 1. The reflector can be compiled WITHOUT -DMULTI should
> be emphasized somewhere in FAQ, not just one line in
> the Makefile.
>
> Multicast function is a great hurdle to most people
> even the sysadmins. But one can compile reflector in
> UNICAST mode and see the wonder of CU-SeeMe.
>
> 2. The explanation for CU-SeeMe's audio window control is
> VERY un-CLEAR. It took me a while to figure out what to
> do to send my voice out and receive audio.
>
> 3. While we are testing we encountered strong echo effect
> on Mac. Turned out it is becuase that the new
> microphone is too sensitive and it will pick up the
> sound from Mac if you put it too close to the machine.
> Thus form a loop and cause echo effect. This is
> somewhat related to the fact that we don't know how
> audio control works.
>
> when Push-to-talk is OFF, only voice volume
> higher than the threshold will be trasmitted.
> BUT...
>
> when Push-to-talk is ON, threshold does not
> filter sound. All volume levels will be
> transmitted.
>
> I still not very clear what kind of effect the
> Lurkers have.
>
> ------------------------------------------------------------------------
>
>
> Compiling the reflector on Solaris?
>
> Julian Humphries said: To make a version for Solaris...loose
> the -lucb on the LIBC line, as Solaris really hates to do
> any Berkeley UNIX stuff (despite hype to the contrary). In
> addition, take out the define for BSD in the make file. I
> also had to add CC=gcc because I use the gnu compiler.
> Finally, the important part is to add a define for solaris
> in the makefile and then add this to reflect.h:
>
> #ifdef SOLARIS
> #define bzero(str,size) memset (str,0,size)
> #define bcopy(s,d,c) memcpy(d,s,c)
> #endif /* SOLARIS */
>
> These are the only real BSD'isms in the code, although I got
> lots of warnings about stuff without casts and a few others
> that probably should be checked out. Seems to work, although
> my testing has been minimal. BTW, my test was on the just
> released version 3.00B1. Your mileage may vary.
>
> ------------------------------------------------------------------------
>
>
> MBONE (Multi-cast backbone)
>
> From the MBONE FAQ: the MBone is a virtual network that has
> been in existence since early1992. It was named by Steve
> Casner of the University of Southern California Information
> Sciences Institute and originated from an effort to
> multicast audio and video from meetings of the Internet
> Engineering Task Force. The MBone shares the same physical
> media as the Internet. It uses a network of routers
> (mrouters) that can support multicast. These mrouters are
> either upgraded commercial routers, or dedicated
> workstations running with modified kernels in parallel with
> standard routers.
>
> Given adequate network bandwidth, you next need a designated
> MBone network administrator. Working part-time, it typically
> takes one to three weeks for a network-knowledgeable person
> to establish MBone at a new site. Setup is not for the faint
> of heart, but all the tools are documented, and help is
> available from the MBone list.
>
> Expect to spend some time if you want to be an MBone user.
> It is time-consuming because learning and fixing are
> involved and because it is lots of fun! You should read the
> FAQ a few times, ensure that software tools and
> multicast-compatible kernels are available for your target
> workstations, and subscribe to the mail list in advance to
> enable you to ask questions and receive answers.
>
> ------------------------------------------------------------------------
>
>
> Can I connect the CU-SeeMe reflector to MBONE broadcasts?
>
> Yes, but only to send the reflector activity (a "CU-SeeMe
> stream") to the MBONE, not to receive MBONE streams (at
> least not with version 9 of the CU-SeeMe reflector).
>
> Only nv is able to receive the CU-SeeMe stream from the
> MBONE. (nv can also receive a CU-SeeMe stream directly from
> a CU-SeeMe reflector.)
>
> The CU-SeeMe reflector works with Maven audio participants,
> and it may work for VAT as well.
>
> The CU-SeeMe development team has expressed an interest in
> being able to provide the following capabilities:
>
> Two-way connectivity via the reflector.
> nv-to-Mac/PC and Mac/PC-to-nv.
> VAT-to-Mac/PC and Mac/PC-to-VAT.
> Mac/PC direct participation in the MBONE. (The
> Macintosh is waiting on Apple releasing a MacTCP with
> multi-cast capability. "Open Transport" is scheduled to
> be in beta-testing in 4Q94, and released in 1Q95.)
> Multi-party conference without a reflector (or perhaps
> having the reflector functionality on the Mac/PC).
> Getting the reflector to work with VAT (and other
> stuff) as it now works with Maven. (Recently it was
> announced that the reflector would work with another
> audio encoding method.)
>
> The CU-SeeMe development teams says: "one area of recent
> progress is to allow a reflector to receive as well as send
> CU-SeeMe streams to the mbone between reflectors to provide
> for conferences with larger numbers of observers." (Details
> are in the (post-version 20b2) reflector documentation and
> will be added to the web when someone prods me.)
>
> On Sat, 11 Feb 1995 Scott Brim said:
>
> For multicast routing, a good place to start is Steve Deering's
> thesis, which is highly readable and covers all the basics. Look on
> gregorio.stanford.edu, or perhaps in
> ftp://parcftp.xerox.com/net-research/. Once you're done there, look at
> the IDMR (Inter-Domain Multicast Routing) internet drafts
> (draft-ietf-idmr-*), and also at the Nimrod architecture draft
> (draft-ietf-nimrod-*). Those will let you know where things are
> currently.
>
> Multicast routing is not a solved problem by any means when you go
> beyond LAN environments. We've got enough pieces nailed down to
> deploy, but I honestly don't think that what we are doing now will
> scale to millions of simultaneous groups. An important idea, which
> hasn't been followed up on recently, is localized dynamic changes in
> algorithm in response to changing conditions. For example if a source
> only sends out one message a week, it's economical for routers just to
> send it everywhere and let the end networks throw the message away,
> rather than maintaining a lot of state information about where it
> shouldn't go (useless 99.99% of the time). If the same source starts
> sending out a message every 10 minutes, then some (but not necessarily
> all) parts of the Internet might want to start maintaining state
> information to make sure it only goes where it should. And so on with
> similar tradeoffs. Happy reading!
>
> Where may I find more MBONE information?
>
> http://www.eit.com/techinfo/mbone/mbone.html
> http://www.cilea.it/MBone/agenda.html
> ftp://nic.es.net/pub/mailing-lists/mail-archive/
>
> ------------------------------------------------------------------------
>
>
> Questions about CU-SeeMe? [Image] Ask the CU-SeeMe Discussion List
> readers.
>
> ------------------------------------------------------------------------
>
> [Go Home] [Get Help] [Send Comment] [Browser Info] [Good Cause(s)]
>
> Michael Sattler <webmaster@jungle.com>
>