REEF
-------------
  * This file is currently at /p/coral/ftp/design/reef_info

  Relevant Coral commands:
    socket_rel    
    async_socket_rel
    setqid
    collection(relname,arity,type).
        where type is 'producer' or 'consumer'

  Files for solvers: 
      solvers/SocketRelSolver.*
      solvers/ASyncSocketRelSolver.*
      solvers/ServerSolvers.*

  Regular socket_rel's have a help file describing them, try
  'help(socket_rel).' from Coral to read it.


  ASynchronous socket_rel's are only available when Coral is compiled
  with the ASYN_SOCK_REL compile-time flag.  

    Files Affected:
      compile/Compile.C
      relation/AsynSockRelation.*
      relation/HashSimpleRelation.*
      relation/Relation.*
      relation/StorageRelation.C
      rule/Predicate.*
      rule/SemiNaiveEval.C
      scc/QFMaterializedModuleData.C
      scc/SccEnv.C
      scc/SccInfo.*
      solvers/AsynSocketRelSolver.C
      stream/SockStream.*


  ASynch socket_rels are the client-side of REEF; they specify a remote
  relation that should Coral should not block on while solving, instead
  it should do work on other SCC's that do not depend on the result of
  the SCC containing the ASynch relation.  ASynch relations are
  implemented, and work well.  They are not compiled in always as
  some of the changes they require in the evaluation code slows down
  normal evaluations as well.

  There is more detailed documentation on the implementation of 
  async_socket_rel at '/p/coral/ftp/design/ASR_info'.


  The 'setqid' command selects a Query-Id to be associated with the next
  query, this is useful when multiple requests are being asked across a
  single connection to the Collector, who may reply to requests
  asynchronously.  The id allows the collector to specify which request
  a set of facts is being given in response to.


  Collectors are the server-side of REEF; they are intended to act as
  a "shared memory" between several Coral processes that are cooperating
  to solve a query.  Unlike shared memory, the collector takes an active
  role.  When a request for facts is made, all relevant facts are returned,
  and the request is remembered; if more relevant facts are obtained later,
  they are forwarded to the requester as well.  

  The Collector implementation is not quite finished, the problem being
  there is currently no way for the collector to identify when it will
  not recieve any more relevant facts for a particular request, and so
  it will never tell the requester (an ASyncSocketRel) that the request
  has been fully satisfied (EOQ - End of Query).


  Some possible work-arounds for this problem that were considered:

    - Allow only pure producers and pure consumers for a single 
      collected relation.  All consumers of a relation would have to
      wait until all producers indicated they could produce no more
      relevant facts; at which time all consumers would recieve the
      EOQ indicator.  This is the reason for the <type> argument in
      the collection command.  Unfortunately, there is no way good
      way for the collector to determine how many producers to expect
      for a particular collection.  Of course, the assumptions of
      this setup disallow even the simplest cycles between cooperating
      Coral's.  Due to the problems and limitations of this method
      its implementation was abandoned, and the design reconsidered.

    - "done" facts from Coral.  Internally, Coral generates done facts,
      indicating that no more facts of a specific form will be generated
      by this process.  [ie: 'done_w(2,X)' would indicate no more facts
      of the form w(2,X) would ever be generated.]  If these done facts
      were forwarded to the collector, it could decide in some cases
      that responses to requests were complete.   One problem with 
      this is the large number of done facts that are generated, and
      the need for the collector to store these facts (or some info
      about them) for each participant of the collection.  This would
      likely generate a significant amount of network traffic, and 
      cause the collector's memory size to become a bottleneck. Avoiding
      the limititation of a single machine's memory size was one of
      the original intents of the Reef.

      Another problem with this approach is that a request may be 
      waiting at the collector for a particular done fact, say 'done_w(5,X)'.
      Some of the participants in the collection may not have a '5' in
      their data, so they will not produce a done fact of this form.
      In this case, the collector has to ask if they could possibly
      generate a fact of this form.  This potentially doubles network
      traffic, as well as requiring the ASyncSocketRel implementation
      to be capable of answering queries, which it currently is not.


    Files Affected:
      relation/Collector.*
      solvers/ServerSolvers.*
      connect/User.h
      relation/Relation.h