Here is the issue in a nutshell - a client might open an SSH tunnel, send some data and close (normally) its side of the tunnel before the channel to the other side has been successfully established and all data transmitted. Currently a race condition may occur in such a scenario where the code closes the channel while pending messages are still in transit.
The patch attempts to accumulate pending messages until channel is open (successfully) and then flush them while maintaining their *order*. At the same time, it attempts to "delay" other messages that may arrive while flushing is in progress so that they will also be sent in the correct order. It also delays the closing of the tunnel until pending data has been flushed (unless an error occurs during the flush...). Since the code is a bit complicated, I would appreciate several extra pairs of eyes reviewing the code. My main areas of concern are (though please feel free to add more): * Does it solve the problem? * Are there any race conditions/deadlocks that it might encounter ? * Is throughput adversely impacted by the extra overhead involved in processing incoming messages - even if no more pending messages. The PR can be found at https://github.com/apache/mina-sshd/pull/72/ and a branch containing this code can be checked out from https://github.com/lgoldstein/mina-sshd/tree/SSHD-849. I would really appreciate your feedback and review on the posted code. Thanks Lyor
