Tom Jennings
1 Sep 89	revision 1
6 Sep 89	revision 2

Proposed WAZOO/FSC001 combined protocol state machines. Tell me what you
think.

This revision is in response to a comment Vince made to me regarding the first
one, that the sync machines would falsely trigger "FSC001" on and two 'C's in
a BBS signon (for example: "... Opus CBCS System ..."). First, a digression...

There is something important that all of our mailers and BBSs do that is not
documented directly in anything I've ever seen: they all output text to
presumably inform humans as to why they may not be able to get access, because
that phone number is mail-only, either temporarily or permanently.

	1. Modems connect
	2. Ambiguous delay
	3. Signon message
	4. Ambiguous delay
	5. Protocol determination
	6. ...

The goal is not to distinguish between two (at the moment...) protocols; it is
to determine "human" login, or FSC001 or WAZOO. BBS vs. mailer.

Anyways, the important Thing is actually in FSC001: the old "whack return"
sequence. It was not only for that terrible baud-rate-determination business,
but also to get in sync with the mailer; the "call back later" code was/is
part of the protocol. It's an edge-detector; the edge between BBS-signon and
no-BBS-signon (from where protocol starts).

The first version of these tables was meant to deal with the TSYNC/YOOHOO
portion only, out of it's overall context, but Vince, by pointing out the
above, made clear the importance of the WhackCR/WaitClear states. 



... but back to the issue at hand. My response is twofold:

