The DHT will find your plugin automatically if it is installed in the
right directory and has a suitable file name following the naming
conventions. Your plugin must expose the right symbols with the correct
API, and then the DHT will basically 'ask' your plugin what block types
it is responsible for, and for those then ask your plugin to evaluate
queries and replies.
Depending on what your blocks look like, you may be able to re-use the
logic from the FS block plugin, or write new logic, hard to say, depends
on what you are storing ;-).
DHTU works a bit differently, in that here you need to explicitly
configure the plugin (the underlay plugins are not automatically
'discovered' and used). DHTU is really just there to allow a DHT node to
communicate with *neighbours*, it doesn't make routing decisions. Thus I
don't think it is suitable to 'guide' each message, but maybe you mean
something else by 'guide'. DHTU is for *transmitting* messages.
On 2/12/24 12:42, Big Boy wrote:
Good day! How exactly does a plugin of a service link up to the main
service? I looked in the C tutorial's subsection regarding DHT and the
need to provide a block plugin in order to validate requests/replies and
it's not quite clear to me how exactly does the service use it in its
inner processes. On a sidenote, would it be an issue to use the same
block validation logic in the FS block plugin?
Another question is about the DHTU, does it also work as a plugin and
would it allow me to customize the underlay in order to guide each
message in the network?
Thank you in advance!
Andrei Usurelu
