********************************************************************** FTSC FIDONET TECHNICAL STANDARDS COMMITTEE ********************************************************************** Publication: FRL-1029 Revision: 1 Title: Serial number allocation in Mesage IDs Author(s): Administrator Date: 2014-10-26 ---------------------------------------------------------------------- Status of this document ----------------------- This document is a Fidonet Reference Library Document (FRL) This document preserves FSP-1029.001 which was not considered for promotion to a standard for lack of gaining widespread use. 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-1029 Revision: 1 Tit1e: Serial number allocation in Mesage IDs. Author(s): Michiel van der Vlist Revision Date: 7 February 2004 Review Date: 7 February 2005 ---------------------------------------------------------------------- Contents: 0. Status of this document. 1. Introduction. 2. The problem. 3. The solution. 4. The standard. 4.1 The serial number file. 4.2 Name and path of the serial number file. 4.3 Issuing numbers using the serial number file. 4.4 Upon successful open and lock. 4.5 Upon failure to open the serial number file. 4.6 Upon failure to obtain a lock. 4.6 A note on "increasing by at least one". 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 --------------- FTS-0009 mandates that serial numbers used in FTN Message IDs be unique on a given system within a period of three years. FTS-0009 does not mandate any particular way to achieve this goal. It does not even offer suggestions, It leaves it entirely to the implementation. This has led to software developers using a variety of methods, using the system clock is the most popular, but random number generators and checksums over the message header and/or body are also used. 2. The Problem -------------- The problem is that none of the above mentioned methods is really satisfactory as it can not guarantee that no duplicate message IDs will be issued. Issuing duplicate message ID's is undesirable as echomail processors and netmail trackers may discard or quarantine messages as dupes. Using the system clock was good enough when computers were slow and single tasking. With computers getting faster, only issuing a new serial number every second however is too coarse. Fast systems can create tens if not hundreds of messages a second. Using a finer scale, i.e. hundreds of a second or even thousands only shifts the problem to the future. Some day we shall see systems that can spew out more than one message in a millisecond. Multitasking systems have worsened the problem. Not only can one application give out the same number twice, Another application running in another task may give out that same number as well! Using random number generators and/or checksums is simply wrong. There is just no guarantee no duplicates will occur. It is roulette, Some day the same number will come up again. 3. The Solution --------------- The obvious solution is to use some sort of "sequencer" that is shared by all applications running on a given system that issue message ID's. The idea is simple, it is the same as drawing a "ticket" from the ticket dispenser in the Post Office. No two tickets in the machine have the same number and only one customer can draw a ticket at the time. If the machine is busy dispensing a ticket to a customer, the next customer has to wait. This way it is ensured that no two customers get the same number. There are many ways to implement the equivalent of such a system for FTN serial numbers, but it will only work properly if all applications use the same method. Hence the need for a standard. 4. The standard --------------- 4.1 The serial number file. The serial number file is an ASCII text file with the first line containing exactly eight characters in the range 0-9, a-z and A-Z. They represent a 32 bit hexadecimal number. Leading zeros may not be omitted. The eight character line may optionally be terminated by a line terminator. The file may contain additional lines containing additional informa- tion, thus making it possible to use this file for supplemen- tary future standards. Applications issuing serial numbers according to this proposed standard shall only consider the first eight bytes of the serial number file. 4.2 Name, extension and path of the serial number file. The default name and extension of the serial number file shall be MSGIDNR.NXT. It is recommended that the name and extension be configurable. The path pointing to the file MUST be configurable. For ease of configuration it is strongly recommended that the implementation supports reading the path from the environment variable SERNRPATH. 4.3 Issuing serial numbers using the serial number file. An application needing to issue a serial number for a message ID shall attempt to open the serial number file and lock the first 8 bytes of it. 4.4 Upon successful open and lock. On a successful lock it shall read the 32 bit hexadecimal number from the file and use that as the next serial number to be issued. After having issued this number it shall increase the serial number by at least one and use that for the next serial number. When the programme is done issuing serial numbers, it shall write the last issued serial number increased by at least one to the serial number file and release the lock. Alternatively if more than one serial number is to be issued in one run, the programme may write the next to issue serial number to the file, close and unlock it; and open, lock and read it again between issuing serial numbers so that other applications can obtain a serial number in the meantime. 4.5 Upon failure to open the serial number file. Upon failure to open the file because it does not exist, the application shall attempt to create it. What method is used to "seed" the serial number generator is up to the implementation. The system clock might be a good suggestion, but this document shall not attempt to mandate any particular method. 4.6 Upon failure to obtain a lock. Failure to obtain a lock normally means another application has locked the file. The logical course of action would be to wait for the lock to clear and retry. Limiting the time to a maximum before aborting and/or supplying a user abort option are at the discretion of the implementation. Another reason for failure to obtain a lock can be that the application is running on a single tasking system that does not support file sharing and locking. (F.e. plain DOS, SHARE not loaded.) If the application is aware of being run in a single tasking environment, either by autodetect or by a configuration switch, it can of course skip the locking and just read and update the sequence number file. 4.6 A note on "increasing by at least one". Simply starting at zero and increasing the serial number by one for each number issued would be perfectly valid and satisfy FTS-0009. That is, provided all applications running on a given system were to use this method, use the same serial number file and the serial number file is never lost. In practise these ideal condition may not be met so using a more sophisticated method of increasing the serial number than just increasing it by one may be preferred. Using the system clock to prime the number generator in case the serial number file is absent and to use the larger value of the system clock and the last number incremented by one for the next number may give reasonable insurance against the loss of the serial number file. 5. References ------------- [FTS-0009] A standard for unique message identifiers and reply chain linkage. Jim Nutt, 17 Dec 1991. [FSC-0083] A proposed standard for message IDs on FTN systems. Jonathan de Boyne Pollard. 17 June 1995. 6. Contact Data --------------- Michiel van der Vlist Fidonet: 2:280/5555 E-mail: pa0mmv@vrza.org History ------- Rev.1, 20040206: Initial Release. Principal author Michiel van der Vlist. ********************************************************************** ================= End Original Document ============================== Contact Data ------------ FTSC Administrator Fidonet: 2:2/20 E-mail: administrator@ftsc.org History ------- Rev.1, 2014-10-26: Initial release.