FRL-1034.TXT
Advanced BinkleyTerm Style Outbound flow and control files.
**********************************************************************
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
**********************************************************************
Publication: FRL-1034
Revision: 1
Title: Advanced BinkleyTerm Style Outbound flow and control
files.
Author(s): Administrator
Date: 2014-11-08
----------------------------------------------------------------------
Status of this document
-----------------------
This document is a Fidonet Reference Library Document (FRL)
This document preserves FSP-1034. It is, after some modifications,
promoted to an FTSC standard and released as FTS-5005.
This document is released to the public domain, and may be used,
copied or modified for any purpose whatever.
====================== Original document =============================
=========================== Original document ========================
**********************************************************************
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
**********************************************************************
Publication: FSP-1034
Revision: 1
Tit1e: Advanced BinkleyTerm Style Outbound flow and control
files.
Author(s): Igor Romanovsky
Revision Date: 22 Jule 2005
Review Date: 22 Jule 2006
----------------------------------------------------------------------
Contents: 0. Status of this document.
1. Introduction.
2. Definitions.
3. Flow files.
4. Control files.
5. References.
6. Contact Info.
----------------------------------------------------------------------
0. Status of this document
--------------------------
This document is a Fidonet Standards Proposal (FSP).
This document proposes a Fidonet standard for the Fidonet
community.
This document is released to the public domain, and may be used,
copied or modified for any purpose whatever.
1. Introduction
---------------
BinkleyTerm Style Outbound (BSO) flow and control files are used
for a long time but still are not documented fully. This has led
to software developers using a different approaches that makes
change of mailer on FTN station rather sophisticated. This document
combines original ideas, introduced by by Vince Perriello and Bob
Hartman (BinkleyTerm), and Andy Elkin (T-Mail).
2. Definitions
--------------
Flow file - a file with specific name and various extension that
contains extension specific information to be sent to remote side.
Control file - same as flow file but usually does not contain any
information inside. Its purpose to control behavior all software
dealing with BSO. Reduced flow file (file does not contain any
information inside or zero length) also may be considered as control
file.
Outbound directory (outbound) - directory, were flow and control
files are stored.
Name of flow file is formed from network and node number of remote
system, expressed as 4 hexadecimal digits each, zero-padded on the
left. Thus information concerning to node 104/36 is stored in flow
and control files with name "00680024" with different extension.
Hexadecimal digits must be lower case if it is supported by OS file
system.
For supporting point systems in outbound is created sub-directory
with name "<nff>.pnt", where <nff> - name of flow file as described
above. In this directory flow and control files is 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 "00680024.pnt" in flow and control files with name
"0000002d" with different extensions. "pnt" must be lower case if it
is supported by OS file system.
For supporting communications with systems from a different zone the
number of directories are created with same generic name chosen
arbitrary and quasi extension equal to zone number expressed as 3
hexadecimal digits zero-padded on the left. If zone number > 4095
then 4 hexadecimal digits are used in quasi extension. The last can
be implemented *only* on modern OS. Thus information concerning to
node 2:104/36 is stored in directory "outbound.002" in flow and
control files with name "00680024" with different extensions.
"outbound" is assumed to be generic name. The last must be lower
case if it is supported by OS file system.
Any zone number may be chosen as own zone number. In this case
directory with generic name without quasi extension is functionally
equal to directory with quasi extension equal to own zone number.
If we consider node 1:234/5, own zone is 1 for it, 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".
Restrictions in term of this document are time intervals when there
is not desirable to call remote system. Restrictions may be external
introducing 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. Address of remote system and name of this file has
one-to-one correspondence. They are divided by type and flavour.
The extension must be lower case if it is supported by OS file
system.
3.1. Types of flow file
There are 3 types of flow files: netmail, file reference, file
request.
Netmail flow files are a FTS-0001 packet containing packed
netmail as described in FTS-0001. This flow file has
signature "ut" as 2nd ant 3rd letters in extension. During
session this file must be renamed dynamically at the moment
of sending to remote system with unique name and extension
"pkt". Method of creating unique name is implementation
dependent.
This file must be transferred to remote system at any successful
session. Would session terminated accidentally during sending
this file it must be resent in next session from the
beginning. After successful transmission file must be deleted
from outbound.
Reference files consist of number of lines (terminated by 0x0a
or 0x0d,0x0a) which consist of one char directive followed by
name file to transfer to remote system. It has signature "lo"
as 2nd ant 3rd letters in extension.
There are 4 directives in reference file.
" " (space) or absent any listed below - just send file
indicated in line. If file name to send starts with "#" or "!"
first char must be space.
"#" - truncate the indicated file 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 sending.
"!" - skip the line from treatment. It may be useful to mark
already processed line.
If indicated file name does not contain symbols, showing
presence of a path in file name, it may be located in same
with flow files directory. Sysop must avoid ambiguity in this
case. If a file is not found, software must ignore the line and
continue processing.
Would mailer send or not files listed in reference file during
the successful session depends on flavour of reference file.
After successful transmission of listed files flow file must be
deleted from outbound. (But see below.) Would session
terminated accidentally during sending listed files, flow file
must be processed in next session from the beginning.
File request has signature "req" as extension. Information in
request file is described in FTS-0006. File request has direct
flavour with possible additional restriction specific to file
request. Normally this file is deleted after receiving
requested files.
Reduced request file has no meaning and must be ignored.
3.2. Flavours of flow file
Flavour of flow file controls mailer's behavior. It can
initiate poll to remote system. Especially it is useful with
reduced flow file. Creating such flow file may force mailer to
do action that is not specified in normal mode of operation.
It is recommended to use as reduced flow file only reference
files and use method of "touch", creating new file if absent
or change file date to current if one exists. Difference in
mailer behavior for flow and reduced flow file is decribed
later.
There are 5 flavours.
Immediate has "i" as 1st char in extension. Thus full
extension of netmail file is "iut" and for reference file is
"ilo". If flow file with such flavour exists mailer must try to
poll remote system without taking in consideration external and
internal restrictions, just immediately. During successful
session files listed in "ilo" file must be sent to remote
system. It is assumed, that information mentioned in "iut" and
"ilo" may be sent to the specific system only. Very often
reduced form is used only for making poll.
Continuous has "c" as 1st char in extension. Thus full
extension of netmail file is "cut" and for reference file is
"clo". If flow file with such flavour exists mailer must try to
poll remote system taking in consideration internal restriction
but not external (assuming that remote system has CM flag).
During successful session files listed in "clo" file must be
sent to remote system. It is assumed, that information
mentioned in "cut" and "clo" may be sent to the specific system
only. During session information in continuous flow file is
transmitted after one in immediate flow file. Very often
reduced form is used only for making poll.
Direct has "d" as 1st char in extension. Thus full extension of
netmail file is "dut" and for reference file is "dlo". If flow
file with such flavour exists mailer must try to poll remote
system taking in consideration both external and internal
restrictions. During successful session files listed in "dlo"
file must be sent to remote system. It is assumed, that
information mentioned in "dut" and "dlo" may be sent to the
specific system only. During session information in direct flow
file is transmitted after one in continuous flow file.
Normal has "o" as 1st char in extension for netamil and "f" for
reference file (using of "n" is considered as outdated). Thus
full extension of netmail file is "out" and for reference file
is "flo". If flow file with such flavour exists mailer must try
to poll remote system taking in consideration both external and
internal restrictions. During successful session files listed
in "flo" file must be sent to remote system. It is assumed,
that information mentioned in "out" and "flo" may be rerouted
by specific programs (such as netmail tracker) to another
system. During session information in normal flow file is
transmitted after one in direct flow file.
Hold has "h" as 1st char in extension. Thus full extension of
netmail file is "hut" and for reference file is "hlo". Flow
file with such flavour instructs mailer wait a poll from remote
system. During successful session files listed in "hlo" file
must be sent if originating is remote system. Sending files
listed in "hlo" file in case when originating is our system is
implementation dependent. It is assumed, that information
mentioned in "hut" and "hlo" may be rerouted by specific
programs (such as netmail tracker) to another system. During
session information in hold flow file is transmitted after one
in normal flow file.
3.3. Simple time chart.
Suppose our node has working hours from 21:00 till 09:00. Let
remote system has working hours from 17:00 till 07:00. Next
time chart indicates period, when poll is produced for different
flavours:
-------------------------------------------------------------------
|12|13|14|15|16|17|18|19|20|21|22|23|00|01|02|03|04|05|06|07|08|09|
-------------------------------------------------------------------
i |xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|
c |--|--|--|--|--|--|--|--|--|xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|--|
d |--|--|--|--|--|--|--|--|--|xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|--|--|--|
f |--|--|--|--|--|--|--|--|--|xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|--|--|--|
h |--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|
-------------------------------------------------------------------
3.4. Differences in flow and reduced flow files.
"Real" flow file means that system have a portion of
information to be sent but reduced flow file only expresses
desire to make poll.
Thus would mailer detects presence of flow file in directory it
must make a conclusion about is it real flow file or just
control file.
If it is real flow file mailer must make poll according its
flavour, send information to remote according type of flow
file and delete flow file after sending all information don't
waiting end of session.
Thus if session is terminated accidentally or specially by
sysop after sending flow file information mailer will return
in state without priority flow file in outbound.
If it is reduced flow file mailer must make poll according its
flavour. Mailer has nothing to send from control file and it
must delete flow file after successful end of session.
Thus if session is terminated accidentally or specially by
sysop during sending another information mailer will return
in state with priority flow file in outbound.
That is why it is not a good idea to lock flow files during
the session.
4. Control files
----------------
4.1. bsy (busy) control file
It is main control file that must be used by any software
dealing with flow files in BSO. It has name same as flow file and
extension ".bsy".
Any software must check this file before doing any changes
in flow files. If bsy-file exists all changes are prohibited
in any corresponding flow files. What a software have to do in
this case is implementation dependent.
If bsy-file does not exist software must touch this file,
ensure that it was successfully created, and work with flow
files. After ending of the job software must delete bsy-file.
During the session and before sending information from flow
files mailer creates the list of all AKAs presented by the
remote system. Then mailer must check bsy-files corresponding
to the list. If some bsy-file is detected corresponding AKA is
removed from the list. If all AKA are removed due to this
procedure, session must be terminated with appropriate
diagnostic message.
If bsy-file for the AKA is not present mailer must touch
them. bsy-file is created by mailer only after successful
connection with remote mailer.
After session - successful or not - mailer must delete all
touched bsy-files.
After restoring system due to crash it is recommended to do
simple routine to delete all bsy-files in all outbounds before
starting any software dealing with BSO.
It is also recommended to check the age of bsy-files. It is
reasonable to ignore and delete bsy-files with age more than
maximum estimated time of session multiplied on 2.
Appropriate diagnostic message may be produced in this case.
For information purpose bsy-file may contain one line PID
information (less that 70 characters).
4.2. csy (call) control file
This control file is created by mailer when it decides
to make poll to remote system. csy-file is valuable only for
another mailer working together on the same system. It has
name same as flow file and extension ".csy".
csy-files are created for all remote AKAs which is possible
to find out in mailer config.
Presence csy-file corresponding to any remote AKA indicates
that mailer must stop try to poll remote system regardless of
presence flow files.
After session - successful or not - and after unsuccessful try
mailer must delete all touched csy-files.
After restoring system due to crash it is recommended to do
simple routine to delete all csy-files in all outbounds before
starting any software dealing with BSO.
It is also recommended to check the age of csy-files. It is
reasonable to ignore and delete csy-files with age more than
maximum estimated time of session multiplied on 2.
Appropriate diagnostic message may be produced in this case.
For information purpose csy-file may contain one line PID
information.
4.3. hld (hold) control file
This control file is created by a mailer or other software
when it decides to stop trying poll remote system.
hld-file is valuable only for mailers. It has name same as
flow file and extension ".hld".
Existing hld-file is replaced by new one or edited.
hld-file must contain one line string with expiration of hold
period expressed in UNIX-time.
Presence hld-file corresponding to any remote AKA indicates
that mailer must check the content before trying to poll
remote system. If expiration time is in future mailer must
stop try to poll remote system regardless of presence flow
files.
Presence and content of hld-file must be checked before each
attempt to create poll.
If software finds out hld-file with expiration time in past,
it must delete such hld-file.
For information purpose second line of hld-file may contain one
line PID information.
4.3. try control file
This control file is created by mailer in time when try to
connect is finished - successful or not. It has name same as
flow file and extension ".try".
Existing try-file is replaced by new one.
try-file must contain one line string with diagnostic message.
It serves for information purpose only.
For information purpose second line of try-file may contain one
line PID information.
5. References
-------------
[FTS-0001] A Basic FidoNet(r) Technical Standard
Randy Bush, 30 Sep 95.
[FTS-0006] YOOHOO and YOOHOO/2U2
Vince Perriello, 30 Nov 1991.
T-Mail. Reference Manual
Andy Elkin, 1997.
BinkleyTerm. Reference Manual
1987-1996 Bit Bucket Software, Co.
6. Contact Data
---------------
Igor Romanovsky
Fidonet: 2:5022/60
E-mail: Igor.Romanovsky@tula.net
History
-------
Rev.1, 20050722: Initial Release.
Assigned FSP-1034.
**********************************************************************
================= End Original Document ==============================
Contact Data
------------
FTSC Administrator
Fidonet: 2:2/20
E-mail: administrator@ftsc.org
History
-------
Rev.1, 2014-11-08: Initial release.