FRIP



Automatic mail/file routing system for FidoNet-Style Networks







Introduction


FRIP: What for?

The reason behind FRIP is really simple. I don't like to do myself anything that is not fun and can be done with the help of computer or some other machine. For example, I don't like to keep routing tables for my FIDO node manually since it doesn't look fu nny for me, can be done automatically and, hopefully, automatic routing is more efficient. Second reason is ability of current FRIP to route files, which is virtually impossible and dangerous by standard FTN means.

Assumptions

You are not too paranoid. :-)

You have a decent computer, such as 486/8M/500HD. Even 386 will do, but it better should be running some multitasker to not to keep your mailer from answering a ring when mail processing takes place. FRIP has a DOS version, but it will be withdrawn in a ha lf of year or so, cause there's only 5% of DOS-based FIDO nodes even here in Russia - that's in August of 1996. FRIP is distributed with sources, so everybody can port it to any OS he likes.

You are able to modify sample config file to suit your system.

You have mailer either with Binkley-style outbound, T-Mail style fileboxes or some program that can create a file-attach for your mailer.


Basics

There is two loosely coupled parts in FRIP today. The FRIP itself and so-called FARA - frip Aided Router of Attaches. Both of them are in one executable, and it is done on purpose. It makes me sure that if FRIP works, FARA is operational too. Well, here's what each one does.

FRIP

Does the routing analysis and builds routing table for FARA. Frip is able to produce text-form routing table for other software too, but it is not a primary function. FRIP builds routing table with the help of RIP-files, or, to be short, RIPs. Such a files are sent on a regular basis (one in a two weeks by default) to all FRIPs around and relayed through all the FRIP-ified nodes. Those nodes, in turn, gather information from RIPs coming through and discover the shortest ways to other nodes, networks, zones and domains around. The description of FRIP operation here is VERY brief. Please, refer to page 9 to read more about it. As a user you don't have to know anything about it, though.

FARA

FRIP-Aided Routing of Attaches is a FRIP-based data (mail, files) delivery mechanism. FRIP is able to encapsulate data into a RIF files and transfer them through the FRIP-able nodes. FARA was brought to life after half of year testing of FRIP, which shown that a lot of people easily sets up FRIP, but does not let it produce routing tables for main system router. With the help of FARA FRIP can be used as a separate, add-on mail delivery system.


Usage


Minimal setup & usage

To be able to use most of the FRIP features you need to perform an easy set up: put FRIP in a separate directory and specify minimum of parameters in a config. File. The most complex parameters is those which let FRIP send files to your direct links. Thing s are real easy if your mailer supports Binkley-style outbound. Most current mailers, including The Brake, Binkley, Bink/+, T-Mail, Xenia and others do support such outbound. If your mailer supports Binkley-style outbound, define BinkOutBound and BinkOutBo undDefault parameters. First must specify path to your outbound, excluding last subdirectory, and second - that last directory name, whithout path. If your mailer does not support Binkley outbound but supports T-Mail style fileboxes (including tobesent.$$$ file feature), you can use TmailFileBoxesFAT or TmailFileBoxesHPFS for FAT (DOS) or HPFS (long name) style fileboxes. If both ways are not for you, still there is a workaround exist: DeliverCommand parameter can be used to tell FRIP which command it has t o execute to send file to some address. Note that file must be sent only directly and in kill file sent mode. Apart from this, you should specify Address (one per your AKA), Dir (where you put FRIP), Inbound (your secure inbound directory), FripMail (NetMa il, transferred by FRIP) and Log (log file name) parameters. In a directory, specified by FripMail parameter your mail, received by FARA will be put, and all netmail written in that folder will be sent by FARA, if possible.

Address 2:5030/16.555

Address 666:777/888.999

Dir c:\net\Frip

Inbound c:\Net\Inbound\Secure

FripMail c:\Net\Mail\Frip

Log c:\Net\Logs\Frip.Log

; The following parameters assume that your main Bink outbound is c:\Net\Outbound

BinkOutBound c:\Net

BinkOutBoundDefault Outbound

In addition to frip.cfg file links.cfg must be defined too. It is even more easy to create this file. For the first time just list all your direct links with neighbor nodes using FRIP, one node per line, together with your main aka first:

<your main address> <first link node address>

<your main address> <second link node address>

...

That's all. Now just run frip.exe when you need to pack fripmail, unpack received RIPs, RIFs and RIZs, and at least daily.


Common errors

To be gathered. :)

Simple tweaking


Total Control


Configuration File Reference

Lines, beginning with ':' and empty lines are ignored.

Boolean parameters can have value of Yes/No/On/Off.

