[strongSwan-dev] strongswan plugin interface

[Tobias Brunner]

Hi Razvan,

> The sql plugin's behaviour was exactly the one that I was trying to 
> replicate, but without using the actual databases, as this would
> become quite troublesome when you are dealing with a rather large
> number of hosts, as you have to keep a database for each of these.

Well, you could use SQLite, which has nearly no overhead (such as
another process etc.), and then make the Java application, which you
would have running on each host, I suppose, simply write the config to
that database instead of storing it somewhere else, or sending it to a
special plugin (no idea if that applies to your use case).

> I got that from the code, but as the plugins don't actually have a 
> while(true) loop inside of them, and they are just basically a set
> of methods, they are called by the daemon in the end(or at least
> that's what I get from the code).

The plugin interface is actually very simple, it basically is just a
single function each plugin has to implement - <name>_plugin_create() -
which gets called by the daemon once the dynamic library is loaded and
which has to return a plugin_t object (the plugin loader in recent
versions allows some dynamic loading and dependencies via get_features,
but the basic interface has not changed).  Have a look at the existing
plugins to see what each of them does in this constructor (you'll find
them in src/libcharon/plugins/<name>/<name>_plugin.c).

> Of course you could do this with a signal, but, again I would like to
> avoid this as much as possible, because for example in java you don't
> have a library to send signals, and you will have to use something
> like Runtime.exec().

Not sure what you mean by signal, whether actual POSIX signals or some
other kind of IPC (because with POSIX signals you can't transmit any
other information than the signal itself).  But I just saw that there
are several libraries which allow you to use Unix domain sockets from
Java (JUDS or junixsocket for instance).  And other kinds of sockets
(TCP/UDP) are certainly also available in Java.
If you want to use Runtime.exec() you could use stroke directly to add
simple connections (with ipsec stroke add) and to initiate and control
those connections (ipsec up etc.).  Combined with the sql plugin, or
even by creating ipsec.conf files (and then calling ipsec update), this
would also work for complex configs.

> The SMP plugin seems a pretty good starting point, though it is only 
> used after the connection configurations have been made.

Yep, its functionality is pretty basic at the moment.  You could, of
course, extend it and submit the patches to us afterwards.

> Also, would it be ok, if a plugin, when created, started a running in
> a separate thread as far as the charon daemon is concerned?

Yes, that's no problem but most plugins that need separate threads use
callback_job_t instead, which simplifies this a lot as it relies on
threads provided by the global thread pool in charon.  The stroke
plugin, for instance, is one that uses this to read from the
aforementioned Unix domain socket.  Another example is the maemo plugin
which actually uses the assigned thread to execute the GLib main event
loop.  Just grep for callback_job_create to see other examples.

Since the main functionality of the charon daemon is contained in
libcharon you could also use JNI to actually include charon in your Java
application (by loading libcharon and the other libraries from it).
Configuration could then be transferred directly via JNI.  But doing
that is probably a lot more work than using or modifying some of the
existing plugins.

Regards,
Tobias