Hi! Author here. The name has been with us since the beginning, and the first few versions were actually quite small. Since then, features and other things have made things grow (mostly in file size). Since I'm a lone developer, the hardships of working with the Win32 API has made me base PicoTorrent on wxWidgets, which is why the file size is what it is.
I still try to keep it slim, fast and clean in overall usage :)
Sure! Two examples where the Win32 API and/or my knowledge of it falls short,
* Layout management. There's no "easy" way of managing dialog layouts (letting controls expand/shrink on resize etc).
* Custom controls (e.g a tree-list-view) are clunky to write.
I'd much rather write PicoTorrent on top of the pure Win32 APIs, which I did in the beginning. It then evolved and when I valued time against frameworks, frameworks won, and saved me time :)
You can hit me up at the email in my profile if you want to discuss further!
We wrote a layout manager and it's under 400 lines with very liberal vertical spacing. There's really not much to it - just hook the container window and reshuffle the contents in response to WM_SIZING, WM_SIZE. Handle WM_GETMINMAXINFO too if needed.
Custom controls aren't that much harder, but they do require some work indeed. TreeView and ListView are _really_ well designed in terms of customization support. The documentation is a bit heavy, granted, but once you get a gist of NMCUSTOMDRAW phases it's all pretty trivial from there.
I'm still waiting for WebTorrent to be implemented in more clients (including libtorrent, which AFAIK underlies Picotorrent). I'd love to be able to quickly deploy headless WebTorrent video seeds, especially if they were sequence-aware (sending chunks in order, possibly incl. MPEG DASH format, though that is patented somehow); and maybe commodity BitTorrent + WebTorrent CDNs could become commonplace.
I'm a huge fan of the WebTorrent protocol too, and think it has potential to completely transform the content distribution paradigm on the web.
However, the JS implementation leaves much to be desired. It's a huge resource hog compared to native libraries like libtorrent and torrents often freeze for no apparent reason on faster connections. Development seems to have also stalled quite a bit in recent times.
At this point I'd be more confident betting on something like IPFS in the long term.
I'm not too sure about the underlying technologies, but something like BitChute: https://www.bitchute.com ?
From what I understand it uses torrents to serve videos, where each viewer help seed the content for other viewers. There are limitations but it seems progress is being made.
For years I've actually been looking for a client that can handle seeding 500+ files and not just completely crap itself all the time. uTorrent seems to be a bit 'unsafe' and full of ads, deluge's web interface regularly falls over. What options are there out there right now?
I've been a happy Transmission user for a while now.
- nice variety of clients/platforms
- webui isn't completely terrible
- works well in daemon mode
- haven't encountered perf issues seeding 2k+ torrents/~5TB data
- supports modern features (DHT, PEX, magnets)
Yes, Transmission is the most stable client I've ever used (Win or Linux), but like so may others, don't run out of disk space, or you're in for a major hassle rebuilding your index.
I'm running rutorrent on a shitty shared server at its at 700 torrents right now. Its slow but its working. The JS ui is actually quite snappy but it takes a long time to get a reply from the backend so if you add a new torrent it takes about 30 seconds to show up.
It's worse than Transmission because it has no mention of any good modern-ish features such as DHT, PEX, LSD(LPD) and it lacks both Linux, OSX and BSD support. Oh and it's banned (not-whitelisted) from all the private trackers.
(Author here) I haven't listed the specific features from Rasterbar-libtorrent but I'll make sure to do that in an upcoming update, to make it clearer. It supports DHT, PeX and LSD as well as various proxies (SOCKS4, SOCKS5, HTTP).
The first few versions actually had the vanilla Rasterbar-libtorrent peer ID and user agent, and in v0.5 users could opt-in to use PicoTorrent peer ID and user agent, and a few versions after that I made that the default.
I've been in contact with as many private trackers I could find and it's an ongoing effort to discuss with them what they require for whitelisting.
It’s a basic UI on top of libtorrent. So it has those features.
It’s very simple and that makes it effective enough for me. All I’ve got is some arch iso files. A fedora and a CentOS file. It starts instantly and connects to 800 DHT nodes, as opposed to Qbittorrent 2-3 seconds and 350 nodes.
I don’t know about private trackers. I don’t have anything I want to pirate.
I don’t see cross platform as a plus for mini sized, simple graphical applications. I see it as an advanced curl.
The readme for this project specifies the user agent of the client as Picotorrent/x.y.z, which makes me think that most private trackers would block it.
I initially wrote a reply about usage pattern being different because uploading tends to be slower and requires the browser to be always on. But then there is no reason why it can't resume uploading to at least 1:1 Ratio next time it is opened.
