mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Evans (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SSHD-108) Add upload monitoring to sftp and scp
Date Sat, 21 Feb 2015 15:50:19 GMT

    [ https://issues.apache.org/jira/browse/SSHD-108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14330308#comment-14330308

David Evans commented on SSHD-108:

This issue has been here for several years with no updates, and I've hit the same problem,
so here's a possible solution (requires a small API-breaking change to the library):

Clients seem to reliably send SSH_FXP_CLOSE after they have uploaded a file, but if the upload
is aborted, they will instead reset the connection. However MINA SSHD handles both of these
scenarios by closing the stream and calling handleClose on the file.

The change would be to provide a new interface method in SshFile (perhaps "handleClientClose").
With this, handleClose continues to be called in all cases, while handleClientClose is called
- before handleClose - only if SSH_FXP_CLOSE was the trigger (I also considered a boolean
parameter but a new method seems cleaner).

Specifically, this line would be the only one which triggers both handleClientClose and handleClose:
(SftpSubsystem.Handle would also need to be extended to be aware of which close type is required)

There *may* also need to be a change to make this work nicely with SCP. Currently the SCP
path doesn't call handleClose at all, but perhaps it should? (since it gets called from exception
paths already it seems like it is intended as a general clean-up method when finished with
a file).

An alternative which would not require an API-breaking change (and is slightly more open to
future variants, e.g. pause detection) would be to provide an interface which could be optionally
implemented by the OutputStream returned by createOutputStream. This would have just 1 extra
method (perhaps "handleSuccess"), which would be called in the same scenarios as described
for handleClientClose above. The down-side to this approach is discoverability; the best way
to explain it is in the JavaDoc of createOutputStream, but any user missing that would likely
never know the functionality exists.

I'm aware that SshFile is shared between server and client logic, and I'm only thinking about
this from a server perspective, so it might be nice to get the client-side perspective of
this API change (specifically, is there any similar client event where it would make sense
to share this new method).

It may also be worth noting that an abort causes java.io.IOException: Connection reset by
peer, whereas pausing causes java.io.IOException: Broken pipe (at least with FileZilla as
the client). While I don't need to access that information for my needs, a future user might
want to distinguish between those two events as well. I couldn't figure out a way to expose
that though, since both seem to be swallowed and translated into a close connection command.

> Add upload monitoring to sftp and scp
> -------------------------------------
>                 Key: SSHD-108
>                 URL: https://issues.apache.org/jira/browse/SSHD-108
>             Project: MINA SSHD
>          Issue Type: Improvement
>    Affects Versions: 0.5.0
>            Reporter: Richard Evans
>            Priority: Minor
> We have sshd integrated into our application and sftp is working fine.  One of the requirements
is to initiate some action when a file upload it complete.  I have made this work by implementing
handleClose in my SshFile implementation and performing the action if createOutputStream had
been called previously.  This seems a bit ugly though; it might be nicer if there was some
plug in mechanism to monitor file transfers.
> Ideally the monitor would be able to distinguish between a successful upload and a cancelled
one (via ctrl-c at the client), but a quick perusal of the sftp stuff seems to inidicate that
this is not possible. 

This message was sent by Atlassian JIRA

View raw message