Re: channel association

[Nicolas Williams <Nicolas.Williams%sun.com@localhost>]

On Wed, Apr 14, 2004 at 04:54:13PM -0400, der Mouse wrote:
> >> More generally, it is a conceptual problem to associate a request
> >> with a session, but have no way to associate an asynchronous
> >> response to that request with the relevant session [...]
> > Agreed.  But note that the draft does say "[t]he resulting channels
> > are independent of the session, ..."
> 
> This is true in terms of their lifetime, but not in terms of the
> content they carry.  (Note that the following phrase, which you didn't
> quote, specifically speaks of the lifetime, strongly implying that this
> remark is intended to refer to channel lifetimes.)

Certainly reading that sentence doesn't make the problem immediately
apparent, but I do think that the first clause of that sentence has
meaning beyond that of the second clause.  But let's not quibble.  The
text could be clarified and the problem could be fixed in a separate
doc.

> > There are several fixes for this that I can imagine:
> 
> > a) Add a channel request for opening forwarded whatever channels.
> 
> > b) Add new SSH_MSG_CHANNEL_OPEN channel types for channels associated
> > with session channels that includes the channel id of the associated
> > session channel.
> 
> > c) Add new channel requests for associating an open channel with a
> > session channel.
> 
> > I much prefer (b).
> 
> Me too, and that's what I'm doing for the moment.  For example, when my
> client requests agent forwarding, it does so by requesting
> "fixed-auth-agent-req%rodents.montreal.qc.ca@localhost", and if that is refused
> it will fall back to trying "auth-agent-req", noting in the process
> that the resulting agent forwarding is inconsistent with the kind of
> optimization I want to do.  The fixed- request is just like the one in
> the draft except it includes an additional uint32, which is returned in
> the "fixed-auth-agent%rodents.montreal.qc.ca@localhost" CHANNEL_OPEN that comes
> back when a forwarded connection is called for.  X forwarding, when I
> add that, will work analogously.
> 
> Unless, of course, someone comes up with a reason to do otherwise,
> which is why I was asking if anyone had addressed it already.

I think this is the way to go.  Obviously we'd need a standard channel
open request name, but that's a minor detail.