Access your desktop PC from your Pocket PC! (Part II)

(Continued from HERE.)

1.2.2 RFB-based (VNC) applications

Note that, after quickly listing the four different solutions, I also explain what needs to be known about different servers, encodings and server-side scaling. This knowledge will be essential in sometimes drastically decreasing the bandwidth needs of the applications. At first, I introduce the applications themselves.

1.2.2.1 VNC clients by Parys Technografx Ltd

Without doubt, Parys Technografx (PT) Ltd produces by far the best VNC clients for the Pocket PC. There are several of them; WM5 users will want to go straight for their latest product, Pocket Office (PO) – it offers the most for the money: it supports Tight (JPG), the most bandwidth-saving encoding protocol; it supports bidirectional (!) file transfers etc.

As far as strictly VNC clients are concerned, as has already been pointed out, PT PO has the best support for bandwidth saving (it supports the Tight encoding, along with JPG), has file transfer and is very snappy. Its usage can be a bit complicated for a newbie, but don’t be afraid: you’ll soon learn it. Just keep playing with the menus.

Note that the author of PT PO has told me may eliminate the need for manually setting whether the VNC server supports server-side scaling – automatic discovery already works in the free .NET VNC Viewer. He may also introduce automatic encoding handshake (as is the case with, say, the Mocha VNC client). He’s also working on making PT PO RealVNC-compliant (currently, it isn’t, unlike with the other Pocket PC-based VNC clients) and, finally, may also introduce clipboard synchronization (which is also supported by the RFB protocol itself).

Some example screenshots: Enter the IP; Password input; Download.

Verdict: if you want to go the VNC way (and aren’t forced to use the RealVNC server – remember, the current version of PT PO isn’t compatible with RealVNC), get this application – you’ll love it.

1.2.2.2 .NET VNC Viewer by Rocky Lo; 1.0.1.16

The free .NET VNC Viewer is better in some respects than PT PO. First, it has a more traditional interface, which is much easier for a newbie to comprehend. Second, it has automatic server-side scaling support (more on this later), unlike with (the current pre-release version of) PT PO. Third, it’s free.

However, it’s VERY-VERY SLOW as it’s based on Compact Framework. Therefore, I only recommend it if you only want VNC (not, say, a Web- or RDP-based client) and only want a free solution (where, for example, LogMeIn Free can’t be used because you prefer VNC as the remote protocol).

Also see this and this PPCT threads.

1.2.2.3 Mocha VNC 1.1 by MochaSoft

This title is definitely superior to the heavily outdated (RDP 4 only) RDP client of the same developer and, therefore, may be worth considering if, for some reason, you don’t want to go the PT PO route, but want to stick strictly with VNC clients. While it doesn’t support the most bandwidth-saving encoding methods (Tight (JPG)), the most compact compression method it’s capable of (ZRLE / Zlib) is still definitely better than that (Hextile) of the free, very slow .NET Viewer.

It’s very similar to the RDP client; in addition to the capabilities of that client, it has an encoding log, which is very useful when you would like to track down protocol-level errors.

It’s compatible with all major VNC servers; it’s only with PTeSVNC (the VNC server that’s bundled with the PT VNC client downloads – see SetUpPTeSVNC.exe) that it’s incompatible with.

1.2.2.4 VNC 3.3-only, not recommended VNC clients (Allware /Mark Midgley (alternate source) / Conduits )

The (unfortunately, still) most widely known and referred-to, very old and outdated, free VNC clients (that of Mark Midgley, Allware and Conduits) should all be avoided. They have really bad (non-existing) error handling, are only compatible with VNC servers in explicit 3.3 mode (and just silently die when they encounter a server that tries to communicate with something more up-to-date), are very slow and only know the not very bandwidth-friendly Hextile encoding. In a word: avoid them all.

Also see this BrightHand thread.

1.2.2.5 VNC servers

Now that I've quickly elaborated on the different VNC clients, let's take a look at the server side. Unlike with the Web- and RDP-based solutions, you must manually install a server on your desktop PC you’d like to access.

There are several VNC servers out there with slightly different capabilities. As a rule of thumb, I'd go for UltraVNC - it is probably the most important, capable and recommended server, unless you use PT PO, in which case you should choose the included PTeSVNC instead (if you need seamless file transfers). Nevertheless, if you don't need for example support for server-side scaling, file transfer with PT PO, extended desktops or international characters, you may also want to go for RealVNC or TightVNC. Finally, the fourth, really nice alternative is the already-mentioned PTeSVNC, which is also free and is bundled with all PT VNC clients (also trial ones). It's really capable (except for the lack of extended desktops).

