This migrates the device-sessions from Redis into PostgreSQL. This fixes
a performance issue in case the same DevAddr is reused many times
(e.g. devices rejoining very often or a NetID with small DevAddr space).
There were two issues:
The Redis key containing the DevAddr -> DevEUIs mapping could contain
DevEUIs that no longer used the DevAddr. This mapping would only expire
from the Redis database after none of the devices would use the DevAddr
for more than the configured device_session_ttl.
The other issue with the previous approach was that on for example a
Type 7 NetID, a single DevAddr could be re-used multiple times. As each
device-session could be stored on a different Redis Cluster instance,
there was no option to retrieve all device-sessions at once. Thus a high
re-usage of a single DevAddr would cause an increase in Redis queries.
Both issues are solved by moving the device-session into PostgreSQL
as the DevAddr is a column of the device record and thus filtering on
this DevAddr would always result in the devices using that DevAddr, as
well all device-sessions for a DevAddr can be retrieved by a single
query.
Note that to migrate the device-sessions, you must run:
chirpstack -c path/to/config migrate-device-sessions-to-postgres
A nice side-effect is that a PostgreSQL backup / restore will also
restore the device connectivity.
Closes#362 and #74.
This refactors the last bit of code that depends on the OpenSSL C
library. Note that the openssl-probe does not depend on OpenSSL, it only
tries to detect the CA certificate directory on the host system.
This still depends on unreleased diesel and diesel-async code. As soon
as new diesel and diesel-async code has been released, we can remove
the [patch.crates-io] from Cargo.toml.
This removes the aws-sdk-sns crate (+ dependencies) and refactors the
AWS SNS integration to use reqwest for the API call + aws-sign-v4 for
creating the AWS request signature.
This crate can be used to build external ChirpStack integrations.
The plan is to move all non-HTTP based integrations to external
repositories. The reason is that these integrations usually require
quite some external dependencies as these rely on their own SDKs.
