MonoTorrent underwent a lot of under the hood changes recently to bring things more in line with the bittorrent specs. I also finished off the implementation of the Fast Peers Extensions, so downloads with monotorrent should be faster when used in swarms that have other clients supporting the Fast Peers Extensions.
A majorly important fix went in today which prevents incoming connections which have just been created from being closed. This should improve things substantially and hopefully remove a long running bug of invalid AsyncRequests being passed into EndXXX methods.
Also, after talking with Ty Norton (http://blog.aproductofsociety.org/) who is hosting www.monotorrent.com, he told me that there have been 211.37 megabytes of downloads of monotorrent so far this month. Considering the zip file is a mere 154kB in size, that's over 1300 downloads! Not too bad. Now, if only i got bug reports from one tenth of those people, i'd be happy.
Or maybe MonoTorrent is so good it doesn't throw any exceptions... who knows ;)
8 comments:
Anyway I have to give you congratulations! Because when running the monotorrent does not show any gtk errors like others applications... :P
Like a user I only want to ask one thing. The option to save each torrent (task) into a selected (by user) folder.
Go on man!!! The app is very good! :P
I would like to know if your client is able to work without the GUI (as a daemon or a service using mono-service).
BTW, I have a suggestion of a feature (if it's not implemented yet) to add to the TODO list: does monotorrent support the priorizing of downloads that are being exchanged by members in the same LAN?
Thanks in advance.
@Daniel: I agree with that feature. That is currently being worked on as part of a newer nicer gui with more features. That won't be ready for release for another 3-5 weeks at the minimum.
@knocte: It is indeed. Take a look at the code for the TestClient (ok, it is a bit messy, it's my debugging client), but it does contain everything you need to run the client as a service or daemon.
If you want to prioritize individual connections that are on the same LAN as you, i'm not sure how easy that would be. I know azureus has something like that, but to be perfectly honest, i don't think it's useful.
If you are on a LAN and you do connect to another person on the LAN with monotorrent, you will download extremely fast off them (unless you apply a download speed limit to the torrent). Ok?
Thanks for your answer Alan.
The reason I am asking for the LAN thing is that I plan to make a software distribution system where you can tell many machines inside a LAN to install the same software (via YAST for example) but I don't want them to download individually, so the ideal would be to have a master server that downloads the packets and then shares them via monotorrent with the other machines which are not allowed to access WAN.
How could I prevent monotorrent to download from WAN sources?
@knocte:
1) Download the files on your server and create new .torrent files for them (you can use the TorrentCreator in MonoTorrent.Client).
2) Host tracker on your server (there's a tracker available in SVN called MonoTorrent.Tracker). You should also run an instance of the Client on your server to act as a seed.
3) Send each client in your WAN the torrent being hosted by your tracker (YAST might be able to do this for you).
4) Download using MonoTorrent. Only other peers connected to your server will be contacted, meaning only LAN peers will be contacted.
You asked for bug reports, well I've got them including unhandled exceptions! But I don't see an email address anywhere on your blog or the monotorrent homepage.
Contact info added to blog and will be added to monotorrent.com soon. I'd love the stack traces alright along with anything else you remember.
Oh my god, there is really much worthwhile data in this post!
Post a Comment