WPN Secondary Client Creation Guide




At first glance a WPN secondary client building project is an immense undertaking as many parts of the client are new and worse some of the operations are totally unfamiliar to most programmers so to help bridge the gap between theory and practical I have written a list of component parts that will be required for the creation of a basic secondary client, each one is in itself a stepping stone to building a complete client at a later stage and thus the order of construction is just as important, this modular /component level approach has many supporters in the community  and will build confidence in meeting the final goal of a new full client, something we all agree is well overdue and is needed to lift the communities spirits as well as allowing essential updates that have become a necessity in these times of throttling and other anti p2p practices, only by resolving existing problems can we hope to regain more users and a stronger user-base.  

Its my belief that the following order of build will give us the maximum chance of reaching a successful secondary client, I cannot offer as much help to those wishing to build a client not based on MFC as most of my knowledge was gained by attempting to duplicate the existing client and thus this is the system I selected to research. I believe however that this will present little more than a small hurdle to many of the community programmers and the technical information gained will offset the time spent porting any code to another platform, with that disclaimer out of the way lets get started.

An MDI framework will be required with winsock(2) support, document/view architecture and a basic toolbar and status bar, the toolbar being an important part of the build as it can be stretched to create a set of false buttons with icons on and give simple "view" selection as shown here.



Alternatively plain buttons can be placed on the main frame window to ensure they are visible regardless of which view is currently selected.
To retain the famous Mx look it would be necessary to use three such bars in the mainframe code and a some toolbar modification code to create a bar with a text edit window to replace the older style active x update window, this is what that would look like.




The project will require the system menu below the title bar to be visually removed and this means we need to add some code to replace the standard MFC handler for this, MS have an article on doing just this here. Now we have a basic window layout its a good time to look over what frame/views we want to place inside the main window frame and the most efficient order we should use to build the client.


1)  A library view and generator code will need to be constructed.
2)  The basic WinMX client base for packet handling (socket level TCP and HTTP) and common encryption features need to be constructed or included.
3)  Basic packet identification needs to be implemented and extended to cover ALL the packet types that will be encountered, also a simple ini/dat file is required for temporary variables and settings.
4)  Function code to retrieve a Chatroom list and a Search/Query Results list should be added.
5)  Add a Chat view with splitter window and a Transfer View
6)  Add further code to deal with utilising a basic chat room feature, and include all new settings to the settings dat file.
7)  The filesharing component is likely to be one of the bigger portions and thus has been placed nearly last when confidence is likely higher from completing all the earlier modules, once this component is in place and working further work is possible to improve threading and allowing for multiple sources as well as adding the ability to locally convert a file into a stream for the purposes of previewing it.


At this stage we can say the secondary project is mostly complete, many of the views and code modules created will however be re-usable in creating a primary client without major modification, and at this stage the addition of a UDP Socket and handling code is necessary as is adding the new range of packets used by primaries only including those for utilising the peer cache, a change in the clients operation may require some extra logic to enforce primary to secondary separation of functions but its likely at this stage any such will be plainly obvious.
In a primary client threading is of major importance as secondaries will be relying on it heavily and testing should be thorough to achieve optimisation of time sensitive operations.

I have been looking at solutions offered by many of the open src projects on sourceforge and other locations for information and examples of the required functions and would like to recommend the following projects and files for their clarity of code and size, some of you will also be able I,m sure to convert any home-grown solution into further components for other operating systems, this is something we need to address and resolve as any open src client must have a model that is able to be ported from one operating system to another without substantial drawbacks, I of course am not able to lead the way in that sphere but if we work together at creating a proof of concept client in any programming language that is portable it would merely be a matter of time and sweat until all where able to enjoy any new features regardless of operating system.  


The Start:

1 - The Library Generator

A WinMX style Library creation requires two important function that some of you may not be aware of how to overcome, namely creating a winmx compatible hash from a file and secondly generating each files metadata and including both in a library.dat file whose contents can later be uploaded to a primary client.
I,m sure you're all capable of creating a basic list view but for the more advanced amongst you the option of using a Treeview ctrl is recommended as this will duplicate the original clients views more closely
The best src of WinMX hash creating routines are contained in MxSock and some other derivatives that use an identical open source version from mxcontrol, I have created an article here for an overview of the hashing itself but if you use the existing code library or a derivative much time and work can be saved.
Metadata extraction is a fairly simple but time consuming process for large libraries and hashing should always be done only after all files have had their metadata extracted and saved to the library.dat file.

The core links for information that will be of help on this phase of the project are:

http://archive.winmxworld.com/String/MxHash/
http://2sen.dip.jp/arcs/MXSock.zip
http://archive.winmxworld.com/MxControl/Shareguard/[Shareguard%20Source]%20inquiro.tar
http://www.codeproject.com/KB/audio-video/mpegaudioinfo.aspx
http://sourceforge.net/projects/sunshineun/
http://sourceforge.net/projects/mynapster/
https://sourceforge.net/projects/mp3explorer
http://www.winmxworld.com/tutorials/file-hashing-info.html

An interesting new contender in this list is the emule client which features many useful and informative items.
http://sourceforge.net/project/showfiles.php?group_id=53489&package_id=47913

