How to better copy&paste big files over RDP?

Question

Recently I was making a few attempts to copy&paste a big (1.2 GB) file to remote computer over RDP. The remote computer is virtual testing machine with MS Windows Server 2008 Datacenter.

First I tried to copy&paste before midnight when the transfer speed was limited by client computer ISP to 100 kB/s. So, it required a few hours and I was forced to cancel transfer since remote desktop became too unresponsive and sluggish (slow). So, I re-started it over midnight when my local transfer speed is over 4MB/s.

So, my impression is that independently on speed (broadband) of copy&paste transfer the remote computer becomes sluggish while copying over RDP. At the same time downloading from internet doesn't make remote host sluggish.

AFAIU, it is because clipboard of remote computer and so its memory becomes overloaded by transfer.
How can I control (restrict) the usage of clipboard for specific process (pasting of file)?

What are the possible way to control it?

Update:
After reading that slow speed of transfer is caused by encryption used for copy&pasting over RDP and since I believe I am more interested in overall efficiency: both the time, or rapidness, of getting file as well as possibility to work without waiting, I changed the question title from:

• How to control the usage of remote desktop clipboard usage for pasting a big file?

to

• How to better copy&paste big files over RDP?

For example, is it better to copy&paste one huge (zip) archive or unzip it and copy paste a folder with unzipped files?

And more exactly I wanted to ask:

• What are possible ways to improve overall experience:

  • the speed of transfer (i.e. availability of needed file)
  • responsiveness of remote host (making remote coputer available for work before completion of copy&pasting)?

Solution 1

When you say a Zip file, do you mean an uncompressed archive that would be the same size as all the individual files? Or do you mean a compressed archive? Because right there, if you are talking about a compressed archive, you'd have a faster transfer, which strictly speaking would be better. Of course, if you take into account the amount of time it takes to make the archive, and how long it takes to extract the archive, then the specs of both machines come into play as to whether the archive is better than loose files.

