Fixed HTML codes in Fidonet documents
This commit is contained in:
Michiel Broek
@@ -1,414 +1,415 @@
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>Echomail Specification.</TITLE>
|
||||
</HEAD>
|
||||
|
||||
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
||||
<BODY
|
||||
BGCOLOR="#FFFFFF"
|
||||
TEXT="#000000"
|
||||
LINK="#0000FF"
|
||||
VLINK="#000080"
|
||||
ALINK="#FF0000"
|
||||
>
|
||||
<PRE>
|
||||
FTS-0004 EchoMail Specification
|
||||
|
||||
This document is directly derived from the documentation of
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
The Conference Mail System
|
||||
|
||||
By
|
||||
Bob Hartman
|
||||
Sysop of FidoNet(tm) node 132/101
|
||||
|
||||
(C) Copyright 1986,87, Spark Software, Inc.
|
||||
|
||||
427-3 Amherst Street
|
||||
CS 2032, Suite 232
|
||||
Nashua, N.H. 03061
|
||||
|
||||
ALL RIGHTS RESERVED.
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
version 3.31 of 12 December, 1987.
|
||||
|
||||
With Bob Hartman's kind consent, copying for the purpose of technological
|
||||
research and advancement is allowed.
|
||||
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
|
||||
WHAT IS THE CONFERENCE MAIL SYSTEM?
|
||||
|
||||
Conference Mail is a technique to permit several nodes on a
|
||||
network to share a message base, similar in concept to the
|
||||
conferences available on many of the computer services, but it is
|
||||
most closely related to the Usenet system consisting of more than
|
||||
8,000 systems world wide. All systems sharing a given conference
|
||||
see any messages entered into the conference by any of the
|
||||
participating systems. This can be implemented in such a way as
|
||||
to be totally transparent to the users of a particular node. In
|
||||
fact, they may not even be aware of the network being used to
|
||||
move their messages about from node to node! Unfortunately, this
|
||||
has its disadvantages also - most users who are not educated
|
||||
about Conference Mail do not realize the messages transmitted
|
||||
cost MANY sysops (system operators) money, not just the local
|
||||
sysop. This is an important consideration in Conference Mail and
|
||||
should not be taken lightly. In a conference with 100 systems as
|
||||
participants the cost per message can get quite high.
|
||||
|
||||
The Conference Mail System is designed to operate in conjunction
|
||||
with a FidoNet compatible mail server. The currently supported
|
||||
mail servers are Fido(tm), SEAdog(tm), Opus, and Dutchie. Since
|
||||
the mail server is a prerequisite to using the Conference Mail
|
||||
System, it will be assumed you already have your mail server
|
||||
operating correctly on your system, and you are connected into
|
||||
FidoNet or a compatible network.
|
||||
|
||||
|
||||
HISTORY OF THE CONFERENCE MAIL SYSTEM
|
||||
|
||||
In late 1985, Jeff Rush, a Fido sysop in Dallas, wanted a
|
||||
convenient means of sharing ideas with the other Dallas sysops.
|
||||
He created a system of programs he called Echomail, and the
|
||||
Dallas sysops' Conference was born.
|
||||
|
||||
Within a short time sysops in other areas began hearing of this
|
||||
marvelous new gadget and Echomail took on a life of its own.
|
||||
Today, a scant year and a half later, the FidoNet public network
|
||||
boasts a myriad of conferences varying in size from the dozen-or-
|
||||
so participants in the FidoNet Technical Standards Committee
|
||||
Conference to the Sysops' Conference with several hundred
|
||||
participants. It is not uncommon for a node to carry 30 or more
|
||||
conferences and share those conferences with 10 or more nodes.
|
||||
|
||||
|
||||
HOW IT WORKS
|
||||
|
||||
The Conference Mail System is functionally compatible with the
|
||||
original Echomail utilities. In general, the process is:
|
||||
|
||||
1. A message is entered into a designated area on a FidoNet
|
||||
compatible system.
|
||||
|
||||
2. This message is "Exported" along with some control information
|
||||
to each system "linked" to the conference through the originating
|
||||
system.
|
||||
|
||||
3. Each of the receiving systems "Import" the message into the
|
||||
proper Conference Mail area.
|
||||
|
||||
4. The receiving systems then "Export" these messages, along with
|
||||
additional control information, to each of their conference
|
||||
links.
|
||||
|
||||
5. Return to step 3.
|
||||
|
||||
As you can see, the method is quite simple - in general. Of
|
||||
course, following the steps literally would mean messages would
|
||||
never stop being Exported and transmitted to other systems. This
|
||||
obviously would not be desired or the network would quickly
|
||||
become overburdened. The information contained in the 'control
|
||||
information' section is used to prevent transmitting the same
|
||||
message more than once to a single system.
|
||||
|
||||
|
||||
CONFERENCE MAIL MESSAGE CONTROL INFORMATION
|
||||
|
||||
There are five pieces of control information associated with a
|
||||
Conference Mail message. Some are optional, some are not.
|
||||
Normally this information is never entered by the person creating
|
||||
the message. The following control fields determine how
|
||||
Conference Mail is handled:
|
||||
|
||||
1. Area line
|
||||
|
||||
This is the first line of a conference mail message. Its
|
||||
actual appearance is:
|
||||
|
||||
AREA:CONFERENCE
|
||||
|
||||
Where CONFERENCE is the name of the conference. This line is
|
||||
added when a conference is being "Exported" to another
|
||||
system. It is based upon information found in the AREAS.BBS
|
||||
(configuration) File for the designated message area. This
|
||||
field is REQUIRED by the receiving system to "Import" a
|
||||
message into the correct Conference Mail area.
|
||||
|
||||
2. Tear Line
|
||||
|
||||
This line is near the end of a message and consists of three
|
||||
dashes (---) followed by an optional program specifier.
|
||||
This is used to show the first program used to add Echomail
|
||||
compatible control information to the message. The tear line
|
||||
generated by Conference Mail looks like:
|
||||
|
||||
--- <a small product-specific banner>
|
||||
|
||||
This field is optional for most Echomail compatible
|
||||
processors, and is added by the Conference Mail System to
|
||||
ensure complete compatibility. Some systems will place this
|
||||
line in the message when it is first created, but it is
|
||||
normally added when the message is first "exported."
|
||||
|
||||
3. Origin line
|
||||
|
||||
This line appears near the bottom of a message and gives a
|
||||
small amount of information about the system where it
|
||||
originated. It looks like:
|
||||
|
||||
* Origin: The Conference Mail BBS (1:132/101)
|
||||
|
||||
The " * Origin: " part of the line is a constant field.
|
||||
This is followed by the name of the system as taken from the
|
||||
AREAS.BBS file or a file named ORIGIN located in the DOS
|
||||
directory of the designated message area. The complete
|
||||
network address (1:132/101 in this case) is added by the
|
||||
program inserting the line. This field is generated at the
|
||||
same time as the tear line, and therefore may either be
|
||||
generated at the time of creation or during the first
|
||||
"export" processing. Although the Origin line is not
|
||||
required by all Echomail processors, it is added by the
|
||||
Conference Mail System to ensure complete compatibility.
|
||||
|
||||
|
||||
4. Seen-by Lines
|
||||
|
||||
There can be many seen-by lines at the end of Conference
|
||||
Mail messages, and they are the real "meat" of the control
|
||||
information. They are used to determine the systems to
|
||||
receive the exported messages. The format of the line is:
|
||||
|
||||
SEEN-BY: 132/101 113 136/601 1014/1
|
||||
|
||||
The net/node numbers correspond to the net/node numbers of
|
||||
the systems having already received the message. In this way
|
||||
a message is never sent to a system twice. In a conference
|
||||
with many participants the number of seen-by lines can be
|
||||
very large. This line is added if it is not already a part
|
||||
of the message, or added to if it already exists, each time
|
||||
a message is exported to other systems. This is a REQUIRED
|
||||
field, and Conference Mail will not function correctly if
|
||||
this field is not put in place by other Echomail compatible
|
||||
programs.
|
||||
|
||||
5. PATH Lines
|
||||
|
||||
These are the last lines in a Conference Mail message and
|
||||
are a new addition, and therefore is not supported by all
|
||||
Echomail processors. It appears as follows:
|
||||
|
||||
^aPATH: 132/101 1014/1
|
||||
|
||||
Where the ^a stands for Control-A (ASCII character 1) and
|
||||
the net/nodes listed correspond to those systems having
|
||||
processed the message before it reached the current system.
|
||||
This is not the same as the seen-by lines, because those
|
||||
lines list all systems the message has been sent to, while
|
||||
the path line contains all systems having actually processed
|
||||
the message. This is not a required field, and few echomail
|
||||
processors currently support it, however it can be used
|
||||
safely with any other system, since the line(s) will be
|
||||
ignored. For a discussion on how the path line can be
|
||||
helpful, see the "Advanced Features" section of this manual.
|
||||
|
||||
|
||||
METHODS OF SENDING CONFERENCE MAIL
|
||||
|
||||
To this point the issue of how Conference Mail is actually sent
|
||||
has been glossed over entirely. The phrase has been, "the message
|
||||
is exported to another system." What exactly does this mean?
|
||||
Well, for starters lets show what is called the "basic" setup:
|
||||
|
||||
In this setup exported mail is placed into the FidoNet mail area.
|
||||
Each message exported from a Conference Mail area has one
|
||||
message generated for each receiving system. This mail is then
|
||||
sent the same as any other network mail. When Echomail was first
|
||||
created this was the only way mail could be sent.
|
||||
|
||||
The "basic" method has some disadvantages. First, since Echomail
|
||||
has grown so large it is not uncommon to get 200 new messages per
|
||||
day imported into various message bases. It is also not uncommon
|
||||
for a system to be exporting messages to 4 or 5 other systems.
|
||||
Simple arithmetic shows 800-1000 messages per day would be sent
|
||||
in normal netmail! This puts a tremendous strain on any netmail
|
||||
system, not to mention transmission time and the resultant phone
|
||||
charges. When this limitation of Echomail was first noticed a lot
|
||||
of people started scratching their heads wondering what to do. If
|
||||
a solution could not be found it appeared Echomail would
|
||||
certainly overrun the capabilities of FidoNet.
|
||||
|
||||
Thom Henderson (from System Enhancement Associates) came up with
|
||||
the original ARCmail program. Having previously written the ARC
|
||||
file archiving and compression program, he knew the savings
|
||||
achievable by having all of the netmail messages placed in .ARC
|
||||
format for transmission. As a byproduct, the messages no longer
|
||||
appeared in the netmail area, but were included in a file
|
||||
attached to a message (see your FidoNet mailer manual for file
|
||||
attaches). In this way the tremendous number of messages
|
||||
generated, and the phone bill problems were both solved.
|
||||
|
||||
Unfortunately, ARCmail required the messages to first be placed
|
||||
into the netmail area before it could be run. In effect, it
|
||||
caused the messages to be scanned once when they were exported,
|
||||
once during the ARCmail phase, once when ARCmail was run at the
|
||||
other end to get the messages out of .ARC format, and once when
|
||||
those messages were later imported into a message base on the
|
||||
receiving system. The Conference Mail System solves this problem
|
||||
by eliminating the ARCmail program. Conference Mail builds the
|
||||
ARCmail files during Export, and unpacks them during Import. This
|
||||
way messages are exported directly to ARCmail style file
|
||||
attaches, and imported directly from ARCmail style file attaches.
|
||||
The scanning phases between importing and exporting messages are
|
||||
totally removed and processing time is proportionally reduced.
|
||||
|
||||
This is now the most common method for sending Conference Mail
|
||||
between systems. The overhead involved in doing it during the
|
||||
importing and exporting phases is much less than what is involved
|
||||
if ARCmailing is not utilized. This was a primary consideration
|
||||
in the design and implementation of the Conference Mail System,
|
||||
and as a result the entire system is optimized for this type of
|
||||
use. Please refer to the Import and Export functions for
|
||||
specifics on how to use the ARCmailing feature.
|
||||
|
||||
|
||||
CONFERENCE TOPOLOGY
|
||||
|
||||
The way in which systems link together for a particular
|
||||
conference is called the "conference topology." It is important
|
||||
to know this structure for two reasons: 1) It is important to
|
||||
have a topology which is efficient in the transfer of the
|
||||
Conference Mail messages, and 2) It is important to have a
|
||||
topology which will not cause systems to see the same messages
|
||||
more than once.
|
||||
|
||||
Efficiency can be measured in a number of ways; least time
|
||||
involved for all systems to receive a message, least cost for all
|
||||
systems to receive a message, and fewest phone calls required for
|
||||
all systems to receive a message are all valid indicators of
|
||||
efficiency. Users of Echomail compatible systems have determined
|
||||
(through trial and error) the best measure of efficiency is a
|
||||
combination of all three of the measurements given above.
|
||||
Balancing the equation is not trivial, but some guidelines can be
|
||||
given:
|
||||
|
||||
1. Never have two systems attempting to send Conference mail
|
||||
to each other at the same time. This results in "collisions"
|
||||
that will cause both systems to fail. To avoid this, one
|
||||
system should be responsible for polling while the other
|
||||
system is holding mail. This arrangement can alternate based
|
||||
upon various criteria, but both systems should never be
|
||||
attempting to call each other at the same time.
|
||||
|
||||
2. Have nodes form "stars" for distribution of Conference
|
||||
Mail. This arrangement has several nodes all receiving their
|
||||
Conference Mail from the same system. In general the systems
|
||||
on the "outside" of the star poll the system on the
|
||||
"inside". The system on the "inside" in turn polls other
|
||||
systems to receive the Conference Mail that is being passed
|
||||
on to the "outside" systems.
|
||||
|
||||
3. Utilize fully connected polygons with a few vertices.
|
||||
Nodes can be connected in a triangle (A sends to B and C, B
|
||||
sends to A and C, C sends to A and B) or a fully connected
|
||||
square (all corners of the square send to all of the other
|
||||
corners). This method is useful for getting Conference Mail
|
||||
messages to each node as quickly as possible.
|
||||
|
||||
|
||||
All of these efficiency guidelines have to be tempered with the
|
||||
guidelines dealing with keeping duplicate messages from being
|
||||
exported. Duplicates will occur in any topology that forms a
|
||||
closed polygon that is not fully connected. Take for example the
|
||||
following configuration:
|
||||
|
||||
A ----- B
|
||||
| |
|
||||
| |
|
||||
C ----- D
|
||||
|
||||
This square is a closed polygon that is not fully connected. It
|
||||
is capable of generating duplicates as follows:
|
||||
|
||||
1. A message is entered on node A.
|
||||
|
||||
2. Node A exports the message to node B and node C placing
|
||||
the seen-by for A, B, and C in the message as it does so.
|
||||
|
||||
3. Node B sees that node D is not listed in the seen-by and
|
||||
exports the message to node D.
|
||||
|
||||
4. Node C sees that node D is not listed in the seen-by and
|
||||
exports the message to node D.
|
||||
|
||||
At this point node D has received the same message twice - a
|
||||
duplicate was generated. Normally a "dup-ring" will not be as
|
||||
simple as a square. Generally it will be caused by a system on
|
||||
one end of a long chain accidentally connecting to a system on
|
||||
the other end of the chain. This causes the two ends of the chain
|
||||
to become connected, forming a polygon.
|
||||
|
||||
In FidoNet this problem is reduced somewhat by having "Regional
|
||||
Echomail Coordinators" (RECS) that try to keep track of Echomail
|
||||
connections within their regions of the world. A further rule
|
||||
which is followed is that only the RECS are allowed to make
|
||||
inter-regional connections for the larger conferences. In return,
|
||||
the RECS have established a very efficient topology which gets
|
||||
messages from coast to coast, and onto over 200 systems in less
|
||||
than 24 hours. If no one were willing to follow the rules, then
|
||||
this system would collapse, but due to the excellent efficiency
|
||||
it has remained intact for over a year.
|
||||
|
||||
|
||||
Why a PATH line?
|
||||
|
||||
As was previously mentioned, the PATH line is a new concept in
|
||||
Echomail. It stores the net/node numbers of each system having
|
||||
actually processed a message. This information is useful in
|
||||
correcting the biggest problem encountered by nodes running an
|
||||
Echomail compatible system - the problem of finding the cause of
|
||||
duplicate messages. How does the PATH line help solve this
|
||||
problem? Take the following path line as an example:
|
||||
|
||||
^aPATH: 107/6 107/312 132/101
|
||||
|
||||
This shows the message was processed by system 107/6 and
|
||||
transferred to system 107/312. It further shows system 107/312
|
||||
transferred the message to 132/101, and 132/101 processed it
|
||||
again. Now take the following path line as the example:
|
||||
|
||||
^aPATH: 107/6 107/312 107/528 107/312 132/101
|
||||
|
||||
This shows the message having been processed by node 107/312 on
|
||||
more than one occasion. Based upon the earlier description of the
|
||||
'information control' fields in Echomail messages, this clearly
|
||||
is an error in processing (see the section entitled "How it
|
||||
Works"). This further shows node 107/528 as the node which
|
||||
apparently processed the message incorrectly. In this case the
|
||||
path line can be used to quickly locate the source of duplicate
|
||||
messages.
|
||||
|
||||
In a conference with many participants it becomes almost
|
||||
impossible to determine the exact topology used. In these cases
|
||||
the use of the path line can help a coordinator of the conference
|
||||
track any possible breakdowns in the overall topology, while not
|
||||
substantially increasing the amount of information transmitted.
|
||||
Having this small amount of information added to the end of each
|
||||
message pays for itself very quickly when it can be used to help
|
||||
detect a topology problem causing duplicate messages to be
|
||||
transmitted to each system.
|
||||
|
||||
-30-
|
||||
</PRE>
|
||||
|
||||
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
|
||||
|
||||
</BODY>
|
||||
</HTML>
|
||||
|
||||
<HTML>
|
||||
<!-- $Id$ -->
|
||||
<HEAD>
|
||||
<TITLE>Echomail Specification.</TITLE>
|
||||
</HEAD>
|
||||
|
||||
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
||||
<BODY
|
||||
BGCOLOR="#FFFFFF"
|
||||
TEXT="#000000"
|
||||
LINK="#0000FF"
|
||||
VLINK="#000080"
|
||||
ALINK="#FF0000"
|
||||
>
|
||||
<PRE>
|
||||
FTS-0004 EchoMail Specification
|
||||
|
||||
This document is directly derived from the documentation of
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
The Conference Mail System
|
||||
|
||||
By
|
||||
Bob Hartman
|
||||
Sysop of FidoNet(tm) node 132/101
|
||||
|
||||
(C) Copyright 1986,87, Spark Software, Inc.
|
||||
|
||||
427-3 Amherst Street
|
||||
CS 2032, Suite 232
|
||||
Nashua, N.H. 03061
|
||||
|
||||
ALL RIGHTS RESERVED.
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
version 3.31 of 12 December, 1987.
|
||||
|
||||
With Bob Hartman's kind consent, copying for the purpose of technological
|
||||
research and advancement is allowed.
|
||||
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
|
||||
WHAT IS THE CONFERENCE MAIL SYSTEM?
|
||||
|
||||
Conference Mail is a technique to permit several nodes on a
|
||||
network to share a message base, similar in concept to the
|
||||
conferences available on many of the computer services, but it is
|
||||
most closely related to the Usenet system consisting of more than
|
||||
8,000 systems world wide. All systems sharing a given conference
|
||||
see any messages entered into the conference by any of the
|
||||
participating systems. This can be implemented in such a way as
|
||||
to be totally transparent to the users of a particular node. In
|
||||
fact, they may not even be aware of the network being used to
|
||||
move their messages about from node to node! Unfortunately, this
|
||||
has its disadvantages also - most users who are not educated
|
||||
about Conference Mail do not realize the messages transmitted
|
||||
cost MANY sysops (system operators) money, not just the local
|
||||
sysop. This is an important consideration in Conference Mail and
|
||||
should not be taken lightly. In a conference with 100 systems as
|
||||
participants the cost per message can get quite high.
|
||||
|
||||
The Conference Mail System is designed to operate in conjunction
|
||||
with a FidoNet compatible mail server. The currently supported
|
||||
mail servers are Fido(tm), SEAdog(tm), Opus, and Dutchie. Since
|
||||
the mail server is a prerequisite to using the Conference Mail
|
||||
System, it will be assumed you already have your mail server
|
||||
operating correctly on your system, and you are connected into
|
||||
FidoNet or a compatible network.
|
||||
|
||||
|
||||
HISTORY OF THE CONFERENCE MAIL SYSTEM
|
||||
|
||||
In late 1985, Jeff Rush, a Fido sysop in Dallas, wanted a
|
||||
convenient means of sharing ideas with the other Dallas sysops.
|
||||
He created a system of programs he called Echomail, and the
|
||||
Dallas sysops' Conference was born.
|
||||
|
||||
Within a short time sysops in other areas began hearing of this
|
||||
marvelous new gadget and Echomail took on a life of its own.
|
||||
Today, a scant year and a half later, the FidoNet public network
|
||||
boasts a myriad of conferences varying in size from the dozen-or-
|
||||
so participants in the FidoNet Technical Standards Committee
|
||||
Conference to the Sysops' Conference with several hundred
|
||||
participants. It is not uncommon for a node to carry 30 or more
|
||||
conferences and share those conferences with 10 or more nodes.
|
||||
|
||||
|
||||
HOW IT WORKS
|
||||
|
||||
The Conference Mail System is functionally compatible with the
|
||||
original Echomail utilities. In general, the process is:
|
||||
|
||||
1. A message is entered into a designated area on a FidoNet
|
||||
compatible system.
|
||||
|
||||
2. This message is "Exported" along with some control information
|
||||
to each system "linked" to the conference through the originating
|
||||
system.
|
||||
|
||||
3. Each of the receiving systems "Import" the message into the
|
||||
proper Conference Mail area.
|
||||
|
||||
4. The receiving systems then "Export" these messages, along with
|
||||
additional control information, to each of their conference
|
||||
links.
|
||||
|
||||
5. Return to step 3.
|
||||
|
||||
As you can see, the method is quite simple - in general. Of
|
||||
course, following the steps literally would mean messages would
|
||||
never stop being Exported and transmitted to other systems. This
|
||||
obviously would not be desired or the network would quickly
|
||||
become overburdened. The information contained in the 'control
|
||||
information' section is used to prevent transmitting the same
|
||||
message more than once to a single system.
|
||||
|
||||
|
||||
CONFERENCE MAIL MESSAGE CONTROL INFORMATION
|
||||
|
||||
There are five pieces of control information associated with a
|
||||
Conference Mail message. Some are optional, some are not.
|
||||
Normally this information is never entered by the person creating
|
||||
the message. The following control fields determine how
|
||||
Conference Mail is handled:
|
||||
|
||||
1. Area line
|
||||
|
||||
This is the first line of a conference mail message. Its
|
||||
actual appearance is:
|
||||
|
||||
AREA:CONFERENCE
|
||||
|
||||
Where CONFERENCE is the name of the conference. This line is
|
||||
added when a conference is being "Exported" to another
|
||||
system. It is based upon information found in the AREAS.BBS
|
||||
(configuration) File for the designated message area. This
|
||||
field is REQUIRED by the receiving system to "Import" a
|
||||
message into the correct Conference Mail area.
|
||||
|
||||
2. Tear Line
|
||||
|
||||
This line is near the end of a message and consists of three
|
||||
dashes (---) followed by an optional program specifier.
|
||||
This is used to show the first program used to add Echomail
|
||||
compatible control information to the message. The tear line
|
||||
generated by Conference Mail looks like:
|
||||
|
||||
--- <a small product-specific banner>
|
||||
|
||||
This field is optional for most Echomail compatible
|
||||
processors, and is added by the Conference Mail System to
|
||||
ensure complete compatibility. Some systems will place this
|
||||
line in the message when it is first created, but it is
|
||||
normally added when the message is first "exported."
|
||||
|
||||
3. Origin line
|
||||
|
||||
This line appears near the bottom of a message and gives a
|
||||
small amount of information about the system where it
|
||||
originated. It looks like:
|
||||
|
||||
* Origin: The Conference Mail BBS (1:132/101)
|
||||
|
||||
The " * Origin: " part of the line is a constant field.
|
||||
This is followed by the name of the system as taken from the
|
||||
AREAS.BBS file or a file named ORIGIN located in the DOS
|
||||
directory of the designated message area. The complete
|
||||
network address (1:132/101 in this case) is added by the
|
||||
program inserting the line. This field is generated at the
|
||||
same time as the tear line, and therefore may either be
|
||||
generated at the time of creation or during the first
|
||||
"export" processing. Although the Origin line is not
|
||||
required by all Echomail processors, it is added by the
|
||||
Conference Mail System to ensure complete compatibility.
|
||||
|
||||
|
||||
4. Seen-by Lines
|
||||
|
||||
There can be many seen-by lines at the end of Conference
|
||||
Mail messages, and they are the real "meat" of the control
|
||||
information. They are used to determine the systems to
|
||||
receive the exported messages. The format of the line is:
|
||||
|
||||
SEEN-BY: 132/101 113 136/601 1014/1
|
||||
|
||||
The net/node numbers correspond to the net/node numbers of
|
||||
the systems having already received the message. In this way
|
||||
a message is never sent to a system twice. In a conference
|
||||
with many participants the number of seen-by lines can be
|
||||
very large. This line is added if it is not already a part
|
||||
of the message, or added to if it already exists, each time
|
||||
a message is exported to other systems. This is a REQUIRED
|
||||
field, and Conference Mail will not function correctly if
|
||||
this field is not put in place by other Echomail compatible
|
||||
programs.
|
||||
|
||||
5. PATH Lines
|
||||
|
||||
These are the last lines in a Conference Mail message and
|
||||
are a new addition, and therefore is not supported by all
|
||||
Echomail processors. It appears as follows:
|
||||
|
||||
^aPATH: 132/101 1014/1
|
||||
|
||||
Where the ^a stands for Control-A (ASCII character 1) and
|
||||
the net/nodes listed correspond to those systems having
|
||||
processed the message before it reached the current system.
|
||||
This is not the same as the seen-by lines, because those
|
||||
lines list all systems the message has been sent to, while
|
||||
the path line contains all systems having actually processed
|
||||
the message. This is not a required field, and few echomail
|
||||
processors currently support it, however it can be used
|
||||
safely with any other system, since the line(s) will be
|
||||
ignored. For a discussion on how the path line can be
|
||||
helpful, see the "Advanced Features" section of this manual.
|
||||
|
||||
|
||||
METHODS OF SENDING CONFERENCE MAIL
|
||||
|
||||
To this point the issue of how Conference Mail is actually sent
|
||||
has been glossed over entirely. The phrase has been, "the message
|
||||
is exported to another system." What exactly does this mean?
|
||||
Well, for starters lets show what is called the "basic" setup:
|
||||
|
||||
In this setup exported mail is placed into the FidoNet mail area.
|
||||
Each message exported from a Conference Mail area has one
|
||||
message generated for each receiving system. This mail is then
|
||||
sent the same as any other network mail. When Echomail was first
|
||||
created this was the only way mail could be sent.
|
||||
|
||||
The "basic" method has some disadvantages. First, since Echomail
|
||||
has grown so large it is not uncommon to get 200 new messages per
|
||||
day imported into various message bases. It is also not uncommon
|
||||
for a system to be exporting messages to 4 or 5 other systems.
|
||||
Simple arithmetic shows 800-1000 messages per day would be sent
|
||||
in normal netmail! This puts a tremendous strain on any netmail
|
||||
system, not to mention transmission time and the resultant phone
|
||||
charges. When this limitation of Echomail was first noticed a lot
|
||||
of people started scratching their heads wondering what to do. If
|
||||
a solution could not be found it appeared Echomail would
|
||||
certainly overrun the capabilities of FidoNet.
|
||||
|
||||
Thom Henderson (from System Enhancement Associates) came up with
|
||||
the original ARCmail program. Having previously written the ARC
|
||||
file archiving and compression program, he knew the savings
|
||||
achievable by having all of the netmail messages placed in .ARC
|
||||
format for transmission. As a byproduct, the messages no longer
|
||||
appeared in the netmail area, but were included in a file
|
||||
attached to a message (see your FidoNet mailer manual for file
|
||||
attaches). In this way the tremendous number of messages
|
||||
generated, and the phone bill problems were both solved.
|
||||
|
||||
Unfortunately, ARCmail required the messages to first be placed
|
||||
into the netmail area before it could be run. In effect, it
|
||||
caused the messages to be scanned once when they were exported,
|
||||
once during the ARCmail phase, once when ARCmail was run at the
|
||||
other end to get the messages out of .ARC format, and once when
|
||||
those messages were later imported into a message base on the
|
||||
receiving system. The Conference Mail System solves this problem
|
||||
by eliminating the ARCmail program. Conference Mail builds the
|
||||
ARCmail files during Export, and unpacks them during Import. This
|
||||
way messages are exported directly to ARCmail style file
|
||||
attaches, and imported directly from ARCmail style file attaches.
|
||||
The scanning phases between importing and exporting messages are
|
||||
totally removed and processing time is proportionally reduced.
|
||||
|
||||
This is now the most common method for sending Conference Mail
|
||||
between systems. The overhead involved in doing it during the
|
||||
importing and exporting phases is much less than what is involved
|
||||
if ARCmailing is not utilized. This was a primary consideration
|
||||
in the design and implementation of the Conference Mail System,
|
||||
and as a result the entire system is optimized for this type of
|
||||
use. Please refer to the Import and Export functions for
|
||||
specifics on how to use the ARCmailing feature.
|
||||
|
||||
|
||||
CONFERENCE TOPOLOGY
|
||||
|
||||
The way in which systems link together for a particular
|
||||
conference is called the "conference topology." It is important
|
||||
to know this structure for two reasons: 1) It is important to
|
||||
have a topology which is efficient in the transfer of the
|
||||
Conference Mail messages, and 2) It is important to have a
|
||||
topology which will not cause systems to see the same messages
|
||||
more than once.
|
||||
|
||||
Efficiency can be measured in a number of ways; least time
|
||||
involved for all systems to receive a message, least cost for all
|
||||
systems to receive a message, and fewest phone calls required for
|
||||
all systems to receive a message are all valid indicators of
|
||||
efficiency. Users of Echomail compatible systems have determined
|
||||
(through trial and error) the best measure of efficiency is a
|
||||
combination of all three of the measurements given above.
|
||||
Balancing the equation is not trivial, but some guidelines can be
|
||||
given:
|
||||
|
||||
1. Never have two systems attempting to send Conference mail
|
||||
to each other at the same time. This results in "collisions"
|
||||
that will cause both systems to fail. To avoid this, one
|
||||
system should be responsible for polling while the other
|
||||
system is holding mail. This arrangement can alternate based
|
||||
upon various criteria, but both systems should never be
|
||||
attempting to call each other at the same time.
|
||||
|
||||
2. Have nodes form "stars" for distribution of Conference
|
||||
Mail. This arrangement has several nodes all receiving their
|
||||
Conference Mail from the same system. In general the systems
|
||||
on the "outside" of the star poll the system on the
|
||||
"inside". The system on the "inside" in turn polls other
|
||||
systems to receive the Conference Mail that is being passed
|
||||
on to the "outside" systems.
|
||||
|
||||
3. Utilize fully connected polygons with a few vertices.
|
||||
Nodes can be connected in a triangle (A sends to B and C, B
|
||||
sends to A and C, C sends to A and B) or a fully connected
|
||||
square (all corners of the square send to all of the other
|
||||
corners). This method is useful for getting Conference Mail
|
||||
messages to each node as quickly as possible.
|
||||
|
||||
|
||||
All of these efficiency guidelines have to be tempered with the
|
||||
guidelines dealing with keeping duplicate messages from being
|
||||
exported. Duplicates will occur in any topology that forms a
|
||||
closed polygon that is not fully connected. Take for example the
|
||||
following configuration:
|
||||
|
||||
A ----- B
|
||||
| |
|
||||
| |
|
||||
C ----- D
|
||||
|
||||
This square is a closed polygon that is not fully connected. It
|
||||
is capable of generating duplicates as follows:
|
||||
|
||||
1. A message is entered on node A.
|
||||
|
||||
2. Node A exports the message to node B and node C placing
|
||||
the seen-by for A, B, and C in the message as it does so.
|
||||
|
||||
3. Node B sees that node D is not listed in the seen-by and
|
||||
exports the message to node D.
|
||||
|
||||
4. Node C sees that node D is not listed in the seen-by and
|
||||
exports the message to node D.
|
||||
|
||||
At this point node D has received the same message twice - a
|
||||
duplicate was generated. Normally a "dup-ring" will not be as
|
||||
simple as a square. Generally it will be caused by a system on
|
||||
one end of a long chain accidentally connecting to a system on
|
||||
the other end of the chain. This causes the two ends of the chain
|
||||
to become connected, forming a polygon.
|
||||
|
||||
In FidoNet this problem is reduced somewhat by having "Regional
|
||||
Echomail Coordinators" (RECS) that try to keep track of Echomail
|
||||
connections within their regions of the world. A further rule
|
||||
which is followed is that only the RECS are allowed to make
|
||||
inter-regional connections for the larger conferences. In return,
|
||||
the RECS have established a very efficient topology which gets
|
||||
messages from coast to coast, and onto over 200 systems in less
|
||||
than 24 hours. If no one were willing to follow the rules, then
|
||||
this system would collapse, but due to the excellent efficiency
|
||||
it has remained intact for over a year.
|
||||
|
||||
|
||||
Why a PATH line?
|
||||
|
||||
As was previously mentioned, the PATH line is a new concept in
|
||||
Echomail. It stores the net/node numbers of each system having
|
||||
actually processed a message. This information is useful in
|
||||
correcting the biggest problem encountered by nodes running an
|
||||
Echomail compatible system - the problem of finding the cause of
|
||||
duplicate messages. How does the PATH line help solve this
|
||||
problem? Take the following path line as an example:
|
||||
|
||||
^aPATH: 107/6 107/312 132/101
|
||||
|
||||
This shows the message was processed by system 107/6 and
|
||||
transferred to system 107/312. It further shows system 107/312
|
||||
transferred the message to 132/101, and 132/101 processed it
|
||||
again. Now take the following path line as the example:
|
||||
|
||||
^aPATH: 107/6 107/312 107/528 107/312 132/101
|
||||
|
||||
This shows the message having been processed by node 107/312 on
|
||||
more than one occasion. Based upon the earlier description of the
|
||||
'information control' fields in Echomail messages, this clearly
|
||||
is an error in processing (see the section entitled "How it
|
||||
Works"). This further shows node 107/528 as the node which
|
||||
apparently processed the message incorrectly. In this case the
|
||||
path line can be used to quickly locate the source of duplicate
|
||||
messages.
|
||||
|
||||
In a conference with many participants it becomes almost
|
||||
impossible to determine the exact topology used. In these cases
|
||||
the use of the path line can help a coordinator of the conference
|
||||
track any possible breakdowns in the overall topology, while not
|
||||
substantially increasing the amount of information transmitted.
|
||||
Having this small amount of information added to the end of each
|
||||
message pays for itself very quickly when it can be used to help
|
||||
detect a topology problem causing duplicate messages to be
|
||||
transmitted to each system.
|
||||
|
||||
-30-
|
||||
</PRE>
|
||||
|
||||
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
|
||||
|
||||
</BODY>
|
||||
</HTML>
|
||||
|
||||
|
||||
Reference in New Issue
Block a user