Re: fds beyond 0/1/2

[Simon Tatham <anakin%pobox.com@localhost>]

der Mouse  <mouse%Rodents-Montreal.ORG@localhost> wrote:
> Hm, this actually raises a potential issue: we really should have
> separate back-pressure on each fd, so that failure to consume data from
> a particular fd does not wedge the whole channel.

I would say that this is the biggest issue of all, and should be
carefully considered before even _starting_ to write the detailed
spec and nail down things like the names and formats of new channel
requests.

What are the pros and cons of folding multiple (fd,direction) pairs
into a single window? Why did we ever invent CHANNEL_EXTENDED_DATA
for stderr at all, instead of setting up two channels with separate
windows and linking them together somehow? Only by understanding
that question can we get a clear idea of whether we should extend
the mechanism for further fds or instead use separate channels.

As far as I can see, the key advantage of CHANNEL_EXTENDED_DATA is
that it allows the recipient to preserve the same interleaving of
the stdout and stderr data, in the case where this is perceptible
(because the SSH client's stdout and stderr fds are duplicates of
each other, i.e. target the _same_ terminal device or pipe or file).

However, in practice, this is of limited use to a server on a
POSIXlike platform, because it in turn can't know what the right
interleaving of stdout and stderr was from the point of view of the
application doing the writing. It can only select() between the
output and error channels, and when data becomes available on both
at once it can't know precisely what sequence of writes was
intended. Of course if _it_ folds stdout and stderr into the same fd
(as it does when allocating a pty) then interleaving is perfect -
but then you don't get CHANNEL_EXTENDED_DATA at all.

So it seems to me that the real added value of CHANNEL_EXTENDED_DATA
is only realised in cases where the server diverges from POSIX in
some way. Therefore, a consciously POSIX-oriented extension to
handle multiple fds ought not to be perpetuating the use of the
mechanism.

(A year or two ago I wrote an application which tried to forward an
arbitrary set of file descriptors across a serialisation boundary in
a completely different context from SSH, and what I actually did was
to have the client _work out_ which of its fds were duplicates of
each other and then pass that information to the server. So the
server would allocate a single pipe on its side for both stdout and
stderr, if and only if the client had not redirected them to
different places. Thus, stdout and stderr output were interleaved
exactly as the application intended in cases where you could tell
the difference, and separated correctly otherwise.)

Cheers,
Simon
-- 
Simon Tatham         "I'm going to pull his head off. Ear by ear."
<anakin%pobox.com@localhost>                          - a games teacher