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=>
[email protected] |
+----------------------------------------------------------------------+
| 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
[email protected]
--- timEd/2 1.10+
-----------------------------------------------------------------
Never heard of ispell?
by Lee Kindness, 2:259/7,
[email protected]
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<max> - 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
<cr> | exit|
| | +-+-----------------------+----------------------
---+-----+
| | |2| ?? <cr>s received | delay 1 sec
| S3 |
| | +-+-----------------------+----------------------
---+-----+
| | |3| <cr>s not received | send <cr> <sp> <cr>
<sp>| 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
<cr>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| +-----+----------+-+-----------------------+----------
---------------+-----+
| R3* | RecMail | | (XMODEM rec packet
XR0) | R4 | +-----+----------+-+-----------------------+---------
----------------+-----+
| R4 | XRecEnd |1| XMODEM successful | delay 1 second
| R5 |
| | | | | flush input
| |
| | +-+-----------------------+----------------------
---+-----+
| | |2| XMODEM failed | hang up, rept mail
fail | exit| +-----+----------+-+-----------------------+---------
----------------+-----+
| R5* | RecFiles | | (BATCH rec files BR0)
| R6 | +-----+----------+-+-----------------------+--------------
-----------+-----+
| R6 | ChkFiles |1| BATCH recv successful | delay 2 secs
| R7 |
| | +-+-----------------------+----------------------
---+-----+
| | |2| BATCH recv failed | hang up, report bad
file| exit| +-----+----------+-+-----------------------+----------
---------------+-----+ | R7 | AllowPkup|1| have pickup for
sender| receiver becomes sender | S3* |
| | +-+-----------------------+----------------------
---+-----+
| | |2| nothing to pickup | hang up, rept recv ok
| exit| `-----+----------+-+-----------------------+--------------
-----------+-----'
There is no change in the Session Layer Receiver state table from
FTS-0001.
FIDONEWS 13-49 Page 20 2 Dec 1996
E. Transport Layer : ?????
This is unchanged from FTS-0001.
10
F. Network Layer : the Network's View of the System, Routing and
Packets
1. Network Layer Data Definition : the Packet Header
This is unchanged from FTS-0001.
2. Network Layer Data Description : a File with Attributes
The BATCH protocol uses the MODEM7 filename and/or
SEAlink/TeLink/XMODEM file transfer protocols to transfer the
file with attributes.
When a file is transferred via FidoNet, an attempt is made to
also pass the operating system's attributes for the file such as
length, modification date, etc. FidoNet does this via a special
prefix block to the XMODEM file transfer using a protocol known
as TeLink. As the TeLink protocol relies on a modification to
the XMODEM file transfer protocol, it is documented at the data
link layer level. Optionally, if both sender and receiver
implement the SEAlink extension, file information is passed
using the SEAlink header block which also contains feature
negotiation information.
The MODEM7 file name is redundant if there is also a TeLink or
SEAlink block, in which case the name may be taken from either
or both. In this extended implementation, the MODEM7 file name
is never required. It is sent, however, if it appears that the
other node is using a strict FTS-0001 implementation. This
implementation will adapt to an FTS-0001 variant which only
sends the TeLink header without the MODEM7 filename also so that
it is compatible with all know variants of FTS-0001 which
are currently in the FidoNet network.
FileName as Sent by MODEM7
Offset
dec hex
.-----------------------------------------------.
0 0 | fileName |
~ 8 bytes ~
| left adjusted blank filled |
+-----------------------------------------------+
8 8 | fileExt |
~ 3 bytes ~
| left adjusted blank filled |
`-----------------------------------------------'
FIDONEWS 13-49 Page 21 2 Dec 1996
11
3. Network Layer Protocol : BATCH File Finite State Machines
BATCH File Sender
.-----+----------+-------------------------+----------------------
---+-----.
|State| State | Predicate(s) | Action(s)
| Next|
| # | Name | |
| St | +-----+----------+-+-----------------------+--------------
-----------+-----+
| BS0 | MoreFiles|1| more files to send |
| BS1 |
| | +-+-----------------------+----------------------
---+-----+
| | |2| no more files to send |
| BS4 | +-----+----------+-+-----------------------+--------------
-----------+-----+
| BS1 | WaitType |1| rec NAK | (MODEM7 FName send
MS0) | BS2 |
| | (*1) +-+-----------------------+----------------------
---+-----+
| | |2| rec 'C' | (SEAlink send file
XS0) | BS3 |
| | +-+-----------------------+----------------------
---+-----+
| | |3| rec other char | eat character
| BS1 |
| | +-+-----------------------+----------------------
---+-----+
| | |4| > 20 sec in BS1 | report name send bad
| exit| +-----+----------+-+-----------------------+--------------
-----------+-----+
| BS2 | CheckFNm |1| MODEM7 Filename ok | (TeLink send file
XS0T) | BS3 |
| | (*2) +-+-----------------------+----------------------
---+-----+
| | |2| MODEM7 Filename bad | report name send bad
| exit| +-----+----------+-+-----------------------+--------------
-----------+-----+
| BS3 | CheckFile|1| File send ok |
| BS0 |
| | +-+-----------------------+----------------------
---+-----+
| | |2| File send bad | report file send bad
| exit| +-----+----------+-+-----------------------+--------------
-----------+-----+
| BS4 | EndSend |1| rec NAK or 'C' | send EOT, report send
ok| exit|
| | (*3) +-+-----------------------+----------------------
---+-----+
| | |2| 10 secs no NAK or 'C' | send EOT, report no
NAK | exit| `-----+----------+-+-----------------------+----------
---------------+-----'
FIDONEWS 13-49 Page 22 2 Dec 1996
*1 - Note: Filenames must be upper case ASCII. The data link
layer uses lower case "u" as a control character during
MODEM7 name transmission.
*2 - Note: SEAdog (through version 4.51b) does not possess a state
"XS0T". It therefore calls XS0 from state BS2, resulting in
a MODEM7 file name being sent with no TeLink header on batch
file transmissions when it is not in SEAlink mode.
*3 - When no files remain, the sender responds to the receiver's
NAK with an EOT. The EOT is not ACK/NAKed by the receiver.
12
BATCH File Receiver
.-----+----------+-------------------------+----------------------
---+-----.
|State| State | Predicate(s) | Action(s)
| Next|
| # | Name | |
| St | +-----+----------+-------------------------+--------------
-----------+-----+
| BR0 | TestSL | | Send 'C',
| BR1 |
| | | | Set T1 to 10 sec
| |
| | | | Set T2 to 120 sec
| | +-----+----------+-+-----------------------+--------------
-----------+-----+
| BR1 | CheckSL |1| > 2 sec with no data | Send 'C'
| BR1 |
| | +-+-----------------------+----------------------
---+-----+
| | |2| Timer T2 expired | (MODEM7 FName recv
MR0) | BR2 |
| | +-+-----------------------+----------------------
---+-----+
| | |3| Character Waiting | "Peek" char to CHR
(*1) | BR4 |
| | +-+-----------------------+----------------------
---+-----+
| | |4| Timer T1 expired | (MODEM7 FName recv
MR0) | BR2 | +-----+----------+-+-----------------------+---------
----------------+-----+
| BR2 | CheckFNm |1| no more files | report files recd ok
| exit|
| | +-+-----------------------+----------------------
---+-----+
| | |2| Filename ok | (Rcv file Telink XR0)
| BR3 |
| | +-+-----------------------+----------------------
---+-----+
| | |3| Filename bad | report name recv bad
FIDONEWS 13-49 Page 23 2 Dec 1996
| exit| +-----+----------+-+-----------------------+--------------
-----------+-----+
| BR3 | CheckFile|1| File received ok |
| BR0 |
| | +-+-----------------------+----------------------
---+-----+
| | |2| File received bad | report file recv bad
| exit| +-----+----------+-+-----------------------+--------------
-----------+-----+
| BR4 | FindType |1| CHR = NUL | eat character,
| BR1 |
| | | | | Reset T1 to 20 secs
| |
| | (*2) +-+-----------------------+----------------------
---+-----+
| | |2| CHR = SOH | (Rcv File SEAlink
XR0B) | BR3 |
| | +-+-----------------------+----------------------
---+-----+
| | |3| CHR = SYN | (Rcv File Telink
XR0B) | BR3 |
| | +-+-----------------------+----------------------
---+-----+
| | |4| CHR = EOT or | eat character,
| exit|
| | | | CHR = SUB | report files recd
ok | |
| | +-+-----------------------+----------------------
---+-----+
| | |5| CHR = Other char | eat character
| BR1 | `-----+----------+-+-----------------------+--------------
-----------+-----'
*1 - "Peek" a character means to place it in CHR but leave it in
the input buffer so the next read operation will re-read it.
*2 - "Eat" a character means to remove it from the input buffer.
13
G. Data Link Layer : Error-Free Data Transfer
1. Data Link Layer Data Definition : XMODEM/TeLink/SEAlink Blocks
XMODEM transfers are in blocks of 128 uninterpreted data bytes
preceded by a three byte header and followed by either a one
byte checksum or a two byte crc remainder. XMODEM makes no
provision for data streams which are not an integral number of
blocks long. Therefore, the sender pads streams whose length is
not a multiple of 128 bytes with the end-of-file character (^Z
for MS-DOS), and uses some other means to convey the true data
length to the receiver (e.g. SEAlink or TeLink file info header
block).
FIDONEWS 13-49 Page 24 2 Dec 1996
Data blocks contain sequence numbers so the receiver can ensure
it has the correct block. Data block numbers are sequential
unsigned eight bit integers beginning with 01H and wrapping to
00H. A TeLink or SEAlink header block is given sequence number
00H.
For files which are attached to the mail packet (but not the
mail packet itself), if the sending system is aware of the file
attributes as they are known to the operating system, then the
first block of the XMODEM transfer may be a special TeLink block
to transfer that information. This block differs in that the
first byte is a SYN character as opposed to an SOH, and it is
always sent checksum as opposed to CRC. Should the receiver be
unwilling to handle such information, after four NAKs (or "C"s),
the sender skips this special block and goes on to the data
itself.
In this extended protocol the TeLink header block may be
replaced by the SEAlink header block which conveys protocol
negotiation information in addition to the file attributes if
both nodes implement SEAlink.
XMODEM Data Block (CRC mode)
Offset
dec hex
.-----------------------------------------------.
0 0 | SOH - Start Of Header - 01H |
+-----------------------------------------------+
1 1 | BlockNumber |
+-----------------------------------------------+
2 2 | BlockComplement |
+-----------------------------------------------+
3 3 | 128 bytes of |
~ uninterpreted ~
| data |
+-----------------------------------------------+
131 83 | CRC high order byte |
+-----------------------------------------------+
132 84 | CRC low order byte |
`-----------------------------------------------'
14
XMODEM Data Block (Checksum mode)
Offset
dec hex
.-----------------------------------------------.
0 0 | SOH - Start Of Header - 01H |
+-----------------------------------------------+
1 1 | BlockNumber |
+-----------------------------------------------+
2 2 | BlockComplement |
FIDONEWS 13-49 Page 25 2 Dec 1996
+-----------------------------------------------+
3 3 | 128 bytes of |
~ uninterpreted ~
| data |
+-----------------------------------------------+
131 83 | Checksum byte |
`-----------------------------------------------'
TeLink File Descriptor Block
Offset
dec hex
.-----------------------------------------------.
0 0 | SYN - File Info Header - 16H |
+-----------------------------------------------+
1 1 | 00H |
+-----------------------------------------------+
2 2 | FFH | dec
hex +-----------------------------------------------+
3 3 | File Length, least significant byte | 0
0 +-----------------------------------------------+
4 4 | File Length, second to least significant byte | 1
1 +-----------------------------------------------+
5 5 | File Length, second to most significant byte | 2
2 +-----------------------------------------------+
6 6 | File Length, most significant byte | 3
3 +-----------------------------------------------+
7 7 | Creation Time of File | 4
4
| "DOS Format" |
+-----------------------------------------------+
9 9 | Creation Date of File | 6
6
| "DOS Format" |
+-----------------------------------------------+
11 B | File Name | 8
8
~ 16 chars ~
| left justified blank filled |
+-----------------------------------------------+
27 1B | 00H | 24
18 +-----------------------------------------------+
28 1C | Sending Program Name | 25
19
~ 16 chars ~
| left justified Null filled |
+-----------------------------------------------+
44 2B | 01H (for CRC) or 00H | 41
29 +-----------------------------------------------+
45 2C | fill | 42
2A
~ 86 bytes ~
| all zero |
+-----------------------------------------------+
131 83 | Checksum byte |
`-----------------------------------------------'
FIDONEWS 13-49 Page 26 2 Dec 1996
15
Offset SEAink File Descriptor Block
dec hex
.-----------------------------------------------.
0 0 | SOH - Start of Header - 01H |
+-----------------------------------------------+
1 1 | 00H |
+-----------------------------------------------+
2 2 | FFH | dec
hex +-----------------------------------------------+
3 3 | File Length, (4 bytes, LSB first) | 0
0 +-----------------------------------------------+
7 7 | Creation Date/Time of File | 4
4
| (4 bytes, LSB first, seconds since 1979) |
+-----------------------------------------------+
11 B | File Name | 8
8
~ 17 chars ~
| left justified Null filled |
+-----------------------------------------------+
28 1C | Sending Program Name | 25
19
~ 15 chars ~
| left justified Null filled |
+-----------------------------------------------+
43 2B | > 0 if SLO Requested | 40
28 +-----------------------------------------------+
44 2C | > 0 if RESYNC Supported | 41
29 +-----------------------------------------------+
45 2D | > 0 if MACFLOW Supported | 42
2A +-----------------------------------------------+
46 2E | fill | 43
2B
~ 85 bytes ~
| all zero |
+-----------------------------------------------+
131 83 | CRC high order byte |
+-----------------------------------------------+
132 84 | CRC low order byte |
`-----------------------------------------------'
Offset SEAlink RESYNC packet
dec hex
.-----------------------------------------------.
0 0 | SYN - Start of RESYNC packet - 16H |
+-----------------------------------------------+
1 1 | ASCII Decimal 128 byte block number in |
~ file to restart sending. (No leading ~
n | or trailing blanks, MSD first). |
+-----------------------------------------------+
n+1 | ETX - End of RESYNC packet - 03H |
+-----------------------------------------------+
n+2 | (*1) CRC low order byte |
+-----------------------------------------------+
FIDONEWS 13-49 Page 27 2 Dec 1996
n+3 | (*1) CRC high order byte |
`-----------------------------------------------'
*1 - CRC does not include the SYN or ETX and is
in the reverse byte order from the CRC in a
normal XMODEM data packet. The following is
a sample RESYNC packet for file block 27 (1BH).
SYN '2' '7' ETX CRCLO CRCHI .-----+-----+-
----+-----+-----+-----.
| 16H | 32H | 37H | 03H | 43H | 25H | `-----+-----
+-----+-----+-----+-----'
16
Data Description language definitions of block types:
XMODEMData = XMODEMBlock (* block of data with hdr and
trailer *)
| SEALinkBlock (* SEALink File Descriptor Block
*)
| TeLinkBlock (* TeLink File Descriptor Block
*)
| ReSyncBlock (* SEAlink RESYNC request packet
*)
| ACK (* acknowledge data received ok
*)
| NAK (* negative ACK & poll 1st block
*)
| SEAlinkACK (* acknowledge data received ok
*)
| SEAlinkNAK (* negative ACK & poll 1st block
*)
| EOT (* end of xfer, after last block
*)
| "C" (* 43H *)
XMODEMBlock = SOH (* Start of Header, XMODEM Block
*)
blockNumber[1] (* sequence, i'=mod( i+1, 256 )
*)
blockCompl[1] (* one's complement of
blockNumber *)
data[128] (* uninterpreted user data block
*)
(CRC | Checksum) (* error detect/correction code
*)
TeLinkBlock = SYN (* File Info Header *)
00H (* block no, must be first block
*)
FFH (* one's complement of block no
*)
FIDONEWS 13-49 Page 28 2 Dec 1996
fileLength[4] (* length of data in bytes *)
(*2) CreationTime[2] (* time file last modified or
zero *)
(*2) CreationDate[2] (* date file last modified or
zero *)
fileName(16) (* name of file, not vol or dir
*)
00H (* header version number *)
sendingProg(16) (* name of program on send side
*)
(*1) crcMode[1] (* 01H for CRC 00H for Checksum
*)
fill[87] (* zeroed *)
Checksum (* error detect/correction code
*)
*1 - Note that the crcMode is always set to 01H in current
implementations as all TeLink/XMODEM implementations use the
CRC method. Therefore, it is always set to 01H by the
sender, and is ignored by the receiver.
*2 - CreationDate and CreationTime are MS-DOS format as follows:
CreationDate = year[.7] (* 7 bits, years since 1980, 0-
127 *)
month[.4] (* 4 bits, month of year, 1-12
*)
day[.5] (* 5 bits, day of month, 1-31 *)
CreationTime = hour[.5] (* 5 bits, hour of day, 0-23 *)
minute[.6] (* 6 bits, minute of hour, 0-60
*)
biSeconds[.2] (* 6 bits, seconds/2, 0-29 *)
17
Data Description Language definition of the block types added
by this extended protocol specification:
SEALinkBlock = SOH (* File Info Header *)
00H (* block no, must be first block
*)
FFH (* one's complement of block no
*)
fileLength[4] (* length of data in bytes *)
(*1) Creation[4] (* Seconds since 1979 file last
chgd *)
fileName(17) (* name of file, not vol or dir
*)
sendingProg(15) (* name of program on send side
*)
SLO[1] (* 01H for Overdrive supported
*)
RESYNC[1] (* 01H for file Restart
FIDONEWS 13-49 Page 29 2 Dec 1996
supported *)
MACFLOW[1] (* 01H for Macintosh flow
supported *)
fill[85] (* zeroed *)
CRC (* error detect/correction code
*)
*1 - Creation is a long integer number of seconds since January 1,
1979.
SEAlinkACK = ACK (* indicator data block received
ok *)
blockNumber[1] (* sequence, i'=mod( i+1, 256 )
*)
blockCompl[1] (* one's complement of
blockNumber *)
SEAlinkNAK = NAK (* indicator block not received
ok *)
blockNumber[1] (* sequence, i'=mod( i+1, 256 )
*)
blockCompl[1] (* one's complement of
blockNumber *)
ReSyncBlock = SYN (* File Restart Position *)
(*1) RestartBlock<20> (* ASCII decimal file block # *)
ETX (* End of block number text *)
CRC(rev order) (* error detection code *)
*1 - RestartBlock is a text ASCII version of the decimal block
number in the file desired. Note: The first block of the file is
block 1.
Definitions of Single byte Character values used in protocol:
ACK = 06H (* acknowledge data received ok
*)
NAK = 15H (* negative ACK & poll 1st block
*)
SOH = 01H (* start of header, begins block
*)
SYN = 16H (* start of TeLink file info blk
*)
EOT = 04H (* end of xfer, after last block
*)
ETX = 03H (* end of RESYNC request data
field*)
18
Block Verification calculated values used by this protocol:
CRC = crc[2] (* CCITT Cyclic Redundancy Check
FIDONEWS 13-49 Page 30 2 Dec 1996
*)
Checksum = checksum[1] (* low 8 bits of sum of data
bytes using unsigned 8 bit
arithmetic *)
Calculating Checksum
--------------------
For blocks which use a checksum to do error detection, the
checksum is calculated by initializing an accumulator to zero and
doing successive addition of each character in the data field.
Carry is discarded on each addition. The resulting 8 bit value is
the checksum.
Calculating CRC
---------------
For blocks which use CRC to do error detection, the CRC is
calculated using the CCITT V.41 generator polynomial. An
accumulator is initialized to zero, and then each character of the
data field is processed by the CRC generator polynomial. This
process can be quite complex to explain, but is not so complex in
practice. The following CRC routine is given here as an aid to
understanding the CRC generation process.
8086 assembler routine to implement CCITT V.41 CRC algorithm
;---------------------------------------------------------------+
; CRCUPD - Update CRC value from character in AL |
; |
; CRC is calculated using the CCITT V.41 generator polynomial. |
; That polynomial is: X^16 + X^12 + X^5 + 1 (X^0) |
; |
; As an aid to understanding, remember that XOR is bitwise |
; addition without carry. |
;---------------------------------------------------------------+
CRCVAL DW 0 ;16 bit CRC accumulator
;
CRCUPD: PUSH AX ;All registers preserved
PUSH CX
PUSH DX
MOV DX,[CRCVAL]
XOR DH,AL ;init X^16 term
XOR DL,DL
MOV CX,8
CRCUP1: SHL DX,1
JNC CRCUP2
XOR DX,1021h ;X^12 + X^5 + 1
CRCUP2: LOOP CRCUP1
XOR DH,BYTE PTR[CRCVAL] ;finish X^16 term
MOV [CRCVAL],DX ;update CRC accumulator
POP DX
POP CX
POP AX
RET
FIDONEWS 13-49 Page 31 2 Dec 1996
19
2. Data Link Layer Protocol : XMODEM/TeLink/SEAlink Finite State
Machines
The protocol is receiver driven, the receiver polling the sender
for each block. If the receiver polls for the first block using a
"C" (43H) as the poll character, it would prefer to have the CRC-
CCITT V.41 polynomial remainder error detection code at the end of
each block as opposed to a one byte unsigned checksum. The sender
will respond to the "C" poll if it can comply. If the sender
chooses checksum as opposed to CRC, it waits for the receiver to
poll with NAK (15H). Should the checksum method be preferable to
the receiver, it polls with NAK rather than "C".
The sender returns an EOT instead of a data block when no data
remain.
With this extended implementation, the sender and the receiver may
send blocks or ACK/NAK responses while there is data being
received, once the SEAlink protocol has been negotiated. This
full duplex operation allows the throughput gains of a sliding
window protocol. When SEAlink is not set the window size of 1
prohibits data being sent at the same time and restores the
attributes of a standard XMODEM protocol.
------------------
In this extended protocol, the FTS-0001 single state table
"XMODEM Sender" is replaced by two state tables.
The top level table is equivalent to the FTS-0001 XMODEM Sender
table. It in turn calls the new state table named "Transmitter
ACK/NAK Check" which implements the full duplex adaptive
SEAlink/XMODEM dynamic switching along with the Overdrive and file
Restart sending features of the extended protocol.
-----------------
In this extended protocol, the FTS-0001 single state table
"XMODEM Receiver" is replaced by three state tables.
The top level table is equivalent to the FTS-0001 XMODEM Receiver
table. It in turn calls the two new state tables named "Send NAK"
and "Send ACK" which implement the full duplex adaptive
SEAlink/TeLink/XMODEM dynamic switching along with the Overdrive
and file Restart receiving features of the extended protocol.
Caution!!!!
-----------
Many current implementations keep file block numbers as 16 bit
numbers. This limits the max file size to either 4 megabytes (if
number is signed) or 8 megabytes (if number is unsigned). To
handle files up to the maximum size DOS allows (4 gigabytes) at
least 25 bits plus sign are required for these numbers. Good
practice is to make file block numbers 32 bit values.
FIDONEWS 13-49 Page 32 2 Dec 1996
20
XMODEM/TeLink/SEAlink - Sender
.-----+----------+-------------------------+----------------------
---+-----.
|State| State | Predicate(s) | Action(s)
| Next|
| # | Name | |
| St | +-----+----------+-------------------------+--------------
-----------+-----+
| XS0 | XmtStart | Normal Entry Point | reset SEAlink flag,
| XS1 |
| | | for file send | SendBLK=1, ACKST=0,
| |
| | | | ACKBLK= -1,
WINDOW=1, | |
| | | | ACKs Rcvd=0,
| |
| | | | NumNAK=0,
| |
| | | | T1=30 seconds,
| |
| | | (*1) | Build SEAlink hdr
blk | | +-----+----------+-------------------------+----------
---------------+-----+
| XS0T| XmTeStrt | Alternate entry from | reset SEAlink flag,
| XS1 |
| | | Batch Send if TeLink | SendBLK=1, ACKST=0,
| |
| | | mode send required | ACKBLK= -1,
WINDOW=1, | |
| | | | ACKs Rcvd=0,
| |
| | | | NumNAK=0,
| |
| | | | T1=30 seconds,
| |
| | | | Build TeLink hdr
blk | | +-----+----------+-------------------------+---------
----------------+-----+
| XS1 | CheckACK | | (Check ACK/NAK AC0)
| XS2 | +-----+----------+-+-----------------------+--------------
-----------+-----+
| XS2 | SendBlk |1| NumNAK > 4 & | If header = SEAlink
| XS0T|
| | (*2) | | SendBLK = 0 +----------------------
---+-----+
| | | | | If header = TeLink,
| XS2 |
| | | | | NumNAK = 0,
| |
| | | | | Incr ACKBLK,
| |
| | | | | Incr SendBLK
| |
FIDONEWS 13-49 Page 33 2 Dec 1996
| | +-+-----------------------+----------------------
---+-----+
| | |2| NumNAK > 10 | report too many
errors | exit|
| | +-+-----------------------+----------------------
---+-----+
| | |3| Timer T1 expired | report fatal timeout
| exit|
| | +-+-----------------------+----------------------
---+-----+
| | |4| SendBLK > Last Blk+1 |
| XS3 |
| | +-+-----------------------+----------------------
---+-----+
| | |5| SendBLK >ACKBLK+Window|
| XS1 |
| | +-+-----------------------+----------------------
---+-----+
| | |6| SendBLK = Last Blk+1 | Send EOT, Incr
SendBLK, | XS1 |
| | | | | Set T1 to 30
seconds | |
| | +-+-----------------------+----------------------
---+-----+
| | |7| SLO set & SEAlink set | Send SendBLK, (*3)
| XS1 |
| | | | | ACKBLK = SendBLK,
| |
| | | | | Incr SendBLK,
| |
| | | | | Set T1 to 60
seconds | |
| | +-+-----------------------+----------------------
---+-----+
| | |8| SLO reset or | Send SendBLK, (*3)
| XS1 |
| | | | SEAlink reset | Incr SendBLK,
| |
| | | | | Set T1 to 30
seconds | | +-----+----------+-+-----------------------+-----
--------------------+-----+
| XS3 | WaitEnd |1| ACKBLK < Last Blk+1 |
| XS1 |
| | +-+-----------------------+----------------------
---+-----+
| | |2| ACKBLK = Last Blk+1 | report send success
| exit| `-----+----------+-+-----------------------+--------------
-----------+-----'
*1 - Build SEAlink Header block with RESYNC set. Set SLO if line
speed > 2400 bps, reset SLO otherwise.
*2 - State (XS2.1) allows the receiver to refuse one or both
header blocks.
*3 - If SendBLK = 0, then send the SEAlink (or TeLink) header
FIDONEWS 13-49 Page 34 2 Dec 1996
block.
If SendBLK > 0, send the corresponding 128 byte file data
block where block #1 begins with the first
byte of the file.
21
XMODEM/TeLink/SEAlink - Transmitter ACK/NAK Check
.-----+----------+-------------------------+----------------------
---+-----.
|State| State | Predicate(s) | Action(s)
| Next|
| # | Name | |
| St | +-----+----------+-+-----------------------+--------------
-----------+-----+
| AC0 | ChkRcvd |1| No character waiting |
| exit|
| | +-+-----------------------+----------------------
---+-----+
| | |2| Character waiting | Read character to CHR
| AC1 | +-----+----------+-+-----------------------+--------------
-----------+-----+
| AC1 | SLCheck |1| ACKST > 2 |
| AC2 |
| | +-+-----------------------+----------------------
---+-----+
| | |2| ACKST <=2 |
| AC6 | +-----+----------+-+-----------------------+--------------
-----------+-----+
| AC2 | SLVerify |1| ARBLK8 = 1's comp(CHR)| ARBLK = SendBLK -
| AC3 |
| | | | | ((SendBLK-
ARBLK8)&0FFh) | |
| | +-+-----------------------+----------------------
---+-----+
| | |2| ARBLK8 # 1's comp(CHR)| Reset SEAlink flag,
| AC6 |
| | | | | WINDOW=1,
| |
| | | | | ACKST=0
| | +-----+----------+-+-----------------------+--------------
-----------+-----+
| AC3 | SLACKNAK |1| ARBLK not valid (*1) |
| exit|
| | +-+-----------------------+----------------------
---+-----+
| | |2| ACKST = 3 | Set SEALink flag,
| AC5 |
| | (*2) | | | WINDOW = 6,
| |
| | | | | ACKBLK = ARBLK,
| |
| | | | | Incr ACKs Rcvd,
| |
FIDONEWS 13-49 Page 35 2 Dec 1996
| | | | | ACKST=0
| |
| | +-+-----------------------+----------------------
---+-----+
| | |3| ACKST = 4 | SendBLK = ARBLK,
| AC4 |
| | | | | ACKST=0
| | +-----+----------+-+-----------------------+--------------
-----------+-----+
| AC4 | XMCheck |1| NumNAK < 4 | Set SEAlink Flag,
| exit|
| | | | | WINDOW = 6
| |
| | +-+-----------------------+----------------------
---+-----+
| | |2| NumNAK >= 4 | Reset SEAlink flag,
| exit|
| | | | | WINDOW = 1
| | +-----+----------+-+-----------------------+--------------
-----------+-----+
| AC5 | SLOCheck |1| SLO Reset |
| exit|
| | +-+-----------------------+----------------------
---+-----+
| | |2| ACKs Rcvd < 10 |
| exit|
| | +-+-----------------------+----------------------
---+-----+
| | |3| ACKs Rcvd >= 10 | Reset SLO
| exit| +-----+----------+-+-----------------------+--------------
-----------+-----+
| AC6 | SL1Check |1| ACKST = 1 or 2 | ARBLK8 = CHR,
| AC6 |
| | | | | ACKST = ACKST+2
| |
| | +-+-----------------------+----------------------
---+-----+
| | |2| SEAlink reset |
| AC7 |
| | +-+-----------------------+----------------------
---+-----+
| | |3| ACKST = 0 |
| AC7 |
| | +-+-----------------------+----------------------
---+-----+
| | |4| ACKST > 2 |
| exit| `-----+----------+-+-----------------------+--------------
-----------+-----'
(Continued on next page)
*1 - ARBLK is valid only if all of the following are true:
a. ARBLK >= 0
b. ARBLK <= SendBLK
c. ARBLK > SendBLK-128
FIDONEWS 13-49 Page 36 2 Dec 1996
*2 - Software error if ACKST is not 3 or 4 in state AC3
22
XMODEM/TeLink/SEAlink - Transmitter ACK/NAK Check
.-----+----------+-------------------------+----------------------
---+-----.
|State| State | Predicate(s) | Action(s)
| Next|
| # | Name | |
| St | +-----+----------+-+-----------------------+--------------
-----------+-----+
| AC7 | ACKNAK |1| CHR = ACK | ACKST = 1
| AC8 |
| | | | | NumNAK = 0
| |
| | +-+-----------------------+----------------------
---+-----+
| | |2| CHR = NAK or 'C' | Set CRC/Chksm if 1st,
| AC9 |
| | (*1) | | | ACKST = 2,
| |
| | | | | Incr NumNAK,
| |
| | | | | Delay 0.6 seconds
| |
| | +-+-----------------------+----------------------
---+-----+
| | (*1) |3| CHR = SYN | Receive RESYNC
packet, | AC10|
| | | | | ACKST = 0
| |
| | (*2) +-+-----------------------+----------------------
---+-----+
| | |4| CHR = other |
| exit| +-----+----------+-+-----------------------+--------------
-----------+-----+
| AC8 | XMACK |1| SEAlink set |
| exit|
| | +-+-----------------------+----------------------
---+-----+
| | |2| SEAlink reset | Incr ACKBLK
| exit| +-----+----------+-+-----------------------+--------------
-----------+-----+
| AC9 | XMNAK |1| SEAlink set |
| exit|
| | +-+-----------------------+----------------------
---+-----+
| | |2| SEAlink reset | SendBLK = ACKBLK+1
| exit| +-----+----------+-+-----------------------+--------------
-----------+-----+
| AC10| RESYNC |1| RESYNC pkt invalid | Send NAK
| exit|
FIDONEWS 13-49 Page 37 2 Dec 1996
| | +-+-----------------------+----------------------
---+-----+
| | |2| RESYNC pkt valid | Set SEAlink flag,
| exit|
| | | | | WINDOW = 6,
| |
| | | | | SendBLK = RESYNC
Blk#,| |
| | | | | ACKBLK = SendBLK-1,
| |
| | | | | Send ACK
| | `-----+----------+-+-----------------------+--------------
-----------+-----'
*1 - If the output is buffered in local computer memory, any
characters which remain in the local buffer should be purged
before leaving states (AC7.2) or (AC7.3) to aid in
resynchronizing the link.
*2 - If the implementation is honoring MACFLOW protocol, set the
flag in the SEAlink header block and add the following state
to (AC7):
.-----+--------+---+-----------------------+----------------------
---+-----.
| AC7 | |3.5| CHR = ^S (13H) & | Delay 10 seconds or
| exit|
| | | | SEAlink set & | until ^Q (11H) rcvd
| |
| | | | ACKST = 0 |
| | `-----+--------+---+-----------------------+--------------
-----------+-----'
23
XMODEM/TeLink/SEAlink - Receiver
.-----+----------+-------------------------+----------------------
---+-----.
|State| State | Predicate(s) | Action(s)
| Next|
| # | Name | |
| St | +-----+----------+-------------------------+--------------
-----------+-----+
| XR0 | RecInit | | reset SEAlink flag,
| XR1 |
| | | | reset SLO flag,
| |
| | | | reset RESYNC flag,
| |
| | | | set CRC flag,
| |
| | | | set blocknum=0,
| |
FIDONEWS 13-49 Page 38 2 Dec 1996
| | | | set WriteBLK=1,
| |
| | | | reset retry cnt
| | +-----+----------+-------------------------+--------------
-----------+-----+
| XR0B| BrecInit | Alternate Entry from | reset SEAlink flag,
| XR2 |
| | | Batch Receive (BR4.2) | reset SLO flag,
| |
| | | or (BR4.3) | reset RESYNC flag,
| |
| | | | set CRC flag,
| |
| | | | set blocknum=0,
| |
| | | | set WriteBLK=1,
| |
| | | | reset retry cnt
| | +-----+----------+-------------------------+--------------
-----------+-----+
| XR1 | RecStart | | (Send NAK SN0)
| XR2 | +-----+----------+-+-----------------------+--------------
-----------+-----+ | XR2 | WaitFirst|1| 10 retries or 1 minute|
report receive failure | exit|
| | | | w/o valid input |
| |
| | +-+-----------------------+----------------------
---+-----+
| | |2| > 3 retries or 30 secs| reset CRC flag
| XR1 |
| | +-+-----------------------+----------------------
---+-----+
| | |3| EOT received | (Send ACK SA0),
| exit|
| | | | | report no file
| |
| | +-+-----------------------+----------------------
---+-----+
| | (*1) |4| TeLink block recd | (Send ACK SA0),
| XR3 |
| | | | | reset retry cnt
| |
| | +-+-----------------------+----------------------
---+-----+
| | (*2) |5| SEAlink block recd | set SEAlink,
| XR4 |
| | | | | set RESYNC as
| |
| | | | | indicated by header
| |
| | +-+-----------------------+----------------------
---+-----+
| | (*3) |6| XMODEM data block 1 | Write block to file,
| XR3 |
| | | | received | Incr WriteBLK,
| |
FIDONEWS 13-49 Page 39 2 Dec 1996
| | | | | Incr blocknum,
| |
| | | | | (Send ACK SA0),
| |
| | | | | reset retry cnt
| |
| | +-+-----------------------+----------------------
---+-----+
| | |7| bad block or 2-10 secs| incr retry count
| XR1 |
| | | | without input |
| | `-----+----------+-+-----------------------+--------------
-----------+-----'
(Continued on next page)
*1 - A TeLink header packet has the standard XMODEM data block
format except that it begins with an SYN instead of an SOH
character and has a block number of 0. Note: SEAdog (through
version 4.51b) does not possess (XR2.4) and therefore will
consider a TeLink header a bad block and process it according
to (XR2.7) when communicating with mailers which do not do
SEAlink protocol.
*2 - A SEAlink header packet has the standard XMODEM data block
format
*3 except that is has a block number of 0. The first block is an
XMODEM data block if its block number is not 0.
24
XMODEM/TeLink/SEAlink - Receiver (cont.)
.-----+----------+-------------------------+----------------------
---+-----.
|State| State | Predicate(s) | Action(s)
| Next|
| # | Name | |
| St | +-----+----------+-+-----------------------+--------------
-----------+-----+ | XR3 | WaitBlock|1| 10 retries or 1 minute|
report receive failure | exit|
| | | | w/o expected block |
| |
| | +-+-----------------------+----------------------
---+-----+
| | |2| EOT received | reset SLO flag,
| exit|
| | | | | (Send ACK SA0)
| |
| | | | | report recd ok
| exit|
| | +-+-----------------------+----------------------
---+-----+
| | |3| expected data | Decrement blocknum,
FIDONEWS 13-49 Page 40 2 Dec 1996
| XR3 |
| | | | block-1 received | (Send ACK SA0)
| |
| | +-+-----------------------+----------------------
---+-----+
| | |4| expected data | Write block to file,
| XR3 |
| | | | block received | Incr WriteBLK,
| |
| | | | | (Send ACK SA0),
| |
| | | | | reset retry cnt
| |
| | +-+-----------------------+----------------------
---+-----+
| | |5| SEAlink set & | Discard block -
resync | XR3 |
| | | | expected block+1 to | in progress,
| |
| | | | expected block+127 | Send Conditional
NAK(*5)| |
| | +-+-----------------------+----------------------
---+-----+
| | |6| bad block or 2-10 secs| (Send NAK SN0),
| XR3 |
| | | | without input | incr retry cnt
| | +-----+----------+-+-----------------------+--------------
-----------+-----+
| XR4 | Restart |1| Want entire file | (Send ACK SA0),
| XR5 |
| | | | or RESYNC not set | reset retry cnt
| |
| | +-+-----------------------+----------------------
---+-----+
| | |2| Want to resume an | WriteBLK = file
restart| XR5 |
| | | | interrupted xfer | block number,
| |
| | | | and RESYNC is set |
blocknum=WriteBLK&0FFh,| |
| | | | | (Send NAK SN0)
| | +-----+----------+-+-----------------------+--------------
-----------+-----+
| XR5 | SetOvrdr | | Set SLO as indicated
| XR3 |
| | | | by SEAlink header
| | `-----+----------+-------------------------+--------------
-----------+-----' Note: The routine that receives a header/data
block should do the following:
1. Report a bad block if the checksum or CRC is not correct or if
the physical layer encounters errors (e.g. parity, framing,
etc.) regardless of checksum or CRC. Report a bad block if the
length of the block is less than expected (Use a 5 second
timeout to detect short blocks).
2. If the block's sequence number does not match the complement,
FIDONEWS 13-49 Page 41 2 Dec 1996
then report a bad block if not in SEAlink. If in SEAlink mode
don't report this as a bad block, just restart the block search
looking for SOH. Check for SOH, BLK, ~BLK characters in a
"sliding" fashion and keep cycling until a valid start of block
(or timeout) is detected before assembling the remainder of the
block. This procedure makes a resync occur much more rapidly,
and with far fewer errors reported.
3. If the sequence number and block are good but not the expected
number, report state (XR3.3) if previous block. If not in
SEAlink, abort on any other out of sequence block. If in
SEAlink, report back state (XR3.5) or (XR3.6) as indicated by
the out of sequence received block number.
4. If an EOT is received on a data block prior to the filesize
specified in the SEAlink or TeLink header block, a NAK should
be issued to ensure that spurious data did not cause a
premature EOF. A NAK should also be issued for the first EOT
received in an Xmodem transfer when the final file size is not
known. A second EOT without intervening data would ensure that
the file really has been sent, and should be ACK'd.
5. If you last sent an ACK, then send a NAK here. If you last
sent a NAK then only NAK evry 32 blocks after the first NAK.
This allows buffer drain in overdrive. Use (Send NAK SN0) to
send the NAK.
25
XMODEM/TeLink/SEAlink - Send NAK
.-----+----------+-------------------------+----------------------
---+-----.
|State| State | Predicate(s) | Action(s)
| Next|
| # | Name | |
| St | +-----+----------+-+-----------------------+--------------
-----------+-----+
| SN0 | ClearLine|1| RESYNC flag set | Send RESYNC packet
| SN3 |
| | +-+-----------------------+----------------------
---+-----+
| | |2| SEAlink flag set |
| SN1 |
| | +-+-----------------------+----------------------
---+-----+
| | |3| > 30 sec contin data | report failure
| exit|
| | +-+-----------------------+----------------------
---+-----+
| | |4| character waiting | eat character
| SN0 |
| | +-+-----------------------+----------------------
---+-----+
| | |5| clear line |
| SN1 | +-----+----------+-+-----------------------+--------------
-----------+-----+
| SN1 | SendNAK |1| CRC flag set | Send "C"
| SN2 |
FIDONEWS 13-49 Page 42 2 Dec 1996
| | +-+-----------------------+----------------------
---+-----+
| | |2| CRC flag reset | send NAK
| SN2 | +-----+----------+-+-----------------------+--------------
-----------+-----+
| SN2 | SEAlink |1| SEAlink flag reset |
| exit|
| | +-+-----------------------+----------------------
---+-----+
| | |2| SEAlink flag set | send blocknum,
~blocknum| exit| +-----+----------+-+-----------------------+-----
--------------------+-----+
| SN3 | AckResync|1| Rcv ACK |
| exit|
| | +-+-----------------------+----------------------
---+-----+
| | |2| Rcv NAK | Resend RESYNC packet
| SN3 |
| | +-+-----------------------+----------------------
---+-----+
| | |3| Rcv Other Char | eat character
| SN3 |
| | +-+-----------------------+----------------------
---+-----+
| | |4| No char for 10 secs | Resend RESYNC packet
| SN3 |
| | +-+-----------------------+----------------------
---+-----+
| | |5| 30 seconds in SN3 |
| exit| `-----+----------+-+-----------------------+--------------
-----------+-----' Note: RESYNC packet should send WriteBLK as its
desired block number.
XMODEM/TeLink/SEAlink - Send ACK
.-----+----------+-------------------------+----------------------
---+-----.
|State| State | Predicate(s) | Action(s)
| Next|
| # | Name | |
| St | +-----+----------+-+-----------------------+--------------
-----------+-----+
| SA0 | ClearLine|1| SLO flag set |
| SA3 |
| | +-+-----------------------+----------------------
---+-----+
| | |2| SEAlink flag set |
| SA1 |
| | +-+-----------------------+----------------------
---+-----+
| | |3| > 30 sec contin data | report failure
| exit|
| | +-+-----------------------+----------------------
---+-----+
| | |4| character waiting | eat character
FIDONEWS 13-49 Page 43 2 Dec 1996
| SA0 |
| | +-+-----------------------+----------------------
---+-----+
| | |5| No char waiting |
| SA1 | +-----+----------+-+-----------------------+--------------
-----------+-----+
| SA1 | SendACK | | Send ACK
| SA2 | +-----+----------+-+-----------------------+--------------
-----------+-----+
| SA2 | SEAlink |1| SEAlink flag reset |
| SA3 |
| | +-+-----------------------+----------------------
---+-----+
| | |2| SEAlink flag set | send blocknum,
~blocknum| SA3 | +-----+----------+-+-----------------------+-----
--------------------+-----+
| SA3 | IncBlk | | Incr blocknum
| exit| `-----+----------+-------------------------+--------------
-----------+-----'
26
3. Data Link Layer Protocol : MODEM7 Filename Finite State
Machines (There is no change to the MODEM7 state tables from
FTS-0001).
MODEM7 Filename Sender
.-----+----------+-------------------------+----------------------
---+-----.
|State| State | Predicate(s) | Action(s)
| Next|
| # | Name | |
| St | +-----+----------+-+-----------------------+--------------
-----------+-----+
| MS0 | WaitNak |1| 20 retries or 1 minute| filename send failed
| exit|
| | +-+-----------------------+----------------------
---+-----+
| | |2| NAK received | send ACK & 1st ch of
fn | MS1 | +-----+----------+-+-----------------------+-----------
--------------+-----+
| MS1 | WaitChAck|1| ACK rcd, fname done | send SUB = 1AH
| MS2 |
| | +-+-----------------------+----------------------
---+-----+
| | |2| ACK rcd, fname ~done | send next ch of fname
| MS1 |
| | +-+-----------------------+----------------------
---+-----+
| | |3| other char or 1 sec | send "u", incr retry
cnt| MS0 | +-----+----------+-+-----------------------+-----------
--------------+-----+
| MS2 | WaitCksm |1| cksum recd and ok | send ACK, report fn
ok | exit|
FIDONEWS 13-49 Page 44 2 Dec 1996
| | +-+-----------------------+----------------------
---+-----+
| | |2| cksum recd but bad | send "u", incr retry
cnt| MS0 |
| | +-+-----------------------+----------------------
---+-----+
| | |3| no cksum in 1 sec | send "u", incr retry
cnt| MS0 | `-----+----------+-+-----------------------+-----------
--------------+-----'
MODEM7 Filename Receiver
.-----+----------+-------------------------+----------------------
---+-----.
|State| State | Predicate(s) | Action(s)
| Next|
| # | Name | |
| St | +-----+----------+-+-----------------------+--------------
-----------+-----+ | MR0 | SendNak |1| 20 tries or 1 minute |
report filename failure | exit|
| | +-+-----------------------+----------------------
---+-----+
| | |2| | send NAK, incr try
cnt | MR1 | +-----+----------+-+-----------------------+---------
----------------+-----+
| MR1 | WaitAck |1| rcd ACK |
| MR2 |
| | +-+-----------------------+----------------------
---+-----+
| | |2| rcd EOT | report no files
remain | exit|
| | +-+-----------------------+----------------------
---+-----+
| | |3| 5 secs & no ACK/EOT |
| MR0 | +-----+----------+-+-----------------------+--------------
-----------+-----+ | MR2 | WaitChar |1| recd EOT (can happen?)|
report no files remain | exit|
| | +-+-----------------------+----------------------
---+-----+
| | |2| recd SUB | send checksum byte
| MR3 |
| | +-+-----------------------+----------------------
---+-----+
| | |3| recd "u" |
| MR0 |
| | +-+-----------------------+----------------------
---+-----+
| | |4| recd char of name | send ACK
| MR2 |
| | +-+-----------------------+----------------------
---+-----+
| | |5| no char in 1 second |
| MR0 | +-----+----------+-+-----------------------+--------------
-----------+-----+ | MR3 | WaitOkCk |1| recd ACK within 1 sec |
report recd filename ok | exit|
FIDONEWS 13-49 Page 45 2 Dec 1996
| | +-+-----------------------+----------------------
---+-----+
| | |2| recd "u" or other char|
| MR0 | `-----+----------+-+-----------------------+--------------
-----------+-----'
SUB is the ASCII character ^Z or 1AH. The checksum is the
unsigned low order eight bits of the sum of the characters in the
transferred filename including the SUB.
Although 1 second timeouts are used successfully by Fido and
SEAdog, some fear that this is too small a value for some
satellite and packet networks.
27
-----------------------------------------------------------------
FIDONEWS 13-49 Page 46 2 Dec 1996
=================================================================
COORDINATORS CORNER
=================================================================
Nodelist-statistics as seen from Zone-2 for day 334
By Ward Dossche, 2:292/854
ZC/2
+----+------+------------+------------+------------+------------+--+
|Zone|Nl-306|Nodelist-313|Nodelist-320|Nodelist-327|Nodelist-334|%%|
+----+------+------------+------------+------------+------------+--+
| 1 | 11332|11332 0 |11127 -205 |11127 0 |10931 -196 |37|
| 2 | 16307|16157 -150 |16300 143 |16291 -9 |16240 -51 |54|
| 3 | 954| 942 -12 | 929 -13 | 905 -24 | 886 -19 | 3|
| 4 | 624| 620 -4 | 620 0 | 589 -31 | 584 -5 | 2|
| 5 | 95| 95 0 | 95 0 | 94 -1 | 94 0 | 0|
| 6 | 1007| 1007 0 | 999 -8 | 1008 9 | 1008 0 | 3|
+----+------+------------+------------+------------+------------+--+
| 30319|30153 -166 |30070 -83 |30014 -56 |29743 -271 |
+------+------------+------------+------------+------------+
-----------------------------------------------------------------
FIDONEWS 13-49 Page 47 2 Dec 1996
=================================================================
WE GET EMAIL
=================================================================
Date: Thu, 28 Nov 1996 17:18:34 +0100
X-Sender:
[email protected]
To:
[email protected]
From: Melle <
[email protected]>
Subject: A message from Sylvia Maxwell
* FORWARDED MESSAGE FROM SYLVIA MAXWELL PLEASE POST
>Dear Melle,
>
>It is so very warm to hear from you. I have a favour to ask. Could
>you please post the following in Fidonews?
>
>-----------------cut here-------------------------
>Erin Gilmour was murdered by the AIDS of president
>Nixon, who had been secunded to act as my security.
>I am the illigitimate child of John F. Kennedy, and
>have been party to military secrets which are being
>hushed up by the CIA and the Kennedy family. The
>Canadian Government is complicit.
>voice (519) 821-4165
>
[email protected]
>------------------------cut here------------------
>
>Doeg,
>Sylvia
Greetings,
Melle (2:281/731.29)
--
Greetings from the Netherlands,
Melle Koning Fidonet(2:281/731.29)
[email protected] [email protected]
http://www.geocities.com/colosseum/1334
+--------------------------------------+
| Not tonight dear... I have a modem.. |
+--------------------------------------+
-30-
-----------------------------------------------------------------
From:
[email protected] (Andrea Santos)
Subject: fido1348.nws
Date: Sun, 01 Dec 1996 03:48:16 GMT
Organization: Santronics Software,
http://www.santronics.com,
(305)-248-3204
To:
[email protected]
FIDONEWS 13-49 Page 48 2 Dec 1996
Hi Chris!
With regard to the "Open letter to Developers of Message Readers" in
fido1348.news, dated 11/25, the Silver Xpress Offline Mail Reader has
the ability to SORT echomail messages by (T)hread, (N)umber,
(R)ecipient, (A)uthor and (D)ate. Current version of Silver Xpress is
SXR43.ZIP or SXR43P.ZIP (386 protected mode), available from the
Xpress Support Center BBS, 1:135/382, 305-248-7815 and
http://www.santronics.com
Happy Holidays!
Andrea Santos/Santronics Software
... Experience the Power Today....Platinum Xpress/WINS!!!!
-30-
-----------------------------------------------------------------
FIDONEWS 13-49 Page 49 2 Dec 1996
=================================================================
NET HUMOR
=================================================================
From: "Mike Riddle" <
[email protected]>
To: "Baker, Christopher" <
[email protected] (Christopher Baker)
Date: Wed, 27 Nov 96 17:37:06 -0500
Reply-To: "Mike Riddle" <
[email protected]>
Subject: Fwd: Holiday Techie Tripe
==================BEGIN FORWARDED MESSAGE==================
>Date: Wed, 27 Nov 1996 10:34:14 -0500
>Message-Id: <
[email protected]>
>Comment: ABA Network 2d List
>Originator:
[email protected]
>Errors-To:
[email protected]
>Reply-To:
[email protected]
>Sender:
[email protected]
>Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas
>From: Ross Kodner <
[email protected]>
>To:
[email protected]
>Subject: Holiday Techie Tripe
From my pal, super legal librarian Jill Farmer (she actually calls
herself an Information Specialist <g>), this bit of holiday techie
humor. Have a great Thanksgiving everyone!
"The 12 Days of Technology Before Christmas
On the first day of Christmas, technology gave to me:
A database with a broken b-tree (what the hell is a b-tree
anyway?)
On the second day of Christmas, technology gave to me:
Two transceiver failures (CRC errors? Collisions? What is going
on?) And a database with a broken b-tree (Rebuild WHAT? It's a
10GB database!)
On the third day of Christmas, technology gave to me:
Three French users (who, of course, think they know everything)
Two transceiver failures (which are now spewing packets all
over the net)
And a database with a broken b-tree (Backup? What backup?)
On the fourth day of Christmas, technology gave to me:
Four calls for support (playing the same Christmas song over
and over)
Three French users (Why do they like to argue so much over
trivial things?)
Two transceiver failures (How the hell do I know which ones
they are?)
And a database with a broken b-tree (Pointer error? What's a
pointer error?)
FIDONEWS 13-49 Page 50 2 Dec 1996
On the fifth day of Christmas, technology gave to me:
Five golden SCSI contacts (Of course they're better than
silver!) Four support calls (Ever notice how time stands still
when on hold? Three French users (No, we don't have footpedals
on PC's.
Why do you ask?)
Two transceiver failures (If I knew which ones were bad, I
would know which ones to fix!)
And a database with a broken b-tree (Not till next week? Are
you nuts?!?!)
On the sixth day of Christmas, technology gave to me:
Six games a-playing (On the production network, of course!)
Five golden SCSI contacts (What do you mean "not terminated!")
Four support calls (No, don't transfer me again - do you HEAR?
Damn!)
Three French users (No, you cannot scan in by putting the page
to the screen...)
Two transceiver failures (I can't look at the LEDs - they're
in the ceiling!)
And a database with a broken b-tree (Norway? That's where this
was written?)
On the seventh day of Christmas, technology gave to me:
Seven license failures (Expired? When?)
Six games a-playing (Please stop tying up the PBX to talk to
each other!)
Five golden SCSI contacts (What do you mean I need "wide"
SCSI?) Four support calls (At least the Muzak is different this
time...) Three French Users (Well, monsieur, there really isn't
an
"any" key, but...)
Two transceiver failures (SQE? What is that? If I knew I would
set it myself!)
And a database with a broken b-tree (No, I really need to talk
to Lars - NOW!)
On the eighth day of Christmas, technology gave to me:
Eight MODEMs dialing (Who bought these? They're a security
violation!)
Seven license failures (How many WEEKS to get a license?)
Six games a-playing (What do you mean one pixel per packet on
updates?!?)
Five golden SCSI contacts (Fast SCSI? It's supposed to be
fast, isn't it?)
Four support calls (I already told them that! Don't transfer
me back - DAMN!)
Three French users (No, CTL-ALT-DEL is not the proper way to
end a program)
Two transceiver failures (What do you mean "babbling
transceiver"?) And a database with a broken b-tree (Does anyone
speak English in Oslo?)
On the ninth day of Christmas, technology gave to me:
Nine lady executives with attitude (She said do WHAT with the
servers?)
FIDONEWS 13-49 Page 51 2 Dec 1996
Eight MODEMs dialing (You've been downloading WHAT?)
Seven license failures (We sent the P.O. two months ago!)
Six games a-playing (HOW many people are doing this to the
network?) Five golden SCSI contacts (What do you mean two have
the same ID?) Four support calls (No, I am not at the console -
I tried that already.)
Three French users (No, only one floppy fits at a time? Why do
you ask?)
Two transceiver failures (Spare? What spare?)
And a database with a broken b-tree (No, I am trying to find
Lars! L-A-R-S!)
On the tenth day of Christmas, technology gave to me:
Ten SNMP alerts flashing (What is that Godawful beeping?)
Nine lady executives with attitude (No, it used to be a men's
room? Why?)
Eight MODEMs dialing (What Internet provider? We don't allow
Internet here!)
Seven license failures (SPA? Why are they calling us?)
Six games a-playing (No, you don't need a graphics accelerator
for Lotus! )
Five golden SCSI contacts (You mean I need ANOTHER cable?)
Four support calls (No, I never needed an account number
before...) Three French users (When the PC sounds like a cat,
it's a head crash!)
Two transceiver failures (Power connection? What power
connection?) And a database with a broken b-tree (Restore what
index pointers?)
On the eleventh day of Christmas, technology gave to me:
Eleven boards a-frying (What is that terrible smell?)
Ten SNMP alerts flashing (What's a MIB, anyway? What's an
extension?)
Nine lady executives with attitude (Mauve? Our computer room
tiles in mauve?)
Eight MODEMs dialing (What do you mean you let your roommate
dial-in?)
Seven license failures (How many other illegal copies do we
have?!?!)
Six games a-playing (I told you - AFTER HOURS!)
Five golden SCSI contacts (If I knew what was wrong, I
wouldn't be calling!)
Four support calls (Put me on hold again and I will slash your
credit rating!)
Three French users (Don't hang your floppies with a magnet
again!) Two transceiver failures (How should I know if the
connector is bad?)
And a database with a broken b-tree (I already did all of
that!)
On the twelfth day of Christmas, technology gave to me:
Twelve virtual pipe connections (There's only supposed to be
two!) Eleven boards a-frying (What a surge suppressor supposed
to do, anyway?)
Ten SNMP alerts flashing (From a distance, it does kinda look
like XMas lights.)
FIDONEWS 13-49 Page 52 2 Dec 1996
Nine lady executives with attitude (What do you mean aerobics
before backups?)
Eight MODEMs dialing (No, we never use them to connect during
business hours.)
Seven license failures (We're all going to jail, I just know
it.) Six games a-playing (No, no - my turn, my turn!)
Five golden SCSI contacts (Great, just great! Now it won't even
boot!)
Four support calls (I don't have that package! How did I end
up with you!)
Three French users (I don't care if it is sexy, no more nude
screen backgrounds!)
Two transceiver failures (Maybe we should switch to token
ring...) And a database with a broken b-tree (No, operator -
Oslo,
Norway. We were just talking and were cut off...)"
--------------
Ross <g>
_____________________________________________________
Ross L. Kodner, Esq. Voice: 414-476-8433
MicroLaw, Inc. FAX: 414-476-8461
825 S. 60th St. E-Mail:
[email protected]
Milwaukee, WI 53214 Web:
http://www.microlaw.com
ABA LPM "Network 2d" Ass't Editor Always Seeking Great Articles!
_____________________________________________________
===================END FORWARDED MESSAGE===================
-----------------------------------------------------------------
FIDONEWS 13-49 Page 53 2 Dec 1996
=================================================================
NOTICES
=================================================================
Future History
12 Dec 1996
Constitution Day, Russia
26 Jan 1997
Australia Day, Australia.
6 Feb 1997
Waitangi Day, New Zealand.
16 Feb 1997
Eleventh Anniversary of invention of Echomail by Jeff Rush.
29 Feb 1997
Nothing will happen on this day.
25 May 1997
Independence Day, Argentina
11 Jun 1997
Independence Day, Russia
1 Dec 1998
Fifteenth Anniversary of release of Fido version 1 by
Tom Jennings.
31 Dec 1999
Hogmanay, Scotland. The New Year that can't be missed.
15 Sep 2000
Sydney (Australia) Summer Olympiad opens.
-- If YOU have something which you would like to see in this
Future History, please send a note to the FidoNews Editor.
-----------------------------------------------------------------
FIDONEWS 13-49 Page 54 2 Dec 1996
=================================================================
FIDONET SOFTWARE LISTING
=================================================================
Latest Greatest Software Versions
by Peter E. Popovich, 1:363/264
Ugh. It's been an interesting couple of weeks. Between RAM failures,
hard drive failures, CMOS config screwups, leaving cables unplugged,
forcibly scraping NT 4.0 off a hard drive, and a Win '95 installation
that just wouldn't work right... It's all fixed now, but it was more
than a little interesting dealing with me last weekend... ;-)
As usual, I'm way behind. I learned a new phrase that describes my
situation well:
Due to budgetary cutbacks, the light at the end of the tunnel
has been turned off turned off until further notice.
I'm going to start running two phase-outs a week. I figure that'll
start cutting down the dead listings a little faster...
Phased out this week: Merlin 1.39n and Lynx 1.30
Phase-out highlights:
This week: PCBoard 14.5a and Phoenix 1.07
Deadline for info: 13 Dec 1996.
This week: Oracomm 5.M.6P and Oracomm Plus 6.E
Deadline for info: 6 Dec 1996.
-=- Snip -=-
Submission form for the Latest Greatest Software Versions column
OS Platform :
Software package name :
Version :
Function(s) - BBS, Mailer, Tosser, etc. :
Freeware / Shareware / Commercial? :
Author / Support staff contact name :
Author / Support staff contact node :
Magic name (at the above-listed node) :
Please include a sentence describing what the package does.
Please send updates and suggestions to: Peter Popovich, 1:363/264
-=- Snip -=-
MS-DOS:
Program Name Version F C Contact Name Node Magic Name
----------------------------------------------------------------------
Act-Up 4.6 G D Chris Gunn 1:15/55 ACT-UP
ALLFIX 4.33 T S Harald Harms 2:281/415 ALLFIX
Announcer 1.1 O S Peter Karlsson 2:206/221 ANNOUNCE
FIDONEWS 13-49 Page 55 2 Dec 1996
BGFAX 1.60 O S B.J. Guillot 1:106/400 BGFAX
CheckPnt 0.5 beta O F Michiel van der Vlist
2:500/9 CHECKPNT
FidoBBS (tm) 12u B S Ray Brown 1:1/117 FILES
FrontDoor 2.12 M S JoHo 2:201/330 FD
FrontDoor 2.20c M C JoHo 2:201/330 FDINFO
GIGO 07-14-96 G S Jason Fesler 1:1/141 INFO
Imail 1.75 T S Michael McCabe 1:297/11 IMAIL
ImCrypt 1.04 O F Michiel van der Vlist
2:500/9 IMCRYPT
InfoMail 1.11 O F Damian Walker 2:2502/666 INFOMAIL
InfoMail/386 1.20 O F Damian Walker 2:2502/666 INFO386
InterEcho 1.19 T C Peter Stewart 1:369/35 IEDEMO
InterMail 2.29k M C Peter Stewart 1:369/35 IMDEMO
InterPCB 1.52 O S Peter Stewart 1:369/35 INTERPCB
IPNet 1.11 O S Michele Stewart 1:369/21 IPNET
Jelly-Bean 1.01 T S Rowan Crowe 3:635/727 JELLY
Jelly-Bean/386 1.01 T S Rowan Crowe 3:635/727 JELLY386
MakePl 1.8 N F Michiel van der Vlist
2:500/9 MAKEPL
Marena 1.1 beta O F Michiel van der Vlist
2:500/9 MARENA
Maximus 3.01 B P Tech 1:249/106 MAX
McMail 1.0g5 M S Michael McCabe 1:1/148 MCMAIL
MDNDP 1.18 N S Bill Doyle 1:388/7 MDNDP
MsgEd 4.00 O G Paul Edwards 3:711/934 MSGED
Opus CBCS 1.73a B P Christopher Baker 1:374/14 OPUS
O/T-Track 2.63a O S Peter Hampf 2:241/1090 OT
PcMerge 2.7 N F Michiel van der Vlist
2:500/9 PCMERGE
PlatinumXpress 1.1 M C Gary Petersen 1:290/111 PX11TD.ZIP
RAR 2.00 C S Ron Dwight 2:220/22 RAR
RemoteAccess 2.50 B S Mark Lewis 1:3634/12 RA
Silver Xpress
Door 5.4 O S Gary Petersen 1:290/111 FILES
Reader 4.3 O S Gary Petersen 1:290/111 SXR43.ZIP
Squish 1.11 T P Tech 1:249/106 SQUISH
StealTag UK 1.c... O F Fred Schenk 2:284/412 STEAL_UK
StealTag NL 1.c... O F Fred Schenk 2:284/412 STEAL_NL
T-Mail 2.599I M S Ron Dwight 2:220/22 TMAIL
Terminate 4.00 O S Bo Bendtsen 2:254/261 TERMINATE
Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK
TriBBS 10.0 B S Patrick Driscoll 1:372/19 TRIBBS
TriDog 10.0 M S Patrick Driscoll 1:372/19 TRIDOG
TriToss 10.0 T S Patrick Driscoll 1:372/19 TRITOSS
WWIV 4.24a B S Craig Dooley 1:376/126 WWIV
WWIVTOSS 1.30 T S Craig Dooley 1:376/126 WWIVTOSS
xMail 2.00 T S Thorsten Franke 2:2448/53 XMAIL
XRobot 3.01 O S JoHo 2:201/330 XRDOS
OS/2:
Program Name Version F C Contact Name Node Magic Name
----------------------------------------------------------------------
BGFAX 1.60 O S B.J. Guillot 1:106/400 BGFAX
FleetStreet 1.18 O S Michael Hohner 2:2490/2520 FLEET
GIGO 07-14-96 G S Jason Fesler 1:1/141 INFO
FIDONEWS 13-49 Page 56 2 Dec 1996
ImCrypt 1.04 O F Michiel van der Vlist
2:500/9 IMCRYPT
Maximus 3.01 B P Tech 1:249/106 MAXP
MsgEd 4.00 O G Paul Edwards 3:711/934 MSGED
PcMerge 2.3 N F Michiel van der Vlist
2:500/9 PCMERGE
RAR 2.00 C S Ron Dwight 2:220/22 RAR2
Squish 1.11 T P Tech 1:249/106 SQUISHP
T-Mail 2.599I M S Ron Dwight 2:220/22 TMAIL2
Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK
XRobot 3.01 O S JoHo 2:201/330 XROS2
Windows (16-bit apps):
Program Name Version F C Contact Name Node Magic Name
----------------------------------------------------------------------
BeeMail 1.0 M C Andrius Cepaitis 2:470/1 BEEMAIL
Windows (32-bit apps):
Program Name Version F C Contact Name Node Magic Name
----------------------------------------------------------------------
BeeMail 1.0 M C Andrius Cepaitis 2:470/1 BEEMAIL
Maximus 3.01 B P Tech 1:249/106 MAXN
PlatinumXpress 2.00 M C Gary Petersen 1:290/111 PXW-INFO
T-Mail 2.599I M S Ron Dwight 2:220/22 TMAILNT
Unix:
Program Name Version F C Contact Name Node Magic Name
----------------------------------------------------------------------
ifmail 2.8g M G Eugene Crosser 2:293/2219 IFMAIL
ifmail-tx 2.8g-tx7.8 M G Pablo Saratxaga 2:293/2219 IFMAILTX
MsgEd 4.00 O G Paul Edwards 3:711/934 MSGED
Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK
Amiga:
Program Name Version F C Contact Name Node Magic Name
----------------------------------------------------------------------
CrashMail 1.23 T X Fredrik Bennison 2:205/324 CRASHMAIL
CrashTick 1.1 O F Fredrik Bennison 2:205/324 CRASHTICK
MsgEd 4.00 O G Paul Edwards 3:711/934 MSGED
Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK
Function: B-BBS, M-Mailer, N-Nodelist, G-Gateway, T-Tosser,
C-Compression, O-Other. Note: Multifunction will be listed
by the first match.
Cost: P-Free for personal use, F-Freeware, S-Shareware, C-Commercial,
X-Crippleware, D-Demoware, G-Free w/ Source
Old info from: 01/27/92
---------------------------------------------------------------------
MS-DOS Systems
--------------
BBS Software NodeList Utilities Other Utilities
FIDONEWS 13-49 Page 57 2 Dec 1996
Name Version Name Version Name Version
-------------------- -------------------- --------------------
Oracomm 5.M.6P@ EditNL 4.00 MailBase 4.11a@
Oracomm Plus 6.E@ FDND 1.10 MSG 4.5*
PCBoard 14.5a MakeNL 2.31 MsgLnk 1.0c
Phoenix 1.07* Parselst 1.33 MsgMstr 2.03a
ProBoard 1.20* Prune 1.40 MsgNum 4.16d
QuickBBS 2.75 SysNL 3.14 MSGTOSS 1.3
RBBS 17.3b XlatList 2.90 Netsex 2.00b
RemoteAccess 1.11* XlaxNode/Diff 2.53 OFFLINE 1.35
SimplexBBS 1.05 Oliver 1.0a
SLBBS 2.15C* Other Utilities OSIRIS CBIS 3.02
Socrates 1.11 Name Version PKInsert 7.10
SuperBBS 1.12* -------------------- PolyXarc 2.1a
SuperComm 0.99 2DAPoint 1.50* QM 1.00a
TAG 2.5g 4Dog/4DMatrix 1.18 QSort 4.04
TBBS 2.1 ARCAsim 2.31 RAD Plus 2.11
TComm/TCommNet 3.4 ARCmail 3.00* Raid 1.00
Telegard 2.7* Areafix 1.20 RBBSMail 18.0
TPBoard 6.1 ConfMail 4.00 ScanToss 1.28
WildCat! 3.02* Crossnet 1.5 ScMail 1.00
XBBS 1.77 DOMAIN 1.42 ScEdit 1.12
DEMM 1.06 Sirius 1.0x
Network Mailers DGMM 1.06 SLMail 2.15C
Name Version DOMAIN 1.42 StarLink 1.01
-------------------- EEngine 0.32 TagMail 2.41
BinkleyTerm 2.50 EMM 2.11* TCOMMail 2.2
D'Bridge 1.30 EZPoint 2.1 Telemail 1.5*
Dreamer 1.06 FGroup 1.00 TGroup 1.13
Dutchie 2.90c FidoPCB 1.0s@ TIRES 3.11
Milqtoast 1.00 FNPGate 2.70 TMail 1.21
PreNM 1.48 GateWorks 3.06e TosScan 1.00
SEAdog 4.60 GMail 2.05 UFGATE 1.03
SEAmail 1.01 GMD 3.10 VPurge 4.09e
TIMS 1.0(mod8) GMM 1.21 WEdit 2.0@
GoldEd 2.31p WildMail 2.00
Compression GROUP 2.23 WMail 2.2
Utilities GUS 1.40 WNode 2.1
Name Version Harvey's Robot 4.10 XRS 4.99
-------------------- HeadEdit 1.18 XST 2.3e
ARC 7.12 HLIST 1.09 YUPPIE! 2.00
ARJ 2.20 ISIS 5.12@ ZmailH 1.25
LHA 2.13 Lola 1.01d ZSX 2.40
PAK 2.51 Mosaic 1.00b
PKPak 3.61
PKZip 1.10
OS/2 Systems
------------
BBS Software Other Utilities(A-M Other Utilities(N-Z)
Name Version Name Version Name Version
-------------------- -------------------- --------------------
FIDONEWS 13-49 Page 58 2 Dec 1996
Kitten 1.01 ARC 7.12 oMMM 1.52
SimplexBBS 1.04.02+ ARC2 6.01 Omail 3.1
ConfMail 4.00 Parselst 1.33
EchoStat 6.0 PKZip 1.02
Network Mailers EZPoint 2.1 PMSnoop 1.30
Name Version FGroup 1.00 PolyXOS2 2.1a
-------------------- GROUP 2.23 QSort 2.1
BinkleyTerm 2.50 LH2 2.11 Raid 1.0
BinkleyTerm(S) 2.50 MSG 4.2 Remapper 1.2
BinkleyTerm/2-MT MsgLink 1.0c Tick 2.0
1.40.02 MsgNum 4.16d VPurge 4.09e
SEAmail 1.01
Xenix/Unix 386
--------------
BBS Software Network Mailers Other Utilities
Name Version Name Version Name Version
-------------------- -------------------- --------------------
ARC 5.21
C-LHARC 1.00
|Contact: Willy Paine 1:343/15,| MSGLINK 1.01
|or Eddy van Loo 2:285/406 | oMMM 1.42
Omail 1.00
ParseLst 1.32
Unzip 3.10
VPurge 4.08
Zoo 2.01
Macintosh
---------
BBS Software Network Mailers Other Software
Name Version Name Version Name Version
-------------------- -------------------- --------------------
FBBS 0.91 Copernicus 1.0 ArcMac 1.3
Hermes 1.6.1 Tabby 2.2 AreaFix 1.6
Mansion 7.15 Compact Pro 1.30
Precision Sys. 0.95b EventMeister 1.0
Red Ryder Host 2.1 Export 3.21
Telefinder Host Import 3.2
2.12T10 LHARC 0.41
MacArd 0.04
Mantissa 3.21
Point System Mehitable 2.0
Software OriginatorII 2.0
Name Version PreStamp 3.2
-------------------- StuffIt Classic 1.6
Copernicus 1.00 SunDial 3.2
CounterPoint 1.09 TExport 1.92
MacWoof 1.1 TimeStamp 1.6
TImport 1.92
Tset 1.3
TSort 1.0
FIDONEWS 13-49 Page 59 2 Dec 1996
UNZIP 1.02c
Zenith 1.5
Zip Extract 0.10
Amiga
-----
BBS Software Network Mailers Other Software
Name Version Name Version Name Version
-------------------- -------------------- --------------------
4D-BBS 1.65 BinkleyTerm 1.00 Areafix 1.48
DLG Pro. 0.96b TrapDoor 1.80 AReceipt 1.5
Falcon CBCS 1.00 WelMat 0.44 ChameleonEdit 0.11
Starnet 1.0q@ ConfMail 1.12
TransAmiga 1.07 ElectricHerald 1.66
XenoLink 1.0 Compression FFRS 1.0@
Utilities FileMgr 2.08
Name Version Fozzle 1.0@
NodeList Utilities -------------------- Login 0.18
Name Version AmigArc 0.23 MessageFilter 1.52
-------------------- booz 1.01 Message View 1.12
ParseLst 1.66 LHARC 1.30 oMMM 1.50
Skyparse 2.30 LhA 1.10 PolyXAmy 2.02
TrapList 1.40 LZ 1.92 RMB 1.30
PkAX 1.00 Roof 46.15
UnZip 4.1 RoboWriter 1.02
Zippy (Unzip) 1.25 Rsh 4.07a
Zoo 2.01 Tick 0.75
TrapToss 1.20
|Contact: Maximilian Hantsch 2:310/6| Yuck! 2.02
Atari ST/TT
-----------
BBS Software Network Mailers Other Utilities
Name Version Name Version Name Version
-------------------- -------------------- --------------------
FIDOdoor/ST 2.5.1 BinkleyTerm 2.40n9 ApplyList 1.00@
FiFo 2.1v The Box 1.95* Burep 1.1
LED ST 1.00 ComScan 1.04
QuickBBS/ST 1.06* ConfMail 4.10
NodeList Utilities Echoscan 1.10
Name Version FDrenum 2.5.2
Compression -------------------- FastPack 1.20
Utilities ParseList 1.30 Import 1.14
Name Version EchoFix 1.20 oMMM 1.40
-------------------- sTICK/Hatch 5.50 Pack 1.00
ARC 6.02 Trenum 0.10
LHARC 2.01i
PackConvert
STZip 1.1*
UnJARST 2.00
WhatArc 2.02
FIDONEWS 13-49 Page 60 2 Dec 1996
Tandy Color Computer 3 (OS-9 Level II)
--------------------------------------
BBS Software Compression Utility Other Utilities
Name Version Name Version Name Version
-------------------- -------------------- --------------------
RiBBS 2.02+ Ar 1.3 Ascan 1.2
DeArc 5.12 AutoFRL 2.0
OS9Arc 1.0 Bundle 2.2
UnZip 3.10 CKARC 1.1
UnLZH 3.0 EchoCheck 1.01
FReq 2.5a
LookNode 2.00
ParseLST
PReq 2.2
RList 1.03
RTick 2.00
UnBundle 1.4
UnSeen 1.1
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Key to old info:
+ - Netmail Capable (Doesn't Require Additional Mailer Software)
* - Recently Updated Version
@ - New Addition
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Please send updates and suggestions to: Peter Popovich, 1:363/264
-----------------------------------------------------------------
FIDONEWS 13-49 Page 61 2 Dec 1996
=================================================================
FIDONEWS PUBLIC-KEY
=================================================================
[this must be copied out to a file starting at column 1 or
it won't process under PGP as a valid public-key]
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2
Comment: Clear-signing is Electronic Digital Authenticity!
-----END PGP PUBLIC KEY BLOCK-----
Pending a formal decision about including 'encrypted' material inside
FidoNews from the Zone Coordinator Council, the guts of the FidoNews
public-key have been removed from this listing.
File-request FNEWSKEY from 1:1/23 [1:18/14] or download it from the
Rights On! BBS at 1-904-409-7040 anytime except 0100-0130 ET and Zone
1 ZMH at 1200-9600+ HST/V32B.
This section will contain only this disclaimer and instructions until
a ZCC decision is forwarded to the Editor.
Sorry for any inconvenience.
-----------------------------------------------------------------
FIDONEWS 13-49 Page 62 2 Dec 1996
=================================================================
FIDONEWS INFORMATION
=================================================================
------- FIDONEWS MASTHEAD AND CONTACT INFORMATION -------
Editor: Christopher Baker
Editors Emeritii: Thom Henderson, Dale Lovell,
Vince Perriello, Tim Pozar,
Tom Jennings, Sylvia Maxwell,
Donald Tees
"FidoNews Editor"
FidoNet 1:1/23
BBS 1-904-409-7040, 300/1200/2400/14400/V.32bis/HST(ds)
more addresses:
Christopher Baker -- 1:18/14,
[email protected]
[email protected]
(Postal Service mailing address)
FidoNews Editor
P.O. Box 471
Edgewater, FL 32132-0471
U.S.A.
voice: 1-904-409-3040 [1400-2100 ET only, please]
[1800-0100 UTC/GMT]
------------------------------------------------------
FidoNews is published weekly by and for the members of the FIDONET
INTERNATIONAL AMATEUR ELECTRONIC MAIL system. It is a compilation
of individual articles contributed by their authors or their
authorized agents. The contribution of articles to this compilation
does not diminish the rights of the authors. OPINIONS EXPRESSED in
these articles ARE THOSE OF THE AUTHORS and not necessarily those of
FidoNews.
Authors retain copyright on individual works; otherwise FidoNews is
Copyright 1996 Christopher Baker. All rights reserved. Duplication
and/or distribution permitted for noncommercial purposes only. For
use in other circumstances, please contact the original authors, or
the Editor.
=*=*=*=*=*=*=*=*=
OBTAINING COPIES: The most recent issue of FidoNews in electronic
form may be obtained from the FidoNews Editor via manual download or
file-request, or from various sites in the FidoNet and Internet.
PRINTED COPIES may be obtained by sending SASE to the above postal
address. File-request FIDONEWS for the current Issue. File-request
FNEWS for the current month in one archive. Or file-request specific
back Issue filenames in distribution format [FNEWSDnn.LZH] for a
FIDONEWS 13-49 Page 63 2 Dec 1996
particular Issue. Monthly Volumes are available as FNWSmmmy.ZIP
where mmm = three letter month [JAN - DEC] and y = last digit of the
current year [6], i.e., FNWSMAY6.ZIP for all the Issues from May 96.
Annual volumes are available as FNEWSn.ZIP where n = the Volume number
1 - 12 for 1984 - 1995, respectively. Annual Volume archives range in
size from 48K to 1.2M.
INTERNET USERS: FidoNews is available via:
http://www.fidonet.org/fidonews.htm
ftp://ftp.fidonet.org/pub/fidonet/fidonews/
ftp://ftp.aminet.org/pub/aminet/comm/fido/
You can read the current FidoNews Issue in HTML format at:
http://www.geocities.com/athens/6894/
STAR SOURCE for ALL Past Issues via FTP and file-request -
Available for FReq from 1:396/1 or by anonymous FTP from:
ftp://ftp.sstar.com/fidonet/fnews/
Each yearly archive also contains a listing of the Table-of-Contents
for that year's issues. The total set is currently about 11 Megs.
=*=*=*=
The current week's FidoNews and the FidoNews public-key are now also
available almost immediately after publication on the Editor's new
homepage on the World Wide Web at:
http://ddi.digital.net/~cbaker84/fidonews.html
There are also links there to jim barchuk's HTML FidoNews source and
to John Souvestre's FTP site for the archives. There is also an email
link for sending in an article as message text. Drop on over.
=*=*=*=*=*=*=*=*=
A PGP generated public-key is available for the FidoNews Editor from
1:1/23 [1:18/14] by file-request for FNEWSKEY or by download from
Rights On! BBS at 1-904-409-7040 as FIDONEWS.ASC in File Area 18. It
is also posted twice a month into the PKEY_DROP Echo available on the
Zone 1 Echomail Backbone.
*=*=*=*=*
Anyone interested in getting a copy of the INTERNET GATEWAY FAQ may
file-request GISFAQ.ZIP from 1:133/411.0, or send an internet message
to
[email protected]. No message or text or subject is
necessary. The address is a keyword that will trigger the automated
response. People wishing to send inquiries directly to David Deitch
should now mail to
[email protected] rather than the
previously listed address.
FIDONEWS 13-49 Page 64 2 Dec 1996
*=*=*=*=*
SUBMISSIONS: You are encouraged to submit articles for publication in
FidoNews. Article submission requirements are contained in the file
ARTSPEC.DOC, available from the FidoNews Editor, or file-requestable
from 1:1/23 [1:18/14] as file "ARTSPEC.DOC". ALL Zone Coordinators
also have copies of ARTSPEC.DOC. Please read it.
"Fido", "FidoNet" and the dog-with-diskette are U.S. registered
trademarks of Tom Jennings, P.O. Box 410923, San Francisco, CA 94141,
and are used with permission.
"Disagreement is actually necessary,
or we'd all have to get in fights
or something to amuse ourselves
and create the requisite chaos."
-Tom Jennings
-30-
-----------------------------------------------------------------
