Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Synapse, a full featured BitTorrent client in Rust

github.com

Post reply on HN
Print view View original

61–70 of 73 posts

Re: Show HN: Synapse, a full featured BitTorrent client in Rust

#61

Post by steveklabnik »

andromeduck wrote: post #58
Luminarys wrote: post #52

Earlier quoted context omitted.

I chose Rust because of its combination of ergonomics and low level control available. The safety came as a bonus.

Ergonomics? I love rust as much as the next guy but ergonomics was the one recurring pain point for me. So much of the language is inconsistent/incomplete and the debuggers barely work sometimes.

When was this? We've been putting a lot of work into ergonomics. We're not done yet; more stuff is coming. But depending on when you last used it, that may explain the discrepancy.

Or maybe not.

> inconsistent/incomplete

I'd be interested in hearing more about this, if you have the time. Rust is certainly incomplete, but I wonder if our perspectives line up here or not regarding how exactly it's not complete.

Re: Show HN: Synapse, a full featured BitTorrent client in Rust

#62

Post by UncleEntity »

kibwen wrote: post #20
ddevault wrote: post #15

Earlier quoted context omitted.

>a bittorrent that actually does more than download and quit always seems like something quite heavy... Don't forget to seed!

Let's brainstorm ways to solve the seeders/leechers problem via cryptocurrency: how much would it cost to encode a complete feature-length film in the bitcoin blockchain? :P

Seems like having every single full node storing multi-gigabyte files for the few who actually want them wouldn't go over too well.

Re: Show HN: Synapse, a full featured BitTorrent client in Rust

#63

Post by UncleEntity »

Sir_Cmpwn wrote: post #60
aw3c2 wrote: post #55

It would be great to have a client that works well for seeding massive amounts of torrents (100,000+) on weak hardware (like a Raspberry). The main problem seems to be memory usage. How is the memory usage of this one? It says it is light-weight. What kind of light-weight is it and are there some metrics?

Please help test it! We currently mean lightweight in terms of design, but we also want it to be lightweight in terms of performance. But we haven't had many opportunities to test it with truly huge numbers of torrents (though we have tested it on large torrents (1.5T+) with lots of files (1000+)). As far as memory usage goes, I don't think low-memory devices have been a use-case Luminarys has had in mind yet, but he…

That's a lot of memory...my little NAS has 512mb IIRC.

I run Transmission (from the Debian repo) on it and never even thought about memory usage before now, it just works. Admittedly I don't really let a bunch of torrents run at once though.

Re: Show HN: Synapse, a full featured BitTorrent client in Rust

#64

Post by ddevault »

UncleEntity wrote: post #63
Sir_Cmpwn wrote: post #60

Earlier quoted context omitted.

Please help test it! We currently mean lightweight in terms of design, but we also want it to be lightweight in terms of performance. But we haven't had many opportunities to test it with truly huge numbers of torrents (though we have tested it on large torrents (1.5T+) with lots of files (1000+)). As far as memory usage goes, I don't think low-memory devices have been a use-case Luminarys has had in mind yet, but he…

That's a lot of memory...my little NAS has 512mb IIRC. I run Transmission (from the Debian repo) on it and never even thought about memory usage before now, it just works. Admittedly I don't really let a bunch of torrents run at once though.

Yeah. I've opened a ticket to audit memory usage:

https://github.com/Luminarys/synapse/issues/80

I should note that I'm stress testing it, however, I have some particularly large torrents going.

Re: Show HN: Synapse, a full featured BitTorrent client in Rust

#65

Post by abhishekjha »

sanxiyn wrote: post #13
josteink wrote: post #11

For automation software, transmission (BitTorrent-client written in python, slow) seems to be the standard. If it could offer a transmission-compatible API-layer, I bet it would receive much more interest. Edit: apparently not written in python. My bad.

Your wish is satisfied: https://github.com/SirCmpwn/broca

What do I use it for? The README isn't very explanatory.

