tomaswolf commented on a change in pull request #201:
URL: https://github.com/apache/mina-sshd/pull/201#discussion_r670204650
##########
File path:
sshd-core/src/main/java/org/apache/sshd/common/session/helpers/AbstractSession.java
##########
@@ -109,6 +109,16 @@
*/
public static final String SESSION = "org.apache.sshd.session";
+ /**
+ * A last-resort timeout for waiting after having received a KEX_INIT
message from the peer until we have prepared
+ * our own KEX proposal. This timeout should actually never be hit unless
there is a serious deadlock somewhere and
+ * the session is never closed.
+ *
+ * @see <a
href="https://issues.apache.org/jira/browse/SSHD-1197";>SSHD-1197</a>
+ * @see #doKexNegotiation()
+ */
+ private static final Duration KEX_PROPOSAL_SETUP_TIMEOUT =
Duration.ofSeconds(42);
Review comment:
I've been thinking more about this -- I'll add it with validation for
now. Reason: we are indeed waiting until sendKexInit has sent the buffer (or
rather, has queued it for sending on the IOSession). But I'm still not happy
with that whole KEX implementation. In particular, this having to wait until
the buffer is sent should not be necessary, but with the current implementation
is unavoidable because of the
`ReservedSessionMessagesHandler.sendKexInitRequest` hook added for SSHD-1097,
which can modify the buffer and even might send it on its own.
That hook was added recently, and is used only in that "endless tarpit"
thing, where it actually only suppresses writing the buffer. If that were
changed to something that could only say "don't send the message", I could
extract that whole KEX state machine in a separate class and it would even
possible to do an implementation that didn't have to wait at all for this race
condition case handled here.
I wouldn't add a full explanation of how KEX works, that's explained in the
RFCs. But the new timeout property will have a comment explaining what it is
for.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
