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.
Olga On Wed, Sep 26, 2012 at 7:16 AM, Russ Allbery <[email protected]> wrote: > ольга крыжановская <[email protected]> writes: > >> Russ, here is my RFE: >> - Support SCTP. > > What does that mean for an application program? > >> - If SCTP is supported, allow that more than stdin/stdout/stderr >> streams (with fifo semantics only, not full file I/O with seek()) to >> be forwarded. This should be easy, as SCTP can embed many streams with >> in a single SCTP connection. > > The remctl protocol already makes it fairly easy to add additional > streams of output from the program run by the server. There just hasn't > been any reason to try to implement that since no one has asked for it. > Could you explain more about your use case? Do you want the remctld > server to open additional file descriptors before running the program? > How many? Why? > > -- > Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> -- , _ _ , { \/`o;====- Olga Kryzhanovska -====;o`\/ } .----'-/`-/ [email protected] \-`\-'----. `'-..-| / http://twitter.com/fleyta \ |-..-'` /\/\ Solaris/BSD//C/C++ programmer /\/\ `--` `--` ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