Configuration file keywords reference

Keyword

Example

Description

Address

address 2:5020/32.555

address 7:1130/32.555

address 7:7/0.555


Your addresses.

Dir

Dir c:/net/frip

Frip home dir

Inbound

Inbound c:/net/in

Mailer (secure!!) inbound

FripMail

FripMail c:\net\FripMail

Frip will send netmail from this directory using FARA (see page 3) and receive FARA netmail to this directory.

Log

Log c:\net\logs\Frip

Log file name

BinkOutBound

BinkOutBound c:/net

Path to Binkley-style outbound EXCLUDING LAST DIRECTORY.

NB!

Select and define one of BinkOutBound+BinkOutBoundDefault, HPFSOutbound, TMailFileBoxes or DeliverCommand.

BinkOutBoundDefault

BinkOutBoundDefault outbound

Last Bink outbound directory name (excluded above)

HPFSOutBound

HPFSOutBound c:/net/HPFS_outbound

Path to HPFS outbound (test version)

TMailFileBoxesFAT

TMailFileBoxesFAT ./filebox

Path to T-Mail fileboxes - FAT format (DOS mode)

TMailFileBoxesHPFS

TMailFileBoxesHPFS ./filebox

Path to T-Mail fileboxes - HPFS format (OS/2 & NT mode, long names)

DeliverCommand

DeliverCommand Squish Send "^%0" to %1

Command to send file %0 to node %1, DIRECT flavor and kill file sent ONLY!

Hold

