Re: channel association

[der Mouse <mouse%Rodents.Montreal.QC.CA@localhost>]

>> 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.)

> 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.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse%rodents.montreal.qc.ca@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B