Hi,,

I see similar questions might be asked often, but since there's predominantly one P2P method (BitTorrent) that seems to have comprehensive and updated links, maybe the question needs to be repeated as it's not being heard?

Many of the more intelligent P2P clients allow for some sort of plugin architecture to allow for downloading from multiple protocols besides their native protocol, and furthermore to synchronize or integrate all the bits of files into one download file. However, nobody can get to these files unless the verified meta data is known, be it hash, hash and file size, filename, and so on. Some protocols capture this data in a simple link (ed2k) and others in a small file (torrent).

Right now, my primary P2P client is capable of talking to ed2k, overnet, BitTorrent, HTTP, FTP, FastTrak, and Gnutella. HTTP and FTP may or may not lend themselves to stop and resume functions, that depends on the server and the client. For example it is fairly common for FTP to handle a resume function, so a client could simply kill the connection to stop, and send another request with a different offset for resume.

In any case, all I need from OOo is the verified meta data posted on the site and up to date. So far the BitTorrent page seems to be an excellent example. Now let's have all the other protocols follow suit.

This process should arguably be automated or a configurable build option, to generate the meta data after a build, similar to multi-format documentation generated from a common source. Once the files can be queued from any network, then I can both send and receive pieces of the file to and from anyone else downloading that file on any other network. But I personally can't kick off that process until I get the file in the first place and generate the meta data within the client(s). Then others may not trust my source because they do not know me, and have no idea if I have tampered with the file. You often don't want to trust unverified metadata, especially for popular programs which become prime targets.

Leif



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to