Commit 9ea89e14 authored by Niels Möller's avatar Niels Möller
Browse files

Updated the section on channel close.

Rev: doc/NOTES:1.10
parent dd541a63
......@@ -71,7 +71,7 @@ zero, the CHANNEL_EOF message is sent.
The decrementing of the counter is done by the close-callback for the
fd, not by the read handler, as this is the easiest way to
ensure that it is called exactly once whenever a fd dies. However, the
sending of the CHANNEL_EOF massage is done by the read handlers
sending of the CHANNEL_EOF message is done by the read handlers
do_channel_write() and do_channel_write_extended(). This is because
otherwise, eof on bidirectional fd:s migth be delayed until it is
closed also for writing. There are more unsolved issues with
......@@ -82,36 +82,44 @@ direction is closed (with shutdown()) long before the other.
CLOSING CHANNELS
The right conditions for closing a channel, and in particular a
session, are even more subtle. There are three events that may happen
in arbitrary order:
session, are even more subtle. The basic rules are:
(i) The client sends EOF on the channel.
1. When SSH_MSG_CHANNEL_CLOSE is both sent and received, the channel
is killed. This is unconditionally required by the spec.
(ii) The server sends EOF on the channel (this happens when there are
no more processes which have the files the server has opened for stdout
or stderr open).
2. When SSH_MSG_CHANNEL_EOF is both sent and received,
SSH_MSG_CHANNEL_CLOSE is sent. This is a rule with a few
exceptions, controlled by the CHANNEL_CLOSE_AT_EOF, see below.
gatewaying channels).
(iii) The child process created by the server dies. An exit-status or
exit-signal message is sent to the client.
These two rules are sufficient for most channel types.
lshd handles these conditions as follows: It will not send a CLOSE
message until *all* the three events above have occurred. Naturally,
this could cause the channel to stay open for ever, for instance if
the child process has started a background job that happens to keep
its stdin open (perhaps without ever using it). In most cases this is
not what you want.
When looking at the channel close logic for session channels, one has
to consider these three events that may occur in arbitrary order:
The lsh client will, by default, respond to exit-signal or exit-status
with an EOF message. If this is the last event keeping the server from
closing the channel, the channel is finally closed, on the server's
initiative.
* The client sends SSH_MSG_CHANNEL_EOF on the channel.
It is conceivable that the user may want to continue communicating
with remaining child processes even after that the first process has
died (i.e. after that it has received exit-status or exit-signal from
the server). In this case, the client should be considered not to send
EOF until it detects EOF on stdin.
* The server sends SSH_MSG_CHANNEL_EOF on the channel (this happens
when there are no more processes which have the files the server
has opened for stdout or stderr open).
* The child process created by the server dies. An exit-status or
exit-signal message is sent to the client.
Previous versions of lshd handled these conditions as follows: It
closed the channel according to rule (2) above, no exceptions. This
causes other clients to hang, because they never send any
SSH_MSG_CHANNEL_EOF. Using lsh did work right, only because it
responded to the exit-status message with a SSH_MSG_CHANNEL_EOF.
But the server can't rely on clients sending SSH_MSG_CHANNEL_EOF.
Instead, it must treat process death in much the same way as reception
of SSH_MSG_CHANNEL_EOF. The channel is closed once the server has both
encountered EOF on the process' stdout and stderr (resulting in a
SSH_MSG_CHANNEL_EOF), and sent an exit-status or exit-signal message.
As a further complication, rule (2) must be relaxed, because otherwise
the channel may get closed before the exit-status message is sent.
PARSING USING STRUCT SIMPLE_BUFFER
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment