Making WinMX independent

[Stealth]

To continue using WinMX we need to make it independent and not rely on the currently available servers.

I have ideas but with no way to make it happen or if its possible.

Any one else have ideas or would like to see this happen?

[Andre]

What about using a system like gnutella/ gnutella2/ mute use.  a gwebcache like cache.

[GhostShip]

Those caches are not much different to the sort currently being used.

Obviously we need to explore possible new ways to deliver node information to joining clients.
I think we could all do with seeing some new ideas to discuss, this subjects been on the back burner for a while and as compatibility is an issue some avenues are currently not viable.

Any more ideas to add to those you have expressed ?

[Lagerlout666]

i have. what about over the network in network chatter betwen primrys their status being sent between them. as in how long they have been online and how much htey have been online over the last month. The network chatter could send these statistics to each primary etc and each primary can make a list of the top 100 users over the last month. this could be saved and downloaded by the secondries when they connect. this would mean that on conenct the software would scan the 100 ips in a list till it found a primary that it could conect to, this would also work for primarys connecting, then cutting out the need fora peer cache. all that would be needed then is a month by month update on sites advertising that months dated Winmx wid that months statistics saved inside incase a user found that they couldnt connect.

I know obvious protecton would be requiered for the statistics etc to not be easily read and thesaved file but it seems feasable 

                          copywrite tiny4eva lmao

[GhostShip]

I have expressed the idea of an encrypted cache of say 100 IP,s before and that sounds similar to your idea, of course any ideas like these have flaws and some are able to be overcome, there are some aspects of mx operation that limit the scope of viable solutions, but its great to see interest in these important matters and debate taking place, lets see some more ideas 

[Lagerlout666]

Never head you mention that quicks, i seen somethin about it when looking at the ares source code not so long ago and reading up on how that works and idea that had been put forward to that. but hay great minds think alike

[GhostShip]

I,m sure I could fill books with all the strange ideas I come up with. 

[J a M e S]

whats wrong with the servers..
i see no need to change something tat works perfectly well..

winmx will allways be alive as long as people are willing to run peer caches.... and thers alot of people that would jump at the opertunity to do so (i myself would do, but router wont lemme open required ports)

[KM]

your proposition to give macrovision control over the caches (which *is* what you are suggesting) is not exactly ideal

5 legitimate caches 5000 macrovision ones returning messed up results, each time you hit a macrovision cache it gives a list of offline primaries and you need to wait ages for it to time out before moving on to the next, say a 30 second delay per query, 1 query in 1000 actually gets to a legitimate cache and can connect, so that's over an 8 hour connect time on average

yeh, I'm sure i wouldn't be alone in sticking to the current system which works perfectly well and has no problems

(btw some sort of system of relying on information of known primaries from last time won't work as the vast majority of primaries have dynamic IPs, and of course macrovision can easily have just as much influence over the results as a legitimate user - multiplied by a few hundred thousand)

[Lagerlout666]

Well i was thinking along the lines of tryig to make a decentralised network. you not got any idea's of your own on this KM. I said that making such ways would need to be heavily security taged to stop corruption by said macrovision but wouldnt a blocklist as we have now in every single programme stop the connecting to bad primarys if coded correctly. Seen as we have no issue of any struggle of finding these morons so why what we do cant just be continued. I understand your concerns i have them also an im sure their is a hell of alot more to think about tat what i come up with but if that part of the programme can just be a called dll like we have a te mo that would be a very private dll that would just be used for conencting as secondry and primary, at the end of the day once that is made their should be no need to modify that part of the programme again.

[Lagerlout666]

And as for dynamic ips. it wouldnt be hard to make the prorame store the lst ip it ws using and check on next restart if it has changed. it then could activate the reporting process or disable it. pretty much the same as the auto dns updater works. if that can call the ip surely mx coded could.

[KM]

if you have a list of 10 primaries (all winmx knows about) and you save it, then open MX even a day later then most if not all are now invalid and offline, if you go offline for a week then you are basically screwed

as for a block list for it, you'd be better off with a list of good caches rather than trying to locate all bad caches and blocking them all... and you'd then still have to have some central control for that list... kinda like, well, in fact exactly like the current cache system

we don't need a completely decentralised cache system - it's not actually required, it's more of a "it would be nice to have" feature... and the risks of such a system are very real and impossible to overcome, a system is either centralised to allow some central authority to control caches to a point (in which case it's like now) or it isn't in which case macrovision can do whatever they want and nobody else can do anything about it

as i said, i'd much rather a system that works perfectly fine instead of something that might be nice to have but doesn't work

and yes, i had looked in to several ideas to reduce the dependence on a central source for locating primaries, but ultimately they all had major flaws, and none actually could provide the same level of service as we have at the moment, let alone trying to improve it

