denozord/strongswan-ext
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

updated charons architecture description

Browse Source
This commit is contained in:
Martin Willi
2007-06-29 09:21:28 +00:00
parent ffbca197c1
commit 0d30da5dfd
1 changed files with 64 additions and 41 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/charon/daemon.h
+64 -41
View File
@@ -47,50 +47,73 @@ typedef struct daemon_t daemon_t;
* *
* @brief IKEv2 keying daemon. * @brief IKEv2 keying daemon.
* *
* @section Architecture
*
* All IKEv2 stuff is handled in charon. It uses a newer and more flexible * All IKEv2 stuff is handled in charon. It uses a newer and more flexible
* architecture than pluto. Charon uses a thread-pool, which allows parallel * architecture than pluto. Charon uses a thread-pool (called processor),
* execution SA-management. Beside the thread-pool, there are some special purpose * which allows parallel execution SA-management. All threads originate
* threads which do their job for the common health of the daemon. * from the processor. Work is delegated to the processor by queueing jobs
@verbatim * to it.
+------+ @verbatim
| E Q |
| v u |---+ +------+ +------+ +--------+ +-------+ +--------+ +-----------+ +-----------+
| e e | | | | | IKE- | | Stroke | | XML | | DBUS | | Local | | SQLite |
| n u | +-----------+ | |--| SA | +--------+ +-------+ +--------+ +-----------+ +-----------+
| t e | | | | I M | +------+ | | | | |
+------------+ | - | | Scheduler | | K a | +---------------------------------+ +----------------------------+
| receiver | +------+ | | | E n | +------+ | Interfaces | | Backends |
+----+-------+ +-----------+ | - a | | IKE- | +---------------------------------+ +----------------------------+
| | +------+ | | S g |--| SA |
+-------+--+ +-----| J Q |---+ +------------+ | A e | +------+
-| socket | | o u | | | | - r | +------------+ +-----------+ +------+ +----------+
+-------+--+ | b e | | Thread- | | | | receiver | | | | | +------+ | CHILD_SA |
| | - u | | Pool | | | +----+-------+ | Scheduler | | IKE- | | IKE- |--+----------+
+----+-------+ | e |------| |---| | | | | | SA |--| SA | | CHILD_SA |
| sender | +------+ +------------+ +------+ +-------+--+ +-----------+ | | +------+ +----------+
+------------+ <->| socket | | | Man- |
+-------+--+ +-----------+ | ager | +------+ +----------+
| | | | | | IKE- |--| CHILD_SA |
+----+-------+ | Processor |--------| |--| SA | +----------+
| sender | | | | | +------+
+------------+ +-----------+ +------+
+---------------------------------+ +----------------------------+
| Bus | | Kernel Interface |
+---------------------------------+ +----------------------------+
| | |
+-------------+ +-------------+ V
| File-Logger | | Sys-Logger | //////
+-------------+ +-------------+
@endverbatim @endverbatim
* The thread-pool is the heart of the architecture. It processes jobs from a * The scheduler is responsible to execute timed events. Jobs may be queued to
* (fully synchronized) job-queue. Mostly, a job is associated with a specific * the scheduler to get executed at a defined time (e.g. rekeying). The scheduler
* IKE SA. These IKE SAs are synchronized, only one thread can work one an IKE SA. * does not execute the jobs itself, it queues them to the processor.
* This makes it unnecesary to use further synchronisation methods once a IKE SA *
* is checked out. The (rather complex) synchronization of IKE SAs is completely * The IKE_SA manager managers all IKE_SA. It further handles the synchronization:
* done in the IKE SA manager. * Each IKE_SA must be checked out strictly and checked in again after use. The
* The sceduler is responsible for event firing. It waits until a event in the * manager guarantees that only one thread may check out a single IKE_SA. This allows
* (fully synchronized) event-queue is ready for processing and pushes the event * us to write the (complex) IKE_SAs routines non-threadsave.
* down to the job-queue. A thread form the pool will pick it up as quick as * The IKE_SA contain the state and the logic of each IKE_SA and handle the messages.
* possible. Every thread can queue events or jobs. Furter, an event can place a *
* packet in the sender. The sender thread waits for those packets and sends * The CHILD_SA contains state about a IPsec security association and manages them.
* them over the wire, via the socket. The receiver does exactly the opposite of * An IKE_SA may have multiple CHILD_SAs. Communication to the kernel takes place
* the sender. It waits on the socket, reads in packets an places them on the * here through the kernel interface.
* job-queue for further processing by a thread from the pool. *
* There are even more threads, not drawn in the upper scheme. The stroke thread * The kernel interface installs IPsec security associations, policies routes and
* is responsible for reading and processessing commands from another process. The * virtual addresses. It further provides methods to enumerate interfaces and may notify
* kernel interface thread handles communication from and to the kernel via a * the daemon about state changes at lower layers.
* netlink socket. It waits for kernel events and processes them appropriately. *
* The bus receives signals from the different threads and relais them to interested
* listeners. Debugging signals, but also important state changes or error messages are
* sent over the bus.
* It's listeners are not only for logging, but also to track the state of an IKE_SA.
*
* The interface manager loads pluggable controlling interfaces. These are written to control
* the daemon from external inputs (e.g. initiate IKE_SA, close IKE_SA, ...). The interface
* manager further provides a simple API to establish these tasks.
* Backends are pluggable modules which provide configuration. They have to implement an API
* which the daemon core uses to get configuration.
*/ */
/** /**