[
https://issues.apache.org/jira/browse/SSHD-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415423#comment-16415423
]
Goldstein Lyor commented on SSHD-812:
-------------------------------------
Of course it does - each session is single threaded - otherwise all hell breaks
loose - e.g., how would you associate a reply to an SFTP command to the correct
one if more than one command is executed in parallel ?
Let us assume that the SFTP server allows parallel commands on the same session:
* Client sends _stat_ command - server starts processing it - thread _A_ is
"stuck" waiting for response
* Client sends _remove_ command (in another thread) through the *same* session
- server starts processing it - thread B is "stuck" waiting for response
* Let's assume that the _stat_ command references a non-existing file - i.e.,
it should fail, whereas _remove_ command references an existing file - i.e. it
should succeed
* Let's assume that the _remove_ command completes first - i.e., successfully -
i.e. {{SSH_FX_OK}} is returned on the session
* Let's further assume that _stat_ command completes unsuccessfully shortly
afterwards and {{SSH_FX_ERROR}} is returned on the session
* Since we have no way of associating each response with the client thread that
sent it. it is quite conceivable that the 2 response will be "crossed" - i.e.,
thread _A_ will believe _stat_ command succeeded (and will failed to decode the
response since it won't be a _stat_ response), and thread _B_ will believe
_remove_ command failed - whereas it succeeded.
This is not part of the SFTP protocol specification (in part because of the
scenario I just indicated). If there is a slowdown because of your middle-man -
then *tune* it - there are many (many) properties that can be used to fine-tune
SSHD server - NIO worker threads, SFTP buffer sizes, etc... Eventually though,
you are limited by the SFTP standard and not by the code. What you are
suggesting is *multiplexing* commands - which is not part of SFTP standard (nor
any SSH standard I know of that is similar to SFTP).
> support asynchronization mode for sftp subsystem
> ------------------------------------------------
>
> Key: SSHD-812
> URL: https://issues.apache.org/jira/browse/SSHD-812
> Project: MINA SSHD
> Issue Type: New Feature
> Affects Versions: 1.7.0
> Environment: java1.8, linux
> Reporter: Zhenliang Su
> Priority: Major
> Labels: asynchronous, sftp
> Attachments: Main.java
>
>
> I used SSHD as a middleman between client and target sftp server.
> I found that, when filezilla client directly connect to the target sftp
> server, it transfers fast. When filezilla client connect to the middleman, it
> transfers slow.
> I analyzed the source code of
> org.apache.sshd.server.subsystem.sftp.SftpSubsystem#doRead, and I found it
> behaves like block mode, and client's other SSH_FXP_READ request blocked in
> the same thread.
>
> my middleman code:
> [^Main.java]
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