Fortunately, these four servers don't differ much as far as server-side configuration is concerned. That is, if you learn to use and configure one of them, you'll be able to do the same with the others too (except for some additional or missing options / tabs / checkboxes).

Note that if you plan to use PT PO, you may encounter screen refresh problems with Ultra (unlike with PTeSVNC) in all modes; for example, the upper rows in this screenshot. In this respect, PTeSVNC is a better choice. The developers are aware of the problem and may fix it in future versions.

In general, installing VNC servers are pretty straightforward. You install the product and just start the server in Start Menu / Programs on the Windows desktop PC. When it's running, it'll display an icon in the system tray (systray), through which you'll have access to the configuration dialog, user list and can even shut down the service.

1.2.2.6 VNC Bandwidth usage fine tuning

With a capable VNC client / server combo, you can fine-tune the bandwidth usage and force it to be really small – almost as small as with GoToMyPC in high/true color modes. This, however, requires you to know what options there are.

First, there are so-called "encodings" used with VNC. Some of them really love wasting bandwidth; for example, RAW, which, as you may already have guessed, just sends over uncompressed raw screen data and, consequently, takes orders of magnitude more bandwidth than protocols utilizing compression methods. Well-known, high-bandwidth and, therefore, to-be-avoided encodings also include RRE and CoRRE.

The widely used Hextile (the best available with the above-introduced, free, not recommended three "legacy" clients) is already a bit better but still consumes a lot of bandwidth and should, therefore, be avoided. With some additional compression (Zlib hextile, for example) it becomes pretty usable, bandwidth-wise: it will "only" consume about three times more bandwidth than RDP or more advanced (for example, JPEG-based) VNC encodings. Of the Pocket PC clients, only Mocha (and, of course, PT PO) supports Zlib / ZRLE compression.

Finally, Tight with or without JPG (the best, most space/bandwidth-efficient way to encode images) is by far the most effective VNC encoding. Of the Pocket PC-based clients, only PT PO supports Tight / JPG.

While CopyRect isn't strictly an encoding form but a way to tell the client "just scroll some of the old screen contents instead of downloading it again", it should be pointed out that it must always be enabled to (in cases - see for example the smooth scrolling examples below -, greatly) reduce bandwidth usage.

Other tips for PT PO: you may freely decrease the, by default, 1.0s update delay to say, 0.3 s - it will have almost no adverse effect on the bandwidth usage.

1.2.2.6.1 Server-side scaling issues

In addition to choosing the right encoding (at least Zlib / ZRLE and, preferably, Tight (JPG)), you should also know what server-side scaling is and how you can fine-tune it to further reduce bandwidth usage.

First, remote desktops are, generally, bigger than the resolution of your Pocket PC screen. For example, my notebook has an UXGA (1600*1200) screen, which is far larger than even the VGA screens of some of my Pocket PC's. If (and only if!) you don't zoom into this image fully and scroll around the page so that a pixel on the remote desktop equals to a pixel on the Pocket PC, you can make use of clever remote desktop-side (!) rescaling of screen images before (!) returning them to the client. Just imagine: if you would like to just navigate on a 1600*1200 desktop with your VGA screen, by instructing the server to resize the screen images returned to the client itself, you can save a LOT of bandwidth. For example, if the server uses the rescaling factor 2, then, it'll send over 1600/2 * 1200/2, that is, 800*600 images, which are still bigger than the VGA screen and, therefore, only result in very small image quality degradation - while delivering considerable bandwidth usage decrease. Using the scaling factor 3 with the above-mentioned UXGA desktops, the full screen images sent over will become 1600/3 * 1200/3; that is, 533*400 in size. Of course, this will introduce some kind of blurriness - but the bandwidth advantage will be considerable.

Note that, currently, VNC servers are only capable of using integer scaling factors - that is, you can't make them return for example strictly 640*480 (VGA) images of a 1600*1200 (UXGA) desktop (1600 divided by 640, that is, 2.5, isn’t an integer). This is why you can't just tell them "with a UXGA remote desktop and a VGA client, use the rescaling factor 2.5 so that you get the most optimal result with the best possible image quality".

Some real-world benchmark results to show all this (PTeSVNC server, 1600*1200 desktop, VGA portrait client, Tight NO JPG, server scale 1:2; all data are in Mbytes; the smaller, the better):

