New Client Bugs

[Plum]

i would hope that the new client eventually drop everything broken about the old client rather than try to remain compatible... once the switchover to the new client is complete there is no reason to keep backwards compatibility....

i also hope no 'trade-only' type stuff makes it into the new client... leech i get but no 'trade'...

I can see either argument, either in including 2 protocols and the ability to disable the old one, or just doing a full port. Maybe keep OpenNap mostly like it is or harden it in either case.

Yes, I can see adding anti-leech stuff, so long as it is off by default. Like you, I don't agree with the forced-trading stuff. Keeping off non-contributors is one thing and can help the network, and also increase the incentive of being vigilant by distributing the risk. But the force-trading seems more harmful. If you want to do that, why not just transfer through OpenNap or some closed channel way, like PM emails for sharing? Or write a client just for them, possibly reusing code from an existing project.

Anyway, I think a leech option should be added, in part to enhance security. Think about it, what if add-ons compromise the network in some way? So there is incentive to add some of the most popular features from add-ons since they would be tested and designed into the project and thus not some shoddy 3rd party addon that does more harm for everyone than good.

I can understand why the protocols would need to be updated, and understand that hardening is only a part of it. With G2, I was around a forum where the young guy who proposed it unveiled it. He made it extensible and packet-oriented, so it had backwards and forwards compatibility built into it. The older clients could safely ignore parts of the payload they could not understand, and newer clients could add client-specific features and coexist with other, slightly different clients on the same network. G1 was unable to do that, and if reverse compatibility between subversions was a goal, it would have to be specifically programmed (otherwise, "snubbing" would result). I am curious what other features a MX protocol update would provide besides security.

[RebelMX]

Hopefully re-implement the regionalisation across the network which is not currently managed (in part due to the caches but also down to the patch as well, with the new client handling the region markers correctly this should change).

Perhaps add extra new packets to support ipv6?  Won't be able to use the current packets as the IP field is a 4 byte field which will need increasing in every packet.  Therefore as well as forward and backward compatibility it will need to be ipv4 and ipv6 compatible.

[Plum]

Hopefully re-implement the regionalisation across the network which is not currently managed (in part due to the caches but also down to the patch as well, with the new client handling the region markers correctly this should change).

Perhaps add extra new packets to support ipv6?  Won't be able to use the current packets as the IP field is a 4 byte field which will need increasing in every packet.  Therefore as well as forward and backward compatibility it will need to be ipv4 and ipv6 compatible.

I see. Yes, the regional thing was temporarily discarded trying to get WinMX to working. Before, it had hard-coded IP addresses to servers in different places. It was much easier to replace some of the addresses rather than all, or to reassign most to the same place. It worked, but no longer had preference to shorter distances. Now, the goal is just to get it to working. The primary side needs more work.

[RebelMX]

Theres no need to hard code ip addresses using them, but maybe prioritise connecting to primary nodes that are in the same region before seeking those outside.

Primary isn't too bad tbh.  So long as there are some type of check placed on the packet contents and dropping primary connections that are sending dodgy packets, then in theory the spammers would be dropped off the net and wouldn't be able to use the network against itself to pass on their packets.  With a new client, adding additional 2 tier packets/types should be easy enough and also would be a perfect time to implement ipv6 imho, then run the client with both sets of packet handling so it can run on the old and "new" network.  The file transfer and sharing doesn't really need touching since its direct between one person and another so theres technically no need to fully split the network.

[White Stripes]

The file transfer and sharing doesn't really need touching....

<sarcasm> yes, because leaving 'get winmx' wont confuse those DPI programs at all </sarcasm>

[GhostShip]

I think we looked at leaving things as they where in the transfers dept and made the decision to upgrade that area due to the reasons alluded to in Stripes post above, the GET string is one of the most giveaway clues to the throttling equipment vendors and its the duty of all p2p developers to work on ways to counteract such an own goal, we do after all pay for the bandwidth we use.