Re: closing a channel

[nisse%lysator.liu.se@localhost (Niels Möller)]

Wei Dai <weidai%eskimo.com@localhost> writes:

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

To me, a channel can be viewed as three parts: two dataflows, one for
each directions, and sometimes auxillary communication like
CHANNEL_REQUEST.

If the parties are A and B, the dataflow from A to B are controlled by
the CHANNEL_DATA, CHANNEL_EXTENDED_DATA and CHANNEL_EOF sent by A, and
the WINDOW_ADJUST messages sent by B.

I think it's best to treat this dataflow independently from the
dataflow in the other direction, and from the auxillary communication.
Theyäre three orthogonal components of the channel.

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

It's hard to know that for sure. As I said in my other message,
initiating close when EOF have been both sent and received is the
right thing to do for most channels, but it doesn't quite work for
sessions.

When I do

  ssh host cat foo

I want the channel to be closed and the local ssh process to exit when
all data has been sent by the server, and the remote process has died.
I think it would be annoying if the above command would keep the
channel open for ever just because the client never sends EOF. If the
server waits for EOF, users would have to type

  ssh host cat foo </dev/null

or

  ssh host cat foo
  ^D

to get the channel to close when they want. That would make sense, but
it would also annoy users. So I think it's better that the server
sends CHANNEL_CLOSE when the remote process is gone, regardless of
whether or not the client has sent EOF. (Clients replying to
exit-status with CHANNEL_EOF would also work; that's what my code used
to do, but I consider that solution less robust than simply having the
server initiate close).

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

For other channels, the "close whenever you have both sent and
received EOF"-rule works fine.

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

Consider the

  ssh host cat foo

case. I'm afraid your simple rules are not sufficient (and I have
actually implemented them).

Regards,
/Niels