Now, if I have my 3 rom files above, and someone else has game.zip with: You get the file, do a CRC and see that your's is 1234569, and we see that the CRCs are different, we know that either the file corrupted in transit (bad link), or someone's been naughty and tried to hack it midstream (maybe add a trojan or virus).
I send you a file, and it has a CRC of 12345678. Why do this? Well, it's a good way to check that data isn't corrupt. Now that file will have a unique CRC (Cyclic Redundancy Check - a mathematical "hash" computed by running an algorithm over the data and coming up with a unique number).
MAME 0.174 ROMS TORRENT ZIP FILE
So say the zip file called "game.zip" contains (in order): Stuff gets added to that zip file in order. I answered you in VBPager, but I'll post here again for the benefit of everyone else: Once I run this ZipTorrent program, what next? Just point my torrent program to my roms folder and away I go or? I honestly can't see what this thing does and/or how it associates with your roms and your torrent program. Particularly considering the whole system from P2P software to torrentzip is all free of cost. Some common-sense preparation work by the end user in the form of torrentzip is more than reasonable, if you ask me. Again, I think that's far from "braindead". If that stream of bytes are in two different orders, then they are deemed different. Whether you have 10x 1MB files or 1x 10MB files, it's all the same. Additionally, P2P systems like torrent don't care about things like "files". I think the scope you're proposing there is a bit much (not to mention the resource requirements it would add to the peers). "Braindead"? A bit harsh, don't you think? Are you suggesting it is the job of P2P systems to peek inside each and every binary file and try to decode the contents, matching the unziped CRC/SHA with that of the other end's, in realtime? It sees a zip file with FileA and FileB as being different to a zip file with FileB and FileA.
0 kommentar(er)
