tomaswolf commented on issue #791: URL: https://github.com/apache/mina-sshd/issues/791#issuecomment-3146482608
> and then maybe find a solution Thought some more about that. We have a server that doesn't respect the SSH protocol and that closes the connection prematurely. The current client code in Apache MINA sshd closes the session immediately if a write fails. Writing and this closing is asynchronous; reading occurs concurrently, and code may already be handling some other received SSH messages, and may have more SSH messages already in its buffer. If we wanted to process these messages, we would have to do quite a lot: - delay closing the session until all buffered messages have been processed. - suppress reading more data from the socket -- we could only deal with already fully buffered messages. - remember the exception and throw it once the session is closed. - suppress exceptions from writes. Processing buffered messages may cause more writes (window adjustments or other stuff). But we can't suppress exceptions on _all_ writes. There may be user code that pumps data through another channel; that code must get an exception when it writes data. - we must disable some SSH mechanisms. Processing a buffered message may trigger requesting a new key exchange, but obviously that cannot work anymore. So starting a new KEX must be disabled. - heartbeats must be disabled, they would produce more writes. - maybe other stuff that I didn't think of yet. - when we finally close the session and there are still any non-closed channels, re-throw the exception. Any such implementation would affect basically all the layers in the code. Testing this would be a nightmare. And what would we get: in a few very special cases (like yours) we might consider an actually failed connection to have completed normally, but in many other cases we'd still have a failed connection, partially transmitted data, and general wreckage. I will not implement and maintain something like this just for a broken server. Besides, an SSH session is always initiated by an SSH client. It is therefore also the client's responsibility to close the session, not the server's. If the SSH session terminates without the client closing it, you have one of: 1. a network failure, or 2. hit a server limit that made the server disconnect, or 3. a server bug. Maybe that "quit" command isn't the right command to send, or use the "end marker" method I outlined above. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
