when I use remote drive file transfers RDPDR the desktop is very laggy

xrdp version

0.9.21.1

Detailed xrdp version, build options

 xrdp -v
xrdp 0.9.21.1
  A Remote Desktop Protocol Server.
  Copyright (C) 2004-2020 Jay Sorg, Neutrino Labs, and all contributors.
  See https://github.com/neutrinolabs/xrdp for more information.

  Configure options:
      --enable-ipv6
      --enable-jpeg
      --enable-fuse
      --enable-rfxcodec
      --enable-opus
      --enable-painter
      --enable-vsock
      --build=x86_64-linux-gnu
      --prefix=/usr
      --includedir=${prefix}/include
      --mandir=${prefix}/share/man
      --infodir=${prefix}/share/info
      --sysconfdir=/etc
      --localstatedir=/var
      --disable-silent-rules
      --libdir=${prefix}/lib/x86_64-linux-gnu
      --libexecdir=${prefix}/lib/x86_64-linux-gnu
      --disable-maintainer-mode
      --disable-dependency-tracking
      --with-socketdir=/run/xrdp/sockdir
      build_alias=x86_64-linux-gnu
      CFLAGS=-g -O2 -ffile-prefix-map=/build/reproducible-path/xrdp-0.9.21.1=. -fstack-protector-strong -Wformat -Werror=format-security 
      LDFLAGS=-Wl,-z,relro -Wl,-z,now -Wl,--as-needed
      CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2 
      PKG_CONFIG_PATH=/build/reproducible-path/xrdp-0.9.21.1/pkgconfig

  Compiled with OpenSSL 1.1.1w  11 Sep 2023

Operating system & version

debian 12

Installation method

dnf / apt / zypper / pkg / etc

Which backend do you use?

freerdp

What desktop environment do you use?

xfce

Environment xrdp running on

yes

What's your client?

freerdp

Area(s) with issue?

File transfer / drive redirection

Steps to reproduce

When I transfer files using rdpdr, the desktop is very laggy

✔️ Expected Behavior

How can I modify the file and its length to reduce the bandwidth usage during file copying

I debugged the RDPDR code and found that the file offset received in the IRP_MJ_READ event is always: [file_id=1] length=1048576, offset=0 [file_id=1] length=1048576, offset=1048576 [file_id=1] length=1048576, offset=2097152

❌ Actual Behavior

the desktop is very laggy

Anything else?

nothing

@bestxpp - I don't think changing the length here won't help.

I'm assuming you're looking at the data path sending from xrdp to the client.

Let's start with the length itself (1048576). This comes from the application which is writing over the channel. You should be able to see this by running strace on the application making the copy.

This moves through the FUSE filesystem, and ends up in the redirector in chansrv. The write happens in devredir_file_write() which calls send_channel_data() in chansrv.c:-

https://github.com/neutrinolabs/xrdp/blob/65993312b78b4014f5dd38e694d958bf24393ae2/sesman/chansrv/chansrv.c#L263-L312

This doesn't however send a 1Mb PDU over the network! send_channel_data() splits the large packet up into smaller ones of approximately 1600 bytes using fragmentation. These are then passed on to xrdp where they are sent as separate PDUs to the client.

There's an overview of the process in section 1.3.3 of [MS-RDPBCGR]

At the moment there's no mechanism for prioritising the PDUs - they're send by xrdp as they arrive.

If you want to try changing the length of the write, a cheap way to start will be to use a different utility to do the copy. Maybe try setting a block size with tar(?) As I said, you can use strace to see the length used by the utility.

@bestxpp - I don't think changing the length here won't help.

I'm assuming you're looking at the data path sending from xrdp to the client.

Let's start with the length itself (1048576). This comes from the application which is writing over the channel. You should be able to see this by running strace on the application making the copy.

This moves through the FUSE filesystem, and ends up in the redirector in chansrv. The write happens in devredir_file_write() which calls send_channel_data() in chansrv.c:-

https://github.com/neutrinolabs/xrdp/blob/65993312b78b4014f5dd38e694d958bf24393ae2/sesman/chansrv/chansrv.c#L263-L312

This doesn't however send a 1Mb PDU over the network! send_channel_data() splits the large packet up into smaller ones of approximately 1600 bytes using fragmentation. These are then passed on to xrdp where they are sent as separate PDUs to the client.

There's an overview of the process in section 1.3.3 of [MS-RDPBCGR]

At the moment there's no mechanism for prioritising the PDUs - they're send by xrdp as they arrive.

If you want to try changing the length of the write, a cheap way to start will be to use a different utility to do the copy. Maybe try setting a block size with tar(?) As I said, you can use strace to see the length used by the utility.

Ok thanks

neutrinolabs / xrdp