134 lines
5.8 KiB
Plaintext
134 lines
5.8 KiB
Plaintext
|
I think I have a first pass at a solution to Wazoo protocol standardization<6F>
|
|||
|
|
that solves all of our problems:
|
|||
|
|
|
|||
|
|
1. No or trivial change to existing programs
|
|||
|
|
2. Existing programs will not become obsolete
|
|||
|
|
3. No or little impact on new designs.
|
|||
|
|
|
|||
|
|
Also there is a simple way to choose amongst the many protocols potentially<6C>
|
|||
|
|
available with this scheme. The bit definitions below are arbitrary, I just<73>
|
|||
|
|
chose them for my convenience in this document:
|
|||
|
|
|
|||
|
|
Y_DIETIFNA 0000 0000 0000 0001 XMODEM w/ TELINK block
|
|||
|
|
Y_SEALINK 0000 0000 0000 0100 base-level SEALINK
|
|||
|
|
ZED_ZAPPER 0000 0000 0000 1000 ZMODEM/8K blocks
|
|||
|
|
DOES_IANUS 0000 0000 0001 0000
|
|||
|
|
Y_ZMODEM 0000 0000 0010 0000 Forsberg ZMODEM
|
|||
|
|
Y_SEA_OVD 0000 0000 0100 0000 SEALINK Overdrive
|
|||
|
|
|
|||
|
|
Change #1: Define DIETIFNA as XMODEM-with-a-TELINK-block, not as SEALINK.
|
|||
|
|
|
|||
|
|
Change #2: Make this bit MANDATORY for Wazoo compatibility.
|
|||
|
|
|
|||
|
|
This is the biggest change I'm proposing. Please bear with me -- this<69>
|
|||
|
|
enhances SEALINK not minimize it. It allows choosing SEALINK OVERDRIVE if<69>
|
|||
|
|
both systems support it (instead of only finding that out when you get the<68>
|
|||
|
|
bit set in the SEALINK block 0). It allows DIETIFNA/ZMODEM systems to<74>
|
|||
|
|
choose ZMODEM in that case.
|
|||
|
|
|
|||
|
|
These bits aren't PROTOCOLS, they are CAPABILITIES; what protocol module<6C>
|
|||
|
|
you invoke in your program is another issue, as will become clear later.
|
|||
|
|
|
|||
|
|
Y_DIETIFNA: Defined as Telink-without-the-Modem7-filename, ie. the stuff in<69>
|
|||
|
|
FSC006. Xmodem-with-the-Telink-block. Since you need to have XMODEM to do<64>
|
|||
|
|
FSC001, this shouldn't be a problem.
|
|||
|
|
|
|||
|
|
Y_SEALINK: Defined separately because SEALINK does things above and beyond<6E>
|
|||
|
|
DIETIFNA -- file update, file restart, etc. Upward compatible with SEALINK<4E>
|
|||
|
|
OVERDRIVE.
|
|||
|
|
|
|||
|
|
Y_SEA_OVD: Full streaming SEALINK.
|
|||
|
|
|
|||
|
|
ZED_ZAPPER: No change.
|
|||
|
|
|
|||
|
|
Y_ZMODEM: Simply Forsberg's "standard" Zmodem, ie. block size never goes<65>
|
|||
|
|
over 1024 bytes. Though it's not exactly "standard" because of the need to<74>
|
|||
|
|
be able to do a null session.
|
|||
|
|
|
|||
|
|
CHOOSING A PROTOCOL AT CONNECT TIME:
|
|||
|
|
|
|||
|
|
Here's where the separate DIETIFNA/SEALINK/SEALINK OVERDRIVE bits come in.<2E>
|
|||
|
|
The procedure is, the calling node sends its Hello packet, which contains<6E>
|
|||
|
|
the bits that say what it is capable of; the receiver responds with its own<77>
|
|||
|
|
Hello packet, which specifies which protocol will be used that session (and<6E>
|
|||
|
|
it was here that the trouble happens if there is no protocol in common.)
|
|||
|
|
|
|||
|
|
The idea is that the receiver should choose one protocol amongst the many.
|
|||
|
|
|
|||
|
|
If both our systems do DIETIFNA and ZEDZAP, the obvious choice is ZEDZAP<41>
|
|||
|
|
(assuming good performance is desired.) If mine does the above, but yours<72>
|
|||
|
|
DIETIFNA, SEALINK, SEALINK OVERDRIVE, then we have no choice but to choose<73>
|
|||
|
|
DIETIFNA.
|
|||
|
|
|
|||
|
|
The actual protocol choice, done by the receiver, is by ANDing with a bit<69>
|
|||
|
|
mask that contains the protocols your program does, then choosing one of<6F>
|
|||
|
|
the remaining bit(s) according to a method chosen by the programmer or<6F>
|
|||
|
|
sysop.
|
|||
|
|
|
|||
|
|
You could then also have a sensible way to refuse a connection -- say you<6F>
|
|||
|
|
have a zillion byte file to send, and the receiver can only do DIETIFNA.
|
|||
|
|
|
|||
|
|
For example, a program that does SEALINK and it's variants will mask<73>
|
|||
|
|
incoming bits with (Y_DIETIFNA | Y_SEALINK | Y_SEA_OVD); my Fido/FidoNet<65>
|
|||
|
|
program would use (Y_DIETIFNA | Y_SEALINK | ZEDZAPPER | Y_ZMODEM). Then, in<69>
|
|||
|
|
my particular program, I would choose the left-most bit remaining and set<65>
|
|||
|
|
that in the returned Hello packet. Other programs could use other methods,<2C>
|
|||
|
|
either an install-time option (ie. I want SEALINK over ZMODEM) or some<6D>
|
|||
|
|
other criteria. (Fido doesn't do SEALINK yet but it will "soon".)
|
|||
|
|
|
|||
|
|
EXISTING PROGRAMS:
|
|||
|
|
|
|||
|
|
There is no impact in all four combinations of "new" vs. "old" programs --<2D>
|
|||
|
|
if "new" programs simply tolerate more than one bit set when they receive<76>
|
|||
|
|
the (edited) Hello packet back from the receiver. For example, you could<6C>
|
|||
|
|
get back both ZEDZAP and DIETIFNA bits set. Which bit you'd choose depends<64>
|
|||
|
|
on what protocols your program supports. For Fido, the choice would clearly<6C>
|
|||
|
|
be ZEDZAP, as Fido doesn't support SEALINK OVERDRIVE. For SEADOG, the<68>
|
|||
|
|
choices would be reversed.
|
|||
|
|
|
|||
|
|
So this would be Change #3, if so desired. I think I read that Bink now<6F>
|
|||
|
|
does this. I am going to make Fido do this also -- have the response Hello<6C>
|
|||
|
|
packet contain only the protocol bit that will be used.
|
|||
|
|
|
|||
|
|
IMPORTANT (NOT SO) SUBTLETY:
|
|||
|
|
|
|||
|
|
Most implementations that do the xmodem variants do it all with one "smart"<22>
|
|||
|
|
module -- therefore most of this protocol switching doesn't really exist --<2D>
|
|||
|
|
DIETIFNA, TELINK, SEALINK and SEALINK OVERDRIVE probably mean the same<6D>
|
|||
|
|
module. For programs that do this, all that need be done is set the<68>
|
|||
|
|
capability bits and go.
|
|||
|
|
|
|||
|
|
Here are some sample scenarios for you.
|
|||
|
|
|
|||
|
|
Scenario #1: My Fido calls your Binkley. (Existing programs.) My hello<6C>
|
|||
|
|
packet says DIETIFNA, ZEDZAP. Bink replies with DIETIFNA, ZEDZAP. Both<74>
|
|||
|
|
choose ZEDZAP.
|
|||
|
|
|
|||
|
|
Scenario #2: My Fido calls your Tabby. Tabby responds with DIETIFNA. We do<64>
|
|||
|
|
DIETIFNA.
|
|||
|
|
|
|||
|
|
Scenario #3: ProgramX calls a Binkley; it does DIETIFNA, SEALINK and<6E>
|
|||
|
|
ZEDZAP. Existing Bink doesn't recognize SEALINK (bit set) so chooses<65>
|
|||
|
|
ZEDZAP.
|
|||
|
|
|
|||
|
|
Scenario #4: "New" Binkley calls SEADOG. Bink does DIETIFNA, SEALINK,<2C>
|
|||
|
|
SEALINK OVERDRIVE, ZEDZAP. SEADOG chooses SEALINK OVERDRIVE.
|
|||
|
|
|
|||
|
|
Scenario #5: "Old" SEADOG calls Binkley. DIETIFNA is the only bit set, and<6E>
|
|||
|
|
so is chosen. In real life SEALINK, then SEALINK OVERDRIVE is used.
|
|||
|
|
|
|||
|
|
Scenario #6: "New" Binkley calls "new" Fido. Bink does ZEDZAP, SEALINK<4E>
|
|||
|
|
OVERDRIVE, SEALINK, DIETIFNA. Fido does ZMODEM, ZEDZAP, SEALINK, DIETIFNA.<2E>
|
|||
|
|
ZEDZAP is chosen.
|
|||
|
|
|
|||
|
|
---------- ON A DIFFERENT BUT RELATED SUBJECT:
|
|||
|
|
|
|||
|
|
Though "more bits" is never a long-term solution (witness .MSG file<6C>
|
|||
|
|
attribute bits...) more at least helps the short-term. Therefore: in the<68>
|
|||
|
|
definition of struct _Hello, in YOOHOO.DOC, make 'capabilities' a LONG, by<62>
|
|||
|
|
shortening 'reserved[12]' to 'reserved[10]'. They are not needed now -- and<6E>
|
|||
|
|
by definition existing programs do not use any "features" specified by<62>
|
|||
|
|
those bits in the future. Hence it's fully compatible, backwards and<6E>
|
|||
|
|
forwards.
|
|||
|
|
|