New posts to the forums are closed for now.
Read more about this decision.
![]() |
Saving communication bandwidth with compression
|
5/24/05 5:00am
Werner Ruotsalainen Moderator |
Please note that these articles/posts are outdated. Check outhttp://www.smartphonemag.com/blogs/menneisyys/ConfigureToonel45.asp for the new version. For historic reasons, though, I keep the old articles intact; they are as follows: Saving precious communication bandwidth using compression Especially mobile phone-based communication may be very expensive unless you use a flat rate service. This is why data compression comes into picture. Let's have a look at the most known TCP/IP protocols commonly used on any of today's computers. The most important of them is HTTP, the protocol that requests and delivers Web pages and resources. HTTP per se supports compression, but very few (if any!) of today's Web servers return compressed pages (due to the computational overhead that on-the-fly compression causes, unless the server also stores the given page in a compressed version, not only uncompressed). A solution for this is 1, using a ZIP'per proxy like RabbIT (http://rabbit-proxy.sourceforge.net/ ) run on your (or your friends'), say, workplace desktop PC 2, using an online service like Skweezer, which has just introduced content compression. Please seehttp://www.pocketpcthoughts.com/forums/viewtopic.php?p=345365 on this question and my remarks on Skweezer and its alternatives. Both of the above solutions have drawbacks. First, it's highly unlikely you will be allowed to run a ZIPper proxy on any of your 24/7 desktop machines. Your work computer is most probably behind a corporate firewall which doesn't allow for running proxies. DSL or cable connections (if you wanted to run the ZIPper proxy server at home) may suffer from another problem: most of them use dynamic IP's that change, in general, in every 24 hours. Sure, you can use a dynamic IP lookup service, but you would end up changing the proxy address in your PDA after the IP of your home PC changes, which can be quite tedious. Second, as for Skweezer (or any online service that does ZIP HTTP compression), it has other problems, which I've outlined in the above-linked PPCT thread. Most important is the need for manual cookie editing if you want to save cookies between sessions. Third, if you also want to use SMTP, IMAP and/or POP3, the protocols in charge of sending/receiving e-mail, you run into another problem: these protocols don't support content compression (unlike HTTP), so, you can't use any kind of remote 'proxy server' (without a local, compression-enabled client) for guaranteeing that you only send/receive highly-compressed contents to reduce bandwidth usage. With e-mailing protocols, therefore, the only solution is using a client run on the local Pocket PC (or just client device, in a broader meaning, let it be a Symbian, a Palm OS or a WinCE-based one) that use some proprietary protocol to communicate to a proprietary server run somewhere on the Internet. This server will then communicate with your POP3 mailbox and/or SMTP server. While on the desktop Windows there're several solutions that make even mail crunching possible (for example, the Bytemobile Macara Optimization Client), on the Pocket PC platform, there haven't been any, up until now. In my article, I explain how the toonel.net client, one of the first solutions to the problems outlined above, works and how it can be used on a Pocket PC device. The clients available athttp://www.toonel.net/ are written in Java. This is why, even without explicit Pocket PC support, they run on them too. Unfortunately, this also means that it requires a JVM to be run, which, taking the the meagre CPU power/memory of PDA's into account, isn't the best compared to a native implementation, but the performance/memory impact on today's hi-end Pocket PC's (for example, the 520 MHz and 128 Mbyte RAM-equipped Fujitsu-Siemens Pocket Loox 720 or the 624 MHz iPAQ hx4700/Dell Axim x50v) is (close to) negligable. First, get the latest version from the Toonel Generic Swing Package section. At present, it's version 0.0.50.20 and is available athttp://www.toonel.net/generic/005020/toonel.jar . Please note that, technically, you don't need the Swing-compatible version at all because current Pocket PC JVM's don't support Swing without additional, manual hacking. It's just that the non-Swing-enabled (and, therefore, slightly smaller) distribution package (see the toonel.net PersonalJava section - the direct link to the downloadable file ishttp://www.toonel.net/pjava/005020/toonel.net.tar.gz ) has bugs; the most important of them is the lack of the Java package jzlib (its old name was syncjzlib and the non-GUI-based version isn't properly tested; this is why the package with the old name is still there.), which renders them useless. Second, install a JVM on your PPC. In this tutorial, I only discuss the Jeode (Insignia) JVM delivered with some Pocket PC's and been purchased by many Pocket PC users. (Old versions of this JVM will run even on the latest devices with very minor problems because of the Palm-size PC (PsPC)-compliant GUI.) Third, copy toonel.jar to \Windows\lib on your Pocket PC and create a link file with the following content in \Windows\Start Menu\Programs[\<any subdirectory name>[\<any subdirectory name>]]: 99#\windows\evm.exe -cp \windows\lib\toonel.jar client.WebUI -v Run it. The program will create a sample initialization parameter file named toonel.ini in the root directory of your PDA. Transfer it to your desktop PC and edit the mail-related server entries so that it looks like the following: # This is a sample toonel.ini file used by toonel.net client application. Pay special attention to the two e-mail related rows in bold; the HTTP-related record ("8080;127.0.0.1;7999") doesn't need to be modified. Copy it back to the root of your PDA. Fourth, set up the HTTP proxy setting of the active connection group used by the "The Internet" drop-down list. (To know more where to find this, please read my article on proxy-related article at, say,http://www.firstloox.org//forums/showthread.php?p=28878 andhttp://discussion.brighthand.com/showthread.php?s=&threadid=118113 ). As the HTTP proxy is listening on your local device at port 8080, fill in the HTTP input textfield in the Advanced section of the proxy setup: Then, the basic page of this will be as follows: Please note that you can change the HTTP proxy server any time. To make this as easy as possible, you may want to read the method I've invented and described in my article in the above-mentioned article. Fifth, overwrite the incoming/outgoing mail server addresses in your mailer client to contain the word 'localhost' or, as with the above example, the IP address '127.0.0.1', which equals to 'localhost': Please note that, unlike the built-in mailer clients of Symbian devices, which support arbitrary port numbers, the built-in Microsoft-shipped Pocket Inbox/Messaging client doesn't support them: (Unfortunately, this can't even be registry-hacked.) Therefore, if you plan to use several POP3 clients with different server addresses (!) with Toonel, you will want to switch to some other, more advanced mailer (POP3/SMTP) client with port defining capabilities for each account you set up. An example of these advanced mailer clients is WebIS Mail (http://www.pocketinformant.com/products_info.php?p_id=mail&dir=wm& ). Note that if you close/kill the JVM by clicking the X button (it not only minimizes it!), your PIE browser and mailer clients won't be able to connect to the net because they'll try connecting to the (non-existing) local proxy. Then, just re-run the proxy starter link. Please note that Toonel will crash on the PPC if you try to use its setter HTTP page at localhost:7999. It's best to leave it alone - fortunately, \toonel.ini has all the settable parameters, so, you don't really need the on-line page. Bottom line Pros: To be continued: 1, using toonel with other JVM's (Créme, IBM etc), also with comparative benchmarks on JVM speed etc. Please post your remarks here. Do you need additional clarification? Was there anything in the article that you haven't really understood? The author is an expert in TCP/IP protocols and wireless communications. He has authored the IBM JavaBeans FTP Java bean and library back in 2000-2001 and has co-authored the POP3 and SMTP libraries in the same section. Has also authored several HTTP proxy and filtering servers and libraries; for example, the Mobipocket Web Companion Support Pack (http://menneisyys.freeweb.hu/mwc ).
|




