FTS-0006 YOOHOO and YOOHOO/2U2 The netmail handshake used by Opus-CBCS and other intelligent Fidonet mail handling packages This document obsoletes and replaces FTS-0003 LEGAL STUFF ----------- The original protocol and documentation are by Wynn Wagner III. Updates have been made to this document by Vincent E. Perriello, who also is responsible for most of the sample routine included with this document. They are released to the public domain 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. SEAdog is a product of System Enhancement Associates. The ZModem protocol was designed by Chuck Forsberg. The Sealink protocol is 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. 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 two WaZOO methods in use: DietIFNA ... similar to the method described by the FidoNet Technical Standards Committee. VARIATION: * file attaches don't even attempt to do a modem7 file name. * SEAlink run-ahead is based on the baud rate and can be as high as 24 packets for 9600 baud. * 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. * 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 activated during a DietIFNA session. File requests, if any, should be transmitted using a .REQ file. 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. VARIATION: * 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 based on the baud rate. For example, at 2400 baud it's 2048 bytes. At 9600 baud, the packets are 8192 bytes. THIS IS A SIGNIFICANT VARIATION FROM STRICT ZMODEM IMPLEMENTATION. (There's another YooHoo capability bit for those systems which cannot handle this block size) YooHoo and YooHoo/2u2 Page 4 WaZOO Filename conventions WaZOO FILENAMES --------------- MESSAGE BUNDLES...xxxxxxxx.PKT Normal (unarchived) messages are sent in a file name that has a tag of .PKT. The "x" characters should be hex digits. IMPLEMENTATION NOTE ------------------- There is no real requirement that a .PKT file be part of a netmail session. Opus 1.03 and below require a .PKT file for DietIFNA, but this is a mistake that will be corrected. The correct way to do things is to send only what needs to be sent. If the calling system is doing a "poll" then only the YooHoo and a SEAlink (or TeLink) end-of-batch sequence should be all that is required. LZ BUNDLES........xxxxxxxx.{MO|TU|WE|TH|FR|SA|SU}# Message bundles 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). 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. YooHoo and YooHoo/2u2 Page 5 Flow of a DietIFNA Session DIETIFNA FLOW AND NOTES ----------------------- All file transfer is done using either Sealink or TeLink. In the case of TeLink, the modem7 file name transfer part is not used, and the file name is extracted from the first block. The sealink run-ahead (number of blocks in the slide) is based on the baud rate: BlocksToSlide = BaudRate / 400, up to a max of 24 blocks. The calling system: * Send YooHoo * Receive YooHoo/2u2 * Send bundles, files, file request (.REQ) files (in that order) * Receive bundles, files, requested files (in that order) Receiving system: * Receive YooHoo * Send YooHoo/2u2 * Receive bundles, files, file requests (in that order) * Send bundles, files, and respond to file requests that arrived from the remote system. YooHoo and YooHoo/2u2 Page 6 Flow of a ZedZap session ZEDZAP FLOW ----------- The calling system: * Send YooHoo * Receive YooHoo/2u2 * Send bundles, files, file request (.REQ) files (in that order) * Receive bundles, files, file requests * If a file request (.REQ) file came in, respond to it Receiving system: * Receive YooHoo * Send YooHoo/2u2 * Receive bundles, files, file requests * 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, wait for the other system to respond. YooHoo and YooHoo/2u2 Page 7 WaZOO File Requests WAZOO FILE REQUESTS ------------------- Rick Huebner, who adapted the ZModem routines for Opus, 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. 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: ! YooHoo and YooHoo/2u2 Page 8 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: [!][<+/->