Quote:
Originally posted by redimpact1 could you please add bittront |
BitTorrent is probably a good addition to think about
: we could still exchange torrent links/trackers in the serch results, but then BitTorrent could be used as an alternate transfer protocol.
The caveat is to define a way to regulate the traffic with other Gnutella messaging and Gnutella HTTP transfers.
Also, it's still quite difficult to unify sets of sources for the same file that would be available on Gnutella and on BitTorrent trackers.
It's true that very large files like videos are more present on BitTorrent than on Gnutella. But I fear that without some regulation, Limewire could be perceived by BitTorrent users a a leacher, and it could be banned if Limewire does not reshare all the files it has downloaded from Torrent sources. To implement BitTorrent in Limewire, would mean that LimeWire should dedicate a minimum output bandwidth for BitTorrent reshares.
But if one finds some solution to manage this share of bandwidth smartly, Gnutella would then benefit of more large files initially loaded from Torrent sources.
For now, all you can do is to install a separate BitTorrent client, running in parallel with LimeWire, and adapt their mutual settings, so that each will have its own minimum dedicated bandwidth.
This solution is workable in practive only for those users that have more than 128Kbit/s of output bandwidth (else, using both clients in parallel will make browsing and emailing a nightmare, and users will need to shutdown one of the two clients. May be this is already happening, so users have to switch from one client to the other, and this gives a negative impact on both networks, with too low connection time...)
Note: we would need a complete open-source Java implementation of BitTorrent; for now Limewire has no time to develop and support it; you should know that what makes BitTorrent so popular is in its protocol that allows swarming; but Limewire implements now secure swarming, including from firewalled sources with its very fast FW-2-FW transport protocol based on UDP (which can be even faster than TCP...)
It is not recommanded however to run two separate P2P clients in parallel on the same Internet connection, as they don't mutualize their use of the bandwidth, and it's difficult to tune them so that they can cohabit. Also, each one will consume large amount of resources on a local host (notably for their internal caches), unless you have comfortable memory, a fast swap disk, and a veryu recent OS that supports hundreds of threads efficiently, and some good knowledge of networking limits in your OS, and in your router configuration.