Werner Ruotsalainen
Moderator
I’ve played a bit with the latest PPC build, 0.0.50.30. It’s working flawlessly. It uses the same gui.ClientForm main class as the previous version, so, your previous scripts will run OK.
I’ve re-tested it with CrEme 4.0; this time, CrEme worked flawlessly; that is, ignore my previous remarks on its incomatibility. You should, however, be afraid of its System Path overwriting bug. If you have ever relocated your DLL’s from \Windows by hand, with Tweaks2k2 or with MemMaid, beware!
Also, please note that if you don’t pass the -Ob switch to CrEme.exe, it won’t display a console window. It doesn’t have much memory advantage (the memory occupation difference is some 100 kbytes) and you won’t see error messages like the one by default, when you don’t fill in the mail server addresses in toonel.ini in the root directory. It has one big advantage, though: if you don’t start a console window and use some simple task switcher like the AltTab utility, the task switcher in the driver of the ThinkOutside keyboards or that of the Close button context menu of Spb Pocket Plus, the console window won’t be listed. This is of great help if you prefer using, for example, the AltTab utility for extra-fast switching between applications.
Then, the two CrEme link files become as follows:
4.00:
255#"\SD-MMCard\JAVA\c400\bin\CrEme.exe" -classpath \SD-MMCard\JAVA\toonel.jar gui.ClientForm
3.26
255#"\SD-MMCard\JAVA\c326\bin\CrEme.exe" -classpath \SD-MMCard\JAVA\toonel.jar gui.ClientForm
where \SD-MMCard\JAVA\c400 and \SD-MMCard\JAVA\c326 refer to the home directory of the two versions, respectively; while \SD-MMCard\JAVA\ is the directory where toonel.jar is located.
Unfortunately, if you execute J9 by giving a call to j9w.exe instead of j9w.exe, the application won’t be executed. Another remark regarding the IBM JVM: It complains about the lack of java.lang.Thread.stop() method when you click the ‘Shutdown’ button. This can be ignored; the Toonel window must be forced to close and you need to exit my choosing File/Exit.
Some memory consumption benchmarks (a.k.a. does CrEme 3.26 consume less memory than 4.0 and what about the J9) with toonel (no Jeode in this test):
CrEme 4.00: ~5Mbytes (44.19/39.12)
CrEme 3.26: ~4.5Mbytes (44.19/39.12)
IBM J9 5.7.2-P-20050304-1743: ~4.8Mbytes (44.19/39.35)
That is, CrEme 3.26 consumes a little less dynamic memory at runtime than version 4.00.
Werner Ruotsalainen
Moderator
I've been contacted the toonel.net people; the new beta version they've sent me is working great under both IBM J9 and CrEme 3.26 (please note that CrEme 4.0b8 seems to have a bug that makes it impossible for toonel to receive anything. Therefore, don't use that version.). Hope they'll also release of this fully PersonalJava-compliant, final version soon.
As far as my experience is concerned with toonel, after some weeks of usage: it's very good. Running the client doesn't slow down the PPC when it's not doing any decompression; and, even then, the difference will be negligable.
The link files to run toonel under IBM J9:
255#"<path to J9>\bin\j9.exe" "-jcl:ppro10" -cp \<path-to-toonel.jar> gui.ClientForm
and, under CrEme:
255#"<path to CrEme>\bin\CrEme.exe" -Ob -classpath \<path-to-toonel.jar> gui.ClientForm
I've explained athttp://smartphonemag.com/forum/topic.asp?TOPIC_ID=16612 , among othertings, how JVM's can be downloaded/installed. (Please note that the current (as of 26/06/2005), .21 build won't run under these JVM's! Later builds will.)
The only problem I've encountered so far is the 32-process limitation of Windows CE. This means that the operating system core may choose to kill the JVM process if you start a new application and quite a few, along with some system processes, are already running.
You'll notice this in Pocket Internet Explorer on a WM2003SE device as soon as you try to fetch a new Web page. On a WM2003 device, however, the situation is different: PIE won't complain of not being able to make a connection, it will just silently connect to the original Web server without more ado. This means on a WM2003 device you may want to periodically test whether the JVM (and toonel) is still running to avoid fetching uncompressed Web pages and/or exposing your identity (toonel is also great at hiding it!).
The above isn't a problem using NetFront, however. Therefore, if you plan to use several programs on your PDA at the same time (for example, you open several PIE windows with a tool like PIEPlus, MultiIE or Spb Pocket Plus), you may want to consider switching to NetFront completely. Beware of the bugs of it, however (even in the latest, 3.2 version); please seehttp://www.pocketpcthoughts.com/index.php?action=expand,41008&/netfront_3.2_english_finally_released.htm on this.
You may also want to readhttp://www.smartphonemag.com/newsl_jkwg/JKWG_06-07-05.htm on other compression techniques.
Werner Ruotsalainen
Moderator
As has been promised, I've continued testing the toonel client with the latest Pocket PC JVM's, in addition to Insignia Jeode (with which it runs flawlessly).
Unfortunately, neither IBM WebSphere Everyplace Micro Environment 5.7.2 - Personal Profile 1.0 for Windows WM2003SE nor Creme 4.00 (http://www.nsicom.com/Default.aspx?tabid=159 ) worked because they don't contain the as of JDK1.1 deprecated java.util.Date.toLocaleString().
Hope the people at toonel.net redesign/recompile their code so that it is compliant with Personal Java/J2ME (while keeping compatibility with other platforms) and doesn't contain (heavily) deprecated method calls. It'd be great to be able to run the app under not only Jeode on the PPC but also alternative (and, as with IBM's, free) JVM's.
Werner Ruotsalainen
Moderator
In the meantime, I've been contacted by the people at toonel.net. They have quickly fixed the bug I've pointed out above with the Personal Java distribution package; the fixed version can be found athttp://www.toonel.net/pjava/005021/toonel.jar . It works flawlessly.
I've also continued playing with the toonel client and found out that you can only connect tohttp://127.0.0.1:7999/ if your current browser doesn't use a proxy at all. That is, in PIE, you just disable the proxy and reconnect (leaving the proxy definition screen also results in a reconnection), and, in Netfront, just go to Tools/Browser Settings/Network, and, in the Proxy group, clear the "Use proxy" checkbox. Then, the config screen will work flawlessly.
Please note that NetFront 3.2 has the Proxy setting screen at the same position as NetFront 3.1. (This is an important question because NF3.2, which is much better than its predecessor - see my remarks and comparisons on this athttp://www.pocketpcthoughts.com/forums/viewtopic.php?t=39674 -, is only available in Japanese.)
In both versions of Netfront, you will find the proxy setting screen at Tools/Browser Settings (G in the Japanese version)/Network/Proxy. In English:
And, in Japanese,
a. the third menu on the menu bar:
b, click the (G) menu item and go to the third tab, as with 3.1:
c, clear the checkbox (it's "Auto-retrieval" in English) in the upper left corner and, if it's not checked, check in the "Use proxy" checkbox in the right. Then, enter the proxy name below. Again, please note that this dialog screen is exactly the same as with the 3.1 English version so you will know what to click, even if it's in Japanese.
Because the proxy deactivation is pretty complicated with PIE because it depends on the system-level proxy setting, I think it'd be best if the authors of toonel added accessinghttp://127.0.0.1:7999/ as an exception to their proxy server - that is, if the proxy server sees a request for this page, it just redirects the request to the local page.
I'm still testing toonel with alternative JVM's - stay tuned!