viktorelofsson

Yes, that's a good suggestion. The readme is due for a rewrite so I'll make sure to mention that somewhere up top!

EDIT: the parent post was edited, and this comment was written for the original post.

It should be correct - or at least, it works for what I use it for :)

What is odd about it?

It's been a few releases in the last 168 days when I announced PicoTorrent on HN and I'd like to get some input on both the progress as well as the new WebSocket API.

You can find the relevant API documentation at

- http://docs.picotorrent.org/en/latest/websocket-api/index.ht...

Hi, the reason PicoTorrent is 20MB installed is that we ship the PDB file in the installer. In the future, the PDB file will be optional. The actual executable is around 5,5MB. We ship the PDB file with the installer to help with issues now in the beginning - to print stack traces (with symbol names) if it crashes, etc.

The installer will receive a nice update with a user interface in the next version.

Thanks for the input! :)

Ninja Edit: I'll take a look at fixing whatever is making PicoTorrent not work in Sandboxie.

The PicoTorrent executable is somewhere around 5-6MB. RAM and CPU usage should be low to tiny if I haven't made a mistake and leak memory all over the place :) The reason our executable is so much bigger is that we have a few indirect dependencies on Boost and OpenSSL (via libtorrent).

I'm open for suggestions on how to reduce size.

Interesting! I did not know this. If their tweaks work, I guess Deluge may have a performance advantage.

We follow the latest vanilla libtorrent sources (not bound by releases), and try to keep our C++ as close to the Windows API as possible. The only dependency we have is libtorrent (plus Boost and OpenSSL since libtorrent depends on those).

Great suggestions! Actually, one of the inspirations for PicoTorrent came from this blog entry, http://blog.libtorrent.org/2012/01/seeding-a-million-torrent....

I haven't had a chance to test it with a million torrents yet, but my development environment has a few thousand at least, so easy bulk operations are a requirement :)

This is true, however we still run PicoTorrent under the default libtorrent peer ID which is whitelisted on a few private trackers as well.

Both are built on Rasterbar-libtorrent and should provide equal performance if configured the same, which I would definitely see as a goal.

Feature wise, PicoTorrent is lacking. Most popular features will be implemented, along with a plugin API. Right now, nothing more than the basics is implemented.

I'll try to put this, along with other information, in a FAQ asap.

Done and done!

https://github.com/hadouken/hadouken/wiki/Getting-started-on...

In what regard? I only have numbers for Windows, and mostly memory-based numbers which will vary depending on load. Here's some recent numbers I pulled,

- It idles at ~1.5-1.8MB with no torrents.

- With 10 seeding torrents, it runs at ~3.8-4MB memory usage.

However, these numbers may or may not run true depending on usage and workload.

I'm gonna try to address everything at once here :)

(Private) trackers are very picky about what clients they allow. This leaves me with few alternatives when it comes to BitTorrent libraries, Rasterbar-libtorrent being one of them. Rasterbar-libtorrent is awesome, and written in C++.

I wrote a C++/CLI wrapper for libtorrent to bridge the native/managed gap and did the rest of the work in pure C#. Awesome, except C++/CLI is not cross-platform and will not be made cross-platform in the MS CoreCLR releases. So to become cross-platform, I either have to rewrite everything in C++, or use P/Invoke. I never got the P/Invoke stuff to work well with the C++ nature of libtorrent, which left me with a C++ rewrite of Hadouken.

As it turns out, C++11 is quite pleasant to work with, and with the Poco framework I actually made some real progress quite fast. I also ran a Ubuntu VM on my Windows dev-machine to make sure everything worked smoothly as I went along.

Performance may have been the wrong word, maybe I should've used memory usage, but I'm currently in the finishing stages of having it running on the older R-Pi boards, so even though 90% of the users will run it on some sort of desktop/server machine, some will run it on the R-Pi where memory is limited.

Author here, some background information.

I'm a C# developer by trade and currently in the end-phase of a total rewrite from C# to C++ for this project in order to get it running cross-platform as well as increase performance.

This is my first C++ project and any feedback is welcome!