the forums at degreez.net

It is currently Fri Jun 22, 2018 9:15 am

All times are UTC - 7 hours [ DST ]




Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 5 posts ] 
Author Message
PostPosted: Mon Dec 04, 2006 9:04 am 
Offline

Joined: Thu Apr 08, 2004 4:04 am
Posts: 7
Location: Givatayim, Israel
NAT port mapping
NAT traversal
DHT
Peer exchange
Encryption
Multi-Torrent GUI
Broadcatching (RSS)
SOCKS support for outgoing connections
Web Remote Control
Torrent Search Engine
Automatic Client Updates

Why not implement these? (note the bold ones)
Also, why not use updates from the original BitTorrent source code and implement them in BitTornado, like you used to?

Source: http://en.wikipedia.org/wiki/Comparison ... t_software


Last edited by DDRRE on Mon Dec 04, 2006 2:41 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Mon Dec 04, 2006 11:13 am 
Offline

Joined: Sun Mar 07, 2004 10:05 am
Posts: 1212
One big problem with my adding new features is that I've been rather busy IRL until recently. That's been cutting down on my coding time.

Another problem, to answer your last question, is that mainline BitTorrent has switched licenses to one based on the Jabber OSL. I want to keep my current MIT/X11 licensing, which means I can't adopt code from their codebase or even look at it, for fear of license contamination. I think it's more important to push the protocol than to try and make money off my codebase. More on that later...

NAT port mapping and NAT traversal: This is problematic with Python, and prior attempts to implement it resulted in problems. For proper NAT traversal the tracker needs to be involved, and I don't have any information on how or whether this has been implemented. Given that information I might be willing to try again.

DHT: Neither mainline BitTorrent nor AFAIK Azureus has published their DHT protocol specifications. Mainline's is based on a MIT/X11-licensed product called Kademlia, but they've made custom modifications to it, and I have no information on those modifications. Azureus' DHT version is disliked by some torrent publishers, since it allows torrents to continue running after they've been withdrawn, and a few have banned clients that implement it.

Peer exchange: This isn't part of the official specification, and is also not implemented in a way mainline recognizes. Future changes to mainline may break it. Given DHT it's also really not necessary.

Encryption: This is scheduled to be incorporated Real Soon Now.

Multi-Torrent GUI: I've been planning this for a while. It's a big job, and has been complicated by other problems. I've been considering moving away from wxPython which has caused problems in the past, but I find the alternative, PyGTK, annoying. The latest version of wxPython has improved though, even if it isn't very RAM-conservative. Consider this to be still in progress.

Broadcatching: Not really usable without the multi-torrent GUI, above.

SOCKS: Very few people have a legitimate purpose for using this, and I'd rather not place a heavy load on some unfortunates trying to run a SOCKS server. I'll consider it though.

Web Remote Control: Also not very useful w/o the multi-torrent GUI.

Torrent Search Engine: I don't think I'll ever incorporate anything like this into my client. Web-based engines are simply more flexible.

Automatic Client Updates: Periodically pinging my server not only potentially overloads my server, but many people will be concerned about maintaining their privacy. I may implement something like this in the future, but don't expect it to be enabled by default. :-)

----

It became clear to me some time ago that a client coded in Python has limited use in being incorporated into other projects, so continuing this codebase under an MIT/X11 license may not be useful. I have two alternatives I can pursue:

(1) Give up MIT/X11 and adopt the BTOSL from mainline BitTorrent. This would allow me to utilize their code, giving me a jump on implementing new features and increasing performance.

(2) Switch codebases to C/C++. This would be a lot of work. I'm actually willing to pay for someone with a decent codebase to release it under MIT/X11, so I can adopt it and make a new version of BitTornado. As above, it would also let me look at the mainline BitTorrent codebase, since I'd need to re-implement any techniques they use and this would isolate me from license contamination.

I'd appreciate feedback on the above two alternatives.


Top
 Profile  
 
PostPosted: Mon Dec 04, 2006 11:39 am 
Offline

Joined: Sat Mar 13, 2004 11:16 am
Posts: 60
Here's my opinion, from a user with an interest in the development of Bittornado.

NAT port mapping: If you mean uPnP, it's already in there.

NAT traversal: Impossible with TCP, except via 3rd party proxying, and that's piss slow. Plus you need a third party proxy.

DHT: Already mentioned as being "difficult". Also, DHT fallback breaks the bittorrent spec and should not be allowed. If added, it would be for trackerless torrents only.

Peer exchange: Same class as DHT, plus I refuse to believe that peer exchange can be implemented very well. I imagine it creating "clumps" of clients who are near each other and support peer exchange, which is bad for health. You want random swarms.