Scaling:Server Scale onScale off
Smooth scroll on1.271.77
Smooth scroll off0.670.91

In Landscape, using the above configuration (UXGA desktop, VGA client), using UltraVNC, some other benchmark results:

Server scale 1:4, no smooth: 310k
Tight JPG max speed, server scale 1:2: 550k
Tight JPG HQ, server scale 1:2: 570k
Tight No JPG, server scale 1:2: 560k
Tight No JPG, server scale 1:1: 780k

Finally, SVGA (800*600) desktop, VGA landscape client, with smooth scrolling on:

1:2 Server Scale on: 1.33 Mbytes
Scale off: 1.95 Mbytes

As can be seen, server-side scaling, while it does introduce some kind of blurriness (example screenshots of this later), really reduce the used bandwidth: with a two-factor server-side resizing, about 35...45%. Also, as can be seen, fine-tuning the JPEG quality parameters (or, for that matter, completely disabling it) in Tight mode of PT PO doesn't really result in considerable bandwidth savings. Other, more graphics-packed pages may differ in this respect: please see the benchmark results here, they are really instructive.

Finally, some examples of the quality degradation (all taken on a VGA Pocket PC):

1:1
1:2
1:3
1:4

As can clearly be seen, the quality slightly degrades even at the rescale factor of two. That is, there is a clear tradeoff between quality and speed. You will want to use / configure the server-side scaling feature in VNC clients (.NET Viewer and PT PO) that directly allow for configuring this wisely.

1.2.3 Other applications

1.2.3.1 z2 Remote2PC 1.2 build 1205 by z2 Software

z2 Remote2PC is a very famous Pocket PC remote controlling solution. It is generally really solid and its only problem is the definitely higher bandwidth consumption compared to most other alternatives. It doesn't support HTTPS either; in a fully firewalled environment, it may prove less useful than Web-based solutions like LogMeIn, I'm InTouch and GoToMyPC. It does support callbacks to combat this, but the latter requires some manual configuration and, in this mode, can't be used with also-firewalled clients. If these aren't an issue (you won't be, for example, accessing your desktop via slow and/or expensive lines and won't try to access your firewalled servers from an also firewalled/NAT'ed client), I highly recommend this application.

Reviews, threads: Thread on 1.0 (note that some users call it even faster than TSC – this is certainly not the case); PocketNow. Also see this and this.

1.2.3.2 pcAnywhere 12.0 by Symantec

The PPC version is 2.0.0 build 121; note that the 2.0.1 update refuses to run. The trial 12 beta download (direct link here and here. Megathanks to akheron for the latter link!). The Mobile client CAB is also available here; I haven’t tested this myself.

This is another all-in-one remote controlling solution. While it does have its strengths (for example, clipboard synchronization, which is only supported by very few other solutions, and connections even through serial links - that is, not necessarily TCP/IP-based ones), in general, I can't really recommend this solution. Remote controlling / access-wise, there are much more sound, powerful solutions with a much better price/performance ratio and bandwidth utilization (another area pcAnywhere doesn't really excel at).

Example screenshots: After, on the desktop, starting Start / Programs / Symantec pcAnywhere, you’re presented this dialog. Here, you can connect to other computers, start file transfer (as can be seen, file transfer, as with all the other Pocket PC and unlike some desktop solutions, must be initiated from here and not from a remote desktop session) and start hosting.

Starting the server on one’s computer: 1 2 3 (as can be seen, you can use your Windows login credentials) 4 5 6.

An example (desktop) screenshot of remote controlling a session

More info here and here.

1.2.3.3 RemoteControl 10.0 by CrossTec Corporation

This cross-platform solution isn't just a remote controlling applications, but also offers a lot more functionality, mostly geared towards the enterprise. This, on the other hand, also means there isn't even a price quoted. This may mean you won't want to prefer this title over the other ones if you "only" want to have a remote controller only for your desktop, unlike with the case of deploying it to your entire enterprise. That is, you should only check out this solution if your entire enterprise wants to switch to it; then, however, you will also want to take a look at alternative and, when deployed to the entire enterprise, really decent solutions like NetOp Remote Control. Also note that the “enterprise” tests here, in this roundup, will mostly be useful for you to see whether you want to use the existing remote controller in your already-deployed CrossTec / NetOp configuration or will want to look for something more useful / bandwidth-friendly instead of them.

