[General Topics] Menneisyys:
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, considerably 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.

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

This means if 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.

Auto-overriding System / Advanced / Performance / Settings / Visual Effects settings for speed: this group scrutinizes whether the given remote controller disables advanced visual effects like font smoothing etc. You can, for all applications, en/disable these effects; a decent remote application should disable them all (it's possible; see for example what happens when the, in this respect, best pcAnywhere 12 client logs into a desktop that has all the effects enabled) upon logging in to, in cases, greatly reduce bandwidth usage.

Disables wallpaper?: one of the most important activities a remote controller should do to conserve bandwidth is disabling the desktop wallpaper to, in cases, reduce bandwidth usage with tens or even hundreds of kilobytes.

Disables font smoothing (see an example here) / Cleartype (IE7: Tools / Internet Options / Advanced/ Multimedia / Always use Cleartype for HTML)?: font smoothing, which is a system-level setting, and ClearType, which is "only" used by applications using the HTML renderer component of Internet Explorer (Outlook Express, Outlook etc., in addition to Internet Explorer itself) . Unfortunately, the latter is disabled by only RDP; the former is disabled by more remote applications.

Disables "Show window contents while dragging"?: should you often drag remote application windows from one place to another with the "Show window contents while dragging" checkbox enabled in System / Advanced / Performance / Settings / Visual Effects, your bandwidth usage can dramatically increase with protocols / remote apps that don't automatically disable this. Unfortunately, even the RDP protocol is sensitive to this - and it doesn't automatically disable window dragging, which can cause a lot of problems because of the increased bandwidth usage.

Disables smooth IE scrolling?: if you enable Internet Explorer smooth scrolling in IE7, Tools / Internet Options / Advanced / Browsing / Use smooth scrolling, does the application disable it. Unfortunately, the none of them does this, with the consequences visible in the "Sensitive to smooth scrolling and other animations?" test.

Connection model? group: in here, I've elaborated on the connection model the tested remote applications use.

In general, there are two main types, which has already been explained in the first section of this application: apps using direct connection where you must pass the remote client the direct Internet address of your remote desktop and apps that rely on a central dispatcher server hosted by the developer.

In the first test case, I give an overview of the model; with direct connections, I've also listed the port numbers to be forwarded, should you need to access these systems behind a firewall, where you can still ask the firewall to route given ports to your PC.

LAN (internet-less)?: can you access these systems without your local area network (LAN) being connected to the Internet (for example, via BT PAN, Wi-Fi p2p or, with some special applications, even non-TCP/IP-based, that is, infrared / serial / parallel port connections) ? As can clearly be seen, it's only the three "true" Web-based applications (apps where you must use the main dispatcher to log in) that you must have a working Internet connection for, at least, the initial login.

Usable through ActiveSync'ed PDA's to access the same desktop the PDA is connected to? (With direct connections using local IP’s (192.168.55.100 with pre-WM5 and 169.254.2.2 with WM5 - see this for more info on the latter) : many Pocket PC users would like to remote control their desktop computers via USB, via ActiveSync. Fortunately, all remote control solutions support this - after all, an ActiveSync USB connection is a full TCP/IP connection; if you enter the above IP's as the server address, you'll be able to connect to the desktop. Also, if you have Internet access, you'll be able to use Web-based applications to access your desktop too from a USB-connected Pocket PC.