home *** CD-ROM | disk | FTP | other *** search
/ DP Tool Club 8 / CDASC08.ISO / VRAC / POINT165.ZIP / FIDOINFO.TXT < prev    next >
Encoding:
Text File  |  1993-09-12  |  11.5 KB  |  230 lines
  1.        The following text was written by Scott Dudley, author of
  2.        MAXIMUS, one of the most common BBS systems in use on the planet.
  3.  
  4.        Scott has also written a mail processor called SQUISH which is
  5.        also a world leader in processing Fidonet mail.  The following
  6.        was taken from the documentation file for Squish with the kind
  7.        permision of Mr. Dudley.
  8.  
  9.                                      * * *
  10.  
  11.        The following text is copyright 1991 by Scott J. Dudley.  All
  12.        rights reserved.
  13.  
  14.  
  15.                                  NETWORK PRIMER
  16.                                 by, Scott Dudley
  17.                                    1:249/106
  18.  
  19.        This section is intended as a primer for SysOps who are new to
  20.        FidoNet or a FidoNet Technology Network (FTN).  This section
  21.        covers many of the terms and concepts which are required for
  22.        everyday FidoNet operations.
  23.  
  24.  
  25.                                   The Basics
  26.  
  27.        The term "FidoNet" refers to an amateur electronic mail network,
  28.        run collectively by a group of system operators.  In the
  29.        beginning, FidoNet started out as a simple system for exchanging
  30.        private messages between different bulletin boards.  Since then,
  31.        FidoNet has grown into a full-fledged electronic mail and
  32.        conferencing network which has members in most countries of the
  33.        world.
  34.  
  35.        FidoNet itself is organized into a numerical hierarchy of
  36.        "zones", "regions", "nets", "nodes" and "points".  Each member of
  37.        FidoNet, individually known as a "node", can be uniquely
  38.        identified by that system's zone, net, node and point numbers.
  39.        To define each term:
  40.  
  41.        Zones are wide geographical areas, usually covering one or more
  42.        continents.  At the time of writing, FidoNet currently has six
  43.        zones:  zone 1 (North America), zone 2 (Europe), zone 3
  44.        (Oceania), zone 4 (South America), zone 5 (Africa) and zone 6
  45.        (Asia).
  46.  
  47.        Nets cover a much smaller area than zones; a net usually
  48.        encompasses a large city and the surrounding area.  There are
  49.        usually many nets within each zone, each of which represents a
  50.        small geographical area within that zone.
  51.  
  52.        Nodes are individual systems.  Most nodes consist of bulletin
  53.        board systems, although a few nodes are devoted exclusively to
  54.        handling mail.  If you wish to become a member of FidoNet and you
  55.        are running a BBS, this is probably where you will start.
  56.  
  57.        Points are users on an individual system.  Normally, points do
  58.        not run full-time systems, since they simply send and receive
  59.  
  60.        mail through their "bossnodes" (the nodes where the points pick
  61.        up their mail).  As the size of the network grows, points are
  62.        becoming increasingly popular.  If you don't wish to run a full-
  63.        time system, this is probably where you'll start.
  64.  
  65.        These four terms can be combined to give a "network address"
  66.        which identifies any one node in the network.  The format of a
  67.        FidoNet address is as follows:
  68.  
  69.                              zone:net/node[.point]
  70.  
  71.        For example, given a user in zone 1, in net 249, with a node
  72.        number of 106, and a point number of 2, that user's full address
  73.        would be '1:249/106.2'.  The point number is optional, so both
  74.        1:249/106 and 1:249/106.0 refer to the bossnode of 1:249/106.2.
  75.  
  76.        This mode of addressing is sometimes referred to as "4D" or four-
  77.        dimensional, since it includes the four basic elements of a
  78.        network address.
  79.  
  80.  
  81.                                The Outside World
  82.  
  83.        Like other electronic mail systems, it's possible to enter a
  84.        private message on a FidoNet system and have that message be
  85.        delivered to its final destination in a short period of time.
  86.        FidoNet systems "talk" with each other over telephone lines,
  87.        using one or more sophisticated handshaking protocols.  To get a
  88.        message (known in this context as "NetMail") from point "A" to
  89.        point "B", the following sequence of events has to occur:
  90.  
  91.        *    The message is created.  Most Fido-compatible software
  92.        packages can be used to generate a private message to a user on
  93.        another node.  The destination address is entered, using the
  94.        standard 4D addressing scheme.
  95.  
  96.        *    The on-disk message is then converted to packet (or *.PKT)
  97.        form.  If you are running BinkleyTerm, this will be performed by
  98.        Squish after a user logs off.  If you are running FrontDoor or a
  99.        similar mailer type, this will be performed by the mailer itself
  100.        on startup, or while your mailer is connected to other systems.
  101.  
  102.        There are four reasons for converting a message into a packet:
  103.  
  104.        1)   The packet structure is much more flexible than the local
  105.        message structure.  All of the fields (such as the To:, From: and
  106.        Subject: fields) in a packet are variable length, whereas the
  107.        fields in stored messages are fixed-length.
  108.  
  109.        2)   Packets are the "compatibility layer".  Since all systems
  110.        convert messages to the *.PKT format before sending them to
  111.        another system, there are few compatibility problems.  This means
  112.        that systems can store their local message bases in different
  113.        formats, but still be able to exchange messages easily.  In
  114.        addition, more than one message can be stored in a single packet.
  115.        Sometimes hundreds (or even thousands) of messages can be stored
  116.        in a single packet.
  117.  
  118.  
  119.        3)   Messages in a packet can have a different address from the
  120.        packet itself.  The packet itself has a destination (the system
  121.        where you'll be sending that packet directly to), but each
  122.        message has an individual destination address.  This is useful,
  123.        for example, when a long-distance call is required to connect
  124.        with certain parts of the network.  The message's final
  125.        destination always stays the same, but by sending the packet to
  126.        someone who is local to you (and then having that someone send it
  127.        to another local system, and so on), costs can be controlled
  128.        quite effectively.  Since the interim destination of packet
  129.        doesn't need to be the same as the final destination of the
  130.        message, routing of messages via the lowest-cost route can be
  131.        performed.
  132.  
  133.        4)   Packets can be given a "flavour".  A "flavour" (or a
  134.        behaviour characteristic) helps your system decide what to do
  135.        with an individual message.  For example, the "hold" flavour
  136.        instructs your system to hold the message and wait for the
  137.        destination system to call and pick it up.  Other flavours
  138.        include "crash" (send a message directly to the destination),
  139.        "direct" (same as crash), and "normal" (wait for later routing
  140.        commands).
  141.  
  142.        Packets always have an extension of *.PKT.  (Qualifier:  if you
  143.        are running a BinkleyTerm system, they may have an extension of
  144.        *.HUT, *.OUT, *.CUT, or *.DUT on your local system, but Binkley
  145.        always changes them to *.PKT files before they are sent to
  146.        another system.)
  147.  
  148.        *    After the packet is created, it can be optionally archived
  149.        using a file compression utility.  Compression is useful when
  150.        transferring large volumes of mail or sending to long- distance
  151.        sites, since compressing mail saves both time and money.
  152.  
  153.        *    The system which created the message then tries to call the
  154.        destination system.  Obviously, if both systems are fairly busy,
  155.        this may take a while.  Messages are sent back and forth between
  156.        systems through the use of mailers, also known as "front ends".
  157.        Mailers call out to deliver waiting mail, handle incoming
  158.        messages and files, and in general, supervise the entire file
  159.        transfer.
  160.  
  161.        *    After the two mailers connect (using one of several FidoNet
  162.        protocols), waiting mail and files are transferred between the
  163.        two systems.
  164.  
  165.        *    After the transfer completes, the receiving system then
  166.        tries to import the message.  If the packet was compressed by the
  167.        sender, it will be decompressed.  The *.PKT files will then be
  168.        imported (otherwise known as "tossed") into the local message
  169.        base, ready for the recipient to read.
  170.  
  171.        Although transferring NetMail can involve much more than just
  172.        what is given above, this should give you a grasp on NetMail
  173.        fundamentals.
  174.  
  175.  
  176.  
  177.                            Is There an Echo In Here?
  178.  
  179.        In the beginning, FidoNet consisted solely of nodes exchanging
  180.        NetMail.  The only way to get a message from "here" to "there"
  181.        was to send a private NetMail message.  However, a technology
  182.        called "EchoMail" was developed in late 1985; EchoMail is
  183.        analogous to a public message area or conference, but EchoMail
  184.        areas (sometimes known as "echoes") are shared among several
  185.        other systems.
  186.  
  187.        EchoMail is organized into different groups of echoes, each with
  188.        a different topic.  For example, the topics of FidoNet echoes
  189.        range from Maximus Support to deep-sea fishing and many more
  190.        special-interest groups.  To facilitate topic-oriented EchoMail,
  191.        each echo must given a tag (or area name).  This tag is used to
  192.        uniquely identify that EchoMail area when transferring messages
  193.        with other systems.  (It doesn't matter what you call the echo on
  194.        YOUR system, as long as you are using the same tag as everyone
  195.        else.)  Area tags are one word only, although they can include
  196.        periods and underscores.  To start receiving an echo area, you
  197.        need to know the tag of that area.  For example, the area tag for
  198.        the echo dealing with hardware and other technical issues is
  199.        "TECH".
  200.  
  201.        EchoMail messages are normally public, and they are entered in a
  202.        message area just like a normal message.  EchoMail messages also
  203.        look like normal, locally-entered messages, but with some special
  204.        control information at the bottom of each message.
  205.  
  206.        After an EchoMail message is saved, an EchoMail utility (such as
  207.        Squish) is invoked to "scan" that message out to the rest of the
  208.        network.  Unlike NetMail, EchoMail areas have an electronic
  209.        topology.  Some echoes are very large, and as such, the cost to
  210.        directly send a message to each system which carried that echo
  211.        would be prohibitive.  Instead, each system carrying that echo
  212.        only transfers EchoMail messages to neighbouring systems.  (The
  213.        neighbour you receive an echo from is also known as your "feed".)
  214.        EchoMail messages get sent from the originating system to its
  215.        neighbours, and from those systems to their neighbours, and so
  216.        on.  Despite this "hoppity-hop" method of transferring messages,
  217.        EchoMail is fairly quick; it can often take less than three days
  218.        for a message to travel from the USA to Australia and back.
  219.  
  220.        Just like NetMail, echoes are sent to other systems in packets.
  221.        EchoMail messages are almost always compressed, since most of the
  222.        popular echoes have a daily throughput anywhere from 20 to 200
  223.        messages per day.
  224.  
  225.             Copyright 1991 by Scott J. Dudley.  All rights reserved.
  226.                              Used with permission.
  227.  
  228.                                      * * *
  229.  
  230.