[General Topics] Menneisyys:
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 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 there 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 how enabling 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 effect 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 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.