OurMx - The Story So Far

In late 2011 it became clear that a sustained attack was continuing against the WinMX Peer Network, the roots of this attack are laid at the door of one single disgruntled former third-party developer.

The attacker was one of a small group of developers whom had knowledge of the WinMX Peer Network's hithertoo secret network level protocols, after the hasty closure of Frontcode it was felt necessary to both discover these protocols and document the functionality of each element, this work was undertaken with no real urgency and many basic draughts appeared across the years with updates and clarifications soley based on the examination of client level network traffic, through using this non-invasive method it was possible to build up a near complete picture of the entire range of protocols used by WinMX, these inluded the primary network protocols, the chat protocols, and the secondary and filesharing protocols, in all a lot of work was undertaken and the reults shared selectively to minimise the publication of the entire documentation.

Nearly all of the community developers where from this point onwards able to gain the basic lower tier sets of data but the jewel in the crown was firmly held back from all but the most active developers whom had reached a "need-to-know" level and in most cases they where helped without exposing the critically vital network header controls to excessive scrutiny, this was undertaken by ensuring packet data fields had no special information or notes added so as not to draw attention to them to ensure that those whom where working on a network level application would make themselves known by the request for further details or help and thus alert the other developers of their activities and intent, this was felt a very important function post-frontcode as without any further releases of WinMX the developer(s) of any new client would have to come from within the community itself, with this as the driving motivation within the developmental community the road was now being laid slowly but surely to work towards achieving some traction in this are as otherwise stagnation and frustration would ensure the network became out-dated and would spiral into decline, thus a long term strategy was formed, create a new Primary network capable client for the future.

A previous project was chosen as the base for begining the client project it's name was MxShare and had been a small work in progress and learning tool for those undertaking its creation, it was initially thought that this secondary only project that was based heavily on the Open-Src RoboMx code base would make a good start as much of its code was already in the right place and much of the unwanted code had been removed to create a WinMX lookalike. The core idea was that if the secondary client code could be made first then when the primary client was later constructed it would enable a set of pre-existing clients to be utilised in a short term as the facility was in place to allow for any updates that where deemed necessary for operating with new primary network based clients.
Work went on in this direction for a short time but it was felt that enough of a client was in hand and the threat of more effective attacks on the horizon was increasing so the secondary project was shelved and a primary version was started using a new code base and internal code structure, this was simply to facillitate improvements and features not available in the RoboMx code being a chat server, Filesharing, Primary client and Secondary server engine, in effect a 5 times increase in code developement, the project was still at this stage going on under the MxShare label albeit at least 50 similar versions exist of the older code under version 7, post version seven the project was primary network based and the secondary side of things was something to be added later, as expected the developers had basic functionality in hand but with so much new aspects of code to add and research it was clear this was going to take a long time and that was even with leaving out the OpenNap network facility to speed things up.

When in 2013 it was felt that the users where becoming restless a Beta release was planned for the upcoming "resurrection" anniversary, this was undertaken purely to both gather new developers and fresh interest as well as demonstrate to the community that a new client project was actually underway, some had after all been suggesting such a project did not exist, the 2013 release proved such folks very wrong.

Beta 1 Release

At the time of the release a new name was selected following a forum vote "OurMx" was chosen however it was not possible to secure the OurMx.com name for the project so we chose the next best thing following on from the WinMX World concept, OurMxWorld was launched under the leadership of Silicon Toad to take over the management of both end user support and developer feedback and to free up such roles from those undertaking the actual client development, this was simply common sense as there remain so few developers even a few hours saved means a lot of prime time is not wasted.

OurMx Beta was happily received and feedback poured in that was of great help, some aspects of the feedback pointed to areas that had not yet been completed within the client, however many parts of the beta client where overlooked when they did in fact work already, the developers accepted that this was likely due to the release not meeting the exacting specifications required by the community prior to accepting any new client and have continued on with updates and research materials published at intervals to show that there is activity even if its slow going.

The following page was created to demonstrate the ongoing commitment and to keep the userbase updated on newly delivered functions and solidifying some of the existing functions.

Beta 2 Preview

 
Whilst working on Beta 2 it was felt that with the WPN network in such a sorry state a "backup network" would be a wise investment of time so the additional facility to connect to OpenNap was scheduled to appear in Beta 3, with many parts of Beta 2 already being worked on by our 2 seperate coders and the hard bug fixes being done by the most experienced of the two it was left to the lesser skilled developer to add the basic building blocks of the OpenNap capable version, this involved not just adding code but doing supporting research to ensure data was to hand when required


OpenNap Protocol research


Some basic external parts of the OpenNap version where laid into place and much work has gone in behind the scenes outlining packet definitions and input/output packet handling and functionality as well as a threading control to handle this section as a stand alone feature, there is at the time of writing still much work to go on but we are in a good place in regards to overall progress, some annoying bugs are still in evidence but the trade off of annoying rare bugs to overall client stability is very favourable.

OpenNap Beta 3 Preview


Its been a while since the last update report due to many factors but of course the work has continued and we have resolved many bugs and undertaken further code review and code routine commenting to assist with the final aim of open sourcing the client.

Lets take a look at whats new.
OpenNap Beta 3 Preview Update