Hold 333 5030/* -5030/222

Send RIPs with HOLD flavor to given nodes. Does not work with DeliverCommand.

AnnouncePeriod

AnnouncePeriod 15

Time in days between automatic announces. Default - 14 days.

NB!

DO NOT SET IT TO LESS THAN A WEEK.

PingPeriod

PingPeriod 2

Time between pings. Default - 2 days.

ZipCmd

ZipCmd zip -mj1

zip or pkzip command. Puhleeease! Do NOT use pkzip under OS/2, Win/NT or Win/95. Use native OS/2 or Win32 zip/unzip instead. This parameter is for special cases only - don't specify it if don't have to. Frip has reasonable defaults.

UnZipCmd

UnZipCmd unzip -Cjn

unzip or pkunzip command. See comments to zip command.

CmdLimit

CmdLimit 400

Max. length of OS command line. Default is 100 for DOS, Win/95 and NT (because of Win95!), 400 for OS/2.

Ansi

Ansi Off

Enable/disable ANSI coloring.

Debug

Debug On

Debugging information switch.

Map

Map n:\temp\MapDir

Directory to build routing map in. FRIP does not use that map at all, and is able to build it for sysop's use only.

MapFormat

MapFormat (%s)_%s_%s/%4s.%-3s

Map file name printf format. Each %s from left ot right substituted with: Domain, Zone, Net, Node, Point, Input rip file name (usually not needed).

AnnounceFromAdFiles

AnnounceFromAdFiles Off

Turn on processing of .ad files. For those who really needs it. Be careful! Don't use, if not understand what you are doing.

ProcessedFlag

ProcessedFlag c:/net/Frip_routing_changed.!!!

Frip will create this file if routing possibly changed



The following table lists keywords, used in external router mode. This mode is obsolete, not recommended and can be used only if neighbor FRIP nodes are support this mode too.

Obsolete Keywords Reference

Keyword

Example

Description

StripDomain

StripDomain Off

If turned on, FRIP will strip domain from addresses it puts in external route file.

PointRouting

PointRouting On

If turned on, FRIP will put routes to/via points to external routing file.

WildWord

WildWord *

Wildcard character or word for external routing file

RouteWildAfter

RouteWildAfter Yes

Whether to put wildcarded routes after or before detailed ones

RouteFilePath

RouteFilePath c:\net\squish

Routing file directory

RouteFileName

RouteFileName route.cfg

Routing file NAME ONLY, with no path. Leave empty if no external routing file to be created. It is recommended to use FRIP without external routing.

RouteFileSuff

RouteFileSuff Suffix.rou

Contents of this file will be added to output routing file at the end.

RouteFilePref

RouteFilePref Prefix.rou

Contents of this file will be prepended to output routing file

RouteLine

RouteLine Route %1 to %0

Routing file line format

ViaSelf

ViaSelf Yes

Put routing of node via itself to route file. For example, »Route 2:5020/666 to 2:5020/666«



Protocol


For those who curious


For those who real interested


For those who's serious to implement


Details, data formats, etc.


RIP structure

RIP file is an ASCII text file with the name beginning with letters »rip«, extension beginning with ».ri« and ending with one letter or digit. Lines in RIP file can end with either Unix-style newline character or RSX-style CRLF. Last line must end with new line or CRLF too. Each line begins with keyword and possibly contains a value. There are a few types of RIPs, distinguished by value of TYPE line.


RIP types

Type

Version

Obligatory keywords

Description

AD

1

Ad, from, to, created, hops, path, seenby

Routing announce. Used to track routing

OFF

20

Off, from, to, created, hops, path, seenby

Routing loss announce.

PING

20

From, to, created

Used to gather average link delay information.

HI

?


Not implemented.

HACK

?


Not implemented.

RRQ

?


Rescan request. Should be used by a new FRIP node to get all available routing information quickly. Not implemented.

RACK

?


Rescan acknowledge. Not implemented. I'm not really sure it has to be implemented at all.

SEARCH

24?


Not implemented.


Here goes description of all possible RIP fields. Note that FRIP passing all the unknown fields through, so all the new fields that will be invented are to come through unnoticed by old FRIPs.


RIP fields

Field name

Version

Data type

Description

From

1

Address

Address of system, that sent this particular RIP-file, i.e. our neighbor.

To

1

Address

Address of system this RIP is intended for. Used to prevent processing of mistakenly routed RIPs by intermediate nodes. NB! RIPs should never be routed, as well as RIFs and RIZs.

Type

?

String

Type of RIP, see above. Not case-sensitive.

Capas

20

Flags

Capabilities of system, which generated this RIP. Used to keep track of neighbors abilities. Was introduced together with FARA-able FRIPs.

Created

1

Time/Date

Time/date to subtract from now to get route quality estimate. It is NOT always a real time/date RIP was created, don't treat as such.

Creator

?

Address

Todo: add version/os type here.

Flags

?

Flags

Special info. Used by AD-type RIPs to distinguish between routing types and carry additional info.

Hops

1

Integer

Hops this RIP made

Ad

1

Address

Announced address

Off

20

Address

Address, we lost routing for

Search

?

(Complex)


Path

1

Address

Primary addresses of all systems RIP passed through

Seenby

1

Address

All AKAs of all systems RIP passed through


RIF structure

RIZ file is a binary file with the name beginning with letters »rif«, extension beginning with ».ri« and ending with one letter or digit. RIF is used to carry mail, and beginning of it is a data carried. All the envelope info including addresses, path/seen by info, etc. etc. is kept in a »tailer«.


RIZ structure

RIZ file is a regular ZIP archive (InfoZIP 2.1 level), with the name beginning with letters »riz«, extension beginning with ».ri« and ending with one letter or digit. There can be RIPs and RIFs in RIZ file.


Final words


Thanks!

I'd like to thank Kirill Lebedev, Kirill Shirokov, Anton Tsarevsky, Alex Tutubalin, Mike Bravo, Serge Troffimovsky, Dmitry Efimov, Andrew Iwanov, Ivan Munitsyn, Alexander Erlikh, Fyodor Ustinov, Basil Dolmatov, Yuri Safronov, Dmitry Morozovsky, Pavel Bour danov, Vladimir Kopiev and all the other people, who took part in protocol discussions, betatesting, etc. etc.

Plans

Time zones must be used in RIPs.

Rescan requests and responses are not done.

Direct RIZ processing - without pre-unzip. Tricky, but possible.

Fatal routing loss. If some database record was not updated in a two months or so, remove it at all and generate routing loss event (OFF-type RIPs to all).

Make FRIP know does it rule the main netmail router or not. If not, add a special flag to a routes coming through to make sure these routes will not be used in generation of external routing tables as well.


Bugs

Not that FRIP has real serious bugs which are known but not fixed. Here is just things that can be done better:

FRIP should discover that routing base is empty and request links for rescan.

Inability to send mail because of route absence should force routing loss (OFF) request, but NOT TOO FREQUENT! I have to be careful here and not to bring OFF-storms to life.

In addition to Deliver command FRIP must understand arcmail-attach style mailers by itself.

Contacts


Yours truly Dmitry Zavalishin aka dz can be reached via:

E-mail (preferred): dz@phantom.ru, dz@kiae.su, dz@virgin.relcom.eu.net, Dmitry_Zavalishin@f32.n5020.z2.fidonet.org, fidonet#2:5020/32.

Phone: +7 (095) 110-6728. If somebody non-English speaking answers your call and you can't speak Russian just keep saying my name. :) Try German, if you can - my mother used to it. :)

Snail-Mail: Arteckovskaya 7-4-260, Moscow, Russia.