RDP file transfers can't be trusted

[time]

Just a heads up. I transferred a 1.3GB file via RDP drive sharing and discovered it was corrupted about 2/3 of the way through. Unfortunately my DSL-VPN upload speed appears to be limited to 40kB/s, so it took all night and I then had to throw it away.

I then chopped it into 7 parts (with 7-zip) and transferred them one at a time. The fourth slice was corrupted, the others made it through intact.

I've used more PC remote control tools than anyone else I've ever heard about, and to my recollection RDP is the only one that didn't use CRC on file transfers (since the early days anyway).

Thank you Microsoft for another quality product.

 

[Chewy509]

I've only rarely used the internal file transfer in RDP, but didn't know that it didn't use any form of checksumming. (Now that explains why the few tims I had problems with it). Thanks for the info.

Most of the time, I've used FTP/HTTP to transfer stuff across especially across the Internet, otherwise just used normal file shares on the LAN.

 

[time]

Same here, I was using it as a fallback.

 

[MaxBurn]

Never used it for something that big but do say 50MB files and smaller all the time with never a problem yet. They are mostly zips and I think that would let me know. Generally I do it over a LAN at work though.

 

[blakerwry]

Never used RDP for file sharing, but assuming it is still using TCP like the video and audio portions of the protocol I don't see why the application needs to perform CRC checking when that's already done at the Ethernet and TCP layers per packet.

Perhaps faulty HDD/RAM/CPU injecting corruption or NIC/NIC driver not verifying checksums?

 

[time]

The PC at the other end uses ECC RAM, but mine could be flaky.

However, it's worth pointing out that low level error detection schemes often don't stop corruption occurring at some higher level. If they did, no data would ever be corrupted ...

The TCP checksum is a weak check by modern standards. Data Link Layers with high bit error rates may require additional link error correction/detection capabilities. The weak checksum is partially compensated for by the common use of a CRC or better integrity check at layer 2, below both TCP and IP, such as is used in PPP or the Ethernet frame. However, this does not mean that the 16-bit TCP checksum is redundant: remarkably, introduction of errors in packets between CRC-protected hops is common, but the end-to-end 16-bit TCP checksum catches most of these simple errors.[15] This is the end-to-end principle at work.

 

[Mercutio]

RDP can disconnect and very quickly re-negotiate a connection if the session remains open. I could very easily imagine a circumstance where someplace in the mess of RDP over VPN over internet connection where some part of that connection momentarily stopped working without actually ending the remote session or file copy.

 

[Will Rickards]

I use RDP for file transfers day in and day out. But it is SLOW and thus is only used mostly for files under 10MB. For more than that we use what equates to an internal web based ftp service.

 

[ddrueding]

For my RDP needs, I map a drive directly to both sides of the connection, and do the file transfer that way. Still no major protections against corruption, but much faster.