New tarball format, imminent 2.2.3, new developments

After the reorganization, we introduced a new tarball format based on the developer's revisions. The tarball name aMule-SVN-r9240.tar.bz2 includes the revision "9240" (the 9240th change to aMule) - the higher the revision number the more recent the code change.

Prior to releases we offer tarballs with prerelease code (in lieu for a Release Candidate), those are labeled with "RELEASE-2_2_X" or similar while the current development is labeled "trunk". The release tarball may have a higher revision number than the trunk tarball, don't let this confuse you.

You can download tarballs from the temporary download page at http://amule.uw.hu/tarballs/.

Thanks to Gnucco, we have a public GIT repository at http://repo.or.cz/w/amule.git , which makes it easier to track changes. Thank you, Gnucco!


Furthermore, we're nearing the release of aMule 2.2.3 - if you can, test the provided tarball to help us to provide a new stable version of aMule.


On the new developments side, lfroen continues working on a Cacoa-Gui for aMule, Stu Redman is successfully hunting little bugs, making sure aMule runs and builds fine everywhere. He rewrote the client speed calculation and fixed the core timer and the download limit.
GonoszTopi fixed handling of invalid KAD pakets and is generally busy preparing the 2.2.3 release.

migration status

As you might already know, late September the hirnriss.net server was shut down, permanently. Since then we have successfully moved the Subversion repository to another server, and slowly services are coming back to online.

However, development didn't stall meanwhile. Stu Redman committed a complete logger rework, and as a temporary tarball server has been set up, user-contributed minor bugfixes came back, too.

webserver template change, small changes

Starting with tomorrow's tarball, only one webserver template will be shipped with aMule - the wonderful litoral design by GeVauDan and Gulp.


This is a first step to improve amuleweb making it a very stable application, which ultimately should be able to support this awesome template concept by GeVauDan.
The name of the skin has been changed to "default" - amuleweb might have to adjust config file.


A couple of small fixes have been committed, too. The progress bar in amuleweb for files > 4GB has been fixed, Stu Redman has committed patches to disable warnings for MSVC builds and for automatic geoip.dat download using the RemoteGUI as well as a compilation fix for the RemoteGUI on MSW when IP2Country was disabled.

MarkAsKnown selection, GeoIP, Win documentation

There were a couple of changes the last days:

LittleAbacus wrote a patch to allow the selection of multiple files for the MarkAsKnown function.

Further work on GeoIP compatibility was done and Stu Redman extended the documentation for Windows builds.

GonoszTopi wrote an instanceless URL decoder, fixed GeoIP flag selection when actived, but not found and patched a sed script to be more portable.

Buffer overflow, notification based EC, MSVC and fixed links

Thanks to a bug report by menos_16, we were able to resolve a nasty buffer overflow error in cas - the command line tool is now fully working again.

lfroen started to rework EC (What is EC?) to use a command/notification system. This will yield in a more stable remote connection experience. Please excuse any EC usage problems during the switching period and report any problems in the forum - thank you!

Stu Redman worked on MSVC solutions for the free Express Edition and solutions for fileview and geoip.

GonoszTopi fixed the links in the amuleweb page shown when there's no template available, so that you should be able to easily get help in this case.

More bug fixes

gtoso and sturedman fixed a bug which affected skin support on localized system.

GonoszTopi worked on the GeoIP integration (IP2Country), making libgeoip optional and prefer static linking .
Edit: I've understood the summary wrong, here's his correction from the comment.

It only checks, if a static link request can be fulfilled and displays a warning if not, reverting to dynamic linkage.

Furthermore he fixed incorrect handling of zipped archives and added another ipfilter file name.

Skolnick's patch to support files bigger than 4 GB with alc and alcc was committed and GonoszTopi fixed the related progress bar display problem.

sturedman also fixed the debug build on MSVC.

Last, but not least, some very good news: gtoso joined our team as a Mac developer and already started on providing valuable help and Mac packages. Welcome!

aMule fileview, configure warnings and Mac GUI discussion

GonoszTopi worked a bit more on the fileview utility. Located in src/utils/fileview it provides an easy way to take a look at binary only files from aMule.

While there is not yet a configure option to compile fileview, it can be easily compiled after running the configure script by switching to the fileview directory and typing 'make'.

The utility itself can be used by executing the mulefileview executable and giving an aMule binary file as argument.

An example:
$ ./mulefileview ~/.aMule/Temp/001.part.met
Decoding file: /home/johkra/.aMule/Temp/001.part.met
Version : PARTFILE_VERSION (0xe0)
LastChanged : 1215680812 (Thu Jul 10 09:06:52 2008 UTC)
FileHash : 834604C8ED9FEB337454B4E75F77CE9F
Parts : 0
HashSet :
TagCount : 18
{ 0x01 FT_FILENAME, 2 TAGTYPE_STRING, "LinkCreator0.7.[contentdb.emule-project.net].zip" }
{ 0x02 FT_FILESIZE, 3 TAGTYPE_UINT32, 128718 (126 kB) }
{ 0x08 FT_TRANSFERRED, 3 TAGTYPE_UINT32, 0 (0 bytes) }
...

