sergio
05886022e0
Opción B: RemoteEngine orquesta en un host remoto tunelando el wire
del daemon sobre un canal SSH direct-streamlocal hacia el sandokan.sock
remoto. El protocolo es idéntico al de DaemonEngine (postcard
length-prefixed) — sólo cambia el transporte, así que read_frame/
write_frame se reusan tal cual.
- brahman-ssh-multiplex: + SshSession::forward_unix — abre un canal
direct-streamlocal y devuelve su ChannelStream (AsyncRead+AsyncWrite).
- sandokan-daemon: protocol ahora pub, exporta read_frame/write_frame.
- sandokan-remote: RemoteEngine { SshSession + remote_socket }.
connect() o with_session(); cada operación abre un canal nuevo
(multiplexado sobre la conexión maestra).
- sandokan umbrella re-exporta RemoteEngine.
Completa Fase B: sandokan tiene Local + Daemon + Remote + auto().
cargo check --workspace verde. RemoteEngine necesita un host remoto
con `sandokan daemon` para validación runtime (sin unit test).
Opción A (text-parse del CLI por compat) queda pendiente por decisión
del usuario.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
20 lines
774 B
Rust
20 lines
774 B
Rust
//! sandokan-daemon — `DaemonEngine` + loop servidor.
|
|
//!
|
|
//! Permite que el orquestador corra en un proceso y otros lo consuman
|
|
//! sin reimplementar la lógica: el `DaemonEngine` (cliente) implementa
|
|
//! el trait [`sandokan_core::Engine`] enviando requests postcard
|
|
//! length-prefixed sobre un Unix socket; [`serve`] corre el lado
|
|
//! servidor envolviendo cualquier `Engine` (típicamente un `LocalEngine`).
|
|
//!
|
|
//! Es la pieza que materializa el patrón horizontal de sandokan: el
|
|
//! primer binario que arranca gana el socket y expone el engine; los
|
|
//! demás se le suman como `DaemonEngine`.
|
|
|
|
mod client;
|
|
pub mod protocol;
|
|
mod server;
|
|
|
|
pub use client::DaemonEngine;
|
|
pub use protocol::{read_frame, write_frame, DaemonRequest, DaemonResponse};
|
|
pub use server::serve;
|