hoprd_inbox/
lib.rs

1//! ## hoprd-inbox
2//! This crate implements the functionality of the Message Inbox (MI) backend.
3//!
4//! The MI works as a non-persistent storage of received HOPR packets categorized by the application tag.
5//! The application tag works as a distinguisher of applications running on top of the HOPR protocol, similarly like
6//! ports work in TCP or UDP.
7//! Application tag is [represented](hopr_internal_types::protocol::Tag) by a 16-bit payload prefix and is built-in the HOPR protocol.
8//! If no tag is given, it defaults to `0`.
9//!
10//! The MI can use different backends, which must implement the [InboxBackend](inbox::InboxBackend) trait.
11//!
12//! ## How `InboxBackend` works
13//! The backend must ensure that both tagged and untagged messages can be `push`ed and `pop`ed to/from it.
14//! Backend can be persistent, but the current [RingBufferInboxBackend](ring::RingBufferInboxBackend) is in-memory only.
15//!
16//! The backend must have a finite capacity of messages, overwriting the oldest elements on `push` if the total capacity is reached.
17//! Messages can be `pop`ed by one (oldest first), or can be drained entirely using `pop_all` (sorted by oldest to latest).
18//! If application tag is specified on a `pop`/`pop_all`, only the messages of the given tag are retrieved. If no tag is
19//! specified, the messages are retrieved regardless the tag (`pop` retrieves the oldest message across all tags, `pop_all`
20//! retrieves all the messages from the entire backend sorted oldest to latest).
21//!
22//! Finally, the backends must hold some sort of timestamp information of when each message was `push`ed. That's because
23//! the backend must also support a `purge` operation which removes messages older than the given Unix timestamp.
24//!
25//! ## The Frontend
26//! The MI has a front-end type [MessageInbox](inbox::MessageInbox), which is thin thread-safe wrapper over a selected backend. It contains choices
27//! of specific parameters: tag type is fixed as a 16-bit unsigned integer to correspond with `core-packet`, the message
28//! type is set to [ApplicationData](hopr_internal_types::protocol::ApplicationData) type.
29//!
30//! The `MessageInbox` currently uses the `RingBufferInboxBacked` as its `InboxBackend` implementations.
31//! This backend is implemented as hash map (with application tag as a key) of ring-buffers of certain capacity `N`.
32//! Each bucket can therefore hold `N` messages which can be `pop`ed from oldest to newest.
33//! The maximum number of messages held in this instantiation of MI is therefore 65536 \* `N`
34//! (unless some tags are excluded). Note that in this implementation `N` must be a power of 2.
35//!
36//! Each `push` and `pop` operation is always followed by a `purge` call to evict expired entries.
37//!
38//! The frontend has the ability to filter out certain application tags on `push`, so that they are ignored by the MI.
39//!
40//! ## Usage
41//!
42//! The [Inbox] instance is supposed to live a singleton in the `hoprd` application, and as messages arrive, they
43//! will be pushed into the inbox. The REST API can then access this singleton to pop messages per request.
44//!
45//! For details on default configuration see [MessageInboxConfiguration](crate::config::MessageInboxConfiguration).
46
47/// Contains configuration object for [MessageInbox](inbox::MessageInbox).
48pub mod config;
49/// Defines the common traits and the [MessageInbox](inbox::MessageInbox) type.
50pub mod inbox;
51/// Implements ring-buffer based in-memory [InboxBackend](inbox::InboxBackend).
52pub mod ring;
53
54/// Alias type for message inbox.
55pub type Inbox = inbox::MessageInbox<
56    ring::RingBufferInboxBackend<hopr_internal_types::protocol::Tag, hopr_internal_types::protocol::ApplicationData>,
57>;