First, the sync machines should never see a BBS signon. The WhackCR/WaitClear
states would take care of getting through the BBS signon in the normal case
(ahem). (See the WaitSync state in the Receiver's state machine.)

Second, sequentiality on the 'C'(or NAKs) s doesn't guarentee anything: why
there's a BBS in my own net called "NCFCC". There you go. 



The WhackCR/WaitClear thing in FSC001 (and in these tables) is not what Fido
ever did, nor does now. (I better get coding!) Fido's is a loop that issues
the CR/space FIRST, then looks for a response. (20 tries max.) All of our
programs DO this in reality; Bink issues the "hit ESCape if you're a human"
message, which satisfies it, then falls into the "loop" where it looks for a
CR "first".

Should we codify this, so that the spec requires the outputting of text (CRs,
more specifically), or should we make it work as in Binkley, that it tolerates
them? I prefer making them mandatory, ie. as in FSC001 (see states
WhackCRs/WaitClear), but it could also be that the sender "prefers" them:

|     |          |                         |                         |     |
|-----+----------+-------------------------+-------------------------+-----|
| WSC | WhackCR  | 1. Over 10 seconds      | assume no BBS signon    | WS0 |
|     |          | 2. CR received          | BBS signon in progress  | WSD |
|     |          | 3. neither              | output CR, space        | WSC |
|-----+----------+-------------------------+-------------------------+-----|
| WSD | WaitClear| 1. no input for 500mS   | go determine protocol   | WS0 |
|     |          | 2. over 60 sec not clear| hang up, report garbage | exit|
|-----+----------+-------------------------+-------------------------+-----|
|     |          |                         |                         |     |

WhackCRs.1: OK, it's either a dead-as-a-doorknob modem, or a mail-only system
with no human/BBS message (rude! (unlikely today)) In either case, the
connection is made, we've paid for it (assuming a phone line), and if it's
dead, well, we're dealing with an exception to begin with. Subsequent states
will figure that out.

WhackCRs.2: No problem. Normal state of affairs today.

WhackCRs.3: FSC001, vestigial, and painless, and also can be used to re-sync
lost and/or confused senders (see Receiver's WaitSync.4). 

Who knows. This isn't critical now; Fido does it "my" way, and Bink does it
according to FSC001 (presumably), and others do similar things, and they all
work together, because we all issue messages. But what about the future, say
assumed-network-node-only? (But we're documenting current practice! Hmm...)



Now let me cause a bit more trouble (Bob & Vince: you can wreak revenge on me
later! :-) I think Bink's outputting the "... if you're a human ..." message
once per second or more often prevents Fido11's mailer from getting past the
WaitClear state; it requires significantly longer than 500mS of quiet. And
will also degrade noise margins, by excessively narrowing the potential for
there actually being 500mS of quiet ...

    0                            500mS                        1000mS
    |--------------------X--------+------------X-----------------|

If a garbage character (X's) occurs say 300mS after the message stops, it
leaves only a 700mS window for the quiet time to occur ... and if one happens
in there, it will miss. Outputting the message every (say) 3 - 4 seconds would
suffice to make the window much wider.

If this is even the case, I am going from memory how fast the Bink message
"appears" to be ... luckily you both live far away from me so physical
retribution is difficult.

----------------------------------------------------------------


SendSync: Wazoo vs. FSC001 Protocol Determination


This is the senders FSC001/Wazoo protocol session synchronization and protocol
determination. In simple terms, this issues the two different protocol sync
characters, YOOHOO for the WAZOO protocol, and TSYNC for the FSC001 protocol,
and attempts to determine from the receivers response which protocol to
select.

The protocol drivers in use "today" (September, 1989) many times support both
WAZOO and FSC001; those that do heavily favor WAZOO, for it's added features
and performance. The sync process below favors WAZOO but allows reliable 
fall-back to FSC001.

(rev2) Before the protocol determination is done, a process historically known
as "whack return" is done; it originally was to determine baud rate from dumb,
non-"AT command" type modems (say, Bell 212A's), but also causes the mailer to
act like a human caller, to get it through initial welcome messages and the
answering modem/software system's initial delays and such. 

After the BBS Response phase, YOOHOO and TSYNC characters are issued, after
which we wait for a response. A response indicating WAZOO is accepted
immediately. Possible responses to TSYNC (see below) are deferred for 10
seconds. This allows distinguishing apparent TSYNC "responses" from garbage,
and allows receivers that favor WAZOO to respond. If no valid response to
YOOHOO is received within 10 seconds, the TSYNC character(s) received earlier
are honored, and FSC001 protocol is selected.

Selection of WAZOO protocol is immediate; selection of FSC001 is delayed 10
seconds from the receipt of the first valid TSYNC character, which adds 10
seconds of connect-time to all FSC001 sessions.

IMPLEMENTATION NOTE: While WAZOO defines ENQ as a response to the senders
YOOHOO, there is no corresponding "TSYNC response" designed into FSC001
protocol. What is generally accepted as a "TSYNC response" is to wait for the
'C' or NAK character that the receivers' XMODEM driver issues when it has
recognized the senders TSYNC. (Refer to FSC001-9, state R2, WaitTsync.) This
"eats" one XMODEM-start character, and delays the actual start of the packet
transfer, but is otherwise acceptable.


Sender:

  .-----+----------+-------------------------+-------------------------+-----.
  |State| State    | Predicate(s)            | Action(s)               | Next|
  |  #  | Name     |                         |                         | Stat|
  |-----+----------+-------------------------+-------------------------+-----|
  | WSA | SendInit |                         | Dial modem              | WSB |
  |-----+----------+-------------------------+-------------------------+-----|
  | WSB | WaitCxD  | 1. Carrier detected     | delay 1 - 5 seconds     | WSC |
  |     |          | 2. busy, etc            | report no connection    | exit|
  |     |          | 3. voice                | report no carrier       | exit|
  |     |          | 4. carrier not detected |                         |     |
  |     |          |    within 120 seconds   | report no connection    | exit|
  |-----+----------+-------------------------+-------------------------+-----|
  | WSC | WhackCRs | 1. Over 30 seconds      | report no response      | exit|
  |     |          | 2. ?? CRs received      | delay 1 second          | WSD |
  |     |          | 3. CRs not received     | output CR, space, CR,   |     |
* |     |          |                         |     space               | WSC |
  |-----+----------+-------------------------+-------------------------+-----|
  | WSD | WaitClear| 1. no input for 500mS   | go determine protocol   | WS0 |
  |     |          | 2. over 60 sec not clear| hang up, report garbage | exit|
  |-----+----------+-------------------------+-------------------------+-----|
  | WS0 | SyncInit |                         | Prepare 3 sec Sync timer|     |
  |     |          |                         | Prepare 10 sec TSYNC tmr| WS1 |
  |-----+----------+-------------------------+-------------------------+-----|
  | WS1 | SendSync | 1. 3 sec elapsed        | Send YOOHOO, then TSYNC | WS2 |
  |     |          | 2. not elapsed          |                         | WS2 |
  |-----+----------+-------------------------+-------------------------+-----|
  | WS2 | WaitResp | 1. ENQ received         | Wazoo Protocol selected | exit|
  |     |          | 2. 'C' received         | probable FSC001         | WS3 |
  |     |          | 3. NAK received         | probable FSC001         | WS3 |
  |     |          | 4. 10 sec timer elapse? | assume FSC001           | exit|
  |     |          | 5. Debris, nothing      | require a response      | WS1 |
& |     |          | 6. (YOOHOO AND 127)     | probable BBS input echo | WS1 |
& |     |          | 7. (TSYNC AND 127)      | probable BBS input echo | WS1 |
  |     |          | 8. Over 60 seconds      | no response             | exit|
  |-----+----------+-------------------------+-------------------------+-----|
  | WS3 | TsyncTmr | 1. Timer not running    | Start 10 second timer   | WS1 |
  |     |          | 2. Timer running        |                         | WS1 |
  `-----+----------+-------------------------+-------------------------+-----'

* (IMPLEMENTATION NOTE: Issueing an ETX (03 decimal) and a VT character (11
decimal) at this point is tolerable to the receiver, and might abort long
bulletin board "welcome messages" that delay getting through the sync
process.)

& (IMPLEMENTATION NOTE: Cute, but hardly necessary. Most BBS line inputters
(say first name, last name, password...) strip parity from incoming
characters, so if you somehow reached a BBS that doesn't do FidoNet mail, it
may assume your mailer program is a human with a strange name. Might be nice to see in a log file, is all.)

Note that there is no mention of the 00/FF responses in YOOHOO.DOC. I don't
know what that is, though I suspect it is SEALINK. I don't know SEALINK.
Doesn't it do an xmodem-like "initial NAK"? Wouldn't it start OK by issuing
NAK/C, and the 00/FF's fall under "debris"?


RecvSync: Wazoo vs. FSC001 Protocol Determination

This is the receivers FSC001/WAZOO session protocol determination. In simple
terms, this listens for one of the two possible protocol sync characters;
YOOHOO for WAZOO protocol, or TSYNC for FSC001 protocol.

Once again, the protocol drivers in use "today" (September, 1989) many times
support both WAZOO and FSC001; those that do heavily favor WAZOO, for it's
added features and performance. The sync process below favors WAZOO but allows
reliable fall-back to FSC001.

Response to YOOHOO is immediate; WAZOO is selected. If a TSYNC character is
received however, it is deferred for 10 seconds to allow detection of any
subsequent YOOHOO character. After 10 seconds, if not YOOHOO is received, the
TSYNC is honored and FSC001 protocol selected.

.-----+----------+-------------------------+-------------------------+-----.
|State| State    | Predicate(s)            | Action(s)               | Next|
|  #  | Name     |                         |                         | Stat|
|-----+----------+-------------------------+-------------------------+-----|
| WR0 |          |                         | send signon/welcome msg | WR1 |
|-----+----------+-------------------------+-------------------------+-----|
| WR1 | WaitSync | 1. YOOHOO received      | Send ENQ character,     |     |
|     |          |                         |     WAZOO selected      | exit|
|     |          | 2. TSYNC received       | probable FSC001         | WR2 |
|     |          | 3. 10 sec timer elapsed | FSC001 protocol selected| exit|
|     |          | 4. CR received          | Sender still in FS2     | WR3 |
|     |          | 5. 60 seconds elapses   | No proper response      | exit|
|-----+----------+-------------------------+-------------------------+-----|
| WR2 | TsyncTmr | 1. Timer not running    | Start 10 second timer   | WR1 |
|     |          | 2. Timer running        |                         | WR1 |
|-----+----------+-------------------------+-------------------------+-----|
| WR3 | SyncCR   |                         | Send CR                 | WR1 |
`-----+----------+-------------------------+-------------------------+-----'

Spare parts:

.-----+----------+-------------------------+-------------------------+-----.
|State| State    | Predicate(s)            | Action(s)               | Next|
|  #  | Name     |                         |                         | Stat|
`-----+----------+-------------------------+-------------------------+-----'

.-----+----------+-------------------------+-------------------------+-----.
|     |          |                         |                         |     |
|     |          |                         |                         |     |
|-----+----------+-------------------------+-------------------------+-----|
|     |          |                         |                         |     |
|     |          |                         |                         |     |
`-----+----------+-------------------------+-------------------------+-----'
