Re: [discuss] Bittorrent

The only technical challenge between integrating the client code from azureus is that it uses nio, which is java 1.4 feature.  However, there are some very serious "political" decisions regarding how much uplink to reserve for torrents and how long to leave torrents running after they are done.  Basically we can't rely on the end-user to decide these things for himself because that can potentially ruin the torrent community.

Regarding the UPnP support, just today I extracted the UPnP plugin from azureus into a standalone program (under the close guidance of Parg - its author, to whom I thank very much).  It comes to a nice 61kb jar _including_ the source ;-)

Regarding UDP pushes - those do not give us the freedom to include firewalled hosts in the download mesh directly, at least not in its current state.  There have been some preliminary ideas about "live" meshes, but those are in early theoretical stage.  The benefit from UDP pushes as of now are only the much faster connection times and the reduced bandwidth usage.

Zlatin

---------- Original Message ----------------------------------
From: "Sam Berlin" <[email protected]>
Reply-To: <[email protected]>
Date: Fri,  2 Jul 2004 19:52:25 -0400

>There's no need to be compatable with Java 1.1.8 anymore.
>
>Thanks,
> Sam
>
>---------- Original Message ----------------------------------
>From: [email protected] (Gregorio Roper)
>Date: Fri, 02 Jul 2004 23:12:39 +0200
>
>>Bittorrent's tit-for-tat idea is a neat idea for large, popular files but I don't see how
>>you could realize something like that using HTTP without breaking the protocol. In
>>addition it does not really solve any problems. If a client basically wants to leech from
>>a network, there are a plenty of ways to do so despite tit-for-tat.
>>
>>I don't think there is such a large part of the Azureus that can/needs to be merged with
>>LimeWire. The actual downloader/uploader is certainly interesting but it needs to be
>>compatible with LimeWire's bandwidth throttling, the file verifying, Java 1.1.8 etc, so it
>>looks very much like you would have to rewrite large parts of it.
>>The code parsing the torrents and communicating with trackers might be very helpful but in
>>general I'm not so fond of the Azureus code.
>>
>>mfg
>>gregorio
>>
>>Gordon Mohr (@ Bitzi) wrote:
>>> Azureus is a really nice program, and GPL, so (after considering due
>>> politeness
>>> to its author(s) and community perceptions), it seems that large
>>> portions could
>>> be merged with LimeWire (or vice versa).
>>>
>>> I still think content-distribution nirvana will occur when there's a global
>>> DHT backed by HTTP sources and URN naming, but clearly that future still
>>> has
>>> some simmering to arrive, and needs some novel throttling/feedback
>>> mechanisms
>>> which can match the tracker/tit-for-tatness of BT.
>>>
>>> Perhaps an official magnet attribute for pointing to a .torrent URI (or
>>> more generally, 'alternate location location' signifying the extra
>>> indirection)
>>> is a good idea...?
>>>
>>> - Gordon
>>>
>>> Susheel M. Daswani wrote:
>>>
>>>> Hi Gregorio,
>>>> Nothing is final yet but there is a good chance we'll be adding
>>>> torrent file support to LimeWire in the near future.  We've been
>>>> discussing/investigating the possiblity for a while now.  As much as
>>>> we'd like to see magnets take off, torrents are the clear winner now
>>>> and probably in the future.
>>>>
>>>> Thanks!
>>>> Susheel
>>>>
>>>> Gregorio Roper wrote:
>>>>
>>>>> I just come back from trying Bittorrent (namely Azureus) and I must
>>>>> say I'm a little impressed. I wouldn't go as far as suggesting a
>>>>> Bittorrent plugin for LimeWire but some of  the Azureus/Bittorrent
>>>>> features would certainly be nice to have.
>>>>>
>>>>> Azureus has the ability to share and download collecions of files or
>>>>> complete folders. It also has UPnP support (completely in java).
>>>>> Especially the ability of firewalled hosts to share partial files is
>>>>> really neat, - since LimeWire is going to use UDP pushes anyway, what
>>>>> would speak against adding push-proxy-alt-locs for firewalled hosts
>>>>> to the download mesh?
>>>>>
>>>>> mfg
>>>>> gregorio
>>
>>
>>_______________________________________________
>>discuss mailing list
>>[email protected]
>>http://www.limewire.org/mailman/listinfo/discuss
>>
>
_______________________________________________
discuss mailing list
[email protected]
http://www.limewire.org/mailman/listinfo/discuss