Amiga Elysian Archive/AmigaElysianArchive.iso/prog/c/afixsrc.lha/RogerSrc.Notes

Text File | 1993-03-07 | 7.6 KB | 122 lines

NOTE: Source released by Roger Walker at the request of Russel Miranda.
Below is his original description of the source flow...


Quickly, theory of operation stuff...  lets hope I can explain it!

It starts up by putting out the nifty little title with my name... it goes
into one of my command line parsing routines (admittedly, not my favorite one,
which uses a right-to-left method of parsing the line.. but I'm babbling!) and
sets one or two global variables.  It goes then into some task renaming stuff
I ripped from Jon's door exaples, but instead it does it RIGHT, by preserving
the pointer to the old task name, to restore when it's done.  StartLink()
hooks it into ParCon for the location of the BBS's config structure (see the
included ParConLnk.h file)  I then allocate some of the string variables I
use, because I was afraid of running over my stack space (I hate for people to
be forced to raise the stack!).  The lprintf() statements work like a
primitive printf() statement that instead goes to the log file.  The log file
is purposely opened and closed for each write, ensuring that it is closed when
the program has the greatest chance of failing (and therefore cutting down on
HD errors, and allowing you to see where it failed).  Several other strings
are allocate, as are some work variables (newadr, orignode).
    The config file is read next... That is an experience in itself...,
but I'll try to explain it here... You of course can figure most of it out,
but I'll explain MY functions.  GetLine(FILE *,char *) is a function that
reads a line out of a text file (just a line, up to 255 characters) and alters
the line so that it contains no leading whitespace, no trailing whitespace,
no characters after a ';', and no blank lines (they are skipped).  It will
return a zero if the file has ended, or a non-zero if EOF was not hit.  Nearly
all of the funtions with the word Add in them add items to linked lists... of
which there are several.  I was linked-list happy, and I prefer them over
arrays and things like that which are always the same size, and leave you with
limits on the amount of data.  In any case... the lists are as follows, I'll
attempt to explain...

The area list... this contains all the vital info on each area, such as A) a
list (yes another) of the systems receiving this echo (hence the unlimited
nature of AreaFix and MailStorm to send echos to various systems), the Paragon
area number, and the areatag... (was 16, I would increase to say 60 or so if
I were you, it's such a small amount of space anyway!) These are added to the
list whenever an AREA x line is hit in the ReadCfg function.  The next is the
alias list... since it's not that important, it wasn't really necessary to
make this a linked list, but why not?  It stores only other names by which
AreaFix may be known.  These are the ALIAS lines (surprisingly enough!)
Following that is the list of passwords.  This list contains information on
the systems that are allowed to perform an areafix session, such as the
address, password, and the security level.  When making this one, though,
like that alias list, I was somewhat new to lists and put the nextXXXX pointer
at the end... in all actuality is should be the first variable in the
structure, but shoot me, it works.  The pass structures go with the PASS
lines in the config.  The protection structures make up the next list, and
they go with the PROTECT lines in the config file.  They contain the areatag
and protection level of each echo you wish to put above the access of other
systems. (note the nextXXXX line is last again... sigh...8-D)  The next list
is the request list.  This list contains an echo tag name, and a list of
systems who wish to connect to it upon its arrival.  This is used in
conjunction with the AreaFix.QUE file, and is described later.  Another list
like this is the fwdsys list, which is used for the request forwarding also.
This list has a fwdarea list hanging off of it.  Back to the config file.
As lines are read from the file, the lists are built in memory.
    GetHiMk() lets AreaFix know where to start its search for netmail,
it reads in the high water mark off the disk and ensures that the area number
has not been changed, as that would most likely mean the watermark is corrupt.
    InputAreas() reads in the Areas.CTL file.  It is parsed with GetLine
also, so all comments are stripped and an internal linked list representation
of the list is built.  The address of 'change' is passed over, so if there is
an invalid area in the Areas.CTL, AreaFix will know that a new one must be
written out.
    BuildReqLst() is a function that reads in the .QUE file, and builds
the internal representation of that in the request list mentioned above.
    Finally, the meat of the program... here AreaFix starts the scan up
to the highest message in the area... It opens each message, and checks the
header to find if the message is addressed to one of its aliases (AliasMatch)
and if so, it double checks to find if the message is addressed to this system
(why someone would pass an AreaFix through another system, I'll never know...
but it's worth checking for)  If it has a message, it immediately opens the
reply message in a temp file (one that is hopefully unique, it uses the task
ID number as part of it, so it should be unique for each AreaFix running).  It
then processes the subject line, checks the password, and sets several
flags for the commands the message's author wishes to use.  Then, it steps
through the message line by line and writes a reply for each line.  It acts
upon the internal lists appropriately removing or adding systems from area
lists, or resetting the High Msg Sent pointer if a rescan is requested.
When it hits the end of the message (or the tear line), it drops out of the
loop and gives a summary of the areas the system is connected with, acts on
a query, and then closes the message (which is then renamed to an actual
message).  If the message called for an area list, the list function is
called which will convert a file into a message.  The message is closed,
and the cycle repeats until there are no more messages in the search area.
The high water marks are saved, then any forwarded requests are sent (for
any info on this black magic with the fwdsys and fwdarea lists, just
ask...).  The Que is processed (it checks to see if any of the areas
previously requested now exist in the paragon config, and removes them from
the que, announces their presence, and auto-connects them.  Any not removed
are saved to the .QUE again, and the link is severed with ParCon.  The
Areas.CTL file is saved out to disk (if there were any modifications), and
the log is written.  There... it's done.  Hope I didn't lose you anywhere,
I've never written docs like THESE before!

In any case, I'd like to stress again that you can give me a call voice at
the above number... and I'd be glad to help you out if something is
unclear.  If you have never done any linked lists (some people don't do
them, others shy away from them because they deal heavily with [dare I say
it?] pointers.  I love them... even more than queueueueues (ok... so
there's a few extra letters in there...).  They are the ideal way to handle
an unknown quantity of data efficiently.

Hope this file has been of some help... it's sure been fun writing it
though!

)Russ

Russel Miranda
Sysop of The Enterprise BBS of Bushkill, Pa.  [phone]
FIDO: (1:268/106.0), 14.4Kbps HST, ADS.  Home of AreaFix, AmigaTick,
MailStorm, SectorWars, UserPrt, CompList, TopTen, WaterMark, ad infinitum
(ad nauseum?  8-D) with more to come.  Place your software orders now, no
reservations, takeout welcomed!

NOTE: Current Address as of 07-Mar-93 is: [e-mail]. The fido addresses
listed above are obsolete (rw)