You can use this tool to view part.met files as demonstrated or to open the known.met file and view all finished downloads by aMule.


Furthermore he also added a new macro for the configure script, which will allow for a nice formatting of messages and more importantly display all warning messages at the end of the configure output, so no warning will be overlooked in the future.


Lastly I want to point to an discussion in the forum: Mac port - different approach

Some bug fixes

I added some checks to cas to prevent segfaults (someone should port it to C++...), added an option to specify the location of the amuleweb binary for autostart and fixed the wxCas save dialog.

lfroen removed mutexts from amuleweb as we don't use threads anymore.

amuleweb-assert, php-standalone, compat

With developers either desperately lacking time and/or not feeling like working during the summer vacation only few changes occured during my absence.

aMuleweb gained support for creating basic backtraces on crash (just like aMule does, but using gdb is still necessary to properly identify problems). I think Vollstrecker, phoenix and GonoszTopi worked on this.

Lfroen changed the build process to allow for php standalone compilation.

GonoszTopi committed some patches to improve compatibility with different shells.

All quiet on the southern front

whilst I haven't updated lately (I blame flower vendors.), there have been some changes to aMule.

It was mainly Vollstrecker going on a patch spree and changing everything which had no svn lock on it.

He worked on Copyright messages, po file encoding, fixed make clean and make distclean (fixing a real bug) and updated the debian folder.

Myth contributed a patch for Feedback from shared files while morph had a look at our man pages.

Oh, and we made a release. But I think you know that already.

amuleGui, Windows Resource leaks, SX

Thanks to xor the amuleGUI desynchronization should be fixed now in 2.2.2 and SVN.

Also Stu Redman was working on fixing GDI resource leaks on the Windows build which should improve long term stability on Windows. (Hopefully this can be fixed on wx side, too.)

Muleview supports now v3 nodes.dat files, thanks to a patch by GonoszTopi.

At last, Kry committed a fix for incorrect source exchange packets.

Kad bugfixes and improvements.

GonoszTopi made more improvements to the aMule Kad implementation. (Will be included in 2.2.2)

• Implemented a special nodes.dat version, which is more suited for mass distribution without causing significant additional traffic for the included nodes. This is to allow eMule to add a nodes.dat to the installer, so that new user can connect to Kad without having to connect to servers or downloading a nodes.dat themself. We also need to be able to read and process this nodes.dat file.


• Implemented an alternate method to estimate the total user count in the Kad network, which is not based on our local routing table. It is experimental and only in trunk.


• Fixed a minor bug with kad obfuscation when contacting answering unbofuscated hello-requests.


• Made sure that only one challenge to verify a contact is sent at a time to the same IP.

Kad v8

GonoszTopi ported Kademlia version 8, which will be intregrated into our next release. I quote the Changelog:

• Kad now ignores multiple IDs pointing to one IP in routing request answers


• When calculating the total user count, Kad now uses (if available) the real number of firewalled clients for the calculation instead a fixed value. This will take more effect when 0.49+ nodes become common


• Kad no longer tries to add UDP firewalled (and therefore mostly unreachable) nodes into its routing table, reducing overhead and increasing reliability [Idea: Netfinity]


• Optimized the Kad packettracking code to only track packets which we check later, to save resources


• Fixed a bug which let Kad sometimes assume a Kad2 contact to be Kad1 after probing for both versions


• Did first small step in dropping Kad1 support by not probing unknown Kad contacts for Kad1 anymore to save overhead. Kad1 clients will nevertheless still be work for now.


• Several changes were made to Kad in order to defy routing attacks researched by University of Minnesota guys [Peng Wang, James Tyra, Eric Chan-Tin, Tyson Malchow, Denis Foo Kune, Nicholas Hopper, Yongdae Kim], in particular:
  
  • Kad contacts will only be able to update themself in others routing tables if they provide the proper key (supported by 0.49a+ nodes) in order to make it impossible to hijack them
  
  
  • Kad uses now a three-way-handshake (or for older version a similar check) for new contacts, making sure they do not use a spoofed IP
  
  
  • Unverified contacts are not used for routing tasks
  
  
  • When reading a nodes.dat without any verified contacts (possible an old file version), aMule will assume all contacts to be verified to avoid slowing down the connecting process
  
  
  
  
  

aMule development blog

This blog serves to inform users about important changes in the developmental version of aMule. This includes new features as well as changes to the application like new configuration options.

The blog won't be updated daily or immediately after every change, but expect to be informed of the most important changes in a timely manner.

I happily accept contributions like feature explanations, please contact me.

kind regards

Johannes Krampf <wuischke@amule.org>