IETF-SSH archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: fds beyond 0/1/2



On Thu, 26 Aug 2010, der Mouse wrote:

> According to the PROTOCOL document you (later) pointed me at (and thank
> you, I've been wanting such a thing for a while), eow%openssh.com@localhost does
> not do what my data-eof%rodents.montreal.qc.ca@localhost request does.  Rather,
> eow%openssh.com@localhost pushes back what I might loosely call SIGPIPE/EPIPE
> status, ie, "don't write more to me", and does it for the whole
> channel.
> 
> data-eof@ is for signaling "I am not going to write anything more", ie,
> a traditional EOF.  The difference between it and SSH_MSG_CHANNEL_EOF
> is that data-eof@ is for one data flow, not for the whole channel.  (If
> there's only one flow in use in that direction on the channel, it is
> functionally equivalent to SSH_MSG_CHANNEL_EOF.)

I'm not sure I follow; SSH_MSG_CHANNEL_EOF doesn't shut down data
bidirectionally.  From rfc4254:

> 5.3.  Closing a Channel
>
>   When a party will no longer send more data to a channel, it SHOULD
>   send SSH_MSG_CHANNEL_EOF.
>
>      byte      SSH_MSG_CHANNEL_EOF
>      uint32    recipient channel
>
>   No explicit response is sent to this message.  However, the
>   application may send EOF to whatever is at the other end of the
>   channel.  Note that the channel remains open after this message, and
>   more data may still be sent in the other direction.  This message
>   does not consume window space and can be sent even if no window space
>   is available.

though it does not allow signalling of closure of the extended-data
subchannel - is this what you are talking about?

> > The documentation for this (and other OpenSSH extensions) is at:
> 
> > http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/PROTOCOL?rev=HEAD
> 
> That file does not, amusingly enough, seem to include the one
> @openssh.com extension I saw in the wild and went looking for
> documentation on, keepalive%openssh.com@localhost.

that's because youd don't have to actually implement it, just follow the
spec and return SSH_MSG_UNIMPLEMENTED/SSH_MSG_CHANNEL_FAILURE

-d



Home | Main Index | Thread Index | Old Index