Note that the current solution is easier to setup (no dependency) and does work with little overhead. It might still be better to stay at the HTTP(S) level. It depends arguably on the scale (e.g network of a dozen machines vs hundreds or even thousands) and how critical the commands are (e.g listing files versus
deleting directories or long computations).
Currently sending a command is done "blasting", cf e.g https://git.benetou.fr/utopiah/offline-octopus/src/branch/master/index.js#L139 which result in either taking shortcut (e.g not collecting return values that could show errors) or sequentially, thus blockingly, which is very slow and can result in hang ups.
Meanwhile, parallel solutions, e.g pssh cf https://parallel-ssh.readthedocs.io/en/latest/quickstart.html do exist.
Note that the current solution is easier to setup (no dependency) and does work with little overhead. It might still be better to stay at the HTTP(S) level. It depends arguably on the scale (e.g network of a dozen machines vs hundreds or even thousands) and how critical the commands are (e.g listing files versus
deleting directories or long computations).
Currently sending a command is done "blasting", cf e.g https://git.benetou.fr/utopiah/offline-octopus/src/branch/master/index.js#L139 which result in either taking shortcut (e.g not collecting return values that could show errors) or sequentially, thus blockingly, which is very slow and can result in hang ups.
Meanwhile, parallel solutions, e.g pssh cf https://parallel-ssh.readthedocs.io/en/latest/quickstart.html do exist.
Note that the current solution is easier to setup (no dependency) and does work with little overhead. It might still be better to stay at the HTTP(S) level. It depends arguably on the scale (e.g network of a dozen machines vs hundreds or even thousands) and how critical the commands are (e.g listing files versus
deleting directories or long computations).