260 lines
14 KiB
Plaintext
260 lines
14 KiB
Plaintext
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|
|
|
`-----+----------+-------------------------+-------------------------+-----'
|
|
|
|
.-----+----------+-------------------------+-------------------------+-----.
|
|
| | | | | |
|
|
| | | | | |
|
|
|-----+----------+-------------------------+-------------------------+-----|
|
|
| | | | | |
|
|
| | | | | |
|
|
`-----+----------+-------------------------+-------------------------+-----'
|