Brainstorming for a new Client

[Sophosaurus]

Sooner or later, it has to be, so now or never.
I am seriously planning to build a new Client.

This is what i have in mind:

This part of it shall be Open-Source
like GUI,
Data-Structures as a relational DB,
Unique Modules for:
Library Management,
Search-Query Management,
Transfer & Queue Handling,
Connections-Management (Networks / Chatserver)
Userlists / Communication / Chat
File-Handling / Hashing / File-Verification

This part of it shall not be Open-Source
Connect-Handling,
Block-Transfer & De- & Encoding,
Traffic-Management

Except last point the seciond group of functions do exist and we hhave to question if KM is willing to provide an adapted Version of his Functions, so we could use a documented Interface, but i'm optimistic for that.

To  get back to modern Standards of P2P, we have to think about developing a Protocoll-Extension and, define Handshake and Connection-Types shaped to stay compatible with older Clients and manage to provide new Functions which aren't to integrate without an extended Protocoll exclusively between new Clients.

I want to work it all top down, starting with a chart as soon as Modules are clearly defined, build up lists of documented Functions and Data-Structures, define Functions in general and start coding when that's done, starting with GUI and DB (whichj can proivide some Dummy-functionality for testing), a simple Responder to provide network-dummy-functionality, which should help developing modules.

I hope, this will not exceed my skills and ressources and naturally to be not the only one interested in this project.

Stabdard language should be C++ vor, to keep the Open-Source parts as consistant and integrative as possible for everyone taking part in it's discussion or development. Some Fuctions could be written in Assembler as long as they are well documented.

What features do i expect from a new Client:

Extended Search-Functionality, ID-Tags, Queue-Handling like MxMonitor integrated, dynamic Upload-Slots, session-independent Results, File-Verification, Identification of Results identical to those in Library, ID-Tag-independent Hashing of MP3-Data, ID-Tag-Corretion (?), to be continued

Ideas and critical remarks appreciated, Sophosaurus

[SamSeeSam]