As with NetOp Remote Control, the desktop PC client supports for example direct client/server voice chat (like Microsoft Netmeeting!) for, say, remote Customer Service purposes; the Pocket PC version is much dumber. To see the differences between the desktop and the Pocket PC clients, check out and compare the docs (just start the EXE file and pass it a dot (.) as the decompression directory target); it’ll extract some (2 with the Windows and 4 with the non-Windows case) PDF files to the current directory): desktop Windows; Pocket PC, Mac and Linux.

Some screenshots: installing (2); server-side configuration: TCP/IP HTTP (for gateways!); mobile client install (2); desktop client; file transfer.

It has two transfer modes: GDI (which can only be used in high-color mode; otherwise, it'll mess up bitmap resources as can be seen for example in here; the CrossTec folks are avare of the problem and will, hopefully, fix it) and the traditional, simple screen scraping. Unfortunately, there really isn't much bandwidth usage difference between the two modes (one would expect the GDI version to be much more bandwidth-friendly).

1.2.3.4 NetOp Remote Control 9.0 by Danware

(mobile); (PPC guest version 8.00)

This product, as with the above-introduced CrossTec RemoteControl, is also a typical enterprise-only remote controller application, offering far more functionalities a non-enterprise user would ever need (and not offered for individual users: the minimum number of deploy hosts you can order it for is 100). Check out the description of the desktop and mobile versions for what it's capable of. In here, therefore, as with the CrossTec product, I only scrutinize it to see whether it's worth sticking to as a remote controller product - an enterprise system administrator in charge of deciding for a complete remote management / help / controller application deployed for the entire enterprise should use a much more broader approach in comparing not strictly Pocket PC-based controlling facilities.

First and foremost, let's get some facts straight: there are two related product lines in the NetOp line. The former, NetOp Remote Control (NRC) for WindowsCE (including Pocket PC / Windows Mobile clients), has been discontinued and is the only to contain a Pocket PC remote client; the latter, NetOp Mobile & Embedded (NME), only has a Pocket PC-side server component (like that of Pocket Controller, dotPocket, MS PowerToys etc. - see this already-linked article for more information). While the two products do work with each other (that is, you can use the old Pocket PC client with the new remote desktop-side component), the NRC 8 (the latest Windows Mobile client available) Pocket PC client is entirely incompatible with WM5.

Danware promises a WM5-compliant, real Pocket PC NME client in Q2 of this year. Up until then, it's only with Pocket PC's using previous operating systems will be able to access remote NetOp desktops.

As far as the general behaviour of the strictly Pocket PC-based remote controlling is concerned, it doesn't have much to write home about; for example, the bandwidth usage results are pretty bad. However, as has been pointed out, this product suite (as with that of CrossTec) should not only be evaluated as a mere remote controller tool: it's capable of much more when deployed in an enterprise. It's just that an individual user with a Pocket PC (and not a, say, notebook or UMPC running desktop Windows and, therefore, using the fully-fledged, great and capable NetOp NME client) won't necessarily want to prefer NetOp to the alternative, on the Pocket PC, much more capable and much less bandwidth-wasting solutions.

Some screenshots: Connect to host (2); desktop client setup 1 2 3 and configuration 1 2 (notice the plethora of usable protocols and the excellent server-side capabilities!); desktop guest in action. The WinCE host looks like this. It, however, also has a desktop configuration component. The setup of the latter (it’s only this that you can, for example, set your password) is as follows: 1 2.

1.2.3.5 Soft Agency Remote Desktop 2.0

The official homepage of this very old and outdated, commercial proprietary remote controller application isn’t accessible any more. Not that it'd be a problem: I don’t recommend this controller at all.

It has very few advantages and the list of its disadvantages is very long. Some screenshots: entering IP; add a user manually into the server (this must be done before the first connection)

1.2.3.6 BitWeen S.R.L. Remote Control 1.1

(alternate source)

This is another highly outdated and in no way recommended remote control application. It's highly overpriced ($49.95) for what it's capable of.

1.2.3.7 PPC Tablet Remote Control Suite 4.0

PPC Tablet is a well-known data input / media remote controller. It has recently received remote desktop accessor features.

They are pretty weak (particularly bandwidth usage-wise) but are still better than nothing. Please check the comparison chart for a more thorough elaboration and screenshot.

1.3 Haven’t tested

1.3.1 ICA client ny Citrix

(also see this page)

Unfortunately, it’s really a MetaFrame Presentation Server client and isn’t able to speak RDP, “just” ICA, the native protocol of MetaFrame. Therefore, a casual Pocket PC user not having access to the enterprise-level MetaFrame Presentation Servers will not be able to use it to access his own desktop computer - only server farms.

1.3.2 Vector PC-Duo Remote Control 9.60 by Vector Networks Inc.

The Vector PC-Duo Remote Control product line is pretty similar to the above-introduced CrossTec products because both are based on the core technology from NetSupport.

Upon trying to install the PPC client trial (version 9.0), it has complained about an old license. The nsm.lic file in the home directory of the application states the trial should expire in September 2005; still, not even setting the date back not to cause problems helps, the app will always complain of the license file being missing or invalid.

When compared to the Crosstec product, the readme.txt of Vector PC-Duo Remote Control states the Pocket PC version supported even File Transfer and Registry Editing. I couldn’t test this because of the client’s not installing.

Some screenshots: On installation, you can choose between the different deploying options; for example, it’s here that you can opt for installing a gateway. (Note that it refers to hosts as “Client” and clients as controls, as with the Crosstec product.) GUI-wise, as has already been pointed out, it is pretty similar to CrossTec 10; see for example the icons, the setting capabilities etc here and here. The menus are also the same.

1.3.3 SecuRemote by Check Point

I couldn’t check this enterprise-grade (!) product because it requires a dedicated VPN connection.

2. Feature / benchmark chart

It's available here. Due to sheer size, I couldn't include it in here - sorry. You'll need to click the link.

2.1 Explanation for the chart

Generic compatibility issues group: everything about operating system: which Pocket PC and desktop operating systems it's compatible with; does it support high-resolution VGA screens etc. Note that all products support Landscape orientation screens; this is why I haven't listed it in here.

As far as Pocket PC operating system compliance (see the OS compatibility: PPC row) is concerned, I've tested all these products on at least one (MIPS) Pocket PC 2000 (when the given application did have a MIPS version), PPC 2002 (I've tested for PPC2k2 compliance even with applications that are, officially, not PPC2k2-compliant and found out that some, only as WM2003+-advertised applications are also PPC2k2-compliant; see for example the Mochasoft products), Windows Mobile 2003, 2003 SE and Windows Mobile 5 devices - that is, all the major Pocket PC operating systems. Note that, in the chart, PPC2k2+ means all operating systems starting with PPC 2002 and WM2003+ means all operating systems starting with Windows Mobile 2003.

