Hello Flavio,
to my knowledge SFTP is not covered by the mentioned RFC 1350 (TFTP) and there
is no RFC which does. As of today there are only a number of drafts specifying
the SFTP protocol.
The FileZilla-Project wiki has a page [1] with links to most or all relevant
RFCs and SFTP specification drafts (English Wikipedia entry for 'SSH File
Transfer Protocol' is also a good starting point). Please see for yourself
whether SFTP does specify the ominous final packet.
Cheers
Volker
[1] https://wiki.filezilla-project.org/SFTP_specifications
Von: Flavio Orfano [mailto:forf...@hotmail.com]
Gesendet: Freitag, 12. Dezember 2014 01:49
An: jsch-users@lists.sourceforge.net
Betreff: [JSch-users] SFTP RFCs
Hello Lads,
I do use JSCH(version 1.0.50) for SFTP on my application .
Running our component against a Sterling Integrator(IBM) to do a SFTP pooling
is failing due to the following:
According to them when the SFTP is done with a file, their Sterling Integrator
(IBM) sends a final packet and waits for a ACK from my component (which uses
JSCH) but as it never get the ACK from us saying all is fine then their
Sterling Integrator resend the file again and again (infinite loop).
They mention that this is according to an RFC (have to confirm with them).
Doing a quick search in google I could find the RFC 1350
https://tools.ietf.org/html/rfc1350. in this RFC it mention about normal
termination:
Normal Termination
The end of a transfer is marked by a DATA packet that contains
between 0 and 511 bytes of data (i.e., Datagram length < 516). This
packet is acknowledged by an ACK packet like all other DATA packets.
The host acknowledging the final DATA packet may terminate its side
of the connection on sending the final ACK. On the other hand,
dallying is encouraged. This means that the host sending the final
ACK will wait for a while before terminating in order to retransmit
the final ACK if it has been lost. The acknowledger will know that
the ACK has been lost if it receives the final DATA packet again.
The host sending the last DATA must retransmit it until the packet is
acknowledged or the sending host times out. If the response is an
ACK, the transmission was completed successfully. If the sender of
the data times out and is not prepared to retransmit any more, the
transfer may still have been completed successfully, after which the
acknowledger or network may have experienced a problem. It is also
possible in this case that the transfer was unsuccessful. In any
case, the connection has been closed.
My QUESTION IS: Do JSCH follow any RFC related to TFTP, FTP etc? Or would it
only follow the SSH RFCs? Also would any RFC for SSH have similar normal
termination as described above?
So I am trying to understand if their comment makes any sense or not. I would
appreciate any input here.
Cheers!
Flavio
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
JSch-users mailing list
JSch-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jsch-users