ProfitPress Mega CDROM2 Shareware Freeware (MSDOS)(1992)(Eng)

home *** CD-ROM | disk | FTP | other *** search

/ ProfitPress Mega CDROM2 …eeware (MSDOS)(1992)(Eng) / ProfitPress-MegaCDROM2.B6I / BBS / NETMAIL / FTSC_ALL.ZIP / FTS-0001.014 < prev next >

Wrap

Text File | 1990-07-05 | 64.3 KB | 1,245 lines

Document: FTS-0001 Version: 014 Date: 07/05/90 A Basic FidoNet(r) Technical Standard | Revision 14 Formerly known as FSC001, FSC-0001 | Randy Bush, Pacific Systems Group | July 5, 1990 Status of this document: This FTS (FidoNet(r) Technical Standard) specifies a standard for the FidoNet community. FidoNet nodes are expected to adopt and implement this standard. Distribution is subject to the restrictions stated in the copyright paragraph below. Fido and FidoNet are registered marks of Tom Jennings and Fido Software. Copyright 1986-90, Randy Bush. All rights reserved. The right to distribute for non-commercial use is granted to the FidoNet Technical Standards Committee, provided that no fee is charged. This may be posted on FidoNet electronic BBSs which charge no fee for accessing this document. Any and all other reproduction or excerpting requires the explicit written consent of the author. A. Introduction FidoNet has grown beyond most peoples' fantasies, and new FidoNet implementations are appearing regularly. Unfortunately, the scattered nature of the documentation and absence of clear testing procedures have | made implementation difficult. FidoNet, in its desire to promote and encourage FidoNet implementations, suggested a project to create a technical standard for FidoNet. This is the first draft document from that effort. This document defines the data structures and communication protocols which a FidoNet implementation must provide. The implementor of FidoNet compatible systems is the intended audience of this document. 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. The content of this document was gleaned from the references given at the end. This is not a a proposal, nor is it yet a standard; it is a plea for correction, more information, and other reference documents. Please direct technical comments and errata to | Randy Bush uucp: uunet!m2xenix!randy Internet: randy@psg.com | Pacific Systems Group FidoNet: 1:105/6 | 9501 S.W. Westhaven Drive | Portland, Oregon US-97225 | and Rick Moore FidoNet: 1:115/333 Statistical Tabulating Corp. | 2 North Riverside Plaza Chicago, Illinois US-60606 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 FidoNet 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. | FidoNet implementations must be able to receive and process the FidoNet format nodelist, and transfer nodelists to other nodes. A companion | document, FTS-0005, defines the FidoNet 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 a FidoNet format nodelist. 2. Levels of Compliance This documents represents the most basic FidoNet implementation. A future document will define well tested extensions which are optional but provide sufficient additional function that implementors should seriously consider them. SEAdog(tm), from System Enhancement Associates, is an excellent example of such an extended FidoNet implementation. 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. 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 automation 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 A language specific notation was avoided. Please help stamp out environmental dependencies. Only you can prevent PClone market dominance. Don't panic, there are rectangular record layouts too. (* 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) (* 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 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. 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. B. Application Layer : the System from the User's View The application layer is outside the domain of a FidoNet standard, as it is the layer that the user's application sees as opposed to what FidoNet sees. In recent months, there has been sufficient confusion and discussion about the format of data at this level to warrant the description of the data structure, the message as it is stored by Fido, SEAdog, and Rover. Perfectly valid FidoNet systems may be implemented whose stored messages differ greatly from this format. 1. Application Layer Data Definition : a Stored Message Stored Message Offset dec hex .-----------------------------------------------. 0 0 | | ~ fromUserName ~ | 36 bytes | +-----------------------+-----------------------+ 36 24 | | ~ toUserName ~ | 36 bytes | +-----------------------+-----------------------+ 72 48 | | ~ subject ~ | 72 bytes | +-----------------------+-----------------------+ 144 90 | | ~ dateTime ~ | 20 bytes | +-----------------------+-----------------------+ 164 A4 | timesRead (low order) | timesRead (high order)| +-----------------------+-----------------------+ 166 A6 | destNode (low order) | destNode (high order) | +-----------------------+-----------------------+ 168 A8 | origNode (low order) | origNode (high order) | +-----------------------+-----------------------+ 170 AA | cost (low order) | cost (high order) | +-----------------------+-----------------------+ 172 AC | origNet (low order) | origNet (high order) | +-----------------------+-----------------------+ 174 AE | destNet (low order) | destNet (high order) | +-----------------------+-----------------------+ | 176 B0 | destZone (optional) | destZone (optional) | | +-----------------------+-----------------------+ | 178 B2 | origZone (optional) | origZone (optional) | | +-----------------------+-----------------------+ | 180 B4 | destPoint(optional) | destPoint(optional) | | +-----------------------+-----------------------+ | 182 B6 | origPoint(optional) | origPoint(optional) | +-----------------------+-----------------------+ 184 B8 | replyTo (low order) | replyTo (high order) | +-----------------------+-----------------------+ 186 BA | Attribute (low order) | Attribute (high order)| +-----------------------+-----------------------+ 188 BC | nextReply (low order) | nextReply (high order)| +-----------------------+-----------------------+ 190 BE | text | ~ unbounded ~ | null terminated | `-----------------------------------------------' Message = fromUserName(36) (* Null terminated *) toUserName(36) (* Null terminated *) subject(72) (* see FileList below *) DateTime (* message body was last edited *) | timesRead (* number of times msg has been read *) destNode (* of message *) origNode (* of message *) cost (* in lowest unit of originator's currency *) origNet (* of message *) destNet (* of message *) | destZone (* of message *) | origZone (* of message *) | destPoint (* of message *) | origPoint (* of message *) replyTo (* msg to which this replies *) AttributeWord nextReply (* msg which replies to this *) text(unbounded) (* Null terminated *) DateTime = (* a character string 20 characters long *) (* 01 Jan 86 02:34:56 *) DayOfMonth " " Month " " Year " " " " HH ":" MM ":" SS Null DayOfMonth = "01" | "02" | "03" | ... | "31" (* Fido 0 fills *) Month = "Jan" | "Feb" | "Mar" | "Apr" | "May" | "Jun" | "Jul" | "Aug" | "Sep" | "Oct" | "Nov" | "Dec" Year = "01" | "02" | .. | "85" | "86" | ... | "99" | "00" HH = "00" | .. | "23" MM = "00" | .. | "59" SS = "00" | .. | "59" AttributeWord bit meaning --- -------------------- 0 + Private 1 + s Crash 2 Recd 3 Sent 4 + FileAttached 5 InTransit 6 Orphan 7 KillSent 8 Local 9 s HoldForPickup 10 + unused 11 s FileRequest 12 + s ReturnReceiptRequest 13 + s IsReturnReceipt 14 + s AuditRequest 15 s FileUpdateReq s - need not be recognized, but it's ok | + - not zeroed before packeting Bits numbers ascend with arithmetic significance of bit position. Message Text Message text is unbounded and null terminated (note exception below). A 'hard' carriage return, 0DH, marks the end of a paragraph, and must be preserved. So called 'soft' carriage returns, 8DH, may mark a previous processor's automatic line wrap, and should be ignored. Beware that they may be followed by linefeeds, or may not. All linefeeds, 0AH, should be ignored. Systems which display message text should wrap long lines to suit their application. If the first character of a physical line (e.g. the first character of the message text, or the character immediately after a hard carriage return (ignoring any linefeeds)) is a ^A (<control-A>, 01H), then that line is not displayed as it contains control information. The convention for such control lines is: o They begin with ^A o They end at the end of the physical line (i.e. ignore soft <cr>s). o They begin with a keyword followed by a colon. o The keywords are uniquely assigned to applications. o They keyword/colon pair is followed by application specific data. Current ^A keyword assignments are: o TOPT <pt no> - origin point address o FMPT <pt no> - origin point address o INTL <dest z:n/n> <orig z:n/n> - used for inter-zone address File Specifications If one or more of FileAttached, FileRequest, or FileUpdateReq are asserted in an AttributeWord, the subject{72} field is interpreted as a list of file specifications which may include wildcards and other system-dependent data. This list is of the form FileList = [ FileSpec { Sep FileSpec } ] Null FileSpec = (* implementation dependent file specification. may not contain Null or any of the characters in Sep. *) Sep = ( " " | "," ) { " " } There are deviations from and additions to these specifications 1 - Fido does not necessarily terminate the message text with a Null, | but uses an empty line (0DH 0AH 0DH 0AH). Some Fido utilities | use an EOF (1AH). 2 - SEAdog zeros the message cost field when building a message. 4 - SEAdog uses a different format for dates, e.g. DateTime = (* a character string 20 characters long *) (* SEAdog format Mon 1 Jan 86 02:34 *) | DayOfWk " " DayOfMo " " Month " " Year " " HH ":" MM Null | DayOfWk = "Mon" | "Tue" | "Wed" | "Thu" | "Fri" | "Sat" | "Sun" | DayOfMo = " 1" | " 2" | " 3" | ... | "31" (* blank fill *) 2. Application Layer Protocol : Schedules and Events At the application level, FidoNet imposes few protocol requirements. An implementation must automatically originate and receive node-to-node FidoNet connections. Some implementations do this in 'windows' or time slots. Routing of messages will usually be different and customizable for each scheduled window. | The ability to send to and receive from any FidoNet listed node during | the Zone Mail Hour (eg. 9:00-10:00 UCT in Z1) is considered mandatory. Current implementations assemble all data for outbound connections at the start of a window, and disassemble inbound data at the end of a window. Due to performance considerations on small machines, this is considered a valid optimization. Observe that it somewhat inhibits dynamic routing. C. Presentation Layer : the User from the System's View 1. Presentation Layer Data Definition : the Packed Message To conserve space and eliminate fields which would be meaningless if sent (e.g. timesRead), messages are packed for transmission. As this is a data structure which is actually transferred, its definition is critical to FidoNet. A packed message has a number of fixed length fields followed by four null terminated strings. While most of the string fields in a stored message are fixed length, to conserve space strings are variable length when in a packet. All variable length strings are all Null terminated, including especially the message text. Packed Message Offset dec hex .-----------------------------------------------. 0 0 | 0 | 2 | 0 | 0 | +-----------------------+-----------------------+ 2 2 | origNode (low order) | origNode (high order) | +-----------------------+-----------------------+ 4 4 | destNode (low order) | destNode (high order) | +-----------------------+-----------------------+ 6 6 | origNet (low order) | origNet (high order) | +-----------------------+-----------------------+ 8 8 | destNet (low order) | destNet (high order) | +-----------------------+-----------------------+ 10 A | Attribute (low order) | Attribute (high order)| +-----------------------+-----------------------+ 12 C | cost (low order) | cost (high order) | +-----------------------+-----------------------+ 14 E | | ~ dateTime ~ | 20 bytes | +-----------------------+-----------------------+ | 34 22 | toUserName | ~ max 36 bytes ~ | null terminated | +-----------------------+-----------------------+ | fromUserName | ~ max 36 bytes ~ | null terminated | +-----------------------+-----------------------+ | subject | ~ max 72 bytes ~ | null terminated | +-----------------------+-----------------------+ | text | ~ unbounded ~ | null terminated | `-----------------------------------------------' Due to routing, the origin and destination net and node of a packet are often quite different from those of the messages within it, nor need the origin and destination nets and nodes of the messages within a packet be homogenous. | PakdMessage = 02H 00H (* message type, old type-1 obsolete *) origNode (* of message *) destNode (* of message *) origNet (* of message *) destNet (* of message *) AttributeWord cost (* in lowest unit of originator's currency *) DateTime (* message body was last edited *) toUserName{36} (* Null terminated *) fromUserName{36} (* Null terminated *) subject{72} (* Null terminated *) text{unbounded} (* Null terminated *) 2. Presentation Layer Protocol : a Mail Window .-----+----------+-------------------------+-------------------------+-----. |State| State | Predicate(s) | Action(s) | Next| | # | Name | | | St | |-----+----------+-------------------------+-------------------------+-----| | W0 | WindTop | 1 end of window reached | reset modem to not answr| exit| | | | 2 time remains in window| ensure modem can answer | W1 | |-----+----------+-------------------------+-------------------------+-----| | W1 | WindIdle | 1 incoming call | | W2 | | | | 2 receive-only mode | | W0 | | | | 3 send-only mode | | W3 | | | | 4 60-180 secs & no call | | W3 | |-----+----------+-------------------------+-------------------------+-----| | W2* | WindRecv | | (receive call R0) | W3 | |-----+----------+-------------------------+-------------------------+-----| | W3 | WindCall | 1 select outgoing call | increment try count | W4 | | | | 2 no outgoing calls | | W0 | |-----+----------+-------------------------+-------------------------+-----| | W4* | WindSend | | (make call S0) | W5 | |-----+----------+-------------------------+-------------------------+-----| | W5 | WindMark | 1 call successful | remove node fr call list| W0 | | | | 2 no connect | remove if try cnt > lim | W0 | | | | 3 call failed | incr conn cnt, remove | W0 | | | | | if con cnt > lim | | `-----+----------+-------------------------+-------------------------+-----' The length of the inter-call delay time at W1.4 is not critical. It is | important that this not be a constant, so two systems calling each other do not incur infinite busy signals. Sophisticated implementations may vary the inter-call delay depending on number of calls to be made, window width, user specification, etc. 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), a change in the protocol may be expected in the near future. 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 errors should be detected. 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 | | | | 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 | S4 | | | | 2 over 60 seconds | hang up, report garbage | exit| | | | and line not clear | | | |-----+----------+-------------------------+-------------------------+-----| | | S4* | TSyncChk | 1 'C' or NAK (peeked at)| (XMODEM send packet XS1)| S5 | | | | | 2 over 2 seconds | eat noise, resend TSYNCH| S4 | | | | | 3 over 30 seconds | hang up report not Fido | exit| |-----+----------+-------------------------+-------------------------+-----| | 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. In state S4, the phrase "peeked at" means that the character is not removed from the buffer. Therefore when XS1 is started the proper character for beginning the Xmodem transfer will be detected. 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) | 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| `-----+----------+-------------------------+-------------------------+-----' E. Transport Layer : ????? 1. Data Definitions | 2. Transport Layer Protocol : Routing FidoNet does not necessarily send a message directly to its destination. To reduce the number of network connections, mail to a subset of the nodelist may be routed to one node for further distribution within that subset. In addition, custom routing is possible. Routing of a message is determined in one of three ways. o If there are files attached, then a message must be sent directly to its destination. o Messages without attached files should be routed through the inbound | host of the destination node's subnet as specified by a FidoNet format nodelist. o To prevent overloading of inbound hosts, a system should provide for host routing to be disabled for a target node, or nodes. F. Network Layer : the Network's View of the System, Routing and Packets 1. Network Layer Data Definition : the Packet Header The packet contains messages in packed format to be transferred over the net during a connection. As this data structure is transferred, its definition is critical to FidoNet. A packet may contain zero or more packed messages. A packet without messages is often generated as a poll packet. Every packet begins with a packet header. The fields of the packet header are of fixed length. Packet Header Offset dec hex .-----------------------------------------------. 0 0 | origNode (low order) | origNode (high order) | +-----------------------+-----------------------+ 2 2 | destNode (low order) | destNode (high order) | +-----------------------+-----------------------+ 4 4 | year (low order) | year (high order) | +-----------------------+-----------------------+ 6 6 | month (low order) | month (high order) | +-----------------------+-----------------------+ 8 8 | day (low order) | day (high order) | +-----------------------+-----------------------+ 10 A | hour (low order) | hour (high order) | +-----------------------+-----------------------+ 12 C | minute (low order) | minute (high order) | +-----------------------+-----------------------+ 14 E | second (low order) | second (high order) | +-----------------------+-----------------------+ 16 10 | baud (low order) | baud (high order) | +-----------------------+-----------------------+ 18 12 | 0 | 2 | 0 | 0 | +-----------------------+-----------------------+ 20 14 | origNet (low order) | origNet (high order) | +-----------------------+-----------------------+ 22 16 | destNet (low order) | destNet (high order) | +-----------------------+-----------------------+ | 24 18 | ProdCode | SerialNo | | | +-----------------------' | | 28 1C | password (some impls) | | + .-----------------------| | | null padded | origZone (some impls) | | +-----------------------+-----------------------| | 36 24 | destZone (some impls) | | | +-----------------------' | | 40 28 | fill | | ~ 18 bytes ~ +-----------------------+-----------------------+ 58 3A | zero or more | ~ packed ~ | messages | +-----------------------+-----------------------+ | 0 | 0 | 0 | 0 | `-----------------------------------------------' Packet = PacketHeader { PakdMessage } 00H 00H PacketHeader = origNode (* of packet, not of messages in packet *) destNode (* of packet, not of messages in packet *) year (* of packet creation, e.g. 1986 *) month (* of packet creation, 0-11 for Jan-Dec *) day (* of packet creation, 1-31 *) hour (* of packet creation, 0-23 *) minute (* of packet creation, 0-59 *) second (* of packet creation, 0-59 *) baud (* max baud rate of orig and dest, 0=SEA *) PacketType (* old type-1 packets now obsolete *) origNet (* of packet, not of messages in packet *) destNet (* of packet, not of messages in packet *) prodCode (* 0 for Fido, write to FTSC for others *) | serialNo (* binary serial number (otherwise null)*) | password (* session password (otherwise null) *) | origZone (* zone of pkt sender (otherwise null) *) | destZone (* zone of pkt receiver (otherwise null)*) | fill[18] PacketType = 02H 00H (* 01H 00H was used by Fido versions before 10 which did not support local nets. The packed message header was also different for those versions *) | ProductCode = ( 00H (* Fido *) | | ... | ??H (* Please apply for new codes *) ) The remainder of the packet consists of packed messages. Each packed message begins with a message type word 0200H. A pseudo-message beginning with the word 0000H signifies the end of the packet. 2. Network Layer Data Description : a File with Attributes The BATCH protocol uses the MODEM7 filename and 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. The MODEM7 file name is redundant if there is also a TeLink block, in which case the name may be taken from either or both. FileName as Sent Offset dec hex .-----------------------------------------------. 0 0 | fileName | ~ 8 bytes ~ | left adjusted blank filled | +-----------------------+-----------------------+ 8 8 | fileExt | ~ 3 bytes ~ | left adjusted blank filled | `-----------------------------------------------' 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 | (MODEM7 FName send MS0) | BS1 | | | | 2 no more files to send | | BS3 | |-----+----------+-------------------------+-------------------------+-----| | BS1 | CheckFNm | 1 MODEM7 Filename ok | (TeLink send file XS0) | BS2 | | | | 2 MODEM7 Filename bad | report name send bad | exit| |-----+----------+-------------------------+-------------------------+-----| | BS2 | CheckFile| 1 TeLink send ok | | BS0 | | | | 2 TeLink send bad | report file send bad | exit| |-----+----------+-------------------------+-------------------------+-----| | BS3 | EndSend | 1 rec NAK for next file | send EOT, report send ok| exit| | | | 2 10 seconds no NAK | send EOT, report no NAK | exit| `-----+----------+-------------------------+-------------------------+-----' When no files remain, the sender responds to the receiver's NAK with an | EOT. The EOT is not ACK/NAKed by the receiver. Filenames must be upper case ASCII. The data link layer uses "u" as a control character. BATCH File Receiver .-----+----------+-------------------------+-------------------------+-----. |State| State | Predicate(s) | Action(s) | Next| | # | Name | | | St | |-----+----------+-------------------------+-------------------------+-----| | BR0*| RecvName | | (MODEM7 FName recv MR0) | BR1 | |-----+----------+-------------------------+-------------------------+-----| | BR1 | CheckFNm | 1 MODEM7 no more files | report files recd ok | exit| | | | 2 MODEM7 Filename ok | (TeLink recv file XR0) | BR2 | | | | 2 MODEM7 Filename bad | report name recv bad | exit| |-----+----------+-------------------------+-------------------------+-----| | BR2 | CheckFile| 1 TeLink recv ok | | BR0 | | | | 2 TeLink recv bad | report file recv bad | exit| `-----+----------+-------------------------+-------------------------+-----' G. Data Link Layer : Error-Free Data Transfer 1. Data Link Layer Data Definition : XMODEM/TeLink 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 use some other means to convey the true data length to the receiver (e.g. TeLink file info block). Data blocks contain sequence numbers so the receiver can ensure it has the correct block. Block numbers are sequential unsigned eight bit integers beginning with 01H and wrapping to 00H, except that a TeLink block is given sequence number 00H. For files which are attached to the mail packet, 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 two NAKs (or "C"s), the sender skips this special block and goes on to the data itself. 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 | `-----------------------------------------------' XMODEM Data Block (Checksum 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 | Checksum byte | `-----------------------------------------------' TeLink File Descriptor Block Offset dec hex .-----------------------------------------------. 0 0 | SYN - File Info Header - 16H | +-----------------------------------------------+ 1 1 | 00H | +-----------------------------------------------+ data offset 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 2C | 01H (for CRC) or 00H | 41 29 +-----------------------------------------------+ | 45 2D | fill | 42 2A ~ 86 bytes ~ | all zero | +-----------------------------------------------+ | 132 84 | Checksum byte | `-----------------------------------------------' XMODEMData = XMODEMBlock (* block of data with header and trailer *) | TeLinkBlock (* TeLink File Descriptor Block *) | ACK (* acknowledge data received ok *) | NAK (* 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 compl 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 *) fileLength[4] (* length of data in bytes *) CreationTime[2] (* time file last modified or zero *) 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 *) crcMode[1] (* 01H for CRC 00H for Checksum *) fill[87] (* zeroed *) Checksum (* error detect/correction code *) 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 *) CRC = crc[2] (* CCITT Cyclic Redundancy Check *) Checksum = checksum[1] (* low 8 bits of sum of data bytes using unsigned 8 bit arithmetic *) 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 *) 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. Data Link Layer Protocol : XMODEM/TeLink 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 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 iff 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. Neither the sender nor the receiver should send the block or ACK/NAK response while there is data being received. They should wait for the line to settle, and possibly time out. It is suggested that one's input buffer be cleared immediately after sending block or ACK/NAK response, before waiting for the response from the other end. This clears any line garbage which occurred during transmit. XMODEM/TeLink Sender .-----+----------+-------------------------+-------------------------+-----. |State| State | Predicate(s) | Action(s) | Next| | # | Name | | | St | |-----+----------+-------------------------+-------------------------+-----| | XS0 | WaitTeLnk| 1 over 40-60 seconds | report sender timeout | exit| | | | 2 over 2 tries | note TeLink block failed| XS1 | | | | 3 NAK or "C" received | send TeLink, incr tries | XS0 | | | | 4 ACK received | TeLink ok, set crc/cksm | XS2 | |-----+----------+-------------------------+-------------------------+-----| | XS1 | WaitStart| 1 over 40-60 seconds | report sender timeout | exit| | | | 2 over 20 tries | report send failed | exit| | | | 3 NAK received | set checksum mode | XS2 | | | | 4 "C" recd, I can crc | set crc mode | XS2 | | | | 5 "C" recd, I can't crc | | XS1 | |-----+----------+-------------------------+-------------------------+-----| | XS2 | SendBlock| 1 more data available | send next data block | XS3 | | | | | as checksum or crc | | | | | 2 last block has gone | send EOT | XS4 | |-----+----------+-------------------------+-------------------------+-----| | XS3 | WaitACK | 1 10 retries or 1 minute| report send failed | exit| | | | 2 ACK received | | XS2 | | | | 3 NAK (or C if 1st blk) | resend last block | XS3 | |-----+----------+-------------------------+-------------------------+-----| | XS4 | WaitEnd | 1 10 retries or 1 minute| report send failed | exit| | | | 2 ACK received | report send successful | exit| | | | 3 NAK received | resend EOT | XS4 | `-----+----------+-------------------------+-------------------------+-----' XMODEM/TeLink Receiver .-----+----------+-------------------------+-------------------------+-----. |State| State | Predicate(s) | Action(s) | Next| | # | Name | | | St | |-----+----------+-------------------------+-------------------------+-----| | XR0 | RecStart | 1 prefer crc mode | Send "C" | XR1 | | | | 2 want checksum mode | send NAK | XR1 | |-----+----------+-------------------------+-------------------------+-----| | XR1 | WaitFirst| 1 10 retries or 1 minute| report receive failure | exit| | | | 2 > 3 retries or 30 secs| set want checksum mode | XR0 | | | | | 3 EOT received | delay < sec, purge input| exit| | | | | | send ACK, report no file| | | | | 4 TeLink block recd | send ACK, set crc/cksm | XR2 | | | | 5 data block recd | send ACK, set crc/cksm | XR2 | | | | 6 bad block or 2-10 secs| incr retry count | XR0 | |-----+----------+-------------------------+-------------------------+-----| | XR2 | WaitBlock| 1 10 retries or 1 minute| report receive failure | exit| | | | 2 EOT received | send ACK, report recd ok| exit| | | | | | send ACK, report recd ok| | | | | 3 data block received | send ACK | XR2 | | | | 4 bad block or 2-10 secs| send NAK, incr retry cnt| XR2 | `-----+----------+-------------------------+-------------------------+-----' A number of checks should be made to ensure a valid data block has been received. o The physical layer should have encountered no errors, e.g. parity, framing, etc. o The length of the block should not be less than expected. o If the blocks sequence number does not match the complement, then respond with a NAK and attempt to read the block again. o If the block's sequence number is one previous (remember wrap around) to that of the expected block, respond with an ACK and read again. o If the sequence number fits neither of the above criteria, and is yet not the expected sequence number, abort the receive. o The checksum or CRC should be correct. 3. Data Link Layer Protocol : MODEM7 Filename Finite State Machines 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 | | | | (note 1) | 3 C received | return fn skipped | exit| |-----+----------+-------------------------+-------------------------+-----| | 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| | | | 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| | | | 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 one second timeouts are used successfully by Fido and SEAdog, some fear that this is too small a timeout for some satellite and packet network links. | Note 1 - MS0.3 is a common addition to accommodate a common noncompliance. | Support of MS0.3 is optional for a compliant mailer. This hack | also requires modification of a number of state tables, see | FSC-0011. H. Physical Layer : the Actual Connection of Two FidoNet Systems Will one of the more hardware-oriented comm types give me some idea of what's needed here? Can we leave it open enough to allow implementation over a non-dial net? Thanks. |I. The Node List - see FTS-0005 J. Tests to Validate an Implementation o It would be ideal if validation were automatic o Implementors could use in last stages of development o Program(s)? Test scripts? Remote Fidos? Bad line conditions? |K. Revisions since FTS-0001 89 Oct 25 o packet header: optional serialNo, password, and orig/dest zone o stored message to/from zone/point info added as option per Fido-12 o XR1 and XR2 changes per FSC-0011 o reference to FSC-0011 for the MODEM7-avoidance hack, MS0.3 o dropped enumeration of product codes o S4 modification from FSC-0011 o Nodelist and EID reference appropriate documents o various cosmetics | 90 July 1 - 5 | o spelling errors caught by Ray Gardner | o references to the now dead IFNA deleted | o offset at end of Packed Message was 10 as opposed to 20 bytes | o Packed Message and Packet Header corrections by Roland Gautschi | o Offsets in TeLink header caught by Rick Moore L. Acknowledgements Ben Baker, Thom Henderson, Tom Jennings, and Gee Wong suggested, informed, reviewed, and encouraged. Thom and Tom gave me all the basics, and even allowed me to look at actual code. Bob Hartman was foolish enough to implement the specification, and was generous with | useful feedback. Ray Gardner caught my spelling errors <blush>, and | Roland Gautschi and Rick Moore found offset and length errors. My employer, Pacific Systems Group was kind enough to donate my time to research and to write this document. Fido and FidoNet are registered trademarks of Tom Jennings. SEAdog is a trademark of System Enhancement Associates. M. Bibliography Documentation for the protocols and data formats are scattered. Some are unattributed, some even untitled. Filenames indicate that softcopy is available from Fido 122/6 and likely many others. | Anonymous, changes to MODEM to implement CRC option XMDM-CRC.TXT Baker, Ken and Moore, Rick, Nodelist Definition, currently FTS-0005 Christensen, Ward, "MODEM Protocol Overview" of 1 January 82 XMODEM.TXT Hartman, Bob, "Some thoughts that I had on FSC001", FSC-0011 Henderson, Thom, "SEAdog Electronic Mail System Version 3" of April 86 International Standards Organization, "Data Processing - Open Systems Interconnection - Basic Reference Model" ISO/DIS 7498 April 82 Jennings, Tom, "FidoNet Electronic Mail Protocol" 8 February 85 FIDOMAIL.DOC Jennings, Tom, "Fido's Internal Structures" of 13 September 85 STRUCT.TXT aka STRUCT.APX Jennings, Tom, "Extending XMODEM/MODEM File Transfer Protocol to support DOS" 20 September 83 FILEXFER.DOC Jordan, Larry, "XMODEM File Transfer Protocol" XMDM-LJ.TXT Rudin, H and West, C, "Protocol Specification, Testing, and Verification, III" Proceedings of the IFIP WG 6.1 Third International Workshop on Protocol Specification, Testing, and Verification, Rueschlikon Switzerland 31 May - 2 June 1983. Tanenbaum, Andrew, "Computer Networks" Prentice Hall 1981 Messages generated by Fido 11w, SEAdog 3.8, and ARCmail 0.37