365 lines
16 KiB
HTML
Executable File
365 lines
16 KiB
HTML
Executable File
<HTML>
|
|
<!-- $Id$ -->
|
|
<HEAD>
|
|
<TITLE>A Proposed Nodelist flag indicating Online Times of a Node.</TITLE>
|
|
</HEAD>
|
|
|
|
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
|
<BODY
|
|
BGCOLOR="#FFFFFF"
|
|
TEXT="#000000"
|
|
LINK="#0000FF"
|
|
VLINK="#000080"
|
|
ALINK="#FF0000"
|
|
>
|
|
<PRE>
|
|
| 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 <stdio.h>
|
|
|
|
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.
|
|
</PRE>
|
|
|
|
<A HREF="index.htm"><IMG SRC="../images/b_arrow.png" ALT="Back" Border="0">Go Back</A>
|
|
|
|
</BODY>
|
|
</HTML>
|
|
|