Re: Show HN: Synapse, a full featured BitTorrent client in Rust

#66

Post by thisacctforreal »

shadeslayer wrote: post #57
aw3c2 wrote: post #55

It would be great to have a client that works well for seeding massive amounts of torrents (100,000+) on weak hardware (like a Raspberry). The main problem seems to be memory usage. How is the memory usage of this one? It says it is light-weight. What kind of light-weight is it and are there some metrics?

Even if you solve the memory issues you will still be constrained by the NIC. Most of these SBC's run ethernet over USB, so the performance is still going to be shit.

I recently selected an ODROID-C2 for a NAS because of its dedicated Ethernet controller. Cute device. My fingers are crossed for the performance test early this week.

Re: Show HN: Synapse, a full featured BitTorrent client in Rust

#67

Post by UncleEntity »

stuaxo wrote: post #27

Interesting ! I tried integrating transmission for downloading content in a video wall app and it was a bit of a nightmare. Hopefully this will be better - please have a sane remote API. One thing that Azeurus did really well, that transmission really did not - You could can tell azeurus to re-check all the files that are there so it can find out how far it's got. In Azeurus I used this to reconstruct a large torrent…

The python API for transmission is pretty simple, I wrote a RSS feed reader that adds new torrents in something like 20 lines of code (not counting my custom rss parser module automagically generated from the schema).

Re: Show HN: Synapse, a full featured BitTorrent client in Rust

#68

Post by agumonkey »

rapfaria wrote: post #9
ronsor wrote: post #6

Earlier quoted context omitted.

http://webtorrent.io

Does it seriously download a 129MB file just by opening the page?

chunk by chunk, and it's kinda the purpose, maybe they should have a "ready ? go" button ..

Re: Show HN: Synapse, a full featured BitTorrent client in Rust

#69

Post by bitcoinmoney »

Luminarys wrote: post #52
mariuolo wrote: post #49

Earlier quoted context omitted.

Is it also to reduce security concerns?

I chose Rust because of its combination of ergonomics and low level control available. The safety came as a bonus.

What kind of rust experience do you have before embarking on this project? Also, did you do systems programming before?

Re: Show HN: Synapse, a full featured BitTorrent client in Rust

#70

Post by andromeduck »

steveklabnik wrote: post #61
andromeduck wrote: post #58

Earlier quoted context omitted.

Ergonomics? I love rust as much as the next guy but ergonomics was the one recurring pain point for me. So much of the language is inconsistent/incomplete and the debuggers barely work sometimes.

When was this? We've been putting a lot of work into ergonomics. We're not done yet; more stuff is coming. But depending on when you last used it, that may explain the discrepancy. Or maybe not. > inconsistent/incomplete I'd be interested in hearing more about this, if you have the time. Rust is certainly incomplete, but I wonder if our perspectives line up here or not regarding how exactly it's not complete.

I wrote a few hundred lines about bout a year or two ago and about 2k the last few months. It's definately gotten better and there's something in the works for most of the things I took issue with which is kind of nice but doesn't really help if you're not on nightly.

Specific pain points for me were: - the lack of traits for numeric primitives/types without pulling in the num crate - the difficulty working with floating point types - the inconsistent type annotations in fn signatures - the type annotations are a bit clunky no easy way to alias - and auto deref mechanics especially via match statement - having to fully specify a type in a match statement or use Self::Type - the use mechanism makes no sense - no optional/default arguments without macros leads to a lot of shimming/boilerplate - having to split operations because the borrow checker can't do partials or non lexical lifetimes - the clunky range syntax wich makes writing invertible/reversible functions really ugly and error prone due to lack of inclusive range and I really can't believe the committee decided to go ahead with ..= instead of ... It's really out of line compared to pretty much every other language is doing - doesn't seem like there's a good way to nicely format long lines

Overall I still really like the language but I really don't see it taking off until these issues are fixed because it makes it so hard to start up.

Post reply on HN