Revision 725270cb doc/prog-intro.sgml

View differences:

6 6
design decisions and rationale behind them. It also contains documentation on
7 7
all the essential components of the system and their interfaces.
8 8

<p>Routing daemons are very complicated things which need to act in real time
<p>Routing daemons are complicated things which need to act in real time
10 10
to complex sequences of external events, respond correctly even to the most erroneous behavior
11 11
of their environment and still handle enormous amount of data with reasonable
12 12
speed. Due to all of this, their design is very tricky as one needs to carefully
47 47
<item><it>Offer powerful route filtering.</it>
48 48
There already were several attempts to incorporate route filters to a dynamic router,
49 49
but most of them have used simple sequences of filtering rules which were very inflexible
and hard to use for any non-trivial filters. We've decided to employ a simple loop-free
and hard to use for non-trivial filters. We've decided to employ a simple loop-free
51 51
programming language having access to all the route attributes and being able to
52 52
modify the most of them.
53 53

65 65
In addition to the online reconfiguration, a routing daemon should be able to communicate
66 66
with the user and with many other programs (primarily scripts used for network maintenance)
67 67
in order to make it possible to inspect contents of routing tables, status of all
routing protocols and also to control their behavior (i.e., it should be possible
to disable, enable or reset a protocol without restarting all the others). To achieve
routing protocols and also to control their behavior (disable, enable or reset a protocol without restarting all the others). To achieve
70 69
this, we implement a simple command-line protocol based on those used by FTP and SMTP
71 70
(that is textual commands and textual replies accompanied by a numeric code which makes
72 71
them both readable to a human and easy to recognize in software).
77 76
the scheduler will assign time to them in a fair enough manner. This is surely a good
78 77
solution, but we have resisted the temptation and preferred to avoid the overhead of threading
79 78
and the large number of locks involved and preferred a event driven architecture with
our own scheduling of events.
our own scheduling of events. An unpleasant consequence of such an approach
is that long lasting tasks must be split to more parts linked by special
events or timers to make the CPU available for other tasks as well.
81 82

82 83
83 84

106 107
of code modules (core, each protocol, filters) there exist a configuration
107 108
module taking care of all the related configuration stuff.
108 109

<tagp>Filters</tagp> implement the route filtering language.
<tagp>The filter</tagp> implements the route filtering language.
110 111

111 112
<tagp>Protocol modules</tagp> implement the individual routing protocols.
112 113

125 126
control over all implementation details and on the other hand enough
126 127
instruments to build the abstractions we need.
127 128

<p>The modules are statically linked to produce a single executable file
(except for the client which stands on its own).

128 132
<p>The building process is controlled by a set of Makefiles for GNU Make,
129 133
intermixed with several Perl and shell scripts.
130 134

131 135
<p>The initial configuration of the daemon, detection of system features
132 136
and selection of the right modules to include for the particular OS
133 137
and the set of protocols the user has chosen is performed by a configure
script created using GNU Autoconf.
script generated by GNU Autoconf.
135 139

136 140
<p>The parser of the configuration is generated by the GNU Bison.
137 141

138 142
<p>The documentation is generated using <file/SGMLtools/ with our own DTD
and mapping rules. The printed form of the documentation is first converted
and mapping rules which produce both an online version in HTML and
a neatly formatted one for printing (first converted
140 145
from SGML to &latex; and then processed by &tex; and <file/dvips/ to
produce a PostScript file.
get a PostScript file).
142 147

143 148
<p>The comments from C sources which form a part of the programmer's
144 149
documentation are extracted using a modified version of the <file/kernel-doc/
145 150
146 151

<p>If you want to work on BIRD, it's highly recommended to configure it
with a <tt/--enable-debug/ switch which enables some internal consistency
checks and it also links BIRD with a memory allocation checking library
if you have one (either <tt/efence/ or <tt/dmalloc/).
147 156

148 157
149 158
LocalWords:  IPv IP CLI snippets Perl Autoconf SGMLtools DTD SGML dvips

Also available in: Unified diff