Its my hope that one or two of you will be able to combine the features of the component parts into a library generator that will fit into a client when further parts of it are created. For those who can create other versions of this item of the project using diff dev platforms this would also be most welcome
To lighten the processing load its advised that the Library listview contents is generated firstly and the hashing is done afterwards on the library.dat file, the local index of the library should not be uploaded to the primary files index until the hashing of files is complete this benefits both the secondary user and the primary user in ensuring all files are tagged correctly and available, a "last modified" flag can be read using the windows API to monitor changes in the library's shared directories.
Although not needed for inclusion in this part of the client the basic theory is that the files index in the Settings.dat file is uploaded to the connected primary (See OFA1/OFA3), any file additions (See 0x0FA1) or removals (See 0x0FA2) must be indicated to the primary so please bear this in mind when writing your code.



2 - The Basic WinMX Client Base

There are many projects that feature the code classes required for this stage of the project  in fact virtually any chat or server codebase contains all the items required to  get some packets flying back and forth , a list of the more promising ones is below

c++
http://2sen.dip.jp/arcs/MXSock.zip
http://archive.winmxworld.com/MxControl/RoboMx/
c#
http://archive.winmxworld.com/WinZo/
http://archive.winmxworld.com/MoonMX/beta/
python
https://sourceforge.net/project/showfiles.php?group_id=225695&package_id=273043&release_id=594935

The core items required from any of these projects are the socket layer files along with the MxSock code or equivalent and MxTables that are necessary to encrypt and decrypt WPN packets, of course more items of code can be utilise for inclusion if your project is open src or alternatively you will need to study the codes underlying theory and create your own functional code replacements.  


3 - Basic Packet Identification

Once the code above is constructed in the most pleasing way it need to be supplemented by a routine that is able to handle the encrypted and decrypted packets (See "WPNClient" in Mxsock/mxcontrol projects )and also be extended by the addition of further packet types not generally found on any of the open src Mx related projects, each new packet must be able to work in the style of the existing infrastructure that was chosen in step 2 above.
You will be able to locate a list of which packets to add by consulting the protocol pages here

http://forum.winmxworld.com/index.php/topic,6499.0.html and here http://forum.winmxworld.com/index.php/topic,6525.0.html

Plese bear in mind that some packets will not need encrypting/decrypting.


4 - Chat Room Selection And Query Results ListViews

For this stage you can once again use existing code or create your own based on information gleaned from the following code, the idea for chat list acquisition is simply to send the 238D packet and then display the 238E packet results in a list view , a similar sequence of operation is required for the query results 177A but those will be of a more expansive type as the packet has many fields that vary depending on the presence or lack of certain markers in the relevant fields, these will have to be factored in when writing this operation. It may be easier to have two sets of packing decoding depending on the type of file searched for as otherwise a bottle neck situation can occur with poor threading.

The room listing listview display is found in the programs listed below and will need some degree of modification to complete the query results listview.

http://2sen.dip.jp/arcs/MXSock.zip
http://archive.winmxworld.com/MxControl/RoboMx/
http://archive.winmxworld.com/KingMacro/Rabbit/


5 - Odds And Ends

Now is a good time to look at adding some of the other other dialogue type the Chat Room dialogue and Transfers dialogue also a  dialogue  based on a Preferences/Settings dat type file that stores the settings, once again for the more advanced a tree view is preferred with multiple child window panels for the settings selection to keep with the familiar MX feel
One of the most "Mx-a-like"  interfaces is shown in the MyNapster project  and also the SunshineUN projects both are MFC C++ and will help you by demonstrating the file transfer mechanisms and display methods also eMule has a decent transfers view that demonstrate the principles of file up/downloading display. I,m confident that some of you are capable of rewriting a basic piece of code that uses the win 32 API's instead of MFC to construct code that suits your platform.

https://sourceforge.net/project/showfiles.php?group_id=4702
https://sourceforge.net/projects/mynapster
https://sourceforge.net/projects/sunshineun/


6 - Chat Room Addition

A basic chat room client feature can be added by using existing code from many client projects. The actual windows layout is made using a splitter window with fixed dimensions to create the familiar "chat room view" we all know much of the code for this section is based around advanced string handling.
Also at this stage the complication level increases as there are many settings now to be added to deal with the chat section and also to prepare for the inclusion of some of the basic filesharing dialogues although the filesharing specific items can be added at the next stage .
To retain compatibility its suggested the normal list of post 3.52 mx chat commands are utilised, these can be found on the forum here


http://archive.winmxworld.com/Nushi/Miscellaneous/Doschat%20Src%20English.zip
http://archive.winmxworld.com/KingMacro/Rabbit/
http://archive.winmxworld.com/MxControl/RoboMx/


7 - Filesharing Code

The filesharing section is perhaps the pinnacle of the project as it will be portable to further enhanced clients (of the primary type), something we have been working our way to by working on this client, this section will require its own socket programming layer and whilst its pretty basic it will require a listview with some form of progress bar  to indicate the files progress uploading or downloading, we are lucky at this stage to have a few basic versions of this somewhat confusing area for many of us and they can be located in the following projects. A holdup for general client coding has been the fact that no mx based c++ code exists for the file transfers routines and this is something this information was set up to address.

https://sourceforge.net/projects/sunshineun/
c#
http://archive.winmxworld.com/WinZo/
http://archive.winmxworld.com/MoonMX/beta/
python
https://sourceforge.net/project/showfiles.php?group_id=225695&package_id=273043&release_id=594935


For the advanced programmers the improvement to the basic code is to create methods  for allowing multiple source downloads , this whole section is highly compatible with the opennap standard filesharing code and thus models do exist for the actual transport layer, the complication being that  WinMX has its own system of status flags using its proprietary set of protocol packets and these will need to be used according to the  conceptual model here

©2005-2020 WinMXWorld.com. All rights reserved. Page last updated Tue Jul 14 2009