ольга крыжановская <[email protected]> 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 ([email protected]) <http://www.eyrie.org/~eagle/> ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
