Extensibility, deployment and distribution, process connections

[ERnsTL]

Problem:

• Multiple processes are slow:
  • full process switches (not just green thread or native thread switch)
  • and have to communicate via kernel = ring switch and syscall ... super slow
• but need better way to allow separate development of components and extensibility and the source-level built-in compilation is not the solution
  • also leads to LGPL license to apply to components
  • and thus to the custom-made and per-project components
  • not desired

Evaluate:

• microVMs:
  • unikraft / kraftkit is fastest according to microVM benchmarks:
  • Rust examples: https://github.com/unikraft/catalog/tree/main/examples
  • and they say "just communicate via TCP, it is so fast"
  • probably because of virtio or vmnet, which is basically shared memory between host and guest
• Running in UEFI
  • example: https://github.com/codyd51/uefirc
  • very bare metal, but not sure if tha TCP facilities on that level are made for performance
• loading of rlib's which can be found in the target/ directory in every Rust project using Cargo.
  • does that exist?

Connections:

• TCP (?)
• named pipes: flowd-go uses that
• shared memory: rtrb ringbuffer, currently in use
• file-based like in NiFi

Plugin system:

• TODO dlopen c abi rust rust object as parameter - is that possible?
• https://www.reddit.com/r/rust/comments/vvutxu/how_does_rust_handle_sharing_code_as_a_dllso/
• Live-reloading rust, plugin-architecture: https://fasterthanli.me/articles/so-you-want-to-live-reload-rust#and-now-some-rust
• lazy_static, useful: https://lib.rs/crates/lazy_static
• libloading: https://lib.rs/crates/libloading
• abi_stable, the other option instead of dlopen: https://docs.rs/abi_stable/latest/abi_stable/
• use cdylib instead of dylib
• Issue for this: Allow export of Rust symbols from a C shared object via a staticlib rust-lang/rust#73295
• Calling from plugin into main app: https://www.reddit.com/r/rust/comments/zaggaj/help_with_having_cdylib_that_gets_loaded_in_c_via/

Building blocks of an FBP runtime:

• GUI for network design, debugging, status, tracing etc.
• Networked API and message format for accepting commands from GUI:
  • frontend/external one, for example noflo's FBP JSON protocol
  • internal
• Graph/Network state - nodes, edges etc.
• Runtime network state with processes - and signaling to processes
• Watchdog thread
• Component API definition - how instantiated, handover of connections, signaling connection, uplink into executor
• Connection and Queueing API
• Executor, which defines a profile of:
  • Component API implementation = how components are loaded, run and stopped
  • Connection, transfer and queueing mechanism
  • Ideally, distribution of components