This is another minor bug fix release. The bugs included IBM JDK compatibility, improved malformed Referer header handling and compatibility improvements with some web servers. This update is recommended for everyone.
Hopefully the next release will be version 2.7 in beta form. I’ll be announcing some of the new features here in the next few days and a beta download will be available to anyone who would like to try it.
The next major features on the horizon for MidpSSH revolve around improving the security of the application.
The first is password protection of the application itself; to prevent anyone else from using it to connect to your servers. Currently you are encouraged to store your username and password in MidpSSH as it is so hard to type reasonable passwords on a phone keyboard! Also if you’re using public-key authentication then anyone can use your key to access your servers. Password protecting MidpSSH will prevent anyone accessing it without your password and will also encrypt your configuration data (including session information and keys) so that people can’t gain access to it either.
Secondly the HTTP proxy solution will be improved and documented properly. Finally I have had feedback from Aleksy Schubert of Warsaw University regarding some improvements that can be made to the implementation of SSH in MidpSSH to make it more robust.
I’ll announce testing releases and further news here.
After over a year as the development version, and off-and-on development, I have released version 1.6.0 of MidpSSH. This is functionally identical to the last development version 1.5.7.
The major features are Keyboard Interactive authentication and an HTTP proxy solution for people behind telco firewalls.
If you don’t know about MidpSSH, it is an SSH client for use on Java enabled mobile devices such as cell phones. If you use SSH then MidpSSH could save you a trip to a computer if you’re in a bind.
This is a minor bug fix release for the 2.6.2 release of two weeks ago. Version 2.6.3 corrects problems with the Port Forwarding tool introduced in the previous release. Thank you to Grant Wilson for detecting the bug and for testing the fix.
On the weekend of the 3rd and 4th of February I attended Baa Camp (the New Zealand Foo Camp) in Warkworth, an hour north of Auckland. From the website:
New Zealand Foo Camp (aka Baa Camp) is a private gathering of around 150 people from New Zealand, Australia, and the world. Invitees are doing interesting work in fields such as web applications, open source programming, wireless, web services, data visualization and search, geolocation, and all manner of emerging technologies, and are invited to network, share their works in progress, show off the latest tech toys and hardware hacks, and tackle challenging problems together.
It was a very interesting and enjoyable weekend. A big thanks to Nathan Torkington for organising it. Highlights included showing off my appalling frisbee skills, meeting Allan Odgaard of TextMate fame, showing off my appalling Wii bowling skills, and meeting and playing Werewolf with three Charles users; one of whom works just around the corner from my office.
In December last year Rich Riendeau reported excessive packet fragmentation from the throttling implementation in Charles v2.6.1. While the simulation of the bandwidth was accurate, it didn’t necessarily reflect the structure of the packets as they would actually exist on the network in a bandwidth limited situation.
Packets are usually be sent out onto the network in fragments equal to the MTU, however Charles tried to share the throttled bandwidth between multiple connections by allowing data through in chunks of approximately 1/10 of the available bandwidth. Therefore depending upon your throttling configuration, and the number of concurrent connections, Charles could produce more packet fragments than would be expected. So as of Charles v2.6.2 the throttling system has been tweaked to use MTU-size packets.
As a consequence of this there is an MTU setting as part of the throttling configuration. On a broadband connection (and on any Ethernet network) the MTU is often 1500 bytes, however on a modem or PPP connection the MTU is 576 bytes and packets must be fragmented to fit. Charles now has the capability to simulate the MTU differences on different types of connections and thus effect the appropriate realistic fragmentation.
Looking to the future: a feature that has been requested a few times is random throttling to simulate variable Internet conditions. I’ve spoken to several people about it and I think that its time may be near! If you’ve got any thoughts about it I’d be pleased to hear them.
Charles previously stored all of the request and response information in memory, so if you had Charles running for a few hours (or browsed a lot of images) it would quite often run out of its 64 MB of heap and stop recording until you had emptied the session. I have Charles running all day every day and I’d have to clear the session several times a day: frustrating.
Furthermore, in an effort to reduce the memory usage, Charles would only record the first 100 KB (or so, this was configurable) of binary files such as images, videos and executables. This helped to not use up all the free memory so quickly, however it also meant that you’d sometimes miss the end of something you were interested in. For example, with the introduction of AMF parsing (a binary format) I had to extend the default 1 MB cut off for binary files to avoid truncating large AMF messages.
But wait! In version 2.6.2 both problems have been solved. Charles now saves large requests and responses to temporary files on the hard drive, and there is just one configurable recording limit (defaulting to 10 MB per request/response) to prevent excessive storage. Recording still uses memory, and you’ll see the memory indicator increase in Charles the more you record, however it should be significantly slower to fill up completely.
On the 1st of February (one day before I was off to Kiwi Foo Camp) Charles v2.6.2 was released and can be downloaded from the usual place. I’m going to blog separately about the major new features in an effort to look more blog-prolific.
Here are the highlights: