Re: [opensuse] Re: sftp is unreliable
On 2017-07-16 19:21, Richmond wrote:
"Carlos E. R." <> writes:
I found this site:
https://serverfault.com/questions/140573/how-can-i-check-if-a-file-is-well-t...
It says that the client may fail to deal with an error from the server properly. As I was getting the data from a slackware system maybe they are different versions.
Also the file would have had a rough ride, as it was coming from a 32 bit system via a homeplug to a router and then by wifi to its destination.
If doesn't matter if it goes round the world... Supposedly TCP is reliable. Years ago we knew we had to verify all transported files. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On 07/16/2017 01:26 PM, Carlos E. R. wrote:
If doesn't matter if it goes round the world... Supposedly TCP is reliable.
Years ago we knew we had to verify all transported files.
TCP uses a 16 bit ones compliment checksum to verify accuracy. It's not that rigorous of a check. For example, 2 wrong bits in the same bit position will cancel out. A CRC would be much better, but wasn't used. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/16/2017 10:26 AM, Carlos E. R. wrote:
On 2017-07-16 19:21, Richmond wrote:
"Carlos E. R." <> writes:
I found this site:
https://serverfault.com/questions/140573/how-can-i-check-if-a-file-is-well-t...
It says that the client may fail to deal with an error from the server properly. As I was getting the data from a slackware system maybe they are different versions.
Also the file would have had a rough ride, as it was coming from a 32 bit system via a homeplug to a router and then by wifi to its destination.
If doesn't matter if it goes round the world... Supposedly TCP is reliable.
Years ago we knew we had to verify all transported files.
That isn't exactly true tho. It is possible to get corrupted transfer over TCP/IP. Wise people put their own checksums into transfers. Further, even if it was true, there is a lot of opportunity for corruption before the transfer is actually handed over to the ssh transport. The problem here is the implementation of sftp is dependent on compatible implimentations on both sides. To avoid that, you want to use something that relies on more basic tools. SFTP = SSH + SFTP-server on server SCP = SSH + `scp` on server side FISH = SSH + `dd` (and some other basic Unix utilities on the server side only) Dolphin knows how to know how to handle fish://user@server:22/[directory] And when you watch what is happening in top on that remote server, you see only sshd and perl and a sh shell running for that connection. (fishsrv.pl is a perl script.) I have no way to be sure that is more reliable or not, but the perl script does not have to be compatible with what is running on the client, and the client need not even have perl installed. I mention it as just one more possibility. -- After all is said and done, more is said than done.
On 2017-07-16 21:57, John Andersen wrote:
On 07/16/2017 10:26 AM, Carlos E. R. wrote:
On 2017-07-16 19:21, Richmond wrote:
"Carlos E. R." <> writes:
I found this site:
https://serverfault.com/questions/140573/how-can-i-check-if-a-file-is-well-t...
It says that the client may fail to deal with an error from the server properly. As I was getting the data from a slackware system maybe they are different versions.
Also the file would have had a rough ride, as it was coming from a 32 bit system via a homeplug to a router and then by wifi to its destination.
If doesn't matter if it goes round the world... Supposedly TCP is reliable.
Years ago we knew we had to verify all transported files.
That isn't exactly true tho. It is possible to get corrupted transfer over TCP/IP. Wise people put their own checksums into transfers.
Further, even if it was true, there is a lot of opportunity for corruption before the transfer is actually handed over to the ssh transport.
The problem here is the implementation of sftp is dependent on compatible implimentations on both sides. To avoid that, you want to use something that relies on more basic tools.
sftp is encrypted. You would get nothing if the toolset is not compatible. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On 07/17/2017 02:58 AM, Carlos E. R. wrote:
The problem here is the implementation of sftp is dependent on compatible implimentations on both sides. To avoid that, you want to use something that relies on more basic tools. sftp is encrypted. You would get nothing if the toolset is not compatible.
fish is encrypted. No specific toolset required. -- After all is said and done, more is said than done.
participants (3)
-
Carlos E. R. -
James Knott -
John Andersen