Encryption: As I understand it, this is the next priority

Multi-Torrent GUI: A GUI overhaul has been desired for a while now. It's just a huge project to do.

Broadcatching (RSS): I'm not sure I like the idea of my torrent client downloading things without my knowledge.

SOCKS support for outgoing connections: hmm... maybe. But on that note, there are libraries which will wrap an entire application with SOCKS support. If you're that stuck, you might want to investigate such a library. It would work on almost any application.

Web Remote Control: Again, a very difficult task, but I would be interested in this myself.

Torrent Search Engine: HA!

Automatic Client Updates: Depending on the operationg system, this might be impossible. Unix systems which have properly installed bittornado don't have permission to upgrade it. Any attempt to upgrade bittornado would result in a Permission Denied error. So I'd just rip this out anyways.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Dec 04, 2006 2:38 pm 
Offline

Joined: Thu Apr 08, 2004 4:04 am
Posts: 7
Location: Givatayim, Israel
Thanks for replying.
Nice to know BitTornado is still alive.

Quote:
It became clear to me some time ago that a client coded in Python has limited use in being incorporated into other projects, so continuing this codebase under an MIT/X11 license may not be useful. I have two alternatives I can pursue:

(1) Give up MIT/X11 and adopt the BTOSL from mainline BitTorrent. This would allow me to utilize their code, giving me a jump on implementing new features and increasing performance.

(2) Switch codebases to C/C++. This would be a lot of work. I'm actually willing to pay for someone with a decent codebase to release it under MIT/X11, so I can adopt it and make a new version of BitTornado. As above, it would also let me look at the mainline BitTorrent codebase, since I'd need to re-implement any techniques they use and this would isolate me from license contamination.

I'd appreciate feedback on the above two alternatives.


Obviously, switching codebases to C/C++ is the best alternative; easier to implement your ideas in other clients, easier to implement others' ideas in your client.

Huge thanks for your reply,
DDRRE

P.S. Keep up the good work! when someone asks me about a BitTorrent client - I immediately tell him to use BitTornado. The next day he praises me and this client.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Feb 03, 2007 1:17 pm 
Offline

Joined: Mon Aug 02, 2004 4:27 pm
Posts: 8
Kind of waking up the dead here, But I'll state my thoughts on the subject, as a former user of BitTornado and someone who appreciates it's author's dedication for the protocol.

I do not currently use it for the lack of certain features listed here, mainly the GUI. A single port driven UI would be nice, too.

--

NAT port mapping and traversal: As said, It's probably not the most important feature, But it might be worth a shot for some users as a lower priority later on.

DHT: I find the cases where this is really needed to be far and in between, So I'd say this isn't a high priority either. Implementing it is always a PITA for the lack of specs (BitTorrent's site does have this spec but its a draft at best, i guess).

PEX: I agree with Both opinions (TheShadow, DeHackEd) about it - It's really not worth the hassle from what I've seen in other clients.

Encryption: Already implemented, as far as i know? It's a good feature to have.

Multi-Torrent GUI: I really do think it's a priority for people who use BitTorrent heavily. I don't consider myself one and even i have at least 5 torrents 'listed' usually, The mass of windows isn't really helping. As a developer myself I'm aware that it is lots of work to implement, Assuming you're basically rearchitecting the logic behind as well.
As a side note, I have to say most cross-platform GUI Kits I've seen are terrible (XUL, GTK).

Broadcatching, Remote Control: Aren't useful without the GUI as noted. RSS isn't widely used outside certain communities, But it does help some users who relay solely on it as their whole BitTorrent experience, simply because it makes their life easier. If it's not too much work, It is a more useful feature than most.
As for remote controlling, It's pretty useful, But not really a higher priority, and might take some time to implement.

Search: I agree that there is no need for built in searching capabilities, for the reason mentioned as well as the problem of which sites or engines to use - i.e. uTorrent's listing of warez sites, Redirected searches and the like.

Automatic client updates: those are really a plus - Most people wont notice an update until something is not working for them - In which said time they will visit the site anyway.

--

As for switching codebases, That all depends. Switching to C/C++ would be a whole lot of work, And would mean re-inventing the wheel for every feature BitTornado would want to adopt for the mainline or any other clients (as most are written in other languages). There's also cross-platforming to think about - Unless the only GUI version of BitTornado is the Windows one - in which case I'd think about taking a look at MonoTorrent as a codebase to built on - Works with MS' Framework as well as Mono.

Hope this helps even a little bit, I'm looking forward to see BitTornado advance :)


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 5 posts ] 

All times are UTC - 7 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 0 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group