Re: fds beyond 0/1/2

[Jeffrey Hutzelman <jhutz%cmu.edu@localhost>]

--On Wednesday, August 25, 2010 04:48:31 PM -0500 Nicolas Williams 
<Nicolas.Williams%oracle.com@localhost> wrote:

> That's true in the pty case (because the stdout/stderr distinction is
> lost before the writes even happen as the two fildes will both refer to
> the same pty).
>
> It's not necessarily true in the no-pty case.  If the server uses two
> distinct pipes for stdout and stderr then the relative ordering of
> stdout/stderr writes will be lost.

But it's _already_ been lost, because there is no guarantee that the server 
will see those pipes become readable in the order in which the app wrote to 
them; they may even become readable at the same time.  The app may write to 
stdout, then stderr, then stdout again before the server has read the first 
bit of stdout, so it doesn't even know there was an interleave, let alone 
where it is.

The only way to preserve relative ordering of stdout/stderr for the server 
to send them in the right order is for the server and app to have a 
communication channel that is already interleaved, either through something 
more complex than a pair of pipes or because they've already been combined 
into a single stream, as in the pty case.


> Do you really need the multiple fd thing?

It seems like it would be useful.  I've certainly encountered situations 
where it was useful to connect multiple fds between processes running on 
the same machine, and what is ssh if not a way to start and communicate 
with processes running on some other machine?

> Sounds like you might need to
> do some violence to the connection protocol...  Well, maybe not so much
> violence, just a way to link channels.

I don't think it'd be too bad.  I can think of three ways to do this:

1) A channel request on the session channel that results in creation of
  a new channel a la SSH_MSG_CHANNEL_OPEN.

  I don't recommend this; it's a horrible abstraction violation and
  basically requires repeating all of the previously common bits of
  channel setup in a new place.  That'll get particularly annoying
  if we ever add a new variation on SSH_MSG_CHANNEL_OPEN.

2) A new "fd" channel type, whose type-specific channel request data
  includes the channel number of the existing session channel, the
  remote fd number, and the direction information.

3) A new generic "pipe" channel type, which establishes a channel but
  doesn't bind it to anything, combined with a new "dup2" channel
  request on the session channel that specifies the remote fd number,
  direction information, and the existing channel to connect the fd
  to.  The existing channel would have to be one of
  - an unused pipe channel
  - a pipe channel already attached to this session
  - the session channel

  Note that this allows you to attach multiple fds to the same channel,
  including the main session channel.  One could even use this to set
  up a "normal" session with separate flow control for stdout and stderr.

-- Jeff