0 Members and 1 Guest are viewing this topic.
personally i dont like the getting the file in blocks, one of winmx's greatest perks to me over torrents was the facility to see a movies beginings with VNC before gettin a huge chunk of the file first like you do with torrents, if you have ever suffered a badly named file you will understand what i mean.
The way to beat qos in my eyes is to have the handshake always a random key. this could be called from the initial handshake and on the end of thechunk being sent will be the new expected key, always changing and pretty hard to block.Ill be honest im not up on the encryption side of things but you could look to waste and such programmes for a little enlightenment.
anyway to see how much of a file someone has or is getting sirmoon?
I cant agree that most folks are concerned with IPv6 , they are like myself concerned with how we can avoid being throttled to death, so in this respect your discussion thread is very relevant Sir Moon
I have one or two workable ideas to utilise the existing networks capabilties without affecting any of the current clients and I,ll make some diagrams of the exact method required so you can look them over, although with the best will in the world it may be better off folks deciding on something completely new and have "old style compatibility mode" to ensure there is a smooth transition to any new standard, of course getting agreement on any standard will not be easy
I am a little concerned that you have not given the readers here any idea of how things work at the moment to base any ideas on, I suspect this being so you have unintentionaly limited the amount of viable new ideas and discussion partners to those already holding that knowledge, any chance of giving the folks here a brief run down on the current method and why its believed necessary to update it ?
* 64-bit file sizes - this would increase the maximum file size from the current 2 gigabytes to something like 9 petabytes
* support for out-of-order transfers (at downloader's discretion)
* support for alternate hashing algorithms (SHA, etc.; the normal MX algorithm is vulnerable to file spoofing attacks)
* support for transfers between firewalled peers (current plan is a UDP conversation initiated by both sides simultaneously)
* encrypt or at least obfuscate the conversation in a way that would make it difficult for qos-type devices to identify (currently MX file transfers aren't encrypted or obfuscated in any way, and are easily identified for throttling purposes)
* some means of negotiating such a transfer between clients using today's wpn (so not every primary has to be updated before secondary clients can begin using it)