remctl 3.3 released

[Russ Allbery]

ольга крыжановская <olga.kryzhanovska at gmail.com> writes:

> Russ, I was comparing this only to rsh. In rsh you can not have extra
> streams so the process called on the remote site can not use the extra
> channels for more detailed communication. Idea was, caller opens extra
> fds which are inherited by the remctl process via fork(), or passed
> via command line by path name (including paths listed in
> /proc/num/fd/12345). Then remctl asks the server to open the same fd
> numbers as extra stream connections for the process it will launch,
> which can be used for extra communication.

Ah, okay.  Currently, remctl doesn't offer any sort of bidirectional
communication with the server program.  The client sends a command, which
the server then runs and returns the output and exit status from.
Bidirectional streaming of data is on the roadmap for the next major
protocol revision, but it requires a fair bit of work to double-buffer the
data to ensure there aren't any deadlocks.  I haven't started working on
that yet in large part because we've found it's rarely that important.
But it's something I'll get to eventually, since every once in a great
while it would be useful to run an interactive program via remctl.

Note, though, that remctl isn't intended as a full replacement for ssh.
At some point, it's probably worth considering whether you want to just
use ssh.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>