Webtorrent: Limit download/upload speeds (throttling)

[green13]

It would be cool to be able to limit download/upload speeds.

[ghost]

+1

[Octexor]

+1 ;)

[feross]

Agreed – this feature is useful to limit bandwidth consumption so other apps (like web browsers) can continue to function. (Btw, it doesn't make much sense for the browser version of webtorrent).

Though it sounds simple, it's definitely non-trivial to implement. Limiting the speed of a single node.js stream is easy, but making it work across the whole client will take a bit of thinking...

[feross]

Wow, nice! stream-throttle looks perfect, at least for TCP streams. Making this work with other transports (like uTP and WebRTC) will require additional work. But uTP isn't supported yet, and WebRTC throttling can wait. Looking forward to the PR!

How about naming it --download-limit and --upload-limit?

[feross]

Btw, in the picture you posted, the aggregate bandwidth was 410 KB/s. We
need to limit across connections.

On Mon Nov 03 2014 at 11:09:51 PM opfl [email protected] wrote:

Whoops, I had accidentally deleted the post. OK, sounds good.

—
Reply to this email directly or view it on GitHub
https://github.com/feross/webtorrent/issues/163#issuecomment-61601514.

[espoal]

As a noobish system administrator it feels a bit strange to me to use Javascript to limit bandwidth. Maybe it's just a prejudice, but node doesn't strike me as being a good candidate.

If it's ok to limit the solution to only unix servers, we could use Ip/Nftables and tc. We could open the stream as a child process, and then the linux kernel could keep track of the process, which is very efficient at doing it.

PID=`ps aux |grep inetd |head -n 1 |cut -b 10-14`

First we get the PID of the process

/usr/local/sbin/iptables -A OUTPUT -p TCP -m owner --pid-owner $PID -j ACCEPT

then we could use iptables to mark the packet, then Traffic control could shaper on a per PID basis

http://lartc.org/howto/lartc.qdisc.filters.html

If it's ok I could try to build something concrete

[espoal]

@Svenskunganka the only thing we would have to rely on is a unix kernel :P If node does it, I'm sure it would use the kernel too. I dont know any other way to shape traffic.

[astro]

No, iptables is specific to Linux.

[espoal]

yes you are right. I'm studying the source to try to come up with a good solution, since I need this, and to better learn this project.
@feross why you say
(Btw, it doesn't make much sense for the browser version of webtorrent).

?

[astro]

While dropping packets is perfectly valid, this shaping is best done in the actual code.

FWIW here's my approach from Bitford: https://github.com/astro/bitford/blob/master/src/shaper.js
I bet there are similar modules on npmjs.org.

[bradisbell]

Once implemented, will stream backpressure on the read side slow the download speed?

[astro]

Backpressure should go into https://github.com/feross/bittorrent-protocol/ where it doesn't seem to be implemented at this time. That will only become a problem if download speeds exceed CPU power & disk throughput.

[bradisbell]

@astro In the download case yes, but when streaming media it is very common that the download speed greatly exceed the playback speed. For example, if you pipe media into VLC, only a couple seconds of media data will be buffered prior to decoding and playback.

[feross]

https://github.com/substack/node-brake

[mbrownnycnyc]

What happened to this issue?

[Deathspike]

I'm guessing this didn't happen yet?

The stream solution that you provided @feross is only for download streams, right?

It's no way to control upload. I'm pretty new in webtorrent, is any of the libs to seed providing support for throttling?

[ghost]

:+1:

Implementing this seems hard with the way the event loop is ran. It seems to walk the swarm a lot.

[scotttrinh]

I'm working on something similar at work (my application just uploads) and this library works really well: https://github.com/tjgq/node-stream-throttle

You can set up a group with an aggregate rate limit and spin off throttles for each stream. I'm working out issues with changing the speed while connections are in-flight, but if I get it sorted, I'd be happy to take a stab at a PR for this.

[feross]

@scotttrinh Yes, that would be much appreciated!

[coleplx]

Any update on this?
It would be great to finally be able to limit users connection :)

[scotttrinh]

@coleplx nothing on my end. I wasn't able to get changing the Throttle mid-stream to work for me, but since Webtorrent deals with smaller chunks, maybe it's acceptable to finish the in-flight chunks at the old speed? @feross ? If that's cool, I can put together a PR.

[scotttrinh]

Actually, I just saw #1040. That seems like a reasonable PR for this feature.

[abcd9999]

Hello, I would like to know if this is implemented, and if it is, then how to do it.

[scotttrinh]

@abcd9999 Unfortunately I never got around to it. :(

[quicoto]

This seems to have a very low priority although it would have a great impact.

[rogerfar]

@feross could PR #1040 be re-evaluated again? If there is an issue with it I can have a look at it again.

[craigharman]

It's been 6 years now, assume this isn't going to be done?

[alxhotel]

@craigharman there is a PR pending #1762. If you want you can test it and help getting the PR merged

[craigharman]

@craigharman there is a PR pending #1762. If you want you can test it and help getting the PR merged

Sure @alxhotel , functionally works really well. Just needs the tests to work in regards to seeding and some modifications to the opts section of the docs API. I have commented this in review.

[subins2000]

There's currently no pause function to close all the active connections of a torrent and actually pause. From #543, this would also help implement the "real pausing" I infer.