Previously it was not possible to disable SQLite because of a linker
error. Also, `sqlite3.h` was always required to be present. This adds
an example to `config.mk.example` and fixes both issues.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
Read transactions need a short, blocking, lock for the database, during
which no write transaction can be started - this means the interaction
of the agent, TX, and RX tasks may block each other if anything takes
longer than 1 ms. Thus, we increase the timeout for blocking locks to
100 ms to significantly reduce that probability.
See: https://www.sqlite.org/src/doc/204dbc15a682125c/doc/wal-lock.md
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This is required to allow bundles being forwarded to storage by
specifying the storage node (a configuration parameter) as next hop.
The CLA initialization is modified slightly to register the CLA before
executing `cla_launch` to ensure that the bundle processor knows about
it when it is executed.
This also moves the Sqlite CLA initialization to the `sqlite_launch`
function because the CLA has to be known ("registered") before we send
a signal to the BP (which is done during link creation).
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
- Introduces a CompoundBundleId to filter exactly one bundle
- Filter bundles either by their ID or selected metadata
- Transfer the entire StorageCall object to the CLA via the agent queue
Signed-off-by: Maximilian Nitsch <maximilian.nitsch@d3tn.com>
To eliminate potential race conditions where rows are deleted before the
CLA processes them, the select statement is moved from the agent to the
CLA and everything is wrapped in a transaction to read all or nothing.
Signed-off-by: Maximilian Nitsch <maximilian.nitsch@d3tn.com>
If bundles that were created by the μD3TN instance itself are stored in
the database via the SQLiteCLA and are received again at a later point
in time, μD3TN recognizes that the source node ID matches its own and
EID spoofing is detected.
This commit adds an exception to perform EID spoofing detection only for
packets that were not received by the SQLiteCLA.
Signed-off-by: Maximilian Nitsch <maximilian.nitsch@d3tn.com>
The SQLiteCLA makes it possible to write bundles, that are to be sent
via this CLA, to an SQLite database in order to persist them over a
longer period of time and also a restart of μD3TN.
The bundles are saved together with selected metadata (source EID,
destination EID, creation timestamp) in the "bundles" table. A
combination of source EID and creation timestamp is used as the primary
key.
To return bundles to μD3TN, they are read from the database and injected
via the cla_read() function, just like other CLAs that receive bundles.
To trigger this, commands are read from a queue that specify which
bundles are to be read from the database.
Signed-off-by: Maximilian Nitsch <maximilian.nitsch@d3tn.com>
In order to prepare the implementation of a SQLite-based storage CLA, a
basic structure of this CLA with empty functions is created and
adjustments are made to the configuration/initialization functions and
the build system.
Signed-off-by: Maximilian Nitsch <maximilian.nitsch@d3tn.com>
