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<6F>
|
||
think.
|
||
|
||
This revision is in response to a comment Vince made to me regarding the first<73>
|
||
one, that the sync machines would falsely trigger "FSC001" on and two 'C's in<69>
|
||
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<6F>
|
||
documented directly in anything I've ever seen: they all output text to<74>
|
||
presumably inform humans as to why they may not be able to get access, because<73>
|
||
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<69>
|
||
to determine "human" login, or FSC001 or WAZOO. BBS vs. mailer.
|
||
|
||
Anyways, the important Thing is actually in FSC001: the old "whack return"<22>
|
||
sequence. It was not only for that terrible baud-rate-determination business,<2C>
|
||
but also to get in sync with the mailer; the "call back later" code was/is<69>
|
||
part of the protocol. It's an edge-detector; the edge between BBS-signon and<6E>
|
||
no-BBS-signon (from where protocol starts).
|
||
|
||
The first version of these tables was meant to deal with the TSYNC/YOOHOO<4F>
|
||
portion only, out of it's overall context, but Vince, by pointing out the<68>
|
||
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<61>
|
||
states would take care of getting through the BBS signon in the normal case<73>
|
||
(ahem). (See the WaitSync state in the Receiver's state machine.)
|
||
|
||
Second, sequentiality on the 'C'(or NAKs) s doesn't guarentee anything: why<68>
|
||
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<64>
|
||
ever did, nor does now. (I better get coding!) Fido's is a loop that issues<65>
|
||
the CR/space FIRST, then looks for a response. (20 tries max.) All of our<75>
|
||
programs DO this in reality; Bink issues the "hit ESCape if you're a human"<22>
|
||
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,<2C>
|
||
more specifically), or should we make it work as in Binkley, that it tolerates<65>
|
||
them? I prefer making them mandatory, ie. as in FSC001 (see states<65>
|
||
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<65>
|
||
with no human/BBS message (rude! (unlikely today)) In either case, the<68>
|
||
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<65>
|
||
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<6E>
|
||
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<69>
|
||
according to FSC001 (presumably), and others do similar things, and they all<6C>
|
||
work together, because we all issue messages. But what about the future, say<61>
|
||
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<6D>
|
||
later! :-) I think Bink's outputting the "... if you're a human ..." message<67>
|
||
once per second or more often prevents Fido11's mailer from getting past the<68>
|
||
WaitClear state; it requires significantly longer than 500mS of quiet. And<6E>
|
||
will also degrade noise margins, by excessively narrowing the potential for<6F>
|
||
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<69>
|
||
leaves only a 700mS window for the quiet time to occur ... and if one happens<6E>
|
||
in there, it will miss. Outputting the message every (say) 3 - 4 seconds would<6C>
|
||
suffice to make the window much wider.
|
||
|
||
If this is even the case, I am going from memory how fast the Bink message<67>
|
||
"appears" to be ... luckily you both live far away from me so physical<61>
|
||
retribution is difficult.
|
||
|
||
----------------------------------------------------------------
|
||
|
||
|
||
SendSync: Wazoo vs. FSC001 Protocol Determination
|
||
|
||
|
||
This is the senders FSC001/Wazoo protocol session synchronization and protocol<6F>
|
||
determination. In simple terms, this issues the two different protocol sync<6E>
|
||
characters, YOOHOO for the WAZOO protocol, and TSYNC for the FSC001 protocol,<2C>
|
||
and attempts to determine from the receivers response which protocol to<74>
|
||
select.
|
||
|
||
The protocol drivers in use "today" (September, 1989) many times support both<74>
|
||
WAZOO and FSC001; those that do heavily favor WAZOO, for it's added features<65>
|
||
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<77>
|
||
as "whack return" is done; it originally was to determine baud rate from dumb,<2C>
|
||
non-"AT command" type modems (say, Bell 212A's), but also causes the mailer to<74>
|
||
act like a human caller, to get it through initial welcome messages and the<68>
|
||
answering modem/software system's initial delays and such.
|
||
|
||
After the BBS Response phase, YOOHOO and TSYNC characters are issued, after<65>
|
||
which we wait for a response. A response indicating WAZOO is accepted<65>
|
||
immediately. Possible responses to TSYNC (see below) are deferred for 10<31>
|
||
seconds. This allows distinguishing apparent TSYNC "responses" from garbage,<2C>
|
||
and allows receivers that favor WAZOO to respond. If no valid response to<74>
|
||
YOOHOO is received within 10 seconds, the TSYNC character(s) received earlier<65>
|
||
are honored, and FSC001 protocol is selected.
|
||
|
||
Selection of WAZOO protocol is immediate; selection of FSC001 is delayed 10<31>
|
||
seconds from the receipt of the first valid TSYNC character, which adds 10<31>
|
||
seconds of connect-time to all FSC001 sessions.
|
||
|
||
IMPLEMENTATION NOTE: While WAZOO defines ENQ as a response to the senders<72>
|
||
YOOHOO, there is no corresponding "TSYNC response" designed into FSC001<30>
|
||
protocol. What is generally accepted as a "TSYNC response" is to wait for the<68>
|
||
'C' or NAK character that the receivers' XMODEM driver issues when it has<61>
|
||
recognized the senders TSYNC. (Refer to FSC001-9, state R2, WaitTsync.) This<69>
|
||
"eats" one XMODEM-start character, and delays the actual start of the packet<65>
|
||
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<31>
|
||
decimal) at this point is tolerable to the receiver, and might abort long<6E>
|
||
bulletin board "welcome messages" that delay getting through the sync<6E>
|
||
process.)
|
||
|
||
& (IMPLEMENTATION NOTE: Cute, but hardly necessary. Most BBS line inputters<72>
|
||
(say first name, last name, password...) strip parity from incoming<6E>
|
||
characters, so if you somehow reached a BBS that doesn't do FidoNet mail, it<69>
|
||
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.<2E>
|
||
Doesn't it do an xmodem-like "initial NAK"? Wouldn't it start OK by issuing<6E>
|
||
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<6C>
|
||
terms, this listens for one of the two possible protocol sync characters;<3B>
|
||
YOOHOO for WAZOO protocol, or TSYNC for FSC001 protocol.
|
||
|
||
Once again, the protocol drivers in use "today" (September, 1989) many times<65>
|
||
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<77>
|
||
reliable fall-back to FSC001.
|
||
|
||
Response to YOOHOO is immediate; WAZOO is selected. If a TSYNC character is<69>
|
||
received however, it is deferred for 10 seconds to allow detection of any<6E>
|
||
subsequent YOOHOO character. After 10 seconds, if not YOOHOO is received, the<68>
|
||
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|
|
||
`-----+----------+-------------------------+-------------------------+-----'
|
||
|
||
.-----+----------+-------------------------+-------------------------+-----.
|
||
| | | | | |
|
||
| | | | | |
|
||
|-----+----------+-------------------------+-------------------------+-----|
|
||
| | | | | |
|
||
| | | | | |
|
||
`-----+----------+-------------------------+-------------------------+-----'
|