0 Members and 1 Guest are viewing this topic.
Hans, is there any way to modify GNUNET so that users can connect as a secondary if they don't have much bandwidth to share due to still being back in the stone age with their dial-up service? Also can C++ coders work with you on this project? I'm not a coder, but since C++ is based off C I thought maybe some parts of the client could be coded in C++. Is this possible? You already mentioned Java could be used to create a plugin for the client.
I don't understand why if you can code you haven't asked to join the secondry client work that last I looked was pretty much done on the grounds of a basic client, and they where making it pretty and stable and working on primary before the attacks started and the effort shifted to patch development. Why not pm ghostship, tell him what you can and can't do..Btw I have messed with gnu net inthe past. I found it only useful if you left the service running all the time, if you turned it off and started it again it seemed to take ages to catch up. That's ok if you have loads of bw and is happy to have something running on your pc 24/7. But I like to game, and watch YouTube and sky player and it makes that stuff laggy ( just installed again to test). And I have 12mb down and 1.5 up. This was after disabling a fair bit of stuff too. Maybe with time it stabalises,but I ain't joining no game with my ping above 100 lol
methinks the plan is to 'migrate' rather than a sudden jump so the first incarnation of the clone will be just that... a clone... later versions less so.. allowing for the phasing out of the original mx and its toys while getting a new client and new set of toys.... ....no reason the chat servers that are still maintained couldnt upgrade as well... lets just hope leeches and the queue problem go the way of the dodo as well
What "Toys" should be incorporated into a new WinMX client?Hans
The 2GB file cap definitely needs to be eliminated
I was thinking of MD5 or maybe whatever Ares uses.
To be honest the reluctance to migrate away from the current protocol is because to do so is to create an entirely new network i.e. NOT winmx!All this talk of changing how the network works, and features and encryption is pointless and actually worthless. Without a basic client that IS compatible, no further development is even worth discussing let alone figuring out the details! The priorities are:1) a new patch to protect the network from the current batch of attacks.2) a clone secondary client3) a clone primary client (2 and 3 are interchangable)4) further development of the open source client to enable all protocol packets to be validated and extra protection added5) new features - increase the 2 gb limit etcWithout the early stuff the later is redundant and a waste of resources and energy!
@hanz;the source to winmx.exe itself is unavailable.... it disappeared with frontcode... its confusing to me too as to what constitutes 'the network' .... i think ppl just dont want to give up winmx.exethe 2gig limit is a holdover from the early days of opennap (any arbitrary filesize can technically be used on the latest and last version of the opennap protocol) however the 'hash' winmx uses is fixed in length and will support an absolute max of 4gb filesize ... no more... frontcodes winmx.exe will also bug out if fed anything larger than 2gig...
a new protocol but keeping a WinMX like user interface
I would like to see updated protocols with WinMx style GUI. I would define the network as the users. It may be a new network based on protocol, but if the users migrate to the new client / network then we still have the same user base which equals the same network.
