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 To get started using this library, begin by checking out the code from the <a
43 href="http://developer.berlios.de/svn/?group_id=7489">BerliOS SVN repository</a>. You may find
44 help on using the library at '\ref senf_usage'. If you are interested in SENF, feel free to subscribe
45 to the <a href="http://developer.berlios.de/mail/?group_id=7489">SENF mailing lists</a>. If you
46 want to contribute, read the docs and \e please adhere to the \ref senf_conventions.
48 \see \ref senf_usage\n
49 <a href="../../Examples/doc/html/index.html">Examples</a>
51 \section senfutil_overview Building Projects using SENF
53 When building projects using senf, SENFSCons has a very simple helper module \ref senfutil to
54 make the building of libraries utilizing senf simpler:
57 sys.path.extend(('senf/site_scons','/usr/lib/senf/site_scons'))
58 import os.path, glob, senfutil
62 senfutil.SetupForSENF( env )
67 CXXFLAGS = [ '-Wall', '-Woverloaded-virtual' ],
71 LINKFLAGS_debug = [ ],
72 LOGLEVELS_debug = [ 'senf::log::Debug||VERBOSE' ],
74 CXXFLAGS_final = [ '-O3' ],
75 LINKFLAGS_final = [ ],
76 LOGLEVELS_final = [ ],
83 env.Program( target = 'udpforward',
84 source = glob.glob('*.cc') )
87 env.Clean(DEFAULT_TARGETS, [ 'udpforward.log', 'udpforward.pid' ])
90 This example builds a simple binary from a number of source files (all '.cc' files). It links
91 against the SENF library and automatically sets all the correct compiler options using
92 <tt>senfutil.SetupForSENF( env )</tt>.
94 This script automatically uses a SENF installation either symlinked or imported into the current
95 project in directory 'senf' or, if this directory does not exist, a globaly installed SENF. A
96 locally installed SENF is automatically recompiled if needed. Parallel building is also
99 This script automatically supports the \c final and \c LOGLEVELS command line parameters. The
100 LOGLEVELS parameter uses a much more readable syntax than SENF_LOG_CONF:
102 $ scons -j2 final=1 \
103 LOGLEVELS='senf::log::Debug||IMPORTANT myapp::Transactions|mytrans::Area|VERBOSE'
107 /** \page senf_usage Using the SENF framework
109 The SENF Framework is a collection of loosely coupled modules. The libraries are heavily object
110 oriented and template based. For compatibility reasons, the libraries are therefore built
111 together with every project making use of the framework.
113 When starting a new project based on the SENF framework, it is advisable, to make use of the
114 SENFSCons build environment and use SVN to manage the code repository. This is the
115 configuration, described in this documentation.
117 \see \ref senf_build \n
119 \ref senf_components \n
122 \section senf_preliminaries Preliminaries
124 Before starting the development, make sure to fulfill the following requirements:
126 \li GNU g++, version at least 3.4
127 \li The Boost libraries (http://www.boost.org)
128 \li The SCons build tool (http://www.scons.org)
130 If you want to build the documentation, you additionally need
132 \li Doxygen (http://www.doxygen.org)
133 \li The \c dia diagram editor (http://www.gnome.org/projects/dia/)
134 \li HTML \c tidy (http://tidy.sourceforge.net/)
135 \li The \c xsltproc XSLT processor (http://xmlsoft.org/XSLT/xsltproc2.html)
136 \li The \c graphviz library (http://www.graphviz.org)
139 The library is only tested with gcc-3.4 and 4.0 on Linux. On other POSIX platforms with a BSD
140 Socket API, the library should be usable, possibly with some tweaking (except for the Scheduler,
141 which relies on \c epoll)
143 \section senf_compiler_options Compiler and Linker Options
145 If SENF is compiled in debug mode (SENF_DEBUG is defined), exception messages will automatically
146 include a stack backtrace. For this to work, you need to add the -rdynamic option to all link
147 commands. This feature depends on gcc and the GNU-libc.
149 It is <B>very important</B> that both the SENF library and the application using it are compiled
150 \e both either with or without this compiler switch (-DSENF_DEBUG). Otherwise, the compiler will
151 emit error messages which might be hard to debug.
154 /** \page senf_build Building the SENF framework
156 This procedure will test building the complete framework including the unit tests and the
157 Sniffer test application. This build is \e not needed to use the framework since every project
158 will include the full SENF source code itself (via Subversion).
160 After you have successfully built the library tests, you can continue to setup your own project
163 \see \ref senf_setup \n
164 \ref senf_components \n
167 \section senf_checkout Getting the code
169 To access the code, check out the code from the BerliOS repository. Change to your development
170 directory and use the following subversion command
173 $ svn checkout http://svn.berlios.de/svnroot/repos/senf/trunk senf
176 This will create a new directory \c senf within the current directory. For further documentation
177 on the use of Subversion, see the \c svn man-page or the subversion homepage at
178 http://subversion.tigris.org. A very good introduction and reference to subversion is available
179 at http://svnbook.red-bean.com.
181 \section senf_compile Building
183 To build the library, execute all unit tests and build the Sniffer test application, use
190 in the \c senf directory. This assumes, that you want to build the library with your default gcc
191 and requires the boost libraries to be available in the system include paths. If this is not the
192 case, you can take a look at <tt>SConfig.template</tt> file. Copy this file to <tt>SConfig</tt>
193 and comment out all the variables you don't want to change (The \e values in the template file
194 are just arbitrary examples).
197 /** \page senf_setup Setting up a new project using SENF
199 The most simple way to use SENF for now is to checkout the svn repository and build SENF
200 yourselves. After you have built SENF, reference your SENF build directory from your build
201 environment. The most flexible way to do this, is to use a symbolic link to your SENF build.
203 Here an example \c SConstruct file for a project using SENF. This script expects SENF to be
204 found in the <tt>%senf</tt> sub-directory of the directory, where the \c SConstruct file is
205 found. This may either be a SENF checkout (if managing your project via subversion, you can use
206 <tt>svn:externals</tt> for this) or a symbolic link to your SENF checkout.
213 LIBS = [ 'senf', 'boost_regex', 'boost_iostreams' ],
214 CXXFLAGS = [ '-Wall', '-Woverloaded-virtual', '-Wno-long-long' ],
220 source = glob.glob('*.cc'),
224 When building against a self-built SENF which will probably be in debug mode, the '-DSENF_DEBUG'
225 option must be added to the compile command.
227 The most simple way to build using SENF is to use a very simple SCons helper which automatically
228 supports debug and final builds, uses SENF either centrally installed or locally built and has
229 some other nice features. See <a
230 href="../../senfscons/doc/html/index.html#senfutil_overview">Building Projects using SENF</a>
231 for more info and an example for this utility.
233 \see \ref senf_components \n
237 /** \page senf_components The SENF modules
239 The framework is made up of several modular components. When using the library, it is possible
240 to selectively choose to use only a subset of the implemented modules.
242 \see \ref senf_overview
244 \section libPPI libPPI: Packet Processing Infrastructure
246 The Packet Processing Infrastructure implements a modular framework for implementing packet
247 oriented network applications. The library provides a large set of pre-defined modules as well
248 as the necessary helpers to implement application specific processing modules.
250 \see <a href="../../PPI/doc/html/index.html">libPPI API reference</a>
252 \section libSocket libSocket: C++ abstraction of the BSD socket API
254 This library provides a high performance and object oriented abstraction of the standard socket
255 API. It utilizes a flexible and extensible policy based design. The library provides predefined
256 types for the important socket types (UDP and TCP sockets etc) including raw and packet sockets.
258 \see <a href="../../Socket/doc/html/index.html">libSocket API reference</a>
260 \section libPackets libPackets: Network packet manipulation
262 This library provides a very flexible infrastructure to parse, create and otherwise manipulate
263 packetized network data. Included is a library of several protocol parsers covering the basic
264 IPv4 and IPv6 network protocols down to the Ethernet layer.
266 \see <a href="../../Packets/doc/html/index.html">libPackets API reference</a>
268 \section libScheduler libScheduler: Asynchronous event handling
270 The scheduler library provides an object oriented interface to the standard UNIX \c select type
271 event dispatcher. It is based on the high performance \c epoll system call. It provides support
272 for read/write events as well as simple timer based events.
274 \see <a href="../../Scheduler/doc/html/index.html">libScheduler API reference</a>
276 \section libUtils libUtils: Collection of arbitrary utilities
278 This library is used be most all of the other modules for miscellaneous tools and utilities. We
281 \li Simple functions to manage daemon processes
282 \li Standard exception classes
283 \li senf::intrusive_refcount to simplify the implementation of classes usable with
285 \li boost::bind extensions
286 \li An interface to the \c g++ de-mangler integrated with type_info
287 \li Typedefs and rudimentary methods to simplify handling high-resolution time values
289 \see <a href="../../Utils/doc/html/index.html">libUtils API reference</a>
291 \section senfscons SENFSCons, the SENF build environment
293 SENF relies on SCons (http://www.scons.org) to build. To further simplify the common tasks, SENF
294 includes a library of custom routines and builders comprising a very concise build
295 environment. Included are a number of templates to help bootstrapping a new project or
298 \see <a href="../../senfscons/doc/html/index.html">SENFSCons reference</a>
301 /** \page senf_overview Introduction to the framework
303 The SENF framework is relatively complex and makes use of advanced features of the C++
304 language. To make the most efficient use of the framework, you should have at least a basic
305 understanding of C++ templates and the standard library concepts.
307 The library implementation at places makes heavy use of advanced template techniques and relies
308 on some very advanced template libraries from Boost. The aim was however for the \e external
309 interface of the library to be as simple as possible without sacrificing important functionality
310 or adversely impacting the runtime performance.
312 As already mentioned several times, the library relies on Boost (http://www.boost.org) as a
313 generic library of high quality reusable C++ components. It also makes frequent use of the
314 standard library. It is designed, to integrate well into both libraries and to use the same
317 \section senf_startup Getting starting developing with SENF
319 To introduce the framework and it's general structure, a simple example application is provided
320 in the SENF repository in the \c Sniffer module. Peruse this example to get a first look at how
323 When building a network Application with SENF, you will use several modules:
325 \li Use the <a href="../../Socket/doc/html/index.html">Socket library</a> for network
326 communication needs. This library includes support for raw and packet sockets to allow low
327 level network access.
328 \li Use the <a href="../../Scheduler/doc/html/index.html">Scheduler library</a> to coordinate
329 the asynchronous event processing. This drastically reduces the number of threads needed in
330 your application and will greatly enhance the overall responsiveness.
331 \li To interpret low level network packets, use the <a
332 href="../../Packets/doc/html/index.html">Packets library</a>. This library will provide
333 efficient and convenient access to all protocol fields. It supports parsing as well as
334 modifying and creating packets. It has default support for the most important Internet
335 protocols and is highly extensible with new protocols.
336 \li Go over the <a href="../../Utils/doc/html/index.html">Utils library</a>. It contains small
337 helpers to simplify tasks like daemonization, exception handling, debugging and so on.
339 The simplest way to get started is: copy the Sniffer application and start to modify it.
341 \see <a href="../../Examples/doc/html/index.html">Examples</a> \n
342 \ref senf_components \n
345 \section senf_conventions Coding Conventions
347 Here we have laid down the coding conventions used throughout the SENF framework. Please ad here
348 to these conventions when changing or adding code. If you use emacs, you can use the C++ IDE for
349 emacs from http://g0dil.de which greatly simplifies following these conventions.
351 \subsection senf_conventions_file_naming File Naming
353 Files should be named according to the main class they define. A single header file should
354 define only one main class. Exceptions to this rule are OK.
357 This simplifies finding the implementation/header for a given class and also reduces the
358 size of each single file.
360 The implementation is divided into a number of different files:
362 <table class="glossary"> <tr><td>\c .h</td><td>C public header</td></tr>
364 <tr><td>\c .hh</td><td>C++ public header</td></tr>
366 <tr><td>\c .ih</td><td>C++ internal header used only by the implementation. This header will
367 probably be included indirectly by the public header but is not meant to be perused by the
368 library user</td></tr>
370 <tr><td>\c .c</td><td>C implementation</td></tr>
372 <tr><td>\c .cc</td><td>C++ implementation of non-inline non-template functions and
375 <tr><td>\c .ct</td><td>C++ implementation of non-inline template functions and members</td></tr>
377 <tr><td>\c .cci</td><td>C++ implementation of inline non-template functions and
380 <tr><td>\c .cti</td><td>C++ implementation of inline template functions and members</td></tr>
382 <tr><td>\c .mpp</td><td>Special include file used for external iteration by the
383 Boost.Preprocessor library</td></tr> </table>
386 There are two part's to this: First, separating the implementation of inlines and templates
387 out of the header file makes the header file much easier to read. This is important, since
388 the header file will be used as a reference by the developers.
390 Separating inline from non-inline members is used together with the \c prefix_ convention
391 below to ensure the correct placement of inline vs non-inline members in the source
392 code. The C++ language requires, that inline members must be included into \e every
393 compilation unit, non-inline members however must be included \e only in one compilation
394 unit. Placing the inline members into a separate file allows to automate this: Simply moving
395 an implementation from one of the inline files into one of the non-inline files will change
396 the type of implementation accordingly.
398 \subsection senf_conventions_type_naming Type Naming
400 SENF prefers the use of the CapitalziedLettersToSeparateWords convention for class names. In
401 this case, class names must start with a capital letter. There are some exceptions to this rule:
402 Types which define new basic data types to be used like other built-in types may be named using
403 lowercase letters plus underscores. Also, if a type or class is directly related to some other
404 library (STL or Boost) which uses the underscore convention, it might be more sensible to follow
405 this convention. This is open to debate.
408 Naming types with capital letters nicely gives a visual clue, that a symbol is a type
409 name. This can also be used by the editor to highlight type names correctly. Additionally,
410 this convention is compact and does not add additional or repeated overhead.
412 \subsection senf_conventions_impl Implementation
414 Only in very few places, SENF allows the use of inline implementations (not to be confused with
415 inline functions). An \e implementation is inline, if it is written directly into the class
416 definition in the header file. Again there are exceptions to this rule but they are very few:
417 \li When defining simple exception classes, the 'what()' member may be defined inline if it
418 returns a string constant.
419 \li It may be OK to use inline implementations for one-line implementations in internal
421 \li The Packet library allows inline implementations for the definition of parsers since doing
422 so outside the declaration just gets to verbose and parsers definitions are quite length but
423 very simple and straight forward.
426 Implementing members inline inside the class declaration makes the declaration much harder
427 to read. Since the declaration in the header file will be used as a reference by the
428 developer, the header files should be as readable as possible.
430 Every function or method implementation in one of the implementation files must \e always be
431 prefixed with \c prefix_. This symbol is defined at the beginning of the file and undefined at
432 the end. The symbol must be defined to be \c inline in the \c .cti and \c .cci files and must be
433 defined empty in the \c .cc and \c .ct files.
436 Together with splitting inlines and non-inlines into separate files, this allows to
437 automatically include the inline definitions at the right places. See above.
439 Private data members are named with a trailing underscore character.
442 This helps distinguishing local variables from parameter names. The trailing underscore
443 does not interfere with other naming conventions and is allowed by the standard (underscore
444 at the beginning of the name are problematic since some classes of names beginning with an
445 underscore are reserved for the standard library implementation)
449 // :vim:textwidth=100
453 // c-file-style: "senf"
454 // indent-tabs-mode: nil
455 // ispell-local-dictionary: "american"
456 // compile-command: "scons doc"