Re: closing a channel

[Wei Dai <weidai%eskimo.com@localhost>]

On Fri, Mar 22, 2002 at 10:30:52PM +0100, Niels Möller wrote:
> * One could delay the CHANNEL_EOF until after the CHANNEL_REQUEST
>   message. I think that's bad, there's no reson not to tell the client
>   right away that it will get no more data on the channel.

What's the purpose of CHANNEL_EOF, anyway? I thought it was used to tell
the other side that no more data will be sent so that the other side can
feel free to close the channel whenever it finishes sending its data. If
you're going to send more information (e.g., the exit code) in the form of
a CHANNEL_REQUEST after sending CHANNEL_EOF, then how does the other side
know when it's safe to close the channel without losing information?

On Fri, Mar 22, 2002 at 11:35:21PM +0100, denis bider wrote:
> But if I knew that I can rely on the server to send 'exit-status' or to
> close the channel upon child process termination, I would prefer not to rush
> with my own CHANNEL_CLOSE so that I can possibly catch the program's exit   
> code.

That's fine in the case of a shell command, but what about other types of
channels where the concept of child process termination doesn't apply?

My interpretation is that no channel data or requests should be sent after
CHANNEL_EOF, but SSH_MSG_CHANNEL_SUCCESS and SSH_MSG_CHANNEL_FAILURE are
allowed. I prefer this interpretation because it allows a simple rule for
deciding when to initiate CHANNEL_CLOSE for all types of channels that
ensures channels don't stay open after they're no longer useful. The rule
is to do it as soon as both of the following two conditions are met: 

1. CHANNEL_EOF has been sent by this side (i.e. this side has no more data
or requests to send)
2. CHANNEL_EOF has been received from the other side, or this side cannot
process any more incoming channel data or requests.