Author Topic: Is there really any reason to make new client compatible with old client? (Read 5110 times)

achilles · « **on:** July 09, 2011, 07:07:19 pm »

Is there really any reason to make the new client compatible with the old client now that the old one does not work anymore? No one will be using the old client now that it does not work anymore anyways. Everyone will have to switch to the new client now to be able to use the network regardless of the outcome. I think we need to keep the familiar WinMx GUI, and start from scratch on the flawed protocols. It will mean much less work in the long run. Only the protocols that can't be exploited so easily from the old client should be used. Trying to make sure the new client is compatible with the old client will only hold up progress, and insure that WinMx is doomed. I believe we need to keep the familiar GUI, and change whats under the hood to insure the most secure network possible.

RebelMX · « **Reply #1 on:** July 09, 2011, 07:39:38 pm »

I see no gain by writing our own protocol. All protocols will have a flaw somewhere. We have now found the holes and are (i assume) somewhere near patching them in the current client. Therefore these fixes can be implemented directly inside a new client and therefore not require a patch. So what is there to gain in writing brand new protocols which will have flaws somewhere and wait for someone to find the holes?

Too much thought is going into new ideas and fixes when there is nothing to even resemble the current program. I don't think we should even be contemplating any features until there is a basic working replacement. To do so is to hype up over nothing.

achilles · « **Reply #2 on:** July 09, 2011, 08:43:36 pm »

I was thinking there was intention of updating the protocols for some time now. Is there no intention then to eliminate the 2GB file cap? If it's not eliminated early on in the new client then it would be much more difficult to do later on. IPV6 compatibility will eventually have to be added. If some of the protocols are not updated then I would not have much use for WinMx. I'm not big on chatting in a chat room all day. I don't have the time to. I'm thankful for the feature, but that's not what brought me to the network. I'm the user that leaves WinMx running for months at a time without ever shutting it down. I may not be in front of the computer screen all day, but its doing its job without me. Exchanging of files is what brought me to the network back when WinMx was first released, and it will be what keeps me on the network or makes me decide to leave at some point if those changes are never made. Equal importance needs to be placed on the chat feature, and the exchanging of files feature. If anyone thinks the chat feature is the reason users prefer WinMx over other clients then I believe that person is gravely mistaken. I like the chat feature a lot, but for communicating with others users on the network for being nice enough to let me download from them. Its good to be able to say thank you or something along those lines. I'm very thankful for chat rooms, but I don't use them often. I want to see equal importance being placed on both features of the client. I hope they are keeping that in mind when work begins on the new client again.

achilles · « **Reply #3 on:** July 09, 2011, 09:01:59 pm »

Btw.. I have an ideal for the patch, but not sure that we have a coder capable of coding such a feat. It is a very basic ideal in nature, but I think it would be difficult to code into the patch. I don't have access to the core though so I don't know what has already been discussed.

White Stripes · « **Reply #4 on:** July 10, 2011, 12:22:25 am »

technically the protocol allows for files up to 4gb in size.... tho i wouldnt trust herns half baked hash to verify a file of that size (guess he didnt either) ....

no real reason a clone client couldnt allow for 4gig files as the legacy client would just say 'file error' for files larger than 2gig...

hash is 128bit filesize is 32bit ... no reason the old hashing system couldnt have md5 dropped in place and 4 more bytes added to the filesize .... new patch on old client pass around the 'new' hash search whilst at the same time ignoring it so that the new clients could have their cake and eat it too...

ipv6 would need larger values as well for ips....

idea is to migrate the userbase then do improvements... granted a little late in the game but eh... more power to those who want to keep on keeping on....

(touch of irony? opennap has no filesize limit... but winmx still wont let files over 2gig over opennap so another client must be used... lets hope the clone keeps the nap side of things and fixes that 'bug' .... )

achilles · « **Reply #5 on:** July 10, 2011, 12:56:14 am »

4GB's is better than 2GB's, but still needs to be raised a bit in order to share media content of today like Bluray format. How much work would it take to go from a client based around FAT32 to NTFS?

White Stripes · « **Reply #6 on:** July 10, 2011, 01:22:15 am »

4 more bytes added to the hashing system, the library, the search....

as for the queue problem thats going to cause... well.. thats for another subject (i dont know about you but i dont want to be sitting behind someone downloading an 18 exabyte file)