Text 22254, 331 rader
Skriven 2015-03-30 00:35:42 av FidoNews Robot (2:2/2.0)
Ärende: FidoNews 32:13 [02/08]: Ftsc Information
================================================
=================================================================
FTSC INFORMATION
=================================================================
Publication: FTS-5005
Revision: 2
Title: Advanced BinkleyTerm Style Outbound flow and control
files.
Authors: Igor Romanovsky
Administrator and FTSC members
Date: 2015-03-29
----------------------------------------------------------------------
Contents: 0. Status of this document.
1. Introduction.
2. Definitions.
3. Flow files.
4. File Requests
5. Control files.
A. References.
B. Contact Info.
C. History
----------------------------------------------------------------------
0. Status of this document
--------------------------
This document is a Fidonet Technical Standard (FTS) - it specifies
the current technical requirements and recommendations for FTN
software developers, coordinators and sysops of the Fidonet network
and other networks using FTN technology.
This document is released to the public domain, and may be used,
copied or modified for any purpose whatever.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in FTA-1006.
1. Introduction
---------------
BinkleyTerm Style Outbound (BSO) flow and control files have been
used for a long time but still are not fully documented. This has
led to software developers using different approaches that make
changing the mailer on a FTN station rather sophisticated.
This document combines the original ideas, introduced by Vince
Perriello and Bob Hartman (BinkleyTerm), and Andy Elkin (T-Mail).
2. Definitions
--------------
Filename case sensitivity - the case of the BSO filenames depends on
the OS file system. Lower case filenames are prefered if supported
by the file system. If the OS file system supports lower and upper
case filenames, the software should be able to handle both for
maximum compatibility. That behaviour might be controlled by a
configuration option.
Outbound directory (outbound) - directory where flow and control
files are stored. Outbound directory names will have the format
<path>[.zzz], for example F:\Mailer\Out.002\ for the zone 2
outbound.
Default Outbound - The Outbound directory for your zone. In this
case a directory generic name without a quasi extension is
functionally equal to a directory with a quasi extension equal to
your own zone number. If we consider node 1:234/5, the default
zone is 1, thus "outbound" and "outbound.001" are both valid
directories for storing flow and control files and it is recommended
to check both of them but create flow and control files only in
first, "outbound".
For supporting point systems an outbound sub-directory is created
with name "<nff>.pnt", where <nff> - name of flow file as described
below. In this directory flow and control files are created with
name formed from point number as 8 hexadecimal digits zero-padded
on the left. Thus information concerning to point 104/36.45 is
stored in subdirectory "outbound\00680024.pnt" in flow and control
files with the name"0000002d.*".
For supporting communications with systems from a different zone, a
number of directories are created with the same generic name chosen
for the default directory, plus a quasi extension equal to the zone
number expressed as 3 hexadecimal digits zero-padded on the left.
If the zone number > 4095 then 4 hexadecimal digits are used in
quasi extension. The last can be implemented *only* with a modern
OS. Thus information concerning node 2:104/36 is stored in directory
"outbound.002" in flow and control files with name "00680024.*".
"outbound" is assumed to be a generic name.
Domain Addressing - is an extended method of designating various
FTNs as compared with the zone-only method previously used. Domain
addressing adds an additional "layer" to address designation that
represents a particular FTN. Within that FTN, zones and nets can be
specified without conflicting with identical zones and nets in other
FTNs. Domain Addressing is only needed if you operate in two or more
Fido Technology Networks (FTNs) using the same Zone numbers, or you
wish to keep different Domains' compiled nodelists separate.
How should Outbound Areas be named when domains are used?
As always, the outbound area for your primary address (including
domain) is the default outbound.
Separate Outbound Areas are needed for each Zone in each Domain.
These take an identical stem path to the primary outbound, except
that the name of the last sub-directory is changed to the
<abbreviation> parameter, plus the zone extension.
For example, if your default outbound is C:\BINKLEY\OUTBOUND
for the outbound holding area (and you are in FidoNet), Alternet
(zone 7) outbound mail would be held in the C:\BINKLEY\ALTERNET.007
directory instead. Note that outbound areas for domains other than
your primary will ALWAYS have a zone extension, and that zone
extensions are always specified in Hexadecimal, up to .FFF (4095).
The outbound holding areas (for Zone 1 FidoNet) would then be as
follows:
c:\bink\outbound (Default Outbound)
c:\bink\outbound.002 (FidoNet Zone 2)
c:\bink\outbound.003 (FidoNet Zone 3)
c:\bink\outbound.004 (FidoNet Zone 4)
c:\bink\outbound.005 (FidoNet Zone 5)
c:\bink\outbound.006 (FidoNet Zone 6)
c:\bink\alternet.007 (Alternet Zone 7)
c:\bink\alternet.059 (Alternet Zone 89)
c:\bink\eggnet.063 (Eggnet Zone 99)
Flow file - a file with specific name and various extension that
contains extension specific information to be sent to remote side.
The name of flow file is formed from network and node number of the
remote system, expressed as 4 hexadecimal digits each, zero-padded
on the left. Thus information concerning node 104/36 is stored in
flow and control files with name "00680024" but with different
extension.
Control file - same as flow for file but usually does not contain
any information inside. Its purpose is to control behavior all
software dealing with BSO. A reduced flow file (file does not
contain any information inside or is of zero length) also may be
considered as a control file.
Restrictions - time intervals when it is not desirable to call the
remote system. Restrictions may be external, introduced, for example
by nodelist's information or internal due to economical or
organizational reasons.
3. Flow files
-------------
Flow files contain references to information to be sent to remote
system. The address of remote system and name of this file has
one-to-one correspondence. Flow files are divided by type and
flavour.
3.1. Types of flow file
There are 2 types of flow files: netmail, file reference.
Netmail flow files are an FTS-0001 packet containing packed
netmail as described in FTS-0001. This flow file has
signature "ut" as 2nd and 3rd letters in extension. During a
session this file must be dynamically renamed at the moment
of sending to a remote system with a unique name and extension
"pkt". The method of creating unique names is implementation
dependent.
This file must be transferred to the remote system at any
successful session. If the session is terminated accidentally
during sending, this file must be resent in the next session
from the beginning. After successful transmission this file
must be deleted from the outbound directory.
Reference files consist of a number of lines (terminated by
0x0a or 0x0d,0x0a) each consisting of the name of the file
to transfer to the remote system. It has signature "lo" as
2nd and 3rd letters in the extension.
The file name is optionally prefixed with a one character
directive that indicates what to do with the file after a
succesful transfer.
The following directives are documented as a standard:
"#" - Indicates that the files should be truncated to zero-
length after successfully sending the file to the remote
system. This is normally only employed when sending compressed
mail (archived mail) to the remote.
"^" - delete the file after successfully sending the file to
the remote system.
"~" - skip the line from treatment. It may be useful to mark
an already processed line.
<none> - indicates that the file should be sent and neither be
truncated nor deleted after sending. Listing the file with the
full path circumvents problems with files that have a name
starting with a character that is a known directive.
Software may optionally recognise the following directives:
"-" As an alternate for "^"
"!" As an alternate for "~"
"@" Send file, do not truncate or delete.
It is recommended that for maximum compatibility new implemen-
tations recognise the above directives as documented, but do
not use them when creating reference files.
If an indicated file does not show a path, the result depends
on the implementation. The implementation may assume that it
resides in the same directory as the flow file, the working
directory or some other directory. Also, programs running in
different tasks may make different assumptions about what is
the default directory. Therefore it is highly recommended to
always use the full path in reference files.
If a file is not found, software must ignore the line and
continue processing.
Whether the mailer does or does not send the files listed in
the reference file during the successful session depends on the
flavour of the reference file.
After successful transmission of the listed files the flow file
must be deleted from the outbound. (But see below.) Should the
session be terminated accidentally while sending the listed
files, the flow file must be processed in the next session from
the beginning.
3.2. Flavours of flow file
The flavour of a flow file controls mailer's behavior. It can
initiate a poll to a remote system. Especially it is useful
with a reduced flow file. Creating such a flow file may force
the mailer to execute actions that are not specified in normal
mode of operation.
It is recommended to use only reference files for reduced flow
files and to use the method of "touch"ing a file; creating a
new file if there isn't one already, or changing the file date
to current if there is a file already. The difference in mailer
behaviour for flow and reduced flow files is described later.
There are 5 flavours.
Immediate has "i" as the first char in the extension. Thus the
full extension of a netmail file is "iut" and for a reference
file is "ilo". If a flow file with such a flavour exists the
mailer must try to poll a remote system without taking in
consideration any external and internal restrictions. During a
successful session files listed in "ilo" file must be sent to
the remote system. It is assumed that information mentioned in
"iut" and "ilo" will be sent to the specific system. Very often
a reduced form is used only for making a poll.
Continuous has "c" as the first char in the extension. Thus
the full extension of netmail file is "cut" and for a reference
file is "clo". If a flow file with such flavour exists the
mailer must try to poll a remote system taking in consideration
internal restrictions but not external ones (assuming that the
remote system carries a CM flag). During a successful session
files listed in "clo" file must be sent to the remote system.
It is assumed that information mentioned in "cut" and "clo"
will be sent to the specific system. Very often a reduced form
is used for making a poll.
Direct has "d" as the first char in the extension. Thus the
full extension of a netmail file is "dut" and for a reference
file is "dlo". If a flow file with such flavour exists the
mailer must try to poll a remote system taking into considera-
tion both external and internal restrictions. During a success-
ful session files listed in "dlo" file must be sent to the
remote system. It is assumed that information mentioned in
"dut" and "dlo" will be sent to the specific system. Very often
a reduced form is used for making a poll.
Normal has "o" as the first char in extension for netmail and
"f" for a reference file (using of "n" is considered as
outdated). Thus the full extension of netmail file is "out" and
for a reference file is "flo". If a flow file with such flavour
exists the mailer must try to poll a remote system taking in
consideration both external and internal restrictions. During a
successful session files listed in "flo" file must be sent to
the remote system. It is assumed that information mentioned in
"out" and "flo" may be rerouted by specific programs (such as
a netmail tracker) to another system.
Hold has "h" as the first char in extension. Thus the full
extension of a netmail file is "hut" and for a reference file
is "hlo". A flow file with such flavour instructs the mailer
to wait for a poll from the remote system. During a successful
session files listed in "hlo" file must be sent if the remote
system is the initiator of the session. If the remote system is
not the initator of the session, it is implementation dependant
whether the files are send or not. It is assumed that informa-
tion mentioned in "hut" and "hlo" may be rerouted by specific
programs (such as a netmail tracker) to another system.
When flow files of more than one flavour are present for a
particular AKA of a remote system, they should be processed in
the following order:
Immediate ("iut" or "ilo")
Continuous ("cut" or "clo")
Direct ("dut" or "dlo")
Normal ("out" or "flo")
Hold ("hut" or "hlo")
3.3. Simple time chart.
Suppose our node has working hours from 21:00 till 09:00, and
the remote system has working hours from 17:00 till 07:00. This
time chart indicates when a poll would be produced for
different flavours:
--- Azure/NewsPrep 3.0
* Origin: Home of the Fidonews (2:2/2.0)
|