[Lagerlout666]

Well ok, ya meanie lol.
I thought it was a good idea, ill go back under me stone and think some more lol

[sIrMoOn]

While we're talking about changing the peer cache mechanism - what is the overhead (time, cache usage) from secondary clients trying to connect to primaries that are really just chat servers?  Would it be worthwhile to implement some system of advertising a primary's capabilities to the peer cache?

1) chat server connects to cache, advertises its capabilities MXP_CHAT and what primaries it's seeking MXP_ANY

2) other third party programs?  (i can't think of any others that use primary connections, but if there are they coudl benefit)

3) winmx primary or legacy third-party program connects to cache, assume capabilities MXP_CHAT + MXP_FILES + MXP_SECSERVER (so current behavior, it gets registered for everything)

4) secondary client connects, capabilities MXP_NONE (doesn't get registered), it's seeking MXP_SECSERVER, which causes it to not pull down chat server ip's (#1) since they don't have the proper capability.

maybe it'd be helpful?  and with such a generalized matching system, maybe new programs with new capabilities could be developed?

[KM]

a client is either a primary server meaning they are accepting connections, or they aren't, meaning they aren't... if they aren't then the cache doesn't return them because nobody would want that information, and if they are then it returns them because that is the information every client wants

[GhostShip]

I'm not sure if your aware of this sIrMoOn but winmx uses a system of client ID,s that specify what crypt table to be used for what type of client, this is something broadly similar to what your describing.

My concern is with the peer cache acting in any increased information gathering role as its likely to then become a target for illegal information gathering attacks that the cartels pay for, the current system is fast has virtually zero logging and stores the latest transactions in ram only while its dealing with a joining client, to offer filtering / logging at the cache for client facility types introduces a potentiall method of filtering file-sharing clients that could be then implemented under a possible future court ruling, we have to look ahead in view of the deteriorating legal climate in the US.

[SamSeeSam]

About the primary ip gathering thingy...
Is it possible to make a provision for setting up static dns addresses?
That way, active primaries could be found quickly.

Cheers

[sIrMoOn]

My concern is with the peer cache acting in any increased information gathering role as its likely to then become a target for illegal information gathering attacks that the cartels pay for, the current system is fast has virtually zero logging and stores the latest transactions in ram only while its dealing with a joining client, to offer filtering / logging at the cache for client facility types introduces a potentiall method of filtering file-sharing clients that could be then implemented under a possible future court ruling, we have to look ahead in view of the deteriorating legal climate in the US.

Fair enough - a very valid point.

a client is either a primary server meaning they are accepting connections, or they aren't, meaning they aren't... if they aren't then the cache doesn't return them because nobody would want that information, and if they are then it returns them because that is the information every client wants

Although you didn't directly address the fundamental error in my post, I think you've helped me fill in a logic gap anyway, something that hadn't ocurred to me but perhaps should have - that chat servers use the peer cache the same way secondary clients do, even though they use those addresses to make primary connections.  That makes a lot of sense and makes capability tracking at the peer cache rather redundant for that specific purpose.  In the extremely hypothetical example I gave of new types of programs trying to use this peer mechanism, the capability tracking would still make sense, but in reality a new program's more likely to use an entirely different connection mechanism independent of WinMX.

I definitely retract my suggestion = )

Still I do wonder if there's any kind of improvements to the WinMX network or client that _are_ being considered.  A lot of people still love and use WinMX, me included, but it really shows its age with things like (for example) no UPnP.  And there are other obvious improvements - like being able to associate a chatroom with a DNS name instead of an IP address.  The advantages of DNS over raw IP addresses are much hyped when it comes to the peer cache - have you considered any way of giving ordinary chat hosts those advantages?

[KM]

hostnames for channels might be useful (although not possible to add to winmx it could easily be added as an extension for third party clients) however to verify that the hostname given is correct (so you can't just type www.google.com as the rooms hostname for example) would mean looking them all up, which would be problematic... of course it wouldn't be too much hassle to allow you to manually give a name using a hostname (in the same way you can use Name_IP:Port currently), however the advantages of that would be limited to say the least

[Bearded Blunder]

i know uPnP has been looked at, there was a whole beta series of patches including it, i suspect any new patch versions are likely to....

the subject of hosting & use of dns has been discussed many times by many people, my understanding is that the protocol doesn't allow for it, so either you live without, or have to replace every chat server & client out there (including winmx itself) with something using a new protocol... which isn't very feasible & certainly wouldn't be wort the effort just to add this for chat... especially considering the vast majority of chat hosts have dynamic hostnames directly related to their dynamic ip address rendering the feature useless unless they go set up no-ip accounts or similar....