********************************************************************** 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 ".pnt", where - 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.