Speak Freely for Unix

by John Walker

Back to Speak Freely for Unix

SFREFLECT(1)              User Commands              SFREFLECT(1)

     sfreflect - Speak Freely conference reflector

     sfreflect [ -du ] [ -hpath ] [ -iinterval ] [ -mhost[:port]
     ] [ -pport ] [ -rinterval ] [ -vtimeout ]

     sfreflect implements a rudimentary  multiparty  conferencing
     facility.   Running  on  a server (which need not have audio
     hardware), it accepts connections from users  and,  whenever
     sound  is  received from any connected user, immediately re-
     transmits it to all others.  Users may join  and  leave  the
     conference at will simply by opening or closing a connection
     to the reflector.  The reflector can  automatically  publish
     an  HTML  file  listing members currently in the conference,
     which can be examined by any user with a Web browser.

     A reflector can invite connections  by  publishing  its  ex-
     istence  on  one  or more directory servers.  See the ``Look
     Who's Listening'' section in the sfspeaker manual  page  for
     details on how to set the environment variables.

     -d    Enables debug output.

          An HTML file is written to the given path name (a fully
          qualified  file  name,  less the .html suffix), listing
          all users currently connected to the  reflector.   Pub-
          lishing  this HTML file as a World-Wide Web document on
          the server allows easy access to a list of  all  active
          users  on  the reflector.  Unlike sflwld, sfreflect al-
          ways includes the identity of connected  users  in  its
          HTML  output, even if they have requested ``exact match
          only''.  Participating in a conference is equivalent to
          connecting  to  another user, in which case identity is
          also always shown.

          The HTML file written by the -h option will be  updated
          every  interval seconds if a change has occurred during
          that period.  If interval is set to zero, the  file  is
          updated immediately after any change.

          Audio received by the reflector will be sent, in  addi-
          tion to the connected hosts, also to the specified port
          on host.  If no port is given,  the  default  sfspeaker
          port of 2074 is used.  The monitor facility is primari-
          ly intended to permit  participating  in  a  conference
          from  the  same  machine on which sfreflect is running,
          but can be used to relay the conference to any host and
          port  on the network.  See the section ``Single Machine
          Set-up'' below for additional details.

          Causes sfreflect to listen on the specified port number
          instead of the default port of 4074.

          The HTML written by the   - h  option  will  contain  a
          client-pull request which causes the user's Web browser
          (if it supports client-pull) to  automatically  refresh
          the  document  every interval seconds.  If no -r option
          is specified or interval is set to  0,  no  client-pull
          updating will occur.  Note the distinction between the
          -i and -r options; -i specifies  how  frequently  sfre-
          flect updates the HTML file on the server, while the -r
          option determines the interval between automatic  down-
          loads  of this file to users displaying it in their Web
          browsers.  It doesn't make sense to set the - r  option
          to a shorter interval than the -i option, but to reduce
          network traffic it may be eminently reasonable  to  up-
          date  the  HTML  file  every 30 seconds or so, but only
          have users refresh their browser display every  two  to
          five minutes.

     -u    Prints how-to-call information.

          When sfreflect receives a packet from a host it  hasn't
          heard  from  in  timeout  seconds,  it  will attempt to
          resolve the host name and print a message  on  standard
          error  noting  the  new connection and what compression
          mode is being used.  If the host name can't  be  deter-
          mined,  the numeric IP address is shown.  After timeout
          seconds of inactivity a message  is  issued  indicating
          the  host  is  idle.   If  no timeout is specified, 180
          seconds is used.

     The -h option creates an HTML file with the given base  name
     and  an  extension  of .new, then swaps the new file for any
     previously-existing file with an extension  of  .html.   The
     file  update process avoids the risk of a user's receiving a
     file in the process of being written.

     To participate in a sfreflect conference, you must determine
     the  host  name running the reflector and the port number it
     listens to.  Start sfspeaker with the -pport option specify-
     ing  the  reflector's port number.  If you don't specify the
     reflector's port number, sfspeaker will listen  on  the  de-
     fault  port  of 2074; if the reflector uses a different port
     you will not hear the packets it returns to you.  Then start
     sfmike specifying the reflector host name and port number as
     hostname:port.  The reflector will not  forward  sound  from
     the conference until you connect to it with sfmike; starting
     sfspeaker is necessary but not sufficient.

     Users of Speak Freely for Windows can join a conference sim-
     ply  by  opening  a  new  connection window and entering the
     reflector's hostname:port.  Speak  Freely  for  Windows  au-
     tomatically listens for packets on all ports to which is has
     open connections.

     sfreflect works by simple packet replication; sound  packets
     received  from  any  user connected to the reflector are im-
     mediately resent, unmodified, to all other  parties  to  the
     conference (but not to the originator), with whatever proto-
     col, compression, and encryption modes were selected by  the
     sender.   This has several consequences you need to be aware
     of in order to run a successful conference.  First  of  all,
     the  site  running  the  reflector  needs to have sufficient
     bandwidth in its connection to the Internet backbone to per-
     mit  sending  a copy of every packet received to each member
     in the conference.  For example, suppose you  routinely  use
     GSM  compression  to communicate over a 28.8 Kb dial-up link
     to your Internet Service Provider, having no bandwidth prob-
     lems  because  GSM  compression uses only slightly more than
     half of your available bandwidth.  If you attempted  to  run
     sfreflect  and  had three parties in the conference, perfor-
     mance would be marginal since  each  packet  received  would
     have  to  be  sent  to  the other two people, and that would
     exceed the capacity of the 28.8  Kb  line.   To  avoid  lost
     packets  (at least with long individual transmissions) you'd
     need a faster modem link.  Reflectors for conferences with a
     large number of participants can be run successfully on fast
     local networks, but are only usable across the  Internet  if
     the reflector site has high bandwidth connectivity.

     It is essential that all participants in a conference,  even
     if  they  have  full-duplex audio hardware, operate in push-
     to-talk or Voice Activation (VOX  or  squelch)  mode  whilst
     connected  to  the reflector.  Transmitting continuously, as
     can be done on a full-duplex connection, will flood the  re-
     flector  with  packets and disrupt the transmissions of oth-
     ers.  As is the case with half-duplex point-to-point connec-
     tions, it's a good idea for all participants in a conference
     to verbally indicate the end of  a  transmission  by  saying
     ``over'' or the equivalent.

     Connections to reflector sites should use Speak Freely  pro-
     tocol  exclusively,  not  RTP  or  VAT.  sfspeaker assumes a
     given sender will use only one protocol at  a  time.   Since
     the  reflector  is considered a single connection, sfspeaker
     has no way to determine the correct protocol if it  receives
     an intermixed stream of packets in various protocols.  Using
     the default Speak Freely protocol guarantees participants in
     the  conference  will  be  able  to  hear  packets  from all

     sfreflect relays packets in a variety of compression schemes
     without  difficulty, and sfspeaker will decompress them with
     the appropriate algorithms and play them properly.  If, how-
     ever,  a  given  compression  scheme  overloads  the network
     bandwidth or CPU capacity of one or more participants in the
     conference,  they will hear garbled audio even though others
     may receive the same transmission perfectly.   When  setting
     up a conference, it's best to specify a recommended compres-
     sion mode appropriate to the computers and  connectivity  of
     the expected participants and urge them to adopt that mode.

     sfreflect correctly forwards encrypted packets.  As long  as
     all  participants  in  a conference have received and supply
     the correct key, they can communicate secure against  eaves-
     dropping  by  others  who  may  connect  but do not know the
     conference key.  The automatic key generation  and  exchange
     using  PGP (-z option on sfmike) cannot be used in a confer-
     ence, as it is strictly a two-party  transaction.   Instead,
     distribute  keys  to  participants  in advance by electronic
     mail encrypted with PGP.

     Like all the other components of Speak Freely, sfreflect  is
     intended  for  communication  among cooperating individuals.
     sfreflect contains no ``social engineering''  mechanisms  to
     deter  or  prevent  abuse.  Users connected to the reflector
     can interrupt one another just as they can in  a  conference
     room,  and  a user who transmits incessantly can disrupt the
     proceedings as effectively as a heckler  in  an  auditorium.
     One  can  easily  envisage  a variety of technological fixes
     which would minimise the impact of this kind  of  behaviour;
     indeed,  systems intended for general public access have in-
     corporated them for many years.  sfreflect  is  neither  in-
     tended  nor  recommended  for  open access ``chat'' applica-
     tions.  It can, if adequate bandwidth is available and  par-
     ticipants  understand  the  constraints  of  the  medium and
     cooperate with one another, permit small  conferences  where
     people  can come and go as they like without any central ad-
     ministration other than a machine running sfreflect.

     In the simplest configuration of sfreflect,  it  runs  on  a
     server  distinct from any machine used to access the reflec-
     tor.  You can host as many different conferences as you wish
     on  the  same server (assuming it has adequate Internet con-
     nectivity for the aggregate  bandwidth)  simply  by  running
     multiple  copies  of sfreflect with each conference assigned
     its own unique port.

     Many potential users of sfreflect may not have the luxury of
     a  machine  to dedicate to it.  sfreflect's ``monitor host''
     facility (-m option) permits hosting and participating in  a
     conference  on a single machine.  It's a little confusing to
     set up, but once properly configured it  will  get  the  job
     done.   The  fundamental  problem  which must be overcome is
     that sfreflect listens and transmits on the port assigned to
     the   conference;  users  on  other  machines  simply  start
     sfspeaker and sfmike specifying that port, and the reflector
     does  the  rest.   But on the machine running sfreflect, one
     cannot start sfspeaker on the conference port because it has
     already  been  assigned  to  the  reflector.  To work around
     this, use the -m option on sfreflect and specify  the  local
     machine  name  (normally  you  can  omit  the  optional port
     specification and use the default port of  2074).   You  can
     now  start  a  copy of sfspeaker which listens on that port,
     and connect to the  conference  in  the  usual  manner  with
     sfmike.   The reflector is careful never to forward audio to
     the host on which it is running, and the monitor host facil-
     ity  doesn't forward monitor packets from the local machine,
     so you can listen to the conference without feedback,  echo,
     or locally duplicated packets.  Here's a concrete example of
     how to set everything up:  assume your machine  has  a  host
     name  of ``gizmo'' and you wish to host a conference on port
     5214.  You routinely run sfspeaker on the  default  port  of
     2074 for regular conversations.  So, you'd start the reflec-
     tor and sfspeaker as follows:

               sfreflect -v -p5214 -mgizmo &
               sfspeaker -v &

     which will copy all audio the  reflector  receives  on  port
     5214  to  the default port of 2074 on gizmo, where sfspeaker
     will play it.  You can now join the conference with the com-
               sfmike gizmo:5214
     and transmit and receive in the usual manner.  If  you  wish
     to  announce  the conference and/or yourself on a Look Who's
     Listening server, set  the  environment  variables  for  the
     conference  prior to starting sfreflect and for yourself be-
     fore starting sfspeaker.  See the ``Look  Who's  Listening''
     section of the sfspeaker manual page for additional details.

     It is easy to imagine  thousands  of  zowie  features  which
     might  be  added  to this program, including transforming it
     into a complete mixer which could receive packets from  con-
     nections  in  a  variety of protocols and compression modes,
     mix or interleave them in an intelligent  fashion,  and  re-
     transmit  the composite audio stream in a specified protocol
     and compression.  Since at present it's unclear how many po-
     tential  users  of  a conferencing program such as this have
     adequate connectivity to make effective use of it, it's  un-
     wise  to  invest  the  much greater effort such an elaborate
     program would require without first getting some  experience
     with a much simpler tool.

     The implementation of MD5 message-digest algorithm is  based
     on  a  public domain version written by Colin Plumb in 1993.
     The algorithm is  due  to  Ron  Rivest.   The  algorithm  is
     described in Internet RFC 1321.

     sfecho(1), sflwld(1), sfmike(1), sfspeaker(1)

Back to Speak Freely for Unix

by John Walker
September 17, 1998