    Document: FTS-0006
    Version:  002
    Date:     30-Nov-1991

                                YOOHOO and YOOHOO/2U2

                        The netmail handshake used by Opus-CBCS
                 and other intelligent Fidonet mail handling packages

                                  Vince Perriello
                                 FidoNet 1:2343/491

    Status of this document:

         This FTS (FidoNet(r) Technical Standard) specifies an optional
         standard for the FidoNet community.  Implementation of the
         protocols defined in this document is not mandatory,  but all
         implementations of these protocols are expected to adhere to this
         standard.  Distribution of this document is subject to the
         restrictions listed below.

         Fido and FidoNet are registered marks of Tom Jennings and Fido
         Software

    LEGAL STUFF
    -----------

    The original  protocol and documentation are by Wynn Wagner III.  Updates
    have  been  made  to  this  document  by  Vince Perriello,  who  also  is
    responsible for most of the sample routine included with this document.

    They are  released to the  public for  any use  whatsoever as long as you
    don't  modify any  transmitted  structure  or try to  make money  hawking
    either the sample code or this document as if you owned them.

    If you choose to use the  method  or  the  sample  routines,  you  do  so
    entirely at your own risk.  It  is  possible that the routines will cause
    physical damage to your equipment, an invasion of  fire ants, the plague,
    or an extended visit from in-laws.  If any  of  that  stuff  (or anything
    else) happens, you accept the consequences totally.

    CREDITS
    -------

    Fido  and  Fidonet  are  registered  trademarks of Tom Jennings and  Fido
    Software.

    ARCmail was originated by System Enhancement Associates.

    The ZModem protocol was designed by Chuck Forsberg. The SEAlink / SEAlink
    Overdrive protocols are copyrighted by System Enhancment Associates.  The
    TeLink protocol was designed and first implemented by Tom Jennings.

    The state charts in this document were done by Vince Perriello.

    Rick Huebner designed  and  implemented  the  basic  WaZOO  file  request
    method.  Update  request functionality was added by Vince Perriello.  Bob
    Hartman is responsible for the addition of Domain support.

    FTS-0001, describing the base FidoNet protocol, was created by Randy Bush.

    FTS-0007, describing enhancement to FTS-0001 using SEAlink and/or SEAlink
    Overdrive, was created by Phil Becker.

    YooHoo and YooHoo/2u2                                              Page 2
    Overview

    UPFRONT
    -------

    YOOHOO and YOOHOO/2U2 are  the  initial  handshakes  for the WaZOO e-mail
    protocol.  They are designed to let two systems establish a common ground
    for a netmail session while making  sure  that non-WaZOO software doesn't
    get upset by material it can't understand.

    The YOOHOO procedure begins as a single  byte  (0xf1).   If the system on
    the other end doesn't reply to that byte,  no  further  YOOHOO  or  WaZOO
    transmissions are attempted.  To a non-WaZOO netmail system,  the  YOOHOO
    byte will simply seem like a byte of debris.

    The  calling  system  initiates  the  YOOHOO  by  sending  the  attention
    character.   If the receiving system seems interested, the calling system
    sends a  128  byte packet containing such information as system and sysop
    names as well as a "capability mask." A 16-bit CRC protects the integrity
    of the 128-byte packet.

    In response, the receiving  system  prepares  a  128  byte packet to send
    back.  This is the YOOHOO/2U2 procedure.

    FEATURES
    --------

    The features of YOOHOO and YOOHOO/2U2 include

          * non-interference with systems that don't understand the
            handshake

          * almost foolproof method for identifying a remote system
            and establishing a common ground for transmission

          * built-in room to expand the capabilities of WaZOO without
            having to resort to a kludge

    USAGE
    -----

    A calling system simply uses  a  routine  that  transmits both YooHoo and
    TSYNC  handshake initiating characters to the  called  system.    If  the
    called system responds with an XMODEM 'NAK',  an FTS-0001 session will be
    initiated.  If an 'ENQ' is received, the  `YooHoo_Sender()'  routine will
    be invoked to handle the session negotiation.

    A  receiving  system  can call a routine like `YooHoo_Receiver()'  if  it
    detects the YOOHOO character, or just drop into the FTS-0001  logic if it
    sees a TSYNC.

    This simple method allows a mailer to take care of both the TSYNC and the
    YOOHOO handshakes.

    YooHoo and YooHoo/2u2                                              Page 3
    WaZOO Protocols

    PROTOCOLS
    ---------

    Currently there are four WaZOO methods in use:

    1. ZedZap
       ------

            a Zmodem variant. The originator does a batch send then goes into a
            receive batch mode.  The called system does receive then send. In
            the event of a file request (see description below) made by the
            called system, one more turnaround is made to service the request.

          * Unlike the "True" Zmodem protocol described by Chuck Forsberg,
            ZedZap routines must be able to handle a batch mode that has no
            actual files. In other words, it is possible for there to be a
            init sequence followed immediately by a ZFIN.

          * The maximum packet size is 8192. This is usually varied based on
            the baud rate. For example, at 2400 it might be 2048 bytes, then
            for 9600 baud and above the maximum of 8192 could apply. Note that
            THIS IS A SIGNIFICANT VARIATION FROM STRICT ZMODEM IMPLEMENTATION.
            (There's another WaZOO capability bit for those systems which
            can not handle this block size)

          * Netmail packets are transmitted as files with names in the form
            "12345678.PKT". Because of this, multiple packets may be sent in
            a single session.

          * If the calling system transmits a .REQ file for file requests, the
            receiving system can respond to it.  See "WaZOO File Requests"
            (below) for information on the .REQ file.

    2. ZedZip
       ------

            This capability is identical to ZedZap, but does not use buffers
            greater than 1K in size (like "True" Zmodem). It is also
            permissible to send a "null" packet in a ZedZip session. This
            allows a system which must use a strict Zmodem implementation to
            participate in a WaZOO session using Zmodem.

    3. DietIFNA
       --------

            The session operates like FTS-0001/FTS-0007. The notable exceptions
            are as follows:

          * The same packet naming convention as ZedZap applies, allowing more
            than one packet to be transmitted in a single session.

    YooHoo and YooHoo/2u2                                              Page 4
    WaZOO Protocols

          * Telink file transfers don't even attempt to exchange file names
            using modem7. The receiving system extracts the file name from the
            Telink or SEAlink header block.

          * If SEAlink is used, run-ahead (the number of blocks to slide) is
            based on the baud rate:  BlocksToSlide = BaudRate / 400, up to a
            max of 24 blocks.

          * When there is nothing to send, a system should remain quiet.  In
            other words, the end of a session can be determined by a timeout.

          * Under no circumstances should "BARK" file request logic be active
            during a DietIFNA session. File requests, if any, should be
            transmitted using a .REQ file.

            Many implementations of DietIfna have been accomplished by the mere
            exchange of packets, followed by straight FTS-0001/0007 code. This
            is incorrect but probably not easily remedied at this point. We have
            made an effort to document this change in "reality" in this revision
            of the document.

    4. Janus
       -----

            Janus is a full-duplex simultaneous bidirectional file transfer
            protocol. In other words, it can send and receive files at the same
            time.  It's very loosely derived from ZModem and HDLC/X.25 protocol
            technology, in that it uses variable length data-typed packets, and
            that transmission of file data does not require ACKs.

            The protocol is documented elsewhere; it is beyond the scope of this
            document to do so.

    YooHoo and YooHoo/2u2                                              Page 5
    Choosing WaZOO Methods

    How to decide which WaZOO method to use
    ---------------------------------------

    Since the called system has all the information  necessary to decide what
    WaZOO method to employ,  the best way to implement the process is for the
    calling  system  to send,  in its  capability  mask,  all the  bits which
    correspond to methods it can use (or wants to use)  in communicating with
    the called system.  The called  system then looks at these bits and sends
    back only the bit which corresponds to the method it wants to use.

    If the  called system  sends  back a mask  which contains  more  than one
    capability of the  calling system,  it can create a  problem situation if
    one system  arrives at its choice of methods  differently from the other.
    Thus, when the called system doesn't make the choice, both systems should
    choose as follows:

    1. Janus

    2. ZedZap

    3. ZedZip

    4. DietIFNA

    The capability highest on the list which both systems indicate ability to
    execute should be the one employed.

    YooHoo and YooHoo/2u2                                              Page 6
    WaZOO Filename conventions

    WaZOO FILENAMES
    ---------------

    1. MESSAGE PACKETS ... xxxxxxxx.PKT

            Normal (unarchived) messages are sent in a file name that has a tag
            of .PKT.  The "x" characters should be hex digits.

    2. ARCmail ... xxxxxxxx.{MO|TU|WE|TH|FR|SA|SU}#

            Message packets are often shipped in an archive that has been
            compressed with some LZ utility.

            The file name consists of a name with hex digits. The tag is one of
            seven two-character prefixes ("MO", "TU", "WE", "TH", "FR", "SA" or
            "SU") and a number (0-9).

            This particular naming convention was established by ARCmail version
            0.60, which is a defacto standard in FidoNet.

    3. FILE REQUESTS ... xxxxxxxx.REQ

            This is explained below.

            In a nutshell, the file name consists of the receiving system's
            Fidonet address expressed as two 4-digit hex numbers.  The file tag
            is .REQ.

            In a Janus session, the .REQ file isn't actually sent. Janus has
            a transaction system which sends the .REQ file one line at a time
            and then accepts the file(s) which the request generates.

    YooHoo and YooHoo/2u2                                              Page 7
    Flow of a ZedZap or ZedZip Session

    FLOW OF A ZEDZAP OR ZEDZIP SESSION
    ----------------------------------

    The calling system:

          * Send YooHoo

          * Receive YooHoo/2u2

          * In a single batch, send bundles, files, file request (.REQ) files
            (in that order)

          * In a single batch, receive bundles, files, file requests, and
            requested files (in that order)

          * If a file request (.REQ) file came in, send all requested files
            in a single batch.

    Receiving system:

          * Receive YooHoo

          * Send YooHoo/2u2

          * In a single batch, receive bundles, files, file requests

          * In a single batch, send bundles, files, our file requests, and
            respond to file requests that arrived from the remote system.

          * If we sent a .REQ file in the preceding step, receive all files
            in a single batch.

    YooHoo and YooHoo/2u2                                              Page 8
    WaZOO File Requests

    WAZOO FILE REQUESTS
    -------------------

    Rick Huebner, who adapted the ZModem routines for Opus, and the architect of
    the Janus file transfer protocol, designed the ".REQ file"-based file request
    system.

    REQ FILE:

    A WaZOO file request is based on a request file.  The name of a request file
    is similar to the .OUT and .FLO files used by Opus-CBCS and similar mail
    products (such as BinkleyTerm).

             TEMPLATE: netnode.REQ

             EXAMPLE:  00010002.REQ   ... a request being sent to 1/2

    The .REQ file is simply a text file that contains the files we want from the
    remote system. Those file names can include wildcards, but should not contain
    a path. Optionally, there can be a password if the sending system requires one.

    The "netnode" part of the file name is built from the remote systems net and
    node numbers.  Both numbers become 4-character hex numbers in the file name.

    Let's say we're requesting THIS.ARC and all node lists from 12/2.  The file
    name would be 000C0002.REQ.  The contents would look like this:

                      this.arc
                      nodelist.*

    If the sysop of 12/2 requires a password of THAT to get the file THIS.ARC, the
    REQ file contents would have to change:

                      this.arc !that
                      nodelist.*

    Transaction-level passwords (of 6 or fewer characters) follow the file name:

                      <filename>!<password><cr>

    YooHoo and YooHoo/2u2                                              Page 9
    WaZOO File Requests

    If the request is of the "update" genre, the type of update and the time,
    expressed as a UNIX-style long decimal ASCII number, follows the name, or in
    the event that there is a transaction-level password, the password. For
    example, an update request for file NEWOPUS.*, where you already have a file
    dated 1-January 1989, 00:00 and you live on the East Coast (GMT+06) would be:

                      NEWOPUS.* +599634000

    The sign is required, it indicates the type of update request. A '+' means
    that all files matching the filespec "NEWOPUS.*" newer than the shown time
    will be sent, a '-' means that all matching files with dates up to and
    including the indicated time will be sent.

    The complete format of an action line in an REQ file is, then:

              <filename>[<space>!<password>][<space><+/->]<cr>

    MECHANISM:

    In a ZedZap or DietIfna session, the .REQ file is simply transmitted to the
    other system.  It goes "as is" like any other file. In a Janus session, the
    .REQ file will be sent one line at a time and individually serviced by the
    other end.

    The other system can ignore the request, send some of the files, or send all
    of the files.  There is no accounting or responsibilities on the part of the
    remote system.

    If your implementation is unable to process the update information for any
    reason, then you should process the line as a "regular" file request.

    NOTE:

    In the YooHoo packet, there's a bit that lets you know if the remote system
    currently accepts .REQ files.  This will be a clue as to whether a .REQ file
    would be a waste of time or not. Procedurally, you just should not send a .REQ
    file to a system which indicates that it won't process it.

    YooHoo and YooHoo/2u2                                              Page 10
    Structures and Definitions

    STRUCTURES AND DECLARATIONS
    ---------------------------

    #define ACK    0x06
    #define NAK    0x15
    #define ENQ    0x05
    #define YOOHOO 0xf1
    #define TSYNC  0xae

    struct   _Hello
        {
        word     signal;           /* always 'o'     (0x6f)                   */
        word     hello_version;    /* currently 1    (0x01)                   */
        word     product;          /* product code                            */
        word     product_maj;      /* major revision of the product           */
        word     product_min;      /* minor revision of the product           */
        char     my_name[60];      /* Other end's name, will include domain   */
                                   /* if DO_DOMAIN is set in capabilities mask*/
        char     sysop[20];        /* sysop's name                            */
        word     my_zone;          /* 0== not supported                       */
        word     my_net;           /* out primary net number                  */
        word     my_node;          /* our primary node number                 */
        word     my_point;         /* 0 == not supported                      */
        byte     my_password[8];   /* This is not necessarily null-terminated */
        byte     reserved2[8];     /* reserved by Opus                        */
        word     capabilities;     /* see below                               */
        byte     reserved3[12];    /* for non-Opus systems with "approval"    */
        };                         /*          total size 128 bytes           */

    /*------------------------------------------------------------------------*/
    /* YOOHOO<tm> CAPABILITY VALUES                                           */
    /*------------------------------------------------------------------------*/
    #define Y_DIETIFNA 0x0001  /* Can do fast "FTS-0001"  0000 0000 0000 0001 */
    #define FTB_USER   0x0002  /* Reserved by Opus-CBCS   0000 0000 0000 0010 */
    #define ZED_ZIPPER 0x0004  /* Does ZModem, 1K blocks  0000 0000 0000 0100 */
    #define ZED_ZAPPER 0x0008  /* Can do ZModem variant   0000 0000 0000 1000 */
    #define DOES_IANUS 0x0010  /* Can do Janus            0000 0000 0001 0000 */
    #define Bit_5      0x0020  /* reserved by FTSC        0000 0000 0010 0000 */
    #define Bit_6      0x0040  /* reserved by FTSC        0000 0000 0100 0000 */
    #define Bit_7      0x0080  /* reserved by FTSC        0000 0000 1000 0000 */
    #define Bit_8      0x0100  /* reserved by FTSC        0000 0001 0000 0000 */
    #define Bit_9      0x0200  /* reserved by FTSC        0000 0010 0000 0000 */
    #define Bit_a      0x0400  /* reserved by FTSC        0000 0100 0000 0000 */
    #define Bit_b      0x0800  /* reserved by FTSC        0000 1000 0000 0000 */
    #define Bit_c      0x1000  /* reserved by FTSC        0001 0000 0000 0000 */
    #define Bit_d      0x2000  /* reserved by FTSC        0010 0000 0000 0000 */
    #define DO_DOMAIN  0x4000  /* Packet contains domain  0100 0000 0000 0000 */
    #define WZ_FREQ    0x8000  /* WZ file req. ok         1000 0000 0000 0000 */

    YooHoo and YooHoo/2u2                                              Page 11
    Domain addressing in Hello Packet

    Since the invention of the WaZOO handshake, nearly every change in the
    FidoNet transport has been accessible by defining bits for new protocols,
    using the point number field in the structure, etc.

    With the advent of Domain addressing in FidoNet, this was no longer the
    case. There was no place set aside in the hello packet where domain info
    could be passed from one system to another.

    We have addressed this requirement by using some of the space set aside
    in the system name field for the domain. It is backward-compatible with
    all systems which determine the end of a string by use of a null.

    WaZOO systems that support domains communicate that fact by setting the
    DO_DOMAIN bit (hex 2000) in the capabilities mask. This tells the other
    side that they can expect to find a domain address in the packet.

    The domain name is stored at the end of the 'my_name' field. It is stored
    in its entirety (no abbreviations as in FSC-0045) after the system name.
    If the length of the system name plus the null terminator plus the length
    of the domain name plus terminator exceeds 60, the system name will be
    truncated (right to left) to make it fit.

    So, for a system named "FUBAR" at address 1:234/567@fidonet.org, the
    address and name fields in the header would look like this:

    hello.my_zone  = 1
    hello.my_net   = 234
    hello.my_node  = 567
    hello.my_point = 0
    hello.my_name  = 'F','U','B','A','R', 0, 'f','i','d','o','n','e','t',
                     '.','o','r','g',0
    hello.capabilities will contain the usual capabilities plus DO_DOMAIN.

    A remote system receiving this packet should look past the null in
    my_name to get the domain name.

    YooHoo and YooHoo/2u2                                              Page 12
    Caller State Tables

    Calling System:

    The parts of FTS-0001 and FTS-0007 which deal with synchronization of calling
    and called system must be modified to deal with the reception and processing
    of the YooHoo character and exchange of Hello packets. The following state
    table may be used to initiate an FTS-0001 or a WaZOO session by the calling
    system.  It replaces state S3 in the FTS-0001 table.

     .-----+----------+-------------------------+-------------------------+-----.
     |State| State    | Predicate(s)            | Action(s)               | Next|
     |  #  | Name     |                         |                         | Stat|
     |-----+----------+-------------------------+-------------------------+-----|
     | SS0 | SyncInit |                         | Prepare 3 sec Sync timer|     |
     |     |          |                         | Prepare .5 sec NAK tmr  |     |
     |     |          |                         | Init NAK Count          |     |
     |     |          |                         | Start 60 sec master tmr | SS1 |
     |-----+----------+-------------------------+-------------------------+-----|
     | SS1 | SendSync | 1. Over 60 seconds      |                         |     |
     |     |          |    or carrier lost      | no response             | exit|
     |     |          +-------------------------+-------------------------+-----|
     |     |          | 2. 3 sec elapsed        | Clear Inbound buffer    |     |
     |     |          |    or timer not started | Send YOOHOO, then TSYNC |     |
     |     |          |                         | Start 3 sec Sync timer  | SS2 |
     |     |          +-------------------------+-------------------------+-----|
     |     |          | 3. not elapsed          |                         | SS2 |
     |-----+----------+-------------------------+-------------------------+-----|
     | SS2 | WaitResp | 1. Nothing received     | require a response      | SS1 |
     |     |          +-------------------------+-------------------------+-----|
     |     |          | 2. ENQ received         | WaZOO Protocol selected | exit|
     |     |          +-------------------------+-------------------------+-----|
     |     |          | 3. 'C' received         | probable FTS-0001       | SS3 |
     |     |          +-------------------------+-------------------------+-----|
     |     |          | 4. NAK received         | probable FTS-0001       | SS3 |
     |     |          +-------------------------+-------------------------+-----|
     |     |          | 5. Debris (might include| Reset NAK timer         |     |
     |     |          |    (YOOHOO|TSYNC) & 127)| if started              | SS1 |
     |-----+----------+-------------------------+-------------------------+-----|
     | SS3 | NAKTmr   | 1. Timer not expired    | Zero NAK count          |     |
     |     |          |    or timer not started | Start .5 sec NAK timer  | SS1 |
     |     |          +-------------------------+-------------------------+-----|
     |     |          | 2. Timer expired        | Bump NAK count          | SS4 |
     |-----+----------+-------------------------+-------------------------+-----|
     | SS4 | NAKCount | 1. Count >= 2?          | assume FTS-0001         | exit|
     |     |          +-------------------------+-------------------------+-----|
     |     |          | 2. Count < 2            | Keep looking            | SS1 |
     `-----+----------+-------------------------+-------------------------+-----'

    YooHoo and YooHoo/2u2                                              Page 13
    Caller State Tables

    Calling System (continued):

    The FTS-0001 exits from the above table should operate using the FTS-0001
    state tables, starting at state S4. The "WaZOO detected" case should proceed
    using the following state table:

     .-----+----------+-------------------------+-------------------------+-----.
     |State| State    | Predicate(s)            | Action(s)               | Next|
     |  #  | Name     |                         |                         | Stat|
     |-----+----------+-------------------------+-------------------------+-----|
     | YS1 | SndHello | Successful              | Looks like WaZOO        | YS2 |
     |     | (state   +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
     |     |  SH1)    | Not successful          | Repeat whole thing      | exit|
     |-----+----------+-------------------------+-------------------------+-----|
     | YS2 | WaitResp | 30 sec timer expires    | repeat whole thing      | exit|
     |     |          | or lost carrier         |                         |     |
     |     |          +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
     |     |          | Received YOOHOO         | Another WaZOO, go       | YS3 |
     |     |          |                         | process receive         |     |
     |     |          +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
     |     |          | Received debris         | Repeat whole thing      | YS2 |
     |-----+----------+-------------------------+-------------------------+-----|
     | YS3 | GetHello | Information             | Report Success          | exit|
     |     | (state   | Successfully            |                         |     |
     |     |  RH1)    | Exchanged               |                         |     |
     |     |          +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
     |     |          | Failure                 | Repeat whole thing      | exit|
     `-----+----------+-------------------------+-------------------------+-----'

    The failure cases in this table may be retried. The retry should be from
    the point of synchronization. This means redoing the process in the SendSync
    table on Page 11. A really smart mailer could therefore do a YooHoo, exchange
    information, decide that it doesn't want to do WaZOO, fail out, and attempt
    an FTS-0001 session.

    If the packet exchange is successful, session method selection proceeds and
    then the chosen session method should be employed to exchange mail and files.

    YooHoo and YooHoo/2u2                                              Page 14
    Called System State Tables

    The following state table may be used to initiate an FTS-0001 or a WaZOO
    session by the called system.  It replaces states R1 and R2 in the FTS-0001
    table.

     .-----+----------+-------------------------+-------------------------+-----.
     |State| State    | Predicate(s)            | Action(s)               | Next|
     |  #  | Name     |                         |                         | Stat|
     |-----+----------+-------------------------+-------------------------+-----|
     | RS0 | SyncInit |                         | Start 5 second idle tmr | RS1 |
     |-----+----------+-------------------------+-------------------------+-----|
     | RS1 | IdleWait | 1. 5 sec tmr expired    | Take the initiative     | RS2 |
     |     |          +-------------------------+-------------------------+-----|
     |     |          | 2. Carrier lost         | Session aborted         | exit|
     |     |          +-------------------------+-------------------------+-----|
     |     |          | 3. Peek = YOOHOO        | Looks like a live WaZOO | RS3 |
     |     |          +-------------------------+-------------------------+-----|
     |     |          | 4. Peek = TSYNC         | Live FTS-0001, we think | RS3 |
     |     |          +-------------------------+-------------------------+-----|
     |     |          | 5. Peek = CR, LF, space | He looks alive          | RS2 |
     |     |          +-------------------------+-------------------------+-----|
     |     |          | 6. Other character      | Eat it                  | RS1 |
     |-----+----------+-------------------------+-------------------------+-----|
     | RS2 |SendBanner| 1. Error returned       | Session aborted         | exit|
     |     |          +-------------------------+-------------------------+-----|
     |     |          | 2. Banner sent OK       |                         | RS3 |
     |-----+----------+-------------------------+-------------------------+-----|
     | RS3 |RecvInit  |                         | Start 20 sec timer      | RS4 |
     |     |          |                         | Init 10 sec timer       |     |
     |-----+----------+-------------------------+-------------------------+-----|
     | RS4 |SendSync  | 1. Error returned       | Session aborted         | exit|
     |     |(xmit sync+-------------------------+-------------------------+-----|
     |     |string)   | 2. String sent OK       | Watch for sender sync   | RS5 |
     |-----+----------+-------------------------+-------------------------+-----|
     | RS5 | WaitSync | 1. Carrier lost         | Session aborted         | exit|
     |     |          +-------------------------+-------------------------+-----|
     |     |          | 2. YOOHOO received      | WaZOO session selected  | exit|
     |     |          +-------------------------+-------------------------+-----|
     |     |          | 3. TSYNC received       | probable FTS-0001       | RS6 |
     |     |          +-------------------------+-------------------------+-----|
     |     |          | 4. CR received          | Still sync'ing          | RS4 |
     |     |          +-------------------------+-------------------------+-----|
     |     |          | 5. Other character rcvd | Get next input character| RS5 |
     |     |          +-------------------------+-------------------------+-----|
     |     |          | 6. 10 sec timer elapsed | FTS-0001 selected       | exit|
     |     |          +-------------------------+-------------------------+-----|
     |     |          | 7. 20 sec timer elapsed | Not a mail session      | exit|
     |-----+----------+-------------------------+-------------------------+-----|
     | RS6 | TsyncTmr | 1. Timer not running    | Start 10 second timer   | RS5 |
     |     |          |                         | Reset 20 sec timer      |     |
     |     |          +-------------------------+-------------------------+-----|
     |     |          | 2. Timer running        | Two TSYNCS = FTS-0001   | exit|
     `-----+----------+-------------------------+-------------------------+-----'

    YooHoo and YooHoo/2u2                                              Page 15
    Called System State Tables

    The FTS-0001 exits from the above table should operate using the FTS-0001
    state tables, starting at state R3. The "WaZOO detected" case should proceed
    using the following state table:

     .-----+----------+-------------------------+-------------------------+-----.
     |State| State    | Predicate(s)            | Action(s)               | Next|
     |  #  | Name     |                         |                         | Stat|
     |-----+----------+-------------------------+-------------------------+-----|
     | YR1 | GetHello | Information             | Start 20 sec timer      | YR2 |
     |     | (state   | Successfully            | Initialize retry count  |     |
     |     |  RH1)    | Exchanged               | Send YooHoo             |     |
     |     |          +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
     |     |          | Failure                 | Repeat whole thing      | exit|
     |-----+----------+-------------------------+-------------------------+-----|
     | YR2 | WaitResp | 20 sec timeout          | try again               | YR3 |
     |     |          +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
     |     |          | Lost carrier            | Failure                 | exit|
     |     |          +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
     |     |          | Received ENQ            | Go send hello           | YR4 |
     |     |          +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
     |     |          | Received debris         | Keep looking            | YR2 |
     |-----+----------+-------------------------+-------------------------+-----|
     | YR3 | PollPeer | More than 3 retries     | Give it up              | exit|
     |     |          +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
     |     |          | Less than 3 retries     | Bump retry count        | YR2 |
     |     |          |                         | Clear input buffer      |     |
     |     |          |                         | Send YOOHOO             |     |
     |     |          |                         | Restart 20 sec timer    |     |
     |-----+----------+-------------------------+-------------------------+-----|
     | YR4 | SndHello | Successful              | All done, report success| exit|
     |     | (state   +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
     |     |  SH1)    | Not successful          | Repeat whole thing      | exit|
     `-----+----------+-------------------------+-------------------------+-----'

    The failure cases in states YR1, YR3 and YR4 of this table may be retried.
    The retry should be from the point of synchronization. This means redoing the
    process in the RecvSync table on Page 13, beginning at state RS3. A really
    smart mailer could therefore do a YooHoo, exchange information, decide that
    it doesn't want to (or cannot) do a WaZOO session, fail out, and attempt
    an FTS-0001 session.

    If the packet exchange is successful, session method selection proceeds and
    then the chosen session method should be employed to exchange mail and files.

    YooHoo and YooHoo/2u2                                              Page 16
    Packet Exchange State Tables

    The following state table describes the transmission of the "Hello" packet
    from one system to its partner:

     .-----+----------+-------------------------+-------------------------+-----.
     |State| State    | Predicate(s)            | Action(s)               | Next|
     |  #  | Name     |                         |                         | Stat|
     |-----+----------+-------------------------+-------------------------+-----|
     | SH1 | InitSend |                         | Disable XON/XOFF        | SH2 |
     |     |          |                         | Set retry count to 0    |     |
     |-----+----------+-------------------------+-------------------------+-----|
     | SH2 | SendHedr |                         | Send Hex 1f, then       | SH3 |
     |     |          |                         | Send HELLO struct       |     |
     |-----+----------+-------------------------+-------------------------+-----|
     | SH3 | SendCRC  |                         | Clear Input Buffer      | SH4 |
     |     |          |                         | Send two-byte CRC of pkt|     |
     |     |          |                         | MSB followed by LSB     |     |
     |     |          |                         | Start 40 second timer   |     |
     |-----+----------+-------------------------+-------------------------+-----|
     | SH4 | GetResp  | 40 second timer expires | Failed to send packet   | exit|
     |     |          | or carrier lost         |                         |     |
     |     |          +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
     |     |          | ACK received            | Successful transmission | exit|
     |     |          +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
     |     |          | '?' received            | Error, try retransmit   | SH2 |
     |     |          +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
     |     |          | ENQ received            | Out of sync?            | SH2 |
     |     |          +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
     |     |          | other character recvd   | Debris, keep watching   | SH4 |
     `-----+----------+-------------------------+-------------------------+-----'

    YooHoo and YooHoo/2u2                                              Page 17
    Packet Exchange State Tables

    The following state table describes the reception of the "Hello" packet sent
    to a system by its partner:

     .-----+----------+-------------------------+-------------------------+-----.
     |State| State    | Predicate(s)            | Action(s)               | Next|
     |  #  | Name     |                         |                         | Stat|
     |-----+----------+-------------------------+-------------------------+-----|
     | RH1 | SendENQ  |                         | Start 2 minute timer    | RH2 |
     |     |          |                         | Send an ENQ character   |     |
     |-----+----------+-------------------------+-------------------------+-----|
     | RH2 | WaitHedr | 2 minute timer expires  | Report failure          | exit|
     |     |          | or carrier lost         |                         |     |
     |     |          +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
     |     |          | Received Hex 1f         | Got header, get packet  | RH5 |
     |     |          +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
     |     |          | Received other char     | Debris, throw away      | RH3 |
     |     |          |                         | Start 10 sec timer      |     |
     |-----+----------+-------------------------+-------------------------+-----|
     | RH3 | TossJunk | 10 sec timer expires    | Too much noise          | RH4 |
     |     |          +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
     |     |          | Received Hex 1f         | Got header, get packet  | RH5 |
     |     |          +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
     |     |          | Input buffer empty      | Try to resynch          | RH4 |
     |     |          +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
     |     |          | Carrier lost            | Report failure          | exit|
     |-----+----------+-------------------------+-------------------------+-----|
     | RH4 | ReSynch  |                         | Clear input buffer      | RH2 |
     |     |          |                         | Send ENQ                |     |
     |-----+----------+-------------------------+-------------------------+-----|
     | RH5 | HdrSetup |                         | Initialize CRC          |     |
     |     |          |                         | Set 30 second timer     | RH6 |
     |-----+----------+-------------------------+-------------------------+-----|
     | RH6 | GetHChar | 30 sec timer expires or |                         |     |
     |     |          | carrier lost            | Report failure          | exit|
     |     |          +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
     |     |          | Character received      | Process character       | RH7 |
     |     |          +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
     |     |          | 10 seconds with no char | Error, try resync       | RH9 |
     |-----+----------+-------------------------+-------------------------+-----|
     | RH7 | StoHChar | Buffer and CRC filled   | Compare CRC             | RH8 |
     |     |          +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
     |     |          | More characters needed  | Reset 30 sec timer      | RH6 |
     |-----+----------+-------------------------+-------------------------+-----|
     | RH8 | CheckCRC | CRC matches             | Finish Receive          | RH10|
     |     |          +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
     |     |          | CRC doesn't match       | Handle error            | RH9 |
     |-----+----------+-------------------------+-------------------------+-----|
     | RH9 | CountERR | Less than 10 errors     | Send '?' (0x3f)         | RH2 |
     |     |          +- - - - - - - - - - - - -+- - - - - - - - - - - - -+- - -|
     |     |          | 10 errors               | Hang up, report failure | exit|
     |-----+----------+-------------------------+-------------------------+-----|
     | RH10| HelloOK  |                         | Clear inbound buffer    | exit|
     |     |          |                         | Send ACK                |     |
     `-----+----------+-------------------------+-------------------------+-----'

Go Back