| Document: FSC-0062
| Version: 003
| Date: April 14, 1996
| Author: David J. Thomas
A Proposed Nodelist flag indicating Online Times of a Node
David J. Thomas
2:442/600@fidonet.org
Status of this document:
This FSC suggests a proposed protocol for the FidoNet(r) community,
and requests discussion and suggestions for improvements.
Distribution of this document is unlimited.
Fido and FidoNet are registered marks of Tom Jennings and Fido
Software.
Note
----
Changes in content between the previous edition of this document, and this
edition, are signified by bars (|) in the left margin, except where
otherwise specified. I have changed the format of the document slightly to
allow this. Where the format of the document has changed, but the actual
text has not, bars are not present.
Purpose
-------
There are currently several systems within FidoNet that offer file request
or mail holding capabilities but are not continuously online. The only time
during which these nodes can be contacted with reference to the nodelist is
currently the Zone Mail Hour of the zone to which the systems belong. In
theory, mailers can only use the zone mail hour(s) specified by the system
in question to contact these nodes, which does not provide for any method
of file requesting or calling for echomail that does not conflict with the
Policy requirement that no echomail or files be transferred during the zone
mail hour. This means that, in practice, if it is known that a particular
node is online for more time than ZMH alone, but less than 24 hours a day,
it is necessary to "kludge," or set this up as a special situation, in most
mailers whenever a node has to be contacted a number of times, whether
regularly or irregularly. The proposed flag would benefit the mailers in
such a way as to provide for them the online times that the node is usually
online for, thus cutting on the costs of calling a non-continuous mail
node, only to find that it is not available; and also, hopefully preventing
annoyance for a sysop whose mailer is being called whilst it is not online,
for example in the case of a voice/data shared line.
Compatibility
-------------
Since the current nodelist format is always being extended and nodelist
processors look only for the flags that they know about, there are no
expected compatibility problems with the suggestion outlined below.
Format of additional nodelist flag
----------------------------------
The proposed nodelist flag has the following form:
Txy
where x represents the startup time, and y the end time, in the following
format:
+------+----+ +------+----+ +------+----+ +------+----+ +------+----+
|Letter|Time| |Letter|Time| |Letter|Time| |Letter|Time| |Letter|Time|
+------+----+ +------+----+ +------+----+ +------+----+ +------+----+
| A |0000| | F |0500| | K |1000| | P |1500| | U |2000|
| a |0030| | f |0530| | k |1030| | p |1530| | u |2030|
| B |0100| | G |0600| | L |1100| | Q |1600| | V |2100|
| b |0130| | g |0630| | l |1130| | q |1630| | v |2130|
| C |0200| | H |0700| | M |1200| | R |1700| | W |2200|
| c |0230| | h |0730| | m |1230| | r |1730| | w |2230|
| D |0300| | I |0800| | N |1300| | S |1800| | X |2300|
| d |0330| | i |0830| | n |1330| | s |1830| | x |2330|
| E |0400| | J |0900| | O |1400| | T |1900| | | |
| e |0430| | j |0930| | o |1430| | t |1930| | | |
+------+----+ +------+----+ +------+----+ +------+----+ +------+----+
| This flag is not intended to be a user flag. The flag is intended to provide
| information to computerised mailer processes, and is not easily read by
| human beings (although they can of course interpret the meaning of the
| flag); most mailers however do not attempt to interpret any information that
| is specified as a user flag, assuming that it is there for the benefit of
| human beings. Such mailers would not be able to make use of the information
| provided, which is the purpose of the flag.
| This flag is of course not specified in FTS-0005 at the time of writing, but
| this is not regarded by FidoNet as a problem because other flags in current
| use are not specified in FTS-0005.
The case of the letter could be relevant. Whereas the case is currently not
used by any flags in the document describing the current format of the
nodelist, there exists the potential for the case of a letter to have
relevant meaning. The case has to be correct for the CRC check calculation
to prove correct, and this would be a good use for the case of the letter.
If it is necessary to ignore the case, then the upper on-the-hour time
should be used, i.e. the time that is listed after the upper-case letter.
| These times are expressed in UTC so that the flag is useful for systems all
around the world, without the need for specific time zone information to be
included in the nodelist. They do not adjust with daylight saving time for a
similar reason. Note the section on daylight saving time for information
about handling adjustments without changing the flag; this is important.
Where necessary, the times can wrap around midnight, so for example, for a
| node that is online between the hours of 1800 and 0600 UTC, the flag TSG
would be a valid indication of this time.
This nodelist entry is not required by any node. It is supplementary to the
#01, #02, #08, #09, #18, #20 flags and their !xx counterparts, though its
meaning is different. It has been suggested to me about the possibility of
an additional flag with the same meaning, but having a W as the first
letter, indicating that the node is also available for all hours during
weekends; however, I believe that the simple inclusion of the single flag
indicated above will solve most problems, as it does indicate a period for
non-CM nodes during which the node is available, which is all that is
really required.
Daylight saving time
--------------------
If a node changes online times with respect to UTC when daylight saving
time becomes effective (which would be the case with most part time nodes),
then this is to be taken into account when assigning this flag. An online
times flag assigned to a node should not be altered for the specific
purpose of adjusting due to daylight saving time, since large difference
files (NODEDIFF's) would result if every node was allowed to do this, e.g.
my node used to be online from 2300 to 0800 in local time, which in winter
| is UTC, but in the summer it becomes BST (British Summer Time). This is one
| hour ahead of UTC, and the corresponding availability times of my node
| during the summer period were 2200 to 0700 UTC. Therefore my online times
flag would have indicated availability between the hours of 2300 and 0700
| UTC, the daily time period encompassing both times, so the flag would be
TXH.
Policy considerations
---------------------
This is a technical document. However, since the flag could make for an
increase in the size of difference files, the author feels that the
following guidelines should be adopted concerning the use of the flag.
The online times flag does not replace the requirement for exclusivity of
zone mail hour to be maintained. It is still annoying behaviour to have
this flag and be unavailable during ZMH, just as it is annoying behaviour
to have the CM (continuous mail) flag in one's entry, and disregard ZMH.
Except for during ZMH, the sysop of a node using this flag finding that
they need to take their mailer offline during the specified times to
perform system maintenance, or for any other reason, would not be acting in
an annoying manner to do so, unless the practice is found to be continuous,
in which case the flag's times could be reduced, or the flag itself could
be removed from their node entry.
It should be noted that this flag is present for the benefit of mailers,
not human beings. This means that the flag should be used only to indicate
when a mailer is ready to receive calls. A system that uses a FidoNet-
technology mailer in ZMH, and a human-access only system during other
period(s) of the day that cannot receive mail, should not use this flag.
This flag does not explicitly specify online times of a public access BBS,
although for presumably most nodes with FidoNet-capable software, a public
access BBS will be available during the times indicated.
Where the flag is used, it should not often be changed. If a situation
exists, for example, where a node uses a certain set of times during the
first two weeks of a month, and a different set of times during the
remainder period, the flag should be set to a time during each day of the
month when the node is online. For example, if a node is online during
1800-0800 for the first two weeks, and then during 2200-1000 for the
remainder, the time flag should specify 2200-0800 only. If there is no such
time (other than ZMH) then no flag should be used. Of course, any permanent
changes, and any necessary reductions in the times, should be permitted at
any time, but changes owing only to daylight saving time should certainly
be expressly forbidden.
File requests and user access are of course permitted during the online
times indicated (except ZMH).
The above list may seem rather frightening! Please note that they are
guidelines rather than rules, unless FidoNet policy has included them as
rules. In the vast majority of situations where a node is online for a
fixed set of hours per day, the only thing to watch out for is that you get
the daylight saving time period right. Then you don't have to worry about
changing it at any time, except when your own online times change.
Example
-------
With regard to time zones now; this is a complicated topic, so I wish to
express an example. Imagine a node in Indiana, USA. It is online for the
time period beginning 6 o'clock pm (1800) and ending 8 o'clock am (0800).
This changes with daylight saving time, so the times expressed effectively
| become an hour earlier with respect to UTC during daylight saving time.
| Indiana is in the Central time zone, which is 6 hours behind UTC. Therefore,
| the online times in UTC can be expressed as 0000-1400 UTC during winter.
| During daylight saving time, however, the local time for Indiana is 5 hours
| behind UTC. The online times during this period are 0100-1500 UTC. The
| subset should be used, so that the online times flag for the node should
| indicate availability between 0100 and 1400 UTC, which is indicated
| by the flag TBO.
| (Thanks to a few people for pointing out that the previous example was in
| error; it assumed that Indiana was ahead of UTC, and not behind as is
| actually the case.)
ANSI C routines to Calculate the Online Times Flag
--------------------------------------------------
These were not provided in the first edition. Change bars will not be used
here, since they would interfere with the syntax of the presented routines.
The first program calculates the online times flag from the user's entry of
the online times of a system, expressed in the local time zone, and the
offset to UTC used by the user's country. It takes into account that the
clock is put forward and back once a year by reducing the end time by one
hour. The program should work on any platform, and has been tested.
=== start of code ===
/* TIMEFLAG.C
Calculates FSC-0062 time flag requirement from user input */
#include
char *onlineflag(char *on, char *off, int utc_diff);
void main()
{
char on[6], off[6]; int utc_diff;
printf("\nPlease specify the time you come online [HH:MM]: ");
scanf("%s", on);
printf("\nPlease specify the time you come offline [HH:MM]: ");
scanf("%s", off);
printf("\nSpecify the difference between your local time zone in winter\n"
"time and UTC (e.g. if your time zone is 6 hours behind UTC,\n"
"enter 6): ");
scanf("%d", &utc_diff);
printf("\nYour online time flag is %s\n\n",
onlineflag(on, off, utc_diff));
}
char *onlineflag(char *ontime, char *offtime, int utcdiff)
{
int onhour, onmin, offhour, offmin;
static char flag[4]="T ";
sscanf(ontime, "%d:%d", &onhour, &onmin);
sscanf(offtime, "%d:%d", &offhour, &offmin);
if(onmin>30) ++onhour;
--offhour; /* to correct for daylight saving time */
onhour = (onhour+24+utcdiff) % 24;
offhour = (offhour+24+utcdiff) % 24;
flag[1]='A'+onhour;
flag[2]='A'+offhour;
if(onmin>0 && onmin<31) flag[1] += 'a'-'A';
if(offmin>29) flag[2] += 'a'-'A';
return flag;
}
=== end of code ===
The second program calculates the online times from the time flag, input
as a pointer to char to the routine (this being of the format "Txy"). It
returns a pointer to a structure which contains the on- and off-times in
UTC. This is not a complete program; it is designed to be used by mailers
to determine the valid online times. It has also been tested.
=== start of code ===
/* INTFLAG.C
Interprets online time flags and converts them to a set of UTC times */
struct TIMES {
int on_hour;
int on_min;
int off_hour;
int off_min;
};
struct TIMES *interpret_flag(char *time_flag);
struct TIMES *interpret_flag(char *timeflag)
{
static struct TIMES times;
times.on_min=0;
times.off_min=0;
times.on_hour=timeflag[1]-'A';
if(times.on_hour>23) {
times.on_hour -= 'a'-'A';
times.on_min=30;
}
times.off_hour=timeflag[2]-'A';
if(times.off_hour>23) {
times.off_hour -= 'a'-'A';
times.off_min=30;
}
return ×
}
=== end of code ===
| The above routines can be copied and re-used as desired. I am now an
| amazing C programmer, but I still make no guarantees about them! :-)
Summary
-------
I believe this to be a neat and compact solution to, what is in my opinion,
one of the gravest problems currently facing FidoNet. In FidoNet, most
nodes are continuous mail, but it is important for the growth and
popularity of FidoNet that non-CM nodes do not receive many mailer calls at
times when they are off line. Users are bad enough in this respect. It is
also useful for people wishing to contact hubs that are non-CM with mail
for a downlink, and for people wishing to file request from a node that is
not CM. There is no need for systems that are only online in zone mail hour
to adopt this flag; also, there is no need for CM systems to adopt this
flag.
Contacting the Author
---------------------
My board is now online continuously, except for periods of down time during
| which the board is maintained (few and far between now that Linux is used).
Netmail contact is therefore possible at any time. I went CM because of a
certain number of nodes calling at the wrong times, and also users. Users
weren't too bad, but I dislike 0600 am wake-up calls, repeated at regular
three-minute intervals for an hour, by mailers, rather intensely :-)
End of document.
Go Back