Brian Madden TV #16 - Wyse VDA video demo, RTO's kid coder, and Brian's USB over RDP 7 woes

Brian and Gabe are back with Brian Madden TV #16 for July 9, 2009. In this episode:

  • Why Brian thinks this year's BriForum will be the best ever (duh!)
  • Brian's switch to RDP 7 and why USB is still troublesome
  • How RemoteScan addresses client scanning via RDP woes



  • We learn that Gabe also wears striped shirts on the road when Brian and Gabe visit RTO Software as their vendor of the week. RTO's Kevin Goodman and Eric Tatum show how their Virtual Profiles product works and give us a sneak peak at some upcoming features.

All this, and next week's Random Vendor of the Week, on Brian Madden TV #16!

View All Videos

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

That WYSE demonstration was really good, but what is doing my head in is how does WYSE proxy the data when it is only going through what people call "First Run"?  If it is the first time it has seen the data, how can it cache the information and therefore "accelerate" the speed of the screen?

At the moment I am sceptical as it doesn't make sense to me.


I love all of these"packet based hardware compressors" in the datapath:

a) Wyse VDA.

b) Citrix with their Repeater/Branch Repeater.

c) And a few other companies that just do packet inspection and compression.

They ALL validate what we at Teradici have been saying for several years now – You NEED hardware to be integrated into the "remoting protocol" at some point in the system to achieve the best possible user desktop experience.

One of the downsides to having the hardware compression after the 'software remoting protocol' is complete and has packed it into ip/ethernet packets is that the "packet based hardware compressor" has to:

Hardware at Host:

1) reverse all of the work of the network layer of the host - IP and Encryption.

2) parse the packet data to detect what is going on and reverse some of the functions done by the remoting protocol.

3) compress the data

4) regenerate/perform the IP header and Encryption

5) send it across the link.

Hardware at Client:

6) undo the new IP header and encryption.

7) uncompress the data.

8) put the data back into the state at which the data is parable by the 'remoting protocol'

9) regenerate/peform the IP header and Encryption for the End client.

You can't do steps 1 through 9 without adding at least a few ms of latency on each side, so you are now adding latency to the already slow link - so putting this in a WAN or LAN based situation will improve WAN performance from a bandwidth perspective, and will degrade the LAN and WAN performance from a latency perspective "Assuming the amount of data sent is never hitting bandwidth limits".  In addition, there are 2 new points of attack on the security of the end-to-end session.

With PCoIP, you also have Hardware in the datapath; however, it starts with raw data from the source of the Host system. The PCoIP hardware compresses the data natively in the 'remoting protocol' allowing a significant reduction in both bandwidth and latency over the other "hardware compression" options.  PCoIP also removes the need for both Software 'remoting protocol' compression improving latency and CPU load.  The PCoIP protocol also adaptively changes the compression mechanisms so that it maintains the bandwidth below the bandwidth available in the network, thus providing the most effective and responsive user experience (see assumption above).

I'm not saying that there isn't a need for the "packet based hardware compressors" - just that if you already have the function in the remoting protocol, there's less of a need for these types of products for remoting your desktop.


We provided something called PnP Redirection in Windows Server 2008; unfortunately few if any device vendors have implemented it for their devices so far. the advantage of this framework is it would support more bus types than USB - hence why we did it.


The big advantage of Wyse VDA is that it is implemented as a SW proxy that runs inside the Windows environment itself. Wyse VDA does not require any additional HW (e.g. it's not a "packet based hardware compressors"). VDA can also improve the performance significantly on "First Run" connections; it doesn't rely solely on caching.


Did you try this USBMAP solutions that map USB over rdp:

But both could not develop an solution to handle 127 devices PER SESSION of

Remote Desktop, they map USB from many users but all users on the logged

server can see all the devices.



I actually got the USB redirection to work using Leostream's Connection Broker/Client/Agent solution.  I launched my Leostream session, connected to my hosted desktop, and as soon as the connection was made my hosted desktop displayed the "found new hardware message".  After it loaded the drivers, I downloaded iTunes and successfully synced my iPhone to my hosted desktop.


Great description of RemoteScan Brian! Thanks for the succinct quote, “RemoteScan works perfectly.”

One minor point, RemoteScan actually does automatically use t RRD and/or ICA directly, but can also be configured to use IP.

 - Steve


Great description of how VDA ( or any accelerator ) works.

BTW I am trying to setup the VDA and test its performance. However, I get this error at the VDA client software "RTT lower than Configured latency threshold, VDA will allow protocol to operate natively"

I fail to proceed further, any help will be of great help.



Got VDA to run, however, I see the video performance is slower than with native RDP, does anyone have an instite on what could be wrong.

The PPT, Word, overall user experience is good with VDA, just that video is slow.