F I D O N E W S -- Volume 13, Number 49 2 December 1996 +----------------------------+-----------------------------------------+ | The newsletter of the | ISSN 1198-4589 Published by: | | FidoNet community | "FidoNews" | | _ | 1-904-409-7040 [1:1/23] | | / \ | | | /|oo \ | | | (_| /_) | | | _`@/_ \ _ | | | | | \ \\ | Editor: | | | (*) | \ )) | Christopher Baker 1:18/14 | | |__U__| / \// | | | _//|| _\ / | | | (_/(_|(____/ | | | (jm) | Newspapers should have no friends. | | | -- JOSEPH PULITZER | +----------------------------+-----------------------------------------+ | Submission address: FidoNews Editor 1:1/23 | +----------------------------------------------------------------------+ | MORE addresses: | | | | submissions=> cbaker84@digital.net | +----------------------------------------------------------------------+ | For information, copyrights, article submissions, | | obtaining copies of FidoNews or the internet gateway FAQ | | please refer to the end of this file. | +----------------------------------------------------------------------+ THE YEAR IS ALMOST OVER. WHERE'S YOUR FIDONEWS ARTICLE? Table of Contents 1. EDITORIAL ................................................ 1 Another LARGE Standard Issue, etc ........................ 1 2. ARTICLES ................................................. 2 InfoMail/386 1.20 Released (and other news) .............. 2 FidoNews as an echomail area? ............................ 3 FTSC Spell Checking Corner ............................... 4 3. GETTING TECHNICAL ........................................ 6 FidoNet Standard FTS-0007 - SEAlink extension ............ 6 4. COORDINATORS CORNER ...................................... 46 Nodelist-statistics as seen from Zone-2 for day 334 ...... 46 5. WE GET EMAIL ............................................. 47 A message from Sylvia Maxwell? ........................... 47 Message Reader response from Santronics .................. 47 6. NET HUMOR ................................................ 49 Christmas Technology? .................................... 49 7. NOTICES .................................................. 53 Future History ........................................... 53 8. FIDONET SOFTWARE LISTING ................................. 54 Latest Greatest Software Versions ........................ 54 9. FIDONEWS PUBLIC-KEY ...................................... 61 This Space intentionally left blank? ..................... 61 10. FIDONEWS INFORMATION .................................... 62 FIDONEWS 13-49 Page 1 2 Dec 1996 ================================================================= EDITORIAL ================================================================= It's that time of year when nor'easters pass thru and tornado watches get issued. It's also time to put up the outside decorations for the holidays. Since we've got both going on here in Edgewater_FL_USA right now, I'm running off this week's Issue a mite earlier than usual so I can attend to the above activities. [Although I'm not really worried about the tornado watch since I don't live in a mobile home [snicker].] Still no new Headline entries or ASCII art submissions? Does anyone read this newsletter? Today, as I compile this [1 Dec 96], is the 12th anniversary of the first Issue of FidoNews which was published this day in 1984. Where are we now compared to 12 years ago? C.B. ----------------------------------------------------------------- FIDONEWS 13-49 Page 2 2 Dec 1996 ================================================================= ARTICLES ================================================================= InfoMail/386 1.20 Released (and other news) Damian Walker, 2:2502/666 Release Information There's a bit of blatant advertising from me this week. InfoMail/386 1.20, the latest version of my document server, has now been released. This version needs a 386 processor. Until an 8086 port is arranged, InfoMail 1.11 will still be supported as a current version so that 286 and 8086 users aren't left out in the cold. What does this new version of InfoMail have over the old? The following list sums it up: * Configurable Log Filename: You can now specify any log file directory and filename at all. So you can include InfoMail's log file in the same directory as that of your other software, or even combine InfoMail's log file with other log files. * Configurable message size up to 64k: Due to requests from users of InfoMail 1.11, the maximum size of documents has been increased. You can still specify a maximum messages size of less than this though, in which case larger documents will be split across several messages. * Option to keep outgoing error messages and notices: Previously all outgoing messages such as document lists were sent with the Kill flag (or according to the 'Kill' setting in the configuration file for InfoMail 1.00). Now you can keep them if you like. * A document list search utility: Users can search for a certain word in document tags and subject lines (but not document text files, though). Such documents must have the 'listed' flag set, or they won't appear. This is useful for systems with a lot of documents on various subjects. * Options to keep various types of inbound message: In earlier versions of InfoMail all inbound requests and updates were deleted when processed. This version allows you to keep the messages, for diagnostic purposes or whatever. * All outgoing messages are sysop-configurable: One of the most requested features for a new version of InfoMail was the ability to customise the outgoing document list. This version of InfoMail allows you to customise _all_ outgoing messages, such as update accept/reject messages, the output of the new document search feature, and other errors. * Multiple AKA's per installation: Another frequently-requested feature was the ability to have more than one address for a single installation of InfoMail. Now, you can have as many addresses as you like. * Indexed (sorted) document list: This makes it easier for sysops with a lot of documents to find the particular document they want to change. It also nicely orders the documents in outgoing document lists, and speeds up the program when identifying and loading documents. * Request passwords for added security: Rather pointless in the author's opinion, since documents can be hidden from a document list, FIDONEWS 13-49 Page 3 2 Dec 1996 but included nevertheless because of a large number of requests from users. * Secondary document messages (useful for held file attaches): If a document is set up to create a message of any description on 'Hold', such as file attaches, a second message can be sent routed to inform the user making the request that a file is waiting for them to pick it up. * Optional monochrome 'colour' scheme: The author now uses a monochrome screen :-( * Some extra macros, including two document list macros: Macros are the way that document lists are included in the new customisable output messages, and in normal document messages now as well. This version of the program is available for file request from 2:2502/666 (UK) and 2:2487/9521 (Germany) using the magic name INFO386, or alternatively the earlier version of 16-bit machines is still available under the magic name INFOMAIL. Further information is available via netmail, just send a netmail to INFOMAIL at 2:2502/666 with the subject INFOMAIL and let the program tell you about itself. Support Echo and Documents InfoMail now has a support echo, called (surprise) INFOMAIL. This echo is on the region 25 backbone, and is also available from the following nodes outside the UK: Christopher Baker 1:18/14 Ronald Troost 2:285/709 In the echo you can expect to find release details, contacts for obtaining the program, and information about related developments. You are welcome to post queries about the program, help other users, make or respond to suggestions for the program's improvement, or any other discussion generally centred around the software. If you're an InfoMail user in need of help or ideas for the program's use then why not link in and join us? The brief echo rules can be requested via netmail by posting a message to INFOMAIL at 2:2502/666 with the subject INFOMAIL.RULES and waiting a day or three for the reply. You can also see them posted in the echo on a monthly basis. Finally, news about the program's development and other related goings on can be found in the 'InfoMail Update' (obtained by netmailing INFOMAIL at 2:2502/666 with the subject INFOMAIL.POST), which is also posted into the echo on a monthly basis. ----------------------------------------------------------------- FidoNews distribution in echomail Peter Karlsson, 2:206/221.0 Here in Sweden (region 2:20), FidoNews is available as a backbone- FIDONEWS 13-49 Page 4 2 Dec 1996 distributed echomail area, where the newsletter is automatically posted each week. I was just curious if this is common practice in other regions. The reason I ask is that, before I found out that it was available as an echo, I never did read it, since I then would have to add a file echo, and unzip the files and read them outside my Fidonet reader, which I never found time to, so they just kept laying around, unread. After the node that originally "did" the Swedish FidoNews echo disappeared, I took on that responsibility, so now my system posts FidoNews as soon as it arrives from my hub. If anyone is interested in the small program that I use for this, a small Turbo Pascal program that creates one text file for each page and a configuration file for my home-built message-poster Announcer, please feel free to contact me via netmail or Internet mail, and I'll send you the source code. (It can, of course, be customized to be used with any other automated message poster that uses text based configuration files, but you'll have to do that yourself). \\// Peter - R20_FNEWS maintainer - E-mail: Fidonet 2:206/221.0 Internet dat95pkn@idt.mdh.se --- timEd/2 1.10+ ----------------------------------------------------------------- Never heard of ispell? by Lee Kindness, 2:259/7, lkindnes@csl.co.uk Well another issue without a detailed comment/new revision of the featured fts document... Never mind the pedantic spell checker can still be cast over fts-0006 to fts-0009 ;) Expect a detailed brake down of fts-0009 (and perhaps a comment or two on fts-0008) in a issue soon... fts-0006: 62c62 < Overdrive protocols are copyrighted by System Enhancment Associates. The --- > Overdrive protocols are copyrighted by System Enhancement Associates. The fts-0007: 213c213 < This means that an extended protocol must miminally do the following: --- > This means that an extended protocol must minimally do the FIDONEWS 13-49 Page 5 2 Dec 1996 following: 1714c1714 < then only NAK evry 32 blocks after the first NAK. This allows buffer --- > then only NAK every 32 blocks after the first NAK. This allows buffer fts-0008: 128c128 < will not be sent. The requestor should set the date to the date of the --- > will not be sent. The requester should set the date to the date of the 217c217 < The diagrams below desribe the session level protocol with Bark file --- > The diagrams below describe the session level protocol with Bark file fts-0009: 46c46 < considered to be the orginating address. A double-quote character --- > considered to be the originating address. A double-quote character (of course the output from diff has been artificially reformatted) It still amazes me how such mistakes can be left unseen in technical documents! ----------------------------------------------------------------- FIDONEWS 13-49 Page 6 2 Dec 1996 ================================================================= GETTING TECHNICAL ================================================================= [This is part of a continuing series of FidoNet Standards and Proposals. They also represent our FidoNet History series. This document has been reformatted for the 70 column limit. 80 column tables are disrupted. File-request FTS-0007.ZIP for a clear copy.] Ed. Document: FTS-0007 Version: 003 Date: 15-Oct-1990 Updates: FTS-0001 An Enhanced FidoNet(r) Technical Standard Extending FTS-0001 to include SEAlink protocol (Including Overdrive and File Restart) October 15, 1990 Status of this document: This document 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 limitations of the copyright notice displayed below. Copyright 1989-90 by Philip L. Becker. Portions of this document are copyright 1986-90 by Randy Bush and are incorporated with his consent. All rights reserved. A right to distribute only without modification and only at no charge is granted. Under no circumstances is this document to be reproduced or distributed as part of or packaged with any product or other sales transaction for which any fee is charged. Any and all other reproduction or excerpting requires the explicit written consent of the copyright holders. Introduction While the basic FTS-0001 protocol has become reasonably standardized, it is technically inferior when used with modem speeds of 2400bps or higher, and results in considerably slower file transfers than more sophisticated protocols under many line and modem configurations. Very sophisticated protocols exist to allow absolute maximum efficiency, but these protocols are much more difficult to implement than the basic XMODEM used by FTS-0001. A need exists for a standardized, easy to implement extension to the FTS-0001 protocol which can gain much better performance. SEAlink is such an extension. It is nearly as easy to implement as the FTS-0001 FIDONEWS 13-49 Page 7 2 Dec 1996 protocol with which it is fully backward compatible. Despite its ease of implementation, it provides several significant performance advantages. Among these advantages are: o Transparently communicates with strict FTS-0001 implementations. o Transparently communicates with FTS-0001 variants which omit either the MODEM7 file name or the TeLink header block. o Transparently becomes a sliding window XMODEM protocol when communicating with a like implementation. This sliding window protocol gives significantly improved throughput when there is an end-to-end delay. o Offers a negotiated streaming mode for high speed asymmetrical modems to further enhance throughput for such links. o Offers a negotiated file restart capability which allows an interrupted transfer to restart where it left off, reducing time spent to retransmit the file. This document defines the data structures and communication protocols which a FidoNet SEAlink implementation must provide. The implementor of FidoNet compatible systems is the intended audience of this document. This document has the same overall format and state table descriptions as FTS-0001. SEAlink is implemented by modifying the following tables: Session Layer: Sender - S1 Network Layer: Batch File Sender - BS0 Network Layer: Batch File Receiver - BR0 Data Link Layer: XMODEM/TeLink Sender - XS0 Data Link Layer: XMODEM/TeLink Receiver - XR0 1 Table of Contents Page The purpose of the SEAlink protocol ................................... 3 How SEAlink negotiates its enhancements ............................... 4 Basic requirements for a FidoNet Implementation ....................... 5 Levels of Compliance .................................................. 5 FIDONEWS 13-49 Page 8 2 Dec 1996 The ISO/OSI Reference Model ........................................... 5 Data Description Language ............................................. 6 Finite State Machine Notation ......................................... 7 Glossary of variables and terms ....................................... 7 Application layer ..................................................... 8 Presentation layer .................................................... 8 Session layer protocol ................................................ 8 Session State Table: Sender (S0) ................................. 9 Session State Table: Receiver (R0) ............................... 10 Transport layer ............................................... 10 Network layer ......................................................... 11 Data Definition: MODEM7 file name ................................ 11 Network State Table: Batch File Sender (BS0) ..................... 12 Network State Table: Batch File Receiver (BR0) ................... 13 Data Link Layer ................................. 14 Data Definition: XMODEM data block (CRC) ......................... 14 Data Definition: XMODEM data block (Checksum) .................... 15 Data Definition: TeLink header block ............................. 15 Data Definition: SEAlink header block FIDONEWS 13-49 Page 9 2 Dec 1996 ............................ 16 Data Definition: SEAlink RESYNC packet ........................... 16 DDL Definition: XMODEMBlock, TeLink header ....................... 17 DDL Definition: SEAlink header, ACK, NAK, RESYNC block ........... 18 Checksum and CRC calculation algorithms .......................... 19 Data Link Layer protocol ......................................... 20 Data Link State Table: XMODEM/TeLink/SEAlink Sender (XS0) ........ 21 Data Link State Table: Transmitter ACK/NAK check (AC0) ........... 22 Data Link State Table: XMODEM/TeLink/SEAlink Receiver (XR0) ...... 24 Data Link State Table: Send NAK (SN0) ............................ 26 Data Link State Table: Send ACK (SA0) ............................ 26 Data Link State Table: MODEM7 Filename Sender (MS0) .............. 27 Data Link State Table: MODEM7 Filename Receiver (MR0) ............ 27 2 The purpose of the SEAlink protocol The purpose of the SEAlink protocol is to provide a much higher level of capability than the XMODEM protocol provides, while retaining the ease of implementation which has made the XMODEM protocol ubiquitous. In order for an extended protocol to function in FidoNet, it has to be fully upward compatible with FTS-0001 mailers, and also those slight variants of FTS-0001 which can communicate well with FTS-0001 mailers. To meet this requirement, any extension to the FTS-0001 protocol has to be capable of transparently negotiating away its extended capabilities and communicate with strict FTS- 0001 mailers (and their approved variants) properly and reliably. FIDONEWS 13-49 Page 10 2 Dec 1996 This means that an extended protocol must miminally do the following: o Detect that the other mailer can or cannot support its extensions automatically, and within the framework of a legitimate FTS-0001 protocol encounter. o Support mail sessions with or without MODEM7 file names and with or without TeLink headers in either combination. To be useful such an extended protocol should also be able to reliably detect when the other mailer can support its extensions so they can be used to maximum benefits. The major problems which exist with a standard FidoNet FTS-0001 session result from the use of the XMODEM protocol. This is a half duplex protocol which forces a line turnaround on every transmitted block. As a result, any end-to-end delay in the transmission link is directly added to each transmitted data block twice (once for each line turnaround). To dramatize how easily XMODEM is impacted by even small line delays, let's examine a 2400bps call on a line with 500ms (1/2 second) delay on each line turnaround. This is not an uncommon delay time on long distance calls. A single data block in the XMODEM CRC format contains 133 characters. This means it will be transmitted in 554ms. The ACK/NAK response is a single character and will take 4ms. Thus with no delay (an ideal link) an XMODEM transfer would send 128 data characters in 558ms for an effective data throughput of about 230cps. With a 500ms line turnaround delay, these same 128 data bytes will take 1558ms resulting in a throughput of 82cps. If faster modem speeds are used, the percentage impact is even greater. The solution to this problem is to enhance the XMODEM protocol by adding a "sliding window" capability which allows more than one block to be sent before an acknowledgment is received. This converts the protocol to a full duplex protocol, and if the "window size" (the number of blocks which may be sent before the sender must wait for an acknowledgment) is larger that the line turnaround delay, then the ideal throughput can be restored even to lines with long turnaround delays. SEAlink is such a protocol. The standard SEAlink window size is 6 blocks, but the state tables given below implement a receiver which will operate correctly with any window size up to 127 blocks. Thus an implementation which uses a larger window size will be totally compatible with the standard 6 block window versions. A second problem with the XMODEM protocol arises when asymmetrical high speed modems are used. These modems achieve much higher throughput when data is sent in only one direction. Since they provide error free links, a protocol which does not send any positive acknowledgments, but only reports any bad blocks received will achieve a significantly higher FIDONEWS 13-49 Page 11 2 Dec 1996 3 throughput than a protocol which is either full duplex or which turns around between each block such as XMODEM or normal SEAlink. It is for this purpose that SEAlink Overdrive is provided. It is a streaming version of SEAlink designed to provide much higher throughput on asymmetrical high speed links which provide end-to- end data flow control. Finally, there is the annoying problem which occurs when a large data file transfer has nearly completed and a loss of connection occurs. Normally the entire file must be retransmitted on a new call, resulting in lost time and money. The SEAlink RESYNC enhancement allows an interrupted file transfer to be resumed at the point it was interrupted thus minimizing the impact of such an interruption. How SEAlink Negotiates its enhancements SEAlink makes some assumptions about how FTS-0001 mailer implementations react to various stimuli in order to negotiate its enhancements. For the sender, the test consists of two parts: 1. Send a SEAlink header and see if the other end acknowledges it. In general it will, because most XMODEM implementations will think that the SEAlink header is a "previous block" and ACK and discard it. If the receiver refuses to accept a SEAlink header block in three tries, then it clearly cannot do SEAlink protocol and the negotiation is over. 2. Since the receiver's acknowledgment of the SEAlink header is not a sufficient criteria to determine if the receiver in fact supports SEAlink, the sender dynamically examines the acknowledgments the receiver provides to determine if their format indicates support of SEAlink or not and adjusts its sending techniques accordingly. This is also the technique used to detect whether the receiver is in fact supporting any extensions (such as SEAlink Overdrive) which have been requested in the header. For the receiver, the negotiation occurs during the receipt of the first valid block. 1. If the first block received is a valid SEAlink header, then the transmitter supports SEAlink and the receiver can switch to it. This same header also indicates if the transmitter wants or can support the SEAlink options such as Overdrive and File RESYNC. 2. If the first block received is a valid TeLink header, then the transmitter supports a variant of FTS-0001 and SEAlink support may be assumed to be absent. 3. If the first block received is an XMODEM data block then SEAlink support may also be assumed to be absent. FIDONEWS 13-49 Page 12 2 Dec 1996 If the receiver gets a SEAlink header, it can then arbitrarily decide which of any requested options it wishes to use. It may not use an option for which support is not indicated in the sender's SEAlink header block. The remainder of this document provides the details for a full SEAlink implementation with Overdrive and RESYNC support. A glossary of terms and indicators is provided along with a full state table description of the protocol implementation. 4 This document follows the format of FTS-0001 to allow ease of comparison of the two protocols. This document could not have been generated without the tremendous efforts of those whose work resulted in FTS-0001. FidoNet owes a great debt to those efforts. The following introduction is reprinted from FTS-0001. The layered metaphor of the ISO Open Systems Interface reference model has been used to view FidoNet from a standard perspective. As with most prospective ISO/OSI descriptions, FidoNet does not always make this easy. 1. Basic Requirements for a FidoNet Implementation Compatibility is a set of abilities which, when taken as a whole, make it safe to list a net or node in the IFNA nodelist. In other words, if another node should attempt contact, does it have a reasonable chance of successful communication? This is a social obligation, as the calling system pays money for the attempt. Conversely, an implementation should be able to successfully contact other systems, as life is not a one-way street. A FidoNet implementation must be able to call other nodes and transfer messages and files in both directions. This includes pickup and poll. A FidoNet implementation must be able to accept calls from other nodes and transfer messages and files in both directions. This includes pickup. A FidoNet implementation must be able to receive and process the IFNA format nodelist, and transfer nodelists to other nodes. A companion document, FTS-0005, defines the IFNA format nodelist and how to interpret and process it. A FidoNet implementation must route messages which do not have files attached through net hosts as shown in an IFNA format nodelist. 2. Levels of Compliance FIDONEWS 13-49 Page 13 2 Dec 1996 This documents represents an extended FidoNet implementation. It defines a well tested extension which is optional but provides sufficient additional function that implementors should seriously consider it. SEAdog(tm), from System Enhancement Associates, is the inspiration for this extended FidoNet implementation. System Enhancement Associates is the creator of the SEAlink protocol. 3. The ISO/OSI Reference Model (cribbed from "Protocol Verification via Executable Logic Specifications", D. P. Sidhu, in Rudin & West) In the ISO/OSI model, a distributed system consists of entities that communicate with each other according to a set of rules called a protocol. The model is layered, and there are entities associated with each layer of the model which provide services to higher layers by exchanging information with their peer entities using the services of lower layers. The only actual physical communication between two systems is at the lowest level. 5 Several techniques have been used in the specification of such protocols. A common ingredient in all techniques is the notion of the extended finite state automata or machine. Extensions include the addition of state variables for the storing of state information about the protocol. The state of an automaton can change as a result of one of the following events: o Request from an upper network layer for service o Response to the upper layer o Request to the lower network layer to perform a service o Response from the lower layer o Interaction with the system and environment in which the protocol is implemented (e.g. timeouts, host operating system aborts, ...) A protocol specification, in a large part, consists of specifying state changes in automata which model protocol entities and in describing the data which they exchange. For historical reasons, the term packet is used in FidoNet to represent a bundle of messages, as opposed to the more common use as a unit of communication, which is known as a block in FidoNet. 4. Data Description FIDONEWS 13-49 Page 14 2 Dec 1996 A language specific notation was avoided. Please help stamp out environmental dependencies. Don't panic, there are rectangular record layouts too. The following defines the data description language used. (* non-terminals *) UpperCaseName - to be defined further on (* literals *) "ABC" - ASCII character string, no termination implied nnH - byte in hexadecimal (* terminals *) someName - 16-bit integer, low order byte first (8080 style) someName[n] - field of n bytes someName[.n] - field of n bits someName(n) - Null terminated string allocated n chars (incl Null) someName{max} - Null terminated string of up to max chars (incl Null) someName - String of up to max chars, NOT null terminated (* punctuation *) a b - one 'a' followed by one 'b' ( a | b ) - either 'a' or 'b', but not both { a } - zero or more 'a's [ b ] - zero or one 'b' (* comment *) - ignored (* predeclared constant *) Null = 00H 6 5. Finite State Machine Notation .-----+----------+-------------------------+---------------------- ---+-----. |State| State | Predicate(s) | Action(s) | Next| | # | Name | | | St | +-----+----------+-------------------------+-------------- -----------+-----+ | fnn*| | | | | `-----+----------+-------------------------+-------------- -----------+-----' State # - Number of this state (e.g. R13). f - FSM initial (Window, Sender, Receiver, ...) nn - state number * - state which represents a lower level protocol which is represented by yet another automation. State Name - Descriptive name of this state. FIDONEWS 13-49 Page 15 2 Dec 1996 Predicate(s) - Conditions which terminate the state. If predicates are non-exclusive, consider them ordered. Action(s) - Action(s) corresponding to predicate(s) Next State - Subsequent state corresponding to predicate(s) Ideally, there should be a supporting section for each state which should give a prose description of the state, its predicates, actions, etc. So much for ideals. The following is a list of all of the terms and variables used in the following state machine descriptions: Glossary of variables and terms SEAlink - Flag indicating SEAlink or XMODEM mode SLO - Flag indicating overdrive if in SEAlink mode RESYNC - Flag indicating whether transmitting end can honor RESYNC file positioning requests or only NAKs MACFLOW - Flag indicating whether the sender supports the Macintosh flow control option. This is an optional feature used by TABBY because the Macintosh serial port does not support RTS/CTS. CRC - Flag indicating whether block check is done using CRC or Checksum T1 and T2 - Timeout Timers which run asynchronously with the code WINDOW - Number of unacknowledged blocks which may be transmitted SendBLK - Next 128 byte block number in file to send. May not occur in sequential order, so file positioning may be necessary when it is time to send this block ACKBLK - Highest block number in file which has been acknowledged by the receiver as received without error Last Blk - Block number of last 128 byte block (or partial block) in the file being sent. NumNAK - Number of NAKs received since last ACK ACKs Rcvd - Number of ACKs received since the start of this file send 7 FIDONEWS 13-49 Page 16 2 Dec 1996 Glossary of variables and terms (cont.) ACKST - State of ACK/NAK machine during auto-detect of SEAlink or XMODEM style ACK/NAK block receipt RESYNC BLK# - Block number in file requested by a received RESYNC packet ARBLK8 - Block # (0-255) received in a SEAlink style ACK/NAK packet ARBLK - Block # in file (calculated from ARBLK8) which is the actual block being referenced in the SEAlink ACK/NAK packet blocknum - Block # (0-255) sent in a SEAlink style ACK/NAK packet WriteBLK - Block # in file to write next correctly received data block. Note: Block 1 is the first byte of the file. CHR - Temp holding variable for received character during send operation B. Application Layer : the System from the User's View This is unchanged from FTS-0001. C. Presentation Layer : the User from the System's View This is unchanged from FTS-0001. D. Session Layer Protocol : Connecting to Another FidoNet Machine A session is a connection between two FidoNet machines. It is currently assumed to be over the DDD telephone network via modems. The calling machine starts out as the sender and the called machine as the receiver. The pickup feature is described by the sender and receiver changing roles midway through the session, after the sender has transferred the message packet and any attached files. Due to the lack of security in the pickup protocol (danger of pickup by a fake node), extensions to the basic Session protocol have been developed. This document describes only the minimum Session Layer protocol (as in FTS- 0001). Once a connection has been established, each system should ensure that the physical connection remains throughout the session. For physical layers implemented through modems, this means monitoring the carrier detect signal, and terminating the session if it is lost. Error detection at the physical layer should be monitored for both sent and received characters. Parity, framing, and other physical FIDONEWS 13-49 Page 17 2 Dec 1996 errors should be detected. The only change to the Session Layer state tables from FTS-0001 is in the Sender state "S1", Predicate "1" (S1.1) entry. 8 Sender .-----+----------+-------------------------+---------------------- ---+-----. |State| State | Predicate(s) | Action(s) | Next| | # | Name | | | St | +-----+----------+-------------------------+-------------- -----------+-----+ | S0 | SendInit | | dial modem | S1 | +-----+----------+-+-----------------------+-------------- -----------+-----+ | S1 | WaitCxD |1| carrier detected | delay 1-5 seconds | S2 | | | (*1) | | | Set SLO if > 2400bps, | | | | | | | Reset SLO if <= 2400bps | | | | +-+-----------------------+---------------------- ---+-----+ | | |2| busy, etc. | report no connection | exit| | | +-+-----------------------+---------------------- ---+-----+ | | |3| voice | report no carrier | exit| | | +-+-----------------------+---------------------- ---+-----+ | | |4| carrier not detected | report no connection | exit| | | | | within 60 seconds | | | +-----+----------+-+-----------------------+-------------- -----------+-----+ | S2 | WhackCRs |1| over 30 seconds | report no response | exit| | | +-+-----------------------+---------------------- ---+-----+ | | |2| ?? s received | delay 1 sec | S3 | | | +-+-----------------------+---------------------- ---+-----+ | | |3| s not received | send | S2 | | | | | | delay ??? secs | | +-----+----------+-+-----------------------+-------------- -----------+-----+ | S3 | WaitClear|1| no input for 0.5 secs | send TSYNCH = AEH FIDONEWS 13-49 Page 18 2 Dec 1996 | S4 | | | +-+-----------------------+---------------------- ---+-----+ | | |2| over 60 seconds | hang up, report garbage | exit| | | | | and line not clear | | | +-----+----------+-+-----------------------+-------------- -----------+-----+ | S4* | SendMail | | (XMODEM send packet XS0)| S5 | +-----+----------+-+-----------------------+---------- ---------------+-----+ | S5 | CheckMail|1| XMODEM successful | (Fido registers success)| S6 | | | +-+-----------------------+---------------------- ---+-----+ | | |2| XMODEM fail or timeout| hang up, report mail bad| exit| +-----+----------+-+-----------------------+----------- --------------+-----+ | S6* | SendFiles| | (BATCH send files BS0) | S7 | +-----+----------+-+-----------------------+-------- -----------------+-----+ | S7 | CheckFile|1| BATCH send successful | | S8 | | | +-+-----------------------+---------------------- ---+-----+ | | |2| BATCH send failed | hang up, rept files fail| exit| +-----+----------+-+-----------------------+---------- ---------------+-----+ | S8 | TryPickup|1| wish to pickup | note send ok | R2* | | | +-+-----------------------+---------------------- ---+-----+ | | |2| no desire to pickup | delay 5 secs | exit| | | | | | hang up, rept send ok | | `-----+----------+-+-----------------------+----------- --------------+-----' Although the above shows the sender emitting only one TSYNCH, it is recommended that a timeout of 5-20 seconds should initiate another TSYNCH. The receiver should tolerate multiple TSYNCHs. *1 - The action for (S1.1) is the only change from the corresponding FTS-0001 state table. 9 Receiver The receiving FSM is given an external timer, the expiration of which will cause termination with a result of 'no calls' (R0.2). .-----+----------+-------------------------+---------------------- ---+-----. |State| State | Predicate(s) | Action(s) FIDONEWS 13-49 Page 19 2 Dec 1996 | Next| | # | Name | | | St | +-----+----------+-+-----------------------+-------------- -----------+-----+ | R0 | WaitCxD |1| carrier detected | | R1 | | | +-+-----------------------+---------------------- ---+-----+ | | |2| external timer expires| report no calls | exit| +-----+----------+-+-----------------------+-------------- -----------+-----+ | R1 | WaitBaud |1| baud rate detected | send signon with s | R2 | | | +-+-----------------------+---------------------- ---+-----+ | | |2| no detect in ?? secs | hang up, report no baud | exit| +-----+----------+-+-----------------------+--------- ----------------+-----+ | R2 | WaitTsync|1| TSYNCH received | ignore input not TSYNCH | R3 | | | +-+-----------------------+---------------------- ---+-----+ | | |2| 60 seconds timeout | hang up, report not Fido| exit| +-----+----------+-+-----------------------+-----