871 lines
40 KiB
HTML
Executable File
871 lines
40 KiB
HTML
Executable File
<HTML>
|
||
<HEAD>
|
||
<TITLE>YOOHOO and YOOHOO/2U2.</TITLE>
|
||
</HEAD>
|
||
|
||
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
||
<BODY
|
||
BGCOLOR="#FFFFFF"
|
||
TEXT="#000000"
|
||
LINK="#0000FF"
|
||
VLINK="#000080"
|
||
ALINK="#FF0000"
|
||
>
|
||
<PRE>
|
||
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><single-space-character>!<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><+/-><time>]<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 | |
|
||
`-----+----------+-------------------------+-------------------------+-----'
|
||
</PRE>
|
||
|
||
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
|
||
|
||
</BODY>
|
||
</HTML>
|
||
|