That is a great offer Sophosaurus ... Many will like it hopefully
I have three if they are not too cumbersome:
1.> Ability of a user to make his own profile...so that it can show up with his whois
2.> (This is a difficult one) Ability to maintain a list of offline files so that you can see that list ask for it from that user ( No need to include them in searches) .....
3.> ( Don't know how much this is... ) Ability to search for erm... users... just like you search for files. Winmx searches by relaying through primaries... i was wondering if the same could be done to users....
You are the best judge...

looking forward for it...
Cheers

[KM]

of course i had to spot this post after going through translating the german one...

any new client would have to remain compatible for any initial release, then when it came time to add any extra features do a complete redesign of the network and make it incompatible (and of course just as frontcode would do, shut down older clients to force an update)... I'm sure you can see the hardest part of the problem there...

[Alison Gordon]

I can now join winmx but still unable to send or receive pm's - can you help plse
my name is Alison and email addy gordonalison3'aol.com thks 

[Josh]

The new client needs to be exactly the same

[Sophosaurus]

at least there'd be one reason for everyone to use it if i get thru:

actually i spend a lot of time with calculations for something, no existing net has to offer but every net should have: statistic-driven upload priorities to get around the mathematical dilemma of adsl which is the main reason for avoidable traffic and growing queue lengths.

I invented a solution for similar problems on methusalahs mainframes some decades ago *g* oh, man... getting old is a strange thing

[KM]

statistic driven upload priorities?

you mean as in the more you upload the less you queue? a few programs do that, the problem is knowing how much the other user has uploaded... are you going to just ask it and trust the response for example? they normally compromise and do it based on how much you have downloaded from that user, which is as good as useless for that purpose...

[Sophosaurus]

No. i mean: calculating a files value by rarity, mean completion and mean download attempts to spread those with higher priority, eventually also calculating peers value by upload-capacity multiplied by average online-time per day

I have an average of 100 users in queue, average file size is 350Mb, average completion is 50%, so average wating time is 17,5 GB divided by capacity.

Most users lose connection long before their turn starts, so in fact, we have no queues at all, we have slot-bingo by random factors.

In the beginning of p2p rare files which are often wanted were spread faster than others which has been regulated by queus. the more a file was wanted, the more user have gotten it, thus increasing the files availability. This dosn't work anymore.

There are ppl out there, hosting some rare files and hundreds of files with good availability and the chance to spread the rare ones is 1/00, so lots of people fill up queues and do searches without getting their files completed.

We can't get around non symmetrical connections, but we can reduce average waiting time and we can guarantee availability of rare files.

[KM]

ahh, i see what you mean... yes, i think emule has a priority system for uploads, only one that does as far as i know

I think the queues of 100 are a huge problem, and the best way to deal with that is to remove the queueing system - the fastest p2p networks are ones that do not support queues at all, even though the justification for queue support is always improvements it always ends up making things worse (many p2p networks have made that mistake... and they still don't seem to learn from it)

The most common problem is people who share music and films, their slots are filled by people wanting films who are happy to sit there for days, so someone wanting a quick song can't get it. And the best solution to that problem would probably also be the solution to the (much smaller IMO) issue you mentioned:

having different slots (/queues) for different files, so an example config might be:
2 slots and a queue with a maximum length of 5 for small music files
1 slot and a queue with a maximum length of 10 for albums
2 slots and a queue with no limit for other files
...of course the exact settings to use should be customisable (allow you to create your own custom queues) and the defaults should be based on connection speed (either selected or detected when installed)

if you have no clue what I'm talking about - shareaza has something sort of like that (although i think the default settings could be improved)

but of course that assumes making a new client (it's not the sort of thing that should be done with a patch before anyone tries to suggest it)... which i don't think will be happening soon, to make an updated client requires someone with some form of authority over the existing client/network, which means a single person/group running winmx... although I do pretty much run winmx and am the person keeping it running, I don't think I can quite consider it my network and therefore make a new client for it...

[GhostShip]

Perhaps the forming of a group to develope some of the bones of a client is the way forward, I do agree some parts of any client should be closed source to prevent abuse.

[Neutron]

The DLL patch can add extentions to the WPNP and deal with it, without representing the data to WinMX, can't it? that way we could make users running WinMX on primary forward those new message types to other primaries, and add the features to new WinMX clients. the only problem would be the hosts file users, but I think most WinMX users should be giving up on the hosts files by now.

[GhostShip]

I havent looked at the demographics recently regarding clusters of host file users but previously the majority of host file users have been from the asian side of the network, this is not an easy section of the community to communicate with regarding some input from them on what they would like to see and whether any programmig talent is willing and able to help any project to upgrade the WPN.

Adding patch protocol extensions is more than feasible but if we had a core engine code base to begin with, it would be more stable and forward looking if further extensions where required, I had a few ideas regarding ip obscuring that could be implemented too if we reached that stage of development.

 

[KM]

I had a few ideas regarding ip obscuring that could be implemented too if we reached that stage of development.

you mean to prevent a client knowing the other users IP Address until the last minute? great, like to see your plan for filtering flooders after removing the method currently used to identify them... lol

There is actually a good reason that the majority of hosts file users are asian, they don't care - simple as that.

The flooders cause 2 problems:
1. uncontrolled they cause huge delays connecting to the network if you can connect at all, enough primaries are blocking to keep this problem minimal
2. they disrupt search results for the search terms they are flooding

1. isn't immediately obvious, you can't see it, and the only time anyone would notice any effects of it is when the network is doomed
2. isn't obvious unless you search for those things being flooded, which are almost exclusively english - most english speaking users and most european non-english users do listen to english music etc so would notice this, however asians don't get nearly as much english music (although many do, it is a much smaller number of asians than say french that do)

the only problem they do see with the hosts file is that they have the issues of unstable secondary connections, and they probably simply don't know the problem and think it is normal - i have yet to see any hosts file distributing site actually admit that a secondary connection should typically stay connected for at least 24 hours at a time on average, they all claim it is normal and should disconnect several times an hour... so anyone reading that would assume there is no problem even though there is

before the fake filtering there were still few users who really cared if they were patched or simply used a hosts file, the majority of patched users were only patched because that was how they had been told to get MX working (often due to being unable to figure out the 57 step "magic formula" that "pie" told them and preferred the 2 steps of "download" and "install")

[GhostShip]

Its polite to ask details of the idea before demolishing your own guesses KM, the idea I had was a optional buddy protocol extension that would allow any of the other primaries connected to you to act as a proxy for you if they too selected the buddy option and only if, this would make it rather a legal minefield to prosecute anyone for downloading/uploading files.

Its just a thought anyway, I still feel sitting idle is no good for coders, they need to be kept busy or they get bored 

[Sophosaurus]

...previously the majority of host file users have been from the asian side of the network, this is not an easy section of the community to communicate

Actually some of my friends are active on some chinese and japanese modding and conversion communities. Maybe they can find us someone to act as a communication node.

[Me Here]

If you do, I could also use a Japanese translator that would be willing to help us fix some previous tranlations and someone I could keep in contact with about further ones..