Now, since you are talking about RDP (as opposed to VNC), the bandwidth usage of the remote connection is quite a bit. RDP is more responsive than VNC, the color depth is (by default) more than 256 colors (32 bit if you don't change it), the screen size will be the size of your desktop, etc... all of these factors affect how much bandwidth is being used just for the remote connection. If you drop things like... the size of the remote desktop, and color depth to 16 bit or less, make sure you aren't sharing sound, etc... this will use less bandwidth for the remote connection, so that when you are transferring files, the remote session should be more responsive.

In the end though, unless you can throttle the file transfer, the remote session is going to get sluggish no matter what you do while you are transferring files, since as much of the available bandwidth as possible is going to be used for the transfer between the remote machine and your machine.

EDIT

You are attempting to find a simple way to transfer files WITHOUT affecting the quality of the remote connection. It doesn't matter if they are large files or small files. At your end (the client machine) you are squirting small amounts of data up to the remote machine (server machine). You know... typing, mouse commands, etc. The server is sending large amounts of data to you all the time, in the form of the images that are making up what you see across the remote connection. So, before you transfer any files, you are ALREADY transferring a large amount of data in one direction. That's why I brought up the things you could do to reduce the amount of data you are transmitting.... namely use a smaller resolution for the remote machine on your desktop (as opposed to full screen).... reducing the number of colors from 32 bit to 16 bit or even 8 bit. Those two steps right there will drop the amount of data you are transmitting from the server (remote) to the client (you). It also means that when you start transferring files along the same connection and route, your remote connection will suffer less.

As I said... nothing you can do will make the connection stay crisp and responsive. Why? Because as soon as you start transferring files from the server to the client, this is going to suck up every bit of bandwidth that is available along that pipe.... and you are already using some of the bandwidth along that pipe for the remote connection itself.

First I tried to copy&paste before midnight when the transfer speed was limited by client computer ISP to 100 kB/s. So, it required a few hours and I was forced to cancel transfer since remote desktop became too unresponsive and sluggish (slow). So, I re-started it over midnight when my local transfer speed is over 4 GB/s

So when you first tried the transfer, you had a download connection of 100kb/s. You were moving 1.2gb of files as fast as possible, which would push to eat up as much of that 100kb/s as it could. Which would leave what room for the data supporting the remote desktop connection? So, of course it would be sluggish and unresponsive. The only thing you are not also taking into account, is the UPLOAD speed of the server. If the upload speed of the server is less than your download speed... and in this perfect hypothetical the route between the server and you allowed for this upload speed to remain constant, as soon as you start to transfer the files, just about all of that bandwidth is going to be eaten up by the file transfer, which will make the remote connection suffer.

Why?

Because there is nothing throttling the file transfer to a specific speed, or a percentage of available bandwidth, it is going to attempt to use every kb/s it can. By the nature of things, this will make the remote connection suffer.

Even transferring the files from the server to a third party (like an FTP server somewhere) would make the connection sluggish during that transfer, because again, as much of the available bandwidth as possible would be allocated to that transfer. Once that transfer was done however, you would be able to download it from the FTP server with no effect on the responsiveness of the remote connection... again because your incoming pipe after midnight is much larger than the server's outgoing pipe.

So, I would try reducing the quality of the remote connection.

Solution 2

There is an RDP option that creates a link to your local drive on the remote computer. To enable it, start the RDP client, click (Show) Options, → open the "Local Resources" tab. → click "More" → tick the "Drives" checkbox.

After you connect, open Windows Explorer on the remote system. Your local drive should appear at the bottom of the drive list in My Computer. It shows up as "C on your_computer_name".

You can now Drag and Drop files from one system to another.

Solution 3

I use robocopy on my windows 7 box, using the unc name \\tsclient.

Solution 4

I think none of these answers really address the question very well.

Microsoft RDP is a protocol that is not really well optimized for file transfer. If your connection is a little slow, the moving of the file bits, which travel over the same network pipe as the UI packets like the screen draws and mouse movement, may cause one of these things to time out; and then, the server will assume you have lost your connection and will disconnect you, breaking your IO channels. This of course makes the problem worse.

Primarily, you should consider your workflow and see if you have an easier way to move the files over another channel (like over the internet to your server instead of from your workstation) that doesn't violate your security policy.

If you decide that you must use the RDP file-copy channel, then follow these guidelines which work pretty well for me.

• Do not access large files directly over the UNC path to the client. For example, enabling shared folders and accessing the file from \TSCLIENT\share. This pushes the large file content over the small multi-use pipe.
• You will gain a little optimiziation and stability by mapping a drive. For instance, NET USE X: \TSCLIENT\Share will map a drive X: to the above location. Still, overloading the network pipes will disconnect you and disconnect your drive mapping as well.
• Most importantly, when starting the RDP client, choose the network bandwidth setting "Modem" or "Slow". This will much better optimize the file transfer and sound channels, so that they cannot clobber the rest of the pipe used for the UI control.
• On the OS X Microsoft Remote Desktop client, this setting is strangely unavailable. In this case, install MacPorts and run sudo port install rdesktop and then you can connect with rdesktop and the -x m setting (set the "experience" level to "modem or 28.8K")
• If you follow the above recommendations, you will now have a connection optimized for stability and pushing large files will not disconnect you. Now, use a more controlled way to copy the files than copy/paste or drag-and-drop: for instance, try **XCOPY X:*.msi C:\Install** to copy items matching a filename pattern into the specified local (server) directory.

I hope someone finds these suggestions helpful. They certainly work for me.

Solution 5

As suggested in his answer by @Tom, it is preferable to D&D the files instead of C&Ping them. This has the added benefit of circumventing a bug that interrupts the file transfer if you use Ctrl+C on the client machine.

View more solutions

Comments

[Rick Henderson]

It would be faster and simpler to use an external storage source. Nowadays I'm finding copying files from OneDrive is easy enough.

[Gennady Vanin Геннадий Ванин]

I tried it, it is not available

[Chris_K]

It is an RDP setting -- off by default. Start the RDP client, click options and click the "Local Resources" tab. Click more and tick "Drives"

[Gennady Vanin Геннадий Ванин]

The size of compressed arhive file is practically the same as uncompressed files. The time of compressing and uncompressing is not an issue since they do not freeze the system for working. And I can use them both as uncompressed bunch of files or compressed one file (in the latter case by mounting a virtual drive)

[Gennady Vanin Геннадий Ванин]

I am not able to copy&paste at all w/o checking options in "Drives" of "Local Resources" RDP options. So, after checking them, I can C&P but cannot D&D. Then, really, isn't D&D is just a more funny way of C&P? Where is the win?

[Tom]

D&D might use a different process "behind the scenes," so it might work, even if C&P doesn't. Have you tried to D&D?

[Bon Gart]

@WebMAOhist then since the files won't compress much, it isn't worth it to zip them up, since you are adding the archiving and extraction time to the total file handling time (includes transit), and you gain nothing by putting it in an archive. Still brings us back to bandwidth for remote session + bandwidth for transfer issue. I'll append the answer since this is going to get longer than a simple comment.

[Gennady Vanin Геннадий Ванин]

Ooops, I was wrong. I realized that you did mean D&D inside the same remote machine, as my local drives appear in file system of remote machine, which I have noticed only after this discussion

[dodgy_coder]

I just copied a 3.8gb file using RDP drag and drop as described above and it worked fine. Had to use a tethered 4G mobile connection to get a better speed than my home internet though .. it took about 50 mins over a 10mbps upload speed.

[Yepeekai]

I didn't find anything official about this, but it looks like RDP is transferring the data compressed automatically using the mapped drive created by RDP. So you don't have to pre zip a file and unzip it on the other side. I came across this because the transferring speed of highly compressible data is faster than the available bandwidth. I don't think there is any difference between using C&P vs D&D

[ratbum]

If you're using Remote Desktop Connection Manager, these settings are under Properties > Local Resources for each server.