4 // Fraunhofer Institute for Open Communication Systems (FOKUS)
5 // Competence Center NETwork research (NET), St. Augustin, GERMANY
6 // Stefan Bund <g0dil@berlios.de>
8 // This program is free software; you can redistribute it and/or modify
9 // it under the terms of the GNU General Public License as published by
10 // the Free Software Foundation; either version 2 of the License, or
11 // (at your option) any later version.
13 // This program is distributed in the hope that it will be useful,
14 // but WITHOUT ANY WARRANTY; without even the implied warranty of
15 // MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
16 // GNU General Public License for more details.
18 // You should have received a copy of the GNU General Public License
19 // along with this program; if not, write to the
20 // Free Software Foundation, Inc.,
21 // 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
23 /** \mainpage SENF: The Simple and Extensible Network Framework
25 The SENF Simple and Extensible Network Framework aims to be a complete set of libraries to
26 facilitate the development of network applications focusing on network protocols on the layers
27 below the application layer. However, the framework includes many general purpose utilities and
28 will be expedient to use well beyond its primary objective.
32 The main goals of this library are (in no particular order):
34 \li modular framework design
35 \li utilizing the power of modern C++
36 \li very low overhead for frequently called members
40 \section start Getting started
42 You may check the Downloads section for binary library releases. However, in all probability you
43 will have to compile SENF for yourself.
45 If you are interested in SENF, feel free to subscribe to the <a
46 href="http://developer.berlios.de/mail/?group_id=7489">SENF mailing lists</a>. If you want to
47 contribute, read the docs and \e please adhere to the \ref senf_conventions.
50 \ref senf_introduction \n
52 \ref senf_senfutil for linking against the SENF library\n
53 <a href="../../Examples/doc/html/index.html">Examples</a>
56 /** \page senf_senfutil SENF SCons build utility (senfutil.py)
60 \c senfutil helps setting up projects which utilize SENF. It will configure all necessary
61 compiler and linker options and additionally sets up some useful defaults and utilities.
63 \c senfutil really serves three roles
65 \li detect the SENF library and configure the build accordingly
66 \li make some SCons extensions used within SENF available to other projects
67 \li set default compilation options in the same way, they are set when compiling SENF proper.
69 The last two points are of course optional.
71 \section senfutil_tutorial Tutorial
73 To utilize \c senfutil you need to do two things:
74 \li Update your \c SConstruct file
75 \li add a bootstrap \c senfutil.py to \c site_scons
77 Lets start with the \c SConstruct file
82 senfutil.SetupForSENF(env)
83 senfutil.DefaultOptions(env)
86 PROJECTNAME = 'Example project',
87 PROJECTEMAIL = 'developer@domain.com',
88 DOCLINKS = [ ('Homepage', 'http://www.domain.com') ]
91 sources, tests = senfutil.Glob(env, exclude=['main.cc'])
93 objects = env.Object(sources)
94 example = env.Program('example', objects + ['main.cc'])
95 test = env.BoostUnitTest('test', objects + tests)
101 senfutil.CleanGlob('all', [ '*~', '#*#' ])
104 This simple sample already enables a lot of functionality:
105 \li support for different \e SENF flavors (debug/normal/final)
106 \li support for different \e build flavors (debug/normal/final)
107 \li sensible default compile options for the different flavors
108 \li support for extended command-line variables
109 \li building documentation with an auto-generated Doxyfile
110 \li running unit-tests
111 \li cleaning backup and temporary files
113 Here a very quick rundown of the important scons commands:
114 \li Build default target:
118 \li Build documentation and unit-tests:
122 \li clean up everything
126 \li Pass custom options on the command-line
128 $ scons CXXFLAGS+=-Wextra
131 Since \c senfutil.py is not on the standard \c python or \c SCons path, some extra steps are
133 \li Either add the possible directories to <tt>sys.path</tt> before importing \c senfutil:
136 sys.path.extend(('/usr/local/lib/senf/site_scons', '/usr/lib/senf/site_scons'))
139 \li Alternatively, install the following utility script as <tt>site_scons/senfutil.py</tt> into
140 your project. This script will search for <tt>site_scons/senfutil.py</tt> in a list of
141 directories and then load the real \c senfutil.py on top of itself. The directories searched
142 include: the current directory and all parents, subdirectories named <tt>senf/</tt>,
143 <tt>Senf/</tt> or <tt>SENF/</tt> thereof, and <tt>/usr/local/lib/senf/</tt> and
144 <tt>/usr/lib/senf/</tt>
147 \section senfutil_features
149 The \c senfutil utility for SCons helps setting up a project to compile against SENF:
151 \li \c senfutil adds all necessary libraries to link against
152 \li \c senfutil will set necessary compile options.
153 \li \c senfutil supports normal, debug and final project build options
154 \li \c senfutil adds support for Boost unit tests
155 \li \c senfutil implements a very simple to use enhanced doxygen build with SENF symbol
157 \li \c senfutil allows specifying variables on the scons command line
158 \li \c senfutil supports more readable compile-time SENF loglevel configuration
160 Using the utility is quite simple
164 sys.path.extend(('senf/site_scons','/usr/lib/senf/site_scons'))
165 import glob, senfutil
168 senfutil.SetupForSENF(env)
169 # senfutil.DefaultOptions(env)
171 # Set or change SCons environment variables with env.Append, env.Replace or env.SetDefault
173 CXXFLAGS = [ '-Wall', '-Woverloaded-virtual' ],
174 CXXFLAGS_final = [ '-O2' ],
175 CXXFLAGS_normal = [ '-O0', '-g' ],
176 CXXFLAGS_debug = [ '$CXXFLAGS_normal' ],
178 LINKFLAGS_normal = [ '-Wl,-S' ],
180 LOGLEVELS_debug = [ 'senf::log::Debug||VERBOSE' ],
182 PROJECTNAME = 'Example project',
183 PROJECTEMAIL = 'developer@domain.com',
184 DOCLINKS = [ ('Homepage', 'http://www.domain.com') ]
187 # Create a list of sources and tests. Sources are all *.cc files, test are *.test.cc
188 sources, tests = senfutil.Glob(env, exclude=['main.cc'] )
190 # Build objects from sources
191 objects = env.Object(sources)
194 env.Default( env.Program( target='example', source=objects + ['main.cc'] ) )
196 # Build a boost unit-test from additional test sources
197 env.BoostUnitTest( 'test', source=objects + tests)
199 # Build a documentation, autogenerates a Doxyfile
200 senfutil.Doxygen(env)
203 This example builds a simple binary from a number of source files (all '.cc' files). It links
204 against the SENF library and automatically sets all the correct compiler options using
205 <tt>senfutil.SetupForSENF( env )</tt>.
207 This script automatically uses a SENF installation either symlinked or imported into the current
208 project in directory 'senf' or, if this directory does not exist, a globally installed SENF.
210 \section senf_senfutil_options Build options
212 \c senfutil supports the <tt>debug=1</tt> or <tt>final=1</tt> build options. These parameters
213 select one of the build configurations 'debug', 'normal' or 'final'. The following variables are
214 supported each with separate values for all three configurations:
221 \c senfutil will detect the type of SENF library used (final or not) and set the correct compile
224 \section senf_senfutil_loglevels Specifying compile-time loglevels
226 To simplify specifying the compile-time loglevel configuration, the build variable \c LOGLEVELS
227 (and it's build configuration specific variants) may be set. This variable will be parsed and
228 converted into the correct \c SENF_LOG_CONF definition. The \c LOGLEVELS Syntax is
230 \par "" \e optional_stream \c | \e optional_area | \e level
232 where \e optional_stream and \e optional_area are optional fully scoped C++ names (e.g. \c
233 senf::log::Debug) and \e level is the loglevel. There must be \e no whitespace in a single
234 specification, multiple specifications are either specified using an array or separated with
237 \section senf_senfutil_default Default options
239 In the example above, all compile options are set manually. To specify the default customary
240 compile options for SENF programs, \c senfutil.DefaultOptions(env) is provided. This function is
244 senfutil.DefaultOptions(env) =>
246 CXXFLAGS = [ '-Wall', '-Woverloaded-virtual' ],
247 CXXFLAGS_final = [ '-O2' ],
248 CXXFLAGS_normal = [ '-O0', '-g' ],
249 CXXFLAGS_debug = [ '$CXXFLAGS_normal' ],
251 LINKFLAGS_normal = [ '-Wl,-S' ],
255 Thus above example can be simplified to
258 sys.path.extend(('senf/site_scons','/usr/lib/senf/site_scons'))
259 import glob, senfutil
262 senfutil.SetupForSENF(env)
263 senfutil.DefaultOptions(env)
265 env.Append( LOGLEVELS_debug = [ 'senf::log::Debug||VERBOSE' ],
266 PROJECTNAME = 'Example project',
267 PROJECTEMAIL = 'developer@domain.com',
268 DOCLINKS = [ ('Homepage', 'http://www.domain.com') ] )
270 sources, tests = senfutil.Glob(env, exclude=['main.cc'] )
272 objects = env.Object(sources)
273 env.Default( env.Program( target='example', source=objects + ['main.cc'] ) )
274 env.BoostUnitTest( 'test', source=objects + tests)
275 senfutil.Doxygen(env)
278 \section senf_senfutil_tests Building unit tests
280 Building unit tests mostly follows a standard pattern
283 # Generate list of sources and tests (sources=*.cc, tests=*.test.cc)
284 extra_sources = ['main.cc']
285 sources, tests = senfutil.Glob(env, exclude=extra_sources)
287 # Build object files needed for both main target and unit tests
288 objects = env.Object(sources)
290 # Build main target, e.g. a Binary with additional sources which are not part of the unit test
291 env.Program('example', objects+extra_sources)
293 # Build unit tests including additional test sources
294 env.BoostUnitTest('test', objects+tests)
297 It is important to exclude the \c main function from the unit-test build since the boost unit
298 test library provides it's own.
300 \section senf_senfutil_doxygen Building documentation
302 Documentation is built using the \c senfutil.Doxygen utility
305 env.Append( PROJECTNAME = "Example project",
306 PROJECTEMAIL = "coder@example.com",
307 COPYRIGHT = "The Master Coders",
308 DOCLINKS = [ ('Homeage', 'http://www.example.com') ],
309 REVISION = 'r'+os.popen('svnversion').read().strip().lower() )
311 senfutil.Doxygen(env)
314 The \c senfutil.Doxygen utility autogenerates a \c Doxyfile.
316 The utility will search for a SENF documentation in the \c senfdoc and \c %senf subdirectories
317 as well as via the senfutil module directory and some other standard locations. If SENF
318 documentation is found, the SENF tagfiles will automatically be added. Links will be resolved
319 to the documentation found.
321 \c senfutil.Doxygen takes some additional optional keyword arguments:
322 \li \c doxyheader: Path of an alternative HTML header
323 \li \c doxyfooter: Path of an alternative HTML footer
324 \li \c doxycss: Path on an alternative CSS file
325 \li \c mydoxyfile: If set to \c True, don't generate or clean the \c Doxyfile\
326 \li \c senfdoc_path: List of additional directories to search for SENF documentation
328 \section senf_senfutil_arguments 'scons' Command line arguments
330 \c senfutil automatically parses SCons command line arguments into the SCons build
331 environment. This allows specifying any parameter on the command line:
333 $ scons CXX=myg++ CXXFLAGS+=-mtune=geode
335 You may either set variables unconditionally using '=' or append values to the end of a list
339 /** \page senf_introduction Introduction to the framework
341 The SENF framework is relatively complex and makes use of advanced features of the C++
342 language. To make the most efficient use of the framework, you should have at least a basic
343 understanding of C++ templates and the standard library concepts.
345 The library implementation at places makes heavy use of advanced template techniques and relies
346 on some very advanced template libraries from Boost. The aim was however for the \e external
347 interface of the library to be as simple as possible without sacrificing important functionality
348 or adversely impacting the runtime performance.
350 As already mentioned several times, the library relies on Boost (http://www.boost.org) as a
351 generic library of high quality reusable C++ components. It also makes frequent use of the
352 standard library. It is designed, to integrate well into both libraries and to use the same
355 \section senf_startup Getting starting developing with SENF
357 To introduce the framework and it's general structure, some simple example applications are
358 provided in the SENF repository. Peruse those examples to get a first look at how to make use of
361 When building a network Application with SENF, you will use several modules:
363 \li One of the central SENF libraries is the <a
364 href="../../senf/PPI/doc/html/index.html">Packet Processing Infrastructure (PPI)</a>. Using
365 this library, it is very simple to develop flexible packet networks of interconnected
367 \li Use the <a href="../../senf/Socket/doc/html/index.html">Socket library</a> for network
368 communication needs. This library includes support for raw and packet sockets to allow low
369 level network access.
370 \li Use the <a href="../../senf/Scheduler/doc/html/index.html">Scheduler library</a> to
371 coordinate the asynchronous event processing. This drastically reduces the number of threads
372 needed in your application and will greatly enhance the overall responsiveness.
373 \li To interpret low level network packets, use the <a
374 href="../../senf/Packets/doc/html/index.html">Packets library</a>. This library will provide
375 efficient and convenient access to all protocol fields. It supports parsing as well as
376 modifying and creating packets. It has default support for the most important Internet
377 protocols and is highly extensible with new protocols.
378 \li Go over the <a href="../../senf/Utils/doc/html/index.html">Utils library</a>. It contains
379 small helpers to simplify tasks like daemonization, exception handling, debugging and so
380 on. Additionally, %Utils contains several larger supplementary modules for <a
381 href="../../senf/Utils/Logger/doc/html/index.html">Logging</a>, <a
382 href="../../senf/Utils/Console/doc/html/index.html">Configuration</a> (including interactive
383 configuration via a network terminal) and <a
384 href="../../senf/Utils/Daemon/doc/html/index.html">Daemon management</a>.
386 The simplest way to get started is: copy the Sniffer application and start to modify it.
388 \see <a href="../../Examples/doc/html/index.html">Examples</a> \n
389 \ref senf_components \n
390 \ref senf_senfutil \n
393 \section senf_dependencies Dependencies
395 Before starting the development, make sure to fulfill the following requirements:
397 \li GNU g++, version at least 3.4
398 \li The Boost libraries (http://www.boost.org)
399 \li The SCons build tool (http://www.scons.org)
401 If you want to build the documentation, you additionally need
403 \li Doxygen (http://www.doxygen.org)
404 \li The \c dia diagram editor (http://www.gnome.org/projects/dia/)
405 \li HTML \c tidy (http://tidy.sourceforge.net/)
406 \li The \c xsltproc XSLT processor (http://xmlsoft.org/XSLT/xsltproc2.html)
407 \li The \c graphviz library (http://www.graphviz.org)
409 The library is tested and developed on Linux. It should be relatively simple to port SENF to
410 other POSIX platforms.
413 /** \page senf_build Building the SENF framework
415 This procedure will build the complete framework including the unit tests and the example
416 applications. After you have successfully built the library tests, you can continue to setup
417 your own project linking against SENF.
419 \section senf_checkout Getting the code
421 To access the code, check out the code from the BerliOS repository. Change to your development
422 directory and use the following subversion command
425 $ svn checkout http://svn.berlios.de/svnroot/repos/senf/trunk senf
428 This will create a new directory \c senf within the current directory. For further documentation
429 on the use of Subversion, see the \c svn man-page or the subversion homepage at
430 http://subversion.tigris.org. A very good introduction and reference to subversion is available
431 at http://svnbook.red-bean.com.
433 Additionally ensure, you have installed all necessary \ref senf_dependencies.
435 \section senf_compile Building
437 To build the library, execute all unit tests and build all examples applications, use
439 $ scons default examples all_tests
441 This assumes, that you want to build the library with your default gcc and requires the boost
442 libraries to be available in the system include paths. If this is not the case take a look a the
443 \c SConstruct file for configuration variables. You may either specify the variables on the
444 command line or place them into a \c SConscript.local file.
447 /** \page senf_components The SENF modules
449 The framework is made up of several modular components. When using the library, it is possible
450 to selectively choose to use only a subset of the implemented modules.
452 \see \ref senf_overview
454 \section libPPI libPPI: Packet Processing Infrastructure
456 The Packet Processing Infrastructure implements a modular framework for implementing packet
457 oriented network applications. The library provides a large set of pre-defined modules as well
458 as the necessary helpers to implement application specific processing modules.
460 \see <a href="../../senf/PPI/doc/html/index.html">libPPI API reference</a>
462 \section libSocket libSocket: C++ abstraction of the BSD socket API
464 This library provides a high performance and object oriented abstraction of the standard socket
465 API. It utilizes a flexible and extensible policy based design. The library provides predefined
466 types for the important socket types (UDP and TCP sockets etc) including raw and packet sockets.
468 \see <a href="../../senf/Socket/doc/html/index.html">libSocket API reference</a>
470 \section libPackets libPackets: Network packet manipulation
472 This library provides a very flexible infrastructure to parse, create and otherwise manipulate
473 packetized network data. Included is a library of several protocol parsers covering the basic
474 IPv4 and IPv6 network protocols down to the Ethernet layer.
476 \see <a href="../../senf/Packets/doc/html/index.html">libPackets API reference</a>
478 \section libScheduler libScheduler: Asynchronous event handling
480 The scheduler library provides an object oriented interface to the standard UNIX \c select type
481 event dispatcher. It is based on the high performance \c epoll system call. It provides support
482 for read/write events as well as simple timer based events.
484 \see <a href="../../senf/Scheduler/doc/html/index.html">libScheduler API reference</a>
486 \section libUtils libUtils: Collection of arbitrary utilities
488 This library is used be most all of the other modules for miscellaneous tools and utilities. We
491 \li Simple functions to manage daemon processes
492 \li Standard exception classes
493 \li senf::intrusive_refcount to simplify the implementation of classes usable with
495 \li boost::bind extensions
496 \li An interface to the \c g++ de-mangler integrated with type_info
497 \li Typedefs and rudimentary methods to simplify handling high-resolution time values
499 \see <a href="../../senf/Utils/doc/html/index.html">libUtils API reference</a>
502 /** \page senf_conventions Coding Conventions
504 Here we have laid down the coding conventions used throughout the SENF framework. Please ad here
505 to these conventions when changing or adding code. If you use emacs, you can use the C++ IDE for
506 emacs from http://g0dil.de which greatly simplifies following these conventions.
508 \subsection senf_conventions_file_naming File Naming
510 Files should be named according to the main class they define. A single header file should
511 define only one main class. Exceptions to this rule are OK.
514 This simplifies finding the implementation/header for a given class and also reduces the
515 size of each single file.
517 The implementation is divided into a number of different files:
519 <table class="glossary"> <tr><td>\c .h</td><td>C public header</td></tr>
521 <tr><td>\c .hh</td><td>C++ public header</td></tr>
523 <tr><td>\c .ih</td><td>C++ internal header used only by the implementation. This header will
524 probably be included indirectly by the public header but is not meant to be perused by the
525 library user</td></tr>
527 <tr><td>\c .c</td><td>C implementation</td></tr>
529 <tr><td>\c .cc</td><td>C++ implementation of non-inline non-template functions and
532 <tr><td>\c .ct</td><td>C++ implementation of non-inline template functions and members</td></tr>
534 <tr><td>\c .cci</td><td>C++ implementation of inline non-template functions and
537 <tr><td>\c .cti</td><td>C++ implementation of inline template functions and members</td></tr>
539 <tr><td>\c .mpp</td><td>Special include file used for external iteration by the
540 Boost.Preprocessor library</td></tr> </table>
543 There are two part's to this: First, separating the implementation of inlines and templates
544 out of the header file makes the header file much easier to read. This is important, since
545 the header file will be used as a reference by the developers.
547 Separating inline from non-inline members is used together with the \c prefix_ convention
548 below to ensure the correct placement of inline vs non-inline members in the source
549 code. The C++ language requires, that inline members must be included into \e every
550 compilation unit, non-inline members however must be included \e only in one compilation
551 unit. Placing the inline members into a separate file allows to automate this: Simply moving
552 an implementation from one of the inline files into one of the non-inline files will change
553 the type of implementation accordingly.
555 \subsection senf_conventions_type_naming Type Naming
557 SENF prefers the use of the CapitalziedLettersToSeparateWords convention for class names. In
558 this case, class names must start with a capital letter. There are some exceptions to this rule:
559 Types which define new basic data types to be used like other built-in types may be named using
560 lowercase letters plus underscores. Also, if a type or class is directly related to some other
561 library (STL or Boost) which uses the underscore convention, it might be more sensible to follow
562 this convention. This is open to debate.
565 Naming types with capital letters nicely gives a visual clue, that a symbol is a type
566 name. This can also be used by the editor to highlight type names correctly. Additionally,
567 this convention is compact and does not add additional or repeated overhead.
569 \subsection senf_conventions_impl Implementation
571 Only in very few places, SENF allows the use of inline implementations (not to be confused with
572 inline functions). An \e implementation is inline, if it is written directly into the class
573 definition in the header file. Again there are exceptions to this rule but they are very few:
574 \li When defining simple exception classes, the 'what()' member may be defined inline if it
575 returns a string constant.
576 \li It may be OK to use inline implementations for one-line implementations in internal
578 \li The Packet library allows inline implementations for the definition of parsers since doing
579 so outside the declaration just gets to verbose and parsers definitions are quite length but
580 very simple and straight forward.
583 Implementing members inline inside the class declaration makes the declaration much harder
584 to read. Since the declaration in the header file will be used as a reference by the
585 developer, the header files should be as readable as possible.
587 Every function or method implementation in one of the implementation files must \e always be
588 prefixed with \c prefix_. This symbol is defined at the beginning of the file and undefined at
589 the end. The symbol must be defined to be \c inline in the \c .cti and \c .cci files and must be
590 defined empty in the \c .cc and \c .ct files.
593 Together with splitting inlines and non-inlines into separate files, this allows to
594 automatically include the inline definitions at the right places. See above.
596 Private data members are named with a trailing underscore character.
599 This helps distinguishing local variables from parameter names. The trailing underscore
600 does not interfere with other naming conventions and is allowed by the standard (underscore
601 at the beginning of the name are problematic since some classes of names beginning with an
602 underscore are reserved for the standard library implementation)
606 // :vim:textwidth=100
610 // c-file-style: "senf"
611 // indent-tabs-mode: nil
612 // ispell-local-dictionary: "american"
613 // compile-command: "scons doc"