White Pages.
Database and server.
DESCRIPTION.
UPDATE REQUESTS.
DATABASE DESCRIPTION.
DATABASE MANAGER.
EPURWP AND UPDATE MESSAGES.
WP SERVER REQUESTS.
Description.
The White Pages implementation in FBB software has been based upon the W0RLI
model (many thanks to Hank for his work). I've tried to maintain a high
degree of compatibility whilst making further development to my own criteria.
I shall try to explain how FBB White Pages works.
I have probably mis-understood some features of W0RLI's specifications but I
hope that this will not greatly affect the compatibility.
First of all, why do we need White Pages?
White pages has some interesting features. Not least :
- A dynamic database containing users Name, zip code, HomeBBS and QTH (as
well as other fields).
- Automatic addressing/routing of mail to the HomeBBS of the destination
callsign.
- A White Pages server for remote interrogation of the database.
The database information is updated, firstly from the information given by
users when they exercise the N, NH, NQ and NZ features at their home (or
another WP equipped) BBS; and secondly, from information contained within the
messages headers as they traverse the Network.
The database is dynamic, it is changing constantly, and it updates itself in
real time. Either as soon as a line of a message header is received when in
ASCII forwarding mode, or when a complete message is decoded in compressed
forwarding mode; or else when a user disconnects from the BBS (this is to
prevent multiple updates being generated during a session).
So, the database can hold many callsigns. In fact it maintains a list of all
the callsigns seen from all individuals sending messages as well has all of
the BBS's seen in the forwarding paths. More than 10,000 valid records is not
impossible today, and this will surely increase as the number of packet radio
users grows with each day. This will allow user to send messages to other
users around the world without necessarily having to be concerned to find
their full Hierarchical Address, the old principle of the user typing:
BBS PROMPT >
SP K6VAZ @ KM6WU.#CENCA.CA.USA.NOAM
should now be replaced by the user entering:
BBS PROMPT >
SP KM6VAZ
The BBS will add the HA and send the response:
BBS PROMPT >
SP K6VAZ
WP ROUTING @KM6WU.#CENCA.CA.USA.NOAM ADDED
TITLE ?
If the routing destination HA is not recorded in the database then the user
will be advised and prompted to enter the address manually.
Another capability of FBB White Pages is the automatic sending of update
messages to other BBS's. These messages are generated every night during
House-Keeping and are a listing of the additions and modifications made to
the database during that day. These messages are sent addressed both to and
from WP.
When passing through or terminating at another White Pages equipped BBS, the
message will automatically update the 'local' WP database at that BBS. This
feature MUST BE USED WITH CARE, as updates can generate a lot of traffic and
the Network must be able to support it.
*** It's not be a good idea to send these update messages on HF ! ***
A built-in White Pages server (WP) will provide information from the
database in response to a remote request. This server is described in
paragraph xx.
All files used by White Pages are in the FBB\SYSTEM\WP subdirectory.
Trace for WP updates (for debugging etc):
in the \windows\winfbb.ini file, add the following line in the main section :
TraceWp=1
You can replace 1 with 2 or 3. 3 gives the maximum information.
A file WP.DBG will be created in the WP directory.
UPDATE REQUESTS.
The database receives information from three sources. The s
indicated on each line of the update message as a suffix to the callsign:-
- The /U suffix denotes that the information in this line of the update is
User-Generated as is therefore assumed to be CORRECT. This information is
collected by the BBS whenever the User responds to the N, NH, NQ or NZ
commands. The date associated with the information is the date when the User
disconnects that session.
- The /G suffix denotes that the information in this line has been gathered
by examining the header of a message to GUESS at which BBS the sender is
registered. The HomeBBS of the User is assumed to be the BBS shown in the
first R: header line. The date associated with this information is the date
shown on this R: header line.
- The /I suffix denotes information about forwarding BBS's taken from the R:
header lines. This information can consist of the HA (the Hierarchical
Address), the QTH (within brackets) and the zip code (following the Z:). The
date of this information is again taken from the R: header line of the BBS in
question.
When the BBS is idle the Database Manager is called and the update
information detailed above is processed.
DATABASE DESCRIPTION.
The database is composed of individual records. Each record
following components :
- Callsign and Name.
- Active information.
- Temporary information.
The active and temporary information components are identical and each
includes the following fields:
- Date of the information
- Hierarchical Address (one word)
- Zip code (one word)
- Qth (one or more words)
Only the Active information is used for addressing/routing and database
requests.
DATABASE MANAGER.
This process freshens the database, following receipt of the new or changed
information detailed above.
The update subroutine will first look for an entry in the database for the
callsign which matches the received information. If it does not exist then a
completely new record will be created in the database and the information be
used to fill what fields it can, in both the active and the temporary
components. The date will be then changed to the one associated with the
update information.
If the record does already exist, then the unknown fields of both the
temporary and active fields will be filled in, and those fields already known
in the temporary part will be replaced by the new information if the date new
information is younger than that already on file. The date will then be
adjusted such that it is consistent with the updated information.
If the new information is of the /U category, then the current fields will
be replaced by the new information in both the primary and secondary (Active
and Temporary) parts of the record, as this information has been input
directly from the user. If the information was of another category then only
the secondary (Temporary) part of the record will be updated, so the Active
or primary record will remain unchanged at this time.
If a field is changed, a flag giving the update request type is then
validated. If the /U flag is already validated, it will not be replaced. This
flag will be used in case the WP update messages are validated.
EPURWP AND UPDATE MESSAGES.
EPURWP is a maintenance program for the White Pages database which should be
run during each House-Keeping cycle.
The program conducts a validity check on each of the entries, and discards
any "unwanted" records (in the case of an invalid callsign for example).
The program also checks the date of the last update of the temporary part of
each record. If this date is older than a pre-defined number of days (given
as a parameter, default 40 days) then the temporary part is considered as
stable, and then the known fields will be transferred to the Primary or
Active part, which is then used to answer all addressing/server requests.
This process ensures that the database is tolerant of users sending messages
from mailboxes other than their normal HomeBBS. Once the Active or primary
part of the record is set, then the temporary (or secondary) part can be
updated/changed many times. Only once this temporary field has remained
unchanged for 40 days, or the user exercises any of the "Nx" options at his
new HomeBBs will the Active or Primary record be changed.
If the changes to the database are validated, then the record is marked with
an update flag and a line will be appended to the file MESS.WP
Each line of the outgoing WP update messages looks like :
On 930123 FD1CDC/U @ F6FBB.FMLR.FRA.EU zip 31240 Claude Saint Jean
Any unknown fields are replaced by "?" like :
On 930123 FD1CDC/U @ F6FBB.FMLR.FRA.EU zip ? ? Saint Jean
The U character is the update type.
WP SERVER REQUESTS.
FBB software has an internal built-in WP server.
The format of the WP server requests are as shown below :
BBS PROMPT >
SP WP @ F6FBB
Title of message
WP Request (does not matter)
Text of message
F6FBB ?
EA3* ?
^Z (or /EX)
The server will answer to the request with a private message, addressed to
the sender, and routed to the BBS according to the first R: header line of
the incoming request.
The reply message is restricted to a maximum of 100 lines, as the use of
wildcards in the request could generate a unacceptably long replies.
This page was last updated 17-Apr-99