Other OS’es : you will want to consult this row if you plan to access your desktop from non-Windows / non-Pocket PC clients too. Several applications / protocols have clients for non-Windows desktops too; the two most important examples being VNC (with clients for all flavors of Unix operating systems) and RDP (there are RDP clients for all alternative operating systems, not only Windows - for example, rdesktop under Unix / Linux). Some of the other products also have Linux / Solaris / Mac OS clients; for example, pcAnywhere, CrossTec Corporation's RemoteControl and Danware's NetOp Remote Control. This is really worth knowing if you plan to access your desktop computer from a wide variety of platforms. As can be seen, as far as strictly Web-based technologies are concerned, RemotelyAnywhere is hands down the best and most compatible.

VGA support?: as can be seen, there are no products that wouldn't support high-resolution VGA screens. Some of them, however, must be "hacked" into this.

Bandwidth usage group: I've made some really extensive tests to find out how each and every remote control solution uses bandwidth. These tests are, therefore, of paramount importance if you

1. Have a very expensive (for example, mobile phone-based) connection, where every byte counts
2. Have a slow connection and would, therefore, welcome the fastest possible solution

To reliably and comparably (!) benchmark the different remote controller solutions, I've done the following:

1. I've created a Wi-Fi connection (through an external access point to avoid not being able to connect to the freshly booted-in desktop / being disconnected because of locked-out users, as is the case with RDP) between my freshly hard reset (no background tasks requesting information off the Internet) WM5-based Dell Axim x51v and my notebook (an IBM ThinkPad a31p with a 1600*1200 UXGA screen). I've used the x51v for this task because its Wi-Fi applet also lists the sent/received bytes as can be seen in this (received bytes) and this (transmitted bytes) screenshots. For some other measurements (most importantly, ones that did require a pre-WM5 device; for example, the NetOp tests), I've used a direct Bluetooth Personal Area Network connection between my Pocket Loox 720 and my notebook. The Widcomm Bluetooth stack also reliably displays the number of bytes sent (that is, the so-called uplink bytes) / received (downlink bytes). Finally, with one application (PT PO), after finding out the multiplication factor (1.33) between the internal data counter it displays and the real bandwidth usage (the latter is higher because of the additional protocol / communication overhead), I've used the built-in counter available in the main menu, under Connection Statistics (screenshot here).
2. I've switched the desktop resolution to 800*600 (SVGA) on the notebook (note that a, I've also made tests in UXGA (1600*1200) and, with I'm InTouch to find out the speed issues, all possible, settable resolutions between; b, remote controllers that did override this setting - for example, TSC - have overridden this to VGA (640*480) or, when I've chosen no scroll-mode with the “Limit size of server desktop to fit on this screen?” checkbox, even less.)
3. I've automatically scrolled through a looooooong test HTML document (my well-known Pocket PC Gaming Bible Part I without the PPCMag header/footer), with disabled smooth scrolling and ClearType by default (in two another tests, I've enabled them both to see how he protocol handles smooth scrolling events and whether it disables ClearType to increase the data transfer efficiency). To automatize scrolling (and also to reliably find out the rendering time of each and every page), I've used My Macros V2.0 by GoldSolution Software. With this application, it's very easy to simulate user input (in this case, pressing the Page Down key) and waiting for a pre-determined time (please also see this screenshot). The latter also helped me to find out the minimal delay between subsequent page down events for the current page to be completely rendered by the client; in the chart, I've sometimes also noted these results as, for example, "600ms delay" or "scrolling delay". By default, I've used a 2-second delay in SVGA mode; in general, all clients were able to keep it with this (except for the very slow .NET Viewer, where I had to increase this to some 8 seconds).
4. by subtracting the bandwidth usage figures after and before starting the full scroll-through, I got the full bandwidth usage of page scrolling.

Note that, during the scrolling, I've paid special attention to not letting the notebook do any additional animation (for example, animated icons in the system tray or MSN contacts / Outlook mail notifications - I've disabled all these applications) and also made sure the mouse cursor was also hovering over the title bar of Internet Explorer, not displaying any additional tip bubbles and not moving at all.

Also note that these results are, generally, an average of several tests. I've often re-run the tests in order to be absolutely sure I'm right, particularly when discussing the results with the developer.

In subsequent tests, I've repeated the test above, in a slightly modified environment; for example, I've switched on ClearType, smooth scrolling, changed the desktop resolution and/or modified the color depth (in the client); all this to see how modifying these parameters affects the bandwidth usage of a given remote control solution. These additional tests delivered a lot of important results, which I've also elaborated on in the tests.

Generally: 8 bit (with Tight VNC, 16 bit), 640*480 (with RDP) / 800*600 (with everything else), no smooth scroll: the bandwidth usage of fully scrolling down the test page in a highly controlled environment, using the a desktop resolution of SVGA (800*600) (with TSC, VGA (640*480)) and the color depth of 8 bits.

It's really worth checking out the results. In addition to the numeric results (the bandwidth usage in kilo / Megabytes), I've also compared these results to the bandwidth usage of the alternative solutions.

File transfer benchmark: with remote control solutions also supporting file transferring, I've also run benchmarks to see whether it uses binary transfer or, similar to, say, how binary content is transcoded to ASCII text to be transferred via E-mails, does it introduce any kind of overhead. I've also benchmarked the file transfer speed to see whether there are major problems with a given application. Note that, with HTTPS tunneling-capable applications, I've made these tests in HTTPS tunneled mode - that is, without direct connections - to see whether the online service is able to transfer even big files without severe slowdowns or crashes.

For this test, I've used a 24.6 Mbyte file. As can be seen, none of the file transfer-capable applications added considerable overhead to the file transfer - even the biggest overhead (that of z2) is much smaller than the overhead of, say, E-mails. I haven't encountered slow file transfers either. This means you can safely go for any of the file transfer-capable solutions, all work great, file transfer-wise.

Based on which protocol?: in here, I've elaborated on what underlying protocol the given remote control application uses. As can clearly be seen, there are three groups: RDP-based ones (with the Mocha client using, unfortunately, the outdated RDP4), RFB (VNC)-based ones and proprietary ones.

Sensitive to smooth scrolling and other animations? (Doesn’t support CopyRect and the like?): in these tests, I've enabled smooth scrolling (in IE7, Tools / Internet Options / Advanced / Browsing / Use smooth scrolling) to see whether the server component of the remote controller is able to catch "simple" scrolling events (that is, where you only communicate to the client the rectangle that was scrolled and the amount it was scrolled by, in addition to the newly-introduced content). In VNC / RFB terminology, the support for this is referred to as CopyRect.

Note that this test not only applies to Internet Explorer's smoothly scrolling Web page contents, but also any kind of similar animations. Testing the behavior of the remote controller application is of paramount importance - if you don't disable all kind of scrolling like this (and the remote controller application doesn't do this for you - several do, as will be seen later), you may end up having seriously degraded remote controlling performance.

As can be clearly seen, remote controller applications behave wildly differently in cases like this. RDP 5-based applications (for example, the Terminal Services client built into the Pocket PC 2002, WM2003, WM2003SE and WM5 operating systems) and LogMeIn don't have any problems with such contents. However, the situation isn't this good with other protocols and even the older (4) version of the RDP protocol: with the latter, the bandwidth usage dramatically (with orders of magnitude!) increases and the responsiveness of the remote control equally dramatically degrades. While, for example, GotoMyPC suffers from a 20-30% and the RFB protocol (used by VNC) exhibits a 50% bandwidth increase, other applications have decidedly worse results. I’m InTouch and CrossTec's RemoteControl exhibit a 100% bandwidth increase and, finally, NetOp Remote Control 9.0's bandwidth usage increases by about an order of magnitude.

… that is, does it send over all the changed screen contents or combines them? (The latter approach is much better): it's an easy-to-understand fact that remote control applications can't keep up with the remote desktop when the latter changes really frequently (for example, while playing a video or quickly scrolling through a document), content rendering-wise. In these cases, there can be two approaches. One approach tries to send over all the changed screen contents, using a very big frame buffer; the other approach, when seeing that the client can't keep up with the content changes, simply drops the interim frames and, in cases, only sends the frames to the client that it can safely render.

Naturally, the latter approach is much better. We've already seen the problems (at least an order of magnitude more bandwidth used and greatly slowed-down client-side rendering) caused by the former approach with both RDP 4 (see Mocha Remote Client 1.2) and NetOp Remote Control 9.0. However, the contents of this row shouldn't be a showstopper if you, in general, don't generally watch animations like this (for example, a splash screen gradually fading in/out or the above-mentioned smooth scrolling in a Web browser) over remote controlling sessions.

Bandwidth increase along with true/high color modes?: while the first test in this group used 8-bit color depth (the default color depth for most remote controller applications, except for the JPEG-based Tight VNC modes, which are 16-bit by default), I've also examined what effects high (16-bit) and, in cases (with desktop clients - the Pocket PC, having "only" a 16-bit color subsystem, can't operate in 24-bit true color mode) true color modes have on the bandwidth usage. As can be seen, the bandwidth usage only increases by between 20% and 66% in high color (and slightly more in true color), the better protocols, in this respect, being RDP 5, GotoMyPC and LogMeIn.

Under-8 bit modes, if any?: I've also benchmarked under-8-bit color depth modes to see whether you can gain significant advantage (and reduced bandwidth usage) by employing modes with fewer and more coarse colors. As can be seen, the results are pretty mixed: with remote controller applications that do support for example 2, 4- or 16-color modes (1 / 2 / 4 bit color depth, respectively), in general, (really) reducing color depth won't help much. Using LogMeIn in 4-bit mode will not help the overall bandwidth consumption (and also resizes the remote desktop to VGA size (640*480), which you may not want); z2 Remote only marginally (7%) benefits from a 16-color mode. That is, you shouldn't suffer with low-color modes with these two remote controllers because it won't deliver lower bandwidth usage. It's only CrossTec's RemoteControl that does benefit from switching to a low (in this case, 2-color) mode; then, its bandwidth needs will then be greatly reduced.

Bandwidth usage when nothing happens (absolutely no changes on the desktop and no client-side input)?: so far, I've tested the bandwidth usage when scrolling through a document. However, this is only one test case of the many possible test cases modeling a remote user's behavior.

Another test case, particularly to test whether a given protocol is well-constructed and not (unnecessarily) bandwidth-wasting is an "idle" test: to test how much traffic is generated by just rendering a non-changing desktop. Ideally, a remote controller application shouldn't generate any traffic in this case. Unfortunately, while most applications behave OK in this respect, there are some that do generate some traffic even in these cases; most importantly, the, otherwise, excellent GotoMyPC. The not-that-recommended pcAnywhere 12 has produced some very bad results.

Finally, note that it's here that I've also elaborated on the exceptionally bad bandwidth usage of I’m InTouch with the cursor blinking in the Internet Explorer address bar. In general, bandwidth usage of other protocols with similar "a cursor is blinking" case was pretty low (at least, that of RDP 5, in which case it was close to negligible); with I’m InTouch, I've measured some 340 kbyte / minute additional traffic in this case. This is much higher than just transferring plain screen contents; hope the excellent and really responsive folks at 01 Communique will fix this problem.

Support for server-side scaling (as opposed to client-side scaling down of full-resolution images)?: in the VNC / RFB chapter above, I've already elaborated on the advantages (and disadvantages) of server-side scaling (that is, server-side resizing of the image returned to the client) to save bandwidth. In here, I've elaborated on whether the tested applications use server-side scaling or not. Note that, as most of them use proprietary, closed protocols, I needed to base this row on my measurements (UXGA vs SVGA scrolling results) and, with the I’m InTouch entry, the developer's statement.

Image fetch model in panned (scrollable) mode: full image download, including currently not visible regions? : if you don't use the full-screen mode to see everything on your remote desktop, which is pretty likely on particularly QVGA clients (as opposed to VGA ones), you can save up bandwidth with clients using a protocol that only communicate the currently visible part of the desktop (the viewport). As can clearly be seen, very few applications / protocols support this advanced functionality. Note that, however, if you usually use full screen modes (on a VGA Pocket PC with not much larger remote desktops, this is pretty usual), the lack of non-progressive download won't have any consequences as you will always download the entire screen, no matter what kind of application you use.

Also note that, if you decide for VNC as the backend of your remote control infrastructure, you can configure all the VNC servers to return only, say, the current window, not the entire desktop (the latter is the default setting). You can also make use of this advanced feature of VNC to further reduce bandwidth usage.

Caching of overlapping windows?: advanced remote controller apps / protocols also integrate in the server desktop in a way that they allow for caching not only content to communicate, say, scrolling events in a bandwidth-friendly way, but also overlapping windows.

RDP 5 is a perfect example of such a well-designed protocol. When you expose a window, the client will render its contents from a local cache if its content hasn't changed in the meantime. This dramatically reduces bandwidth usage if you often switch between different tasks.

RFB (the protocol of VNC), unfortunately, doesn't support this functionality; neither do any of the enterprise-oriented trio (pcAnywhere, CrossTec RemoteControl and Danware NetOp Remote Control). The Web-based applications (except for I'm InTouch) do support this, GotoMyPC being the best and the RemotelyAnywhere - LogMeIn duo considerably worse (but still much better than any non-caching solution). Finally, RDP-based solutions (even the RDP 4-based Mocha client!) really excel in this area.

Bandwidth usage of maintaining the persistent connection with HTTPS-capable services: in the section on LapLink Everywhere (LLE), I've already pointed out LLE has severe problems with the idle server-side bandwidth usage - that is, when no clients are connected and the LLE processes "only" maintain an active connection with the central LLE server located on the Internet. LLE consumes, for mobile phone-based users, considerable bandwidth (about 18 kbytes a minute) even in this case. This is why I've made some very extensive tests to find out how the HTTPS-capable (that is, in this case, Web-based, except for RemotelyAnywhere, which doesn't have a central server) alternatives behave in this respect. Fortunately, none of the three HTTPS-enabled services exhibits so bad a behavior.

Note that, in here, I've not only listed the idle server bandwidth, but also the bandwidth usage of the initial log-in (after you start the service). Fortunately, this is pretty low too.

Other bandwidth benchmarks of interest?: in here, I've listed for example my UXGA benchmark (document scrolling) results.

Initial bandwidth usage: Loading all non-visible windows upon connection?: while RDP, in general, is very bandwidth-friendly and only GoToMyPC / Tight JPG VNC beat it in this respect (the latter not using smooth scrolling and not taking into account caching of hidden windows), it has an, in cases, very annoying feature: upon connecting to a remote desktop, it will load the contents of all the visible windows (and the desktop too), even hidden ones (ones in the background). This can lead to a lot of unnecessary bandwidth usage and slowdowns upon connection. This all means if you use RDP and you always have a lot of non-minimized windows in the background and you do want to reduce bandwidth, either make sure you minimize them (instead of just letting other windows hide them) and only let the current window to be displayed or use a remote control solution that doesn't load all hidden windows upon logging in.

In these tests, I've scrutinized whether the given remote access solution does the same. Fortunately, none of them does.

(The article continues HERE).