Hi :)

An example case:
You wish to resume a download, but your client has no knowledge of peers who share it. Your client will issue a broadcast request for users who share that specific file, by Hash. Caring, sharing peers will respond with their piecemaps. Your client now has sufficient data to begin making requests to specific peers for specific pieces. Let's suppose your client makes one or more such requests, and one of the requests times out.
The peer has actively refused your request for a piece of a file you know they have. The client is not adhering to the protocol !! We will dump them from our own list of peers, and disregard all requests from Them to Us, for the remainder of the session or until a second timeout is reached.

By not sharing, they are only hurting their own transfer rates, because we are potentially routing traffic to them, and we've banned them.
This mechanism encourages filesharing, which is what a filesharing network is all about, right?


If I understood things correctly, just sharing an empty folder defeats this scheme. The peers will never respond to the first request in the first place, so they don't share any files but still never get banned... what's worse, a false positive (peer is compliant, but the response gets lost) may get sharing users banned at random times. :(
Posted on 2005-01-05 18:31:50 by QvasiModo
just a small word about the md5 hash.
isn't it found a collision in md5 by now?
i guess, mabye changing to a new hash will be better.
you don't want to download diff files with same hash eh?
theoreticlly it can happen, practicle i guess not .
just a though.
Posted on 2005-01-06 01:51:52 by wizzra
Maybe sha-1 is a better algorthm?
I supose with any algorthm you can get a collision but what is the chance that the collision would be with another file? I think it's not very high.
Posted on 2005-01-06 03:11:11 by QuantumMatrix1024
Probably better to go with a SHA variant, or perhaps the Tiger hash, even if you think that MD5 collisions are "theoretical"... sounds like an interesting project anyway, I've been lurking :)
Posted on 2005-01-06 04:00:50 by f0dder
I'll switch to a more secure hash later - for the moment md5 is fine by me.
As for the issue of not sharing files, the protocol does not handle this, the client does though - it won't permit you to join the network with no shares.
If you remove all your shares while it is running is another story, thanks for waking me up on that one.
Posted on 2005-01-06 04:46:36 by Homer
Basically, not sharing files isn't possible... even if you start the client with no shares, as soon as you start a download, that download is shared as soon as you have just one piece of it.

If your client is "modified" to not share FilesBeingDownloaded, your transfer rate will very quickly become zero - every time you deny a peer request for a piece of file, the immediate peer who relayed it to you will ignore you - you will no longer receive ANY traffic from them.

Leeching is possible as you can see, but painfully slow.
I don't think leechers would have much fun on this network.

The machines which provide the initial SeedList of potential peers are not breaking any laws, unlike the webservers which provide the "torrent" files used by BitTorrent... there is no legal argument for the removal of my Seeders.
Posted on 2005-01-09 08:52:39 by Homer
Basically, not sharing files isn't possible... even if you start the client with no shares, as soon as you start a download, that download is shared as soon as you have just one piece of it.

Good point. However full downloads can be moved out from the download folder (I recall a small utility for KaZaA Lite that did the same). But that's probably unavoidable.
If your client is "modified" to not share FilesBeingDownloaded, your transfer rate will very quickly become zero - every time you deny a peer request for a piece of file, the immediate peer who relayed it to you will ignore you - you will no longer receive ANY traffic from them.

Maybe you could modify a client to report no files are being downloaded? Still reversing is far beyond what I was suggesting! If someone cares enough to do thatmuch work, he deserves to leech! :-D
Leeching is possible as you can see, but painfully slow.
I don't think leechers would have much fun on this network.

Definitely not! :wink:
Posted on 2005-01-10 16:39:31 by QvasiModo
Maybe you could modify a client to report no files are being downloaded?


The one who you are downloading from wouldn't beleive your client :)

Legal issues

I wonder about the leagal issues of a network like this. Supose a file is shared without the copyright holders permision and you wish to download it :). The peer you receive a file peice from may not be the one who is sharing/downloading the file but he still forewarded it. Is that still classed as distributing copyrighted material? I think this is a legal grey area. Could somone be sued for being a peer in a network like thiis?
Posted on 2005-01-10 17:28:08 by QuantumMatrix1024
Shouldn't transfers be direct, after searching has been done? Otherwise there will be a LOT of bottlenecks in this network...
Posted on 2005-01-10 19:38:26 by f0dder
Direct file transfers are avoided...there's a very obvious reason for this.
The RIAA and similar bodies are sharing on networks like Gnutella (and clones), Kazaa, EDonkey, BitTorrent (Believe me on this, I'm speaking from experience) ... they sit back and wait for you to direct-connect to THEM, then bust you for downloading copyrighted material.
In the past, the solution has been to compile "blacklists" of ip addresses to be avoided, and this mechanism has been more effective being abused to DoS peers than it has to shield users from the Bastards That Be.
They are using those kinds of filesharing networks to associate particular files with specific ip addresses.
The MUTE network on which this protocol is partially based does not suffer very greatly from bottlenecks due to the ant routing mechanism, however it performs badly in terms of transfer rates due to the fact that a LOT of data is cached for each "door"... preventing most users from being able to have very many "doors" open at once.

Yes, direct transfers are cleaner and faster, always will be, but insecure and downright dangerous depending on exactly what type of content you are looking for...
Posted on 2005-01-10 22:08:28 by Homer
I see... good point. Sounds like it's going to be very very slow transfer rates on that network :/
Posted on 2005-01-10 22:18:44 by f0dder
Should the owner of a socksv4 proxy server be held accountable for the traffic routed through it? It's the same argument.
What exactly is the legal aspect? I'm not sure - I'm not a lawyer.
My understanding however is that in order to be charged with aiding and abetting a criminal act that you must be conscious of said act.
It's a matter for the prosecution to prove that you are AWARE that you are aiding in nefarious activities... and at least in my own country, you are innocent until PROVEN guilty.

Since HP2P has much less overhead per "door" than MUTE, I expect that most users will run far more than the four "doors" MUTE runs by default.
Each "door" can be considered a potential source of filepieces, and therefore, your transfer rate is directly proportional to the number of "doors".. I've also noted elsewhere that more doors=more speed=more security in terms of being more difficult to "corral" you (the only way to associate your ip with your traffic)
Posted on 2005-01-10 22:55:33 by Homer
I'm not sure of the legal aspect either but we can be sure that if there is a possibility that the RIAA can shutdown a file sharing network they'll try.
Posted on 2005-01-11 03:58:33 by QuantumMatrix1024
We're ready to begin round two BetaTesting :)

If you wish to join our OpenSlather Beta Team, please sign up at http://homer.ultrano.com
Posted on 2005-01-12 00:52:26 by Homer
Done :)
Which is the newest file to get OpenSlather.exe, OpenSlather_Beta_000.exe or OpenSlather_New.zip?
Posted on 2005-01-12 13:00:27 by QuantumMatrix1024
The most recent file on the server is not listed.
In fact, all the listed versions are old.

The most recent exe is http://homer.ultrano.com/OpenSlather100.exe
It will generate "MCI errors" unless you ALSO fetch the "SoundFilez.rar" and extract its contents into a folder called Sound which resides in the same folder as the exe...

On the first run, the exe will make sure its name is correct (part of its autoupdate logic) and check that certain folders exist, creating them if necessary.
Please shove a couple of large files into the Shares folder and then restart the application to test the new Hashing code...
This will generate some binary data files in the HashFiles folder, which should be a once-off event as next time you restart the exe it will load data from those instead of regenerating hashes..You should be able to see the Shares on the exe's Shares tab..

Assuming all this is working ok, feel free to test filetransfers with a friend or two, I'm attempting to organize a group test but it's like trying to organize a colony of insects :)

I should have a "proper" install pack ready later today or early tomorrow, my time just became shorter as I've managed to destroy two cars within a week and since I'm a poor man I have to repair them myself (blew up the clutch in one, dropped a con rod in the other)..

We'll get there eventually...it's early days :)
Posted on 2005-01-12 21:59:24 by Homer
OK. I'm now downloading the beta and try to test it extensively today.



/siddhartha
Posted on 2005-01-13 03:51:20 by siddhartha
Shout for me if you need help, Homer. :-D
Posted on 2005-01-13 05:59:56 by roticv
Currently the most recent update is available on my dumpsite http://homer.ultrano.com as OpenSlather.exe

I've recently made a bunch of bugfixes, added some graphic stuff like progress splashscreens, reworked the HashFile format, and importantly, the application can now detect missing files, download the relevant archive for you and then extract the files, all automatic... easy :)

Lots of work was also done in the baseclasses such as FStream (file io) and CDoor (abstracted tcpsession object).

Looking for some feedback :)
Posted on 2005-01-20 08:35:27 by Homer
I've been making daily updates for the past couple of weeks.
My apologies to those of you who signed up for betatesting, nobody recieved mail yet. Don't be concerned, your address is confidential.
We had some problems to resolve in the codebase before we were willing to fire up the massmailer script. No point getting feedback on known issues, it would only give some individuals a bad impression of the application which would prove detrimental to the network in the long run.
Alienating the top users was never on the agenda.
Posted on 2005-01-31 07:57:27 by Homer