Author: Anže Vidmar
Any user on the system can run Trickle without needing administrative privileges. The software can handle only TCP stream connections, so it cannot shape traffic for network services that uses UDP stream connections, such as DNS (Bind) and TFTP. Actually, it cannot work with all network services that use TCP streams; because trickle uses the dynamic linker and loader, it can handle only network services that uses dynamic libraries (glibc) and not any programs that are statically linked. You can check whether a network service or command uses dynamic libraries with help of the ldd command, which prints shared library dependencies, so that you can see exactly what libraries are used with the specific command. For example to check whether FTP uses dynamic libraries:
~# ldd /usr/bin/ftp | grep libc.so
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7d42000)
Since I get back a positive result, I can use shape FTP traffic on my system. If the ldd and grep combination returns no result, a command will not work with trickle.
Trickle can run on any machine running the Linux, *BSD, or Solaris operating system without any need for kernel recompilation. By design, it uses an application-level method of delaying sending and receiving data over a socket to limit specified applications’ bandwidth.
Trickle requires you to have libevent libraries version 0.6 or higher installed on your system. You can find a trickle package in Fedora, Debian, and Ubuntu software repositories, or you can download the source and install the program with the usual configure, make, and make install commands.
When you’re done, you’ll have two binaries installed — trickle and trickled. You must run trickle in front of any command whose traffic you want to shape. Trickled is a bandwidth manager daemon that runs in the background and manages multiple sessions at one time. If you want trickled to be run at boot time, you need to put the link to it in rc.local.
You can start using trickle right away. When might it come in handy? Suppose you want to download a large ISO file but you don’t want wget to take all your bandwidth. You can limit wget to 50Kbps like this:
~$ trickle -d 50 wget ftp://mirror.switch.ch/mirror/fedora/linux/core/test/6.92/Prime/i386/iso/F-6.92-i386-DVD.iso
You should choose appropriate values for download and upload throughput based on your network connection and your needs.
Instead of running trickle in standalone mode, you can set global limitations and priorities by taking advantage of the trickled daemon. When you run the trickle command, it checks to see if the trickled daemon is running. If so, since trickled shapes traffic for a set of programs, trickle reads the /etc/trickled.conf file and applies the rules it finds to the program it is running. (You can override the values in trickled.conf by specifying values with the trickle command.) The trickled.conf file sets values for each specified service in a format like this:
[service]
Priority = <value>
Time-Smoothing = <value>
Length-Smoothing = <value>
Priority numbers let you set one service to have a higher priority relative to another. Services with a low number will get more bandwidth than services with higher numbers. By using priorities, you can connect to a services such as SSH remotely even if your network bandwidth is maxed out.
Time smoothing is defined in seconds and is meant to define the time intervals trickled uses to let the application transceive data. The smaller the value, the smoother the session will feel. For example, suppose you limit the FTP transfer to 50Kbps, and have time smoothing set to 1 second. You should get a transfer rate of exactly 50Kbps. If you increase the traffic smoothing number to a higher value (15 seconds, for example), the transfer rate may change between 40 and 60Kbps. With different limitations you’ll get different numbers.
Length smoothing defines the smoothing fallback time. That is, if trickled cannot meet the requested smoothing time, it will instead fall back to sending the number of KB of data specified here. If no value is specified, the default is 10Kbps.
Note that even when trickled is running, you still need to use trickle binary to run SSH, FTP, HTML, and other commands in order to make traffic shaping work. But when trickled is running, you don’t need to specify any parameters to the trickle command.
Here’s an example of a trickled.conf file:
[ssh]
Priority = 1
Time-Smoothing = 0.1
Length-Smoothing = 1
[ftp]
Priority = 8
Time-Smoothing = 5
Length-Smoothing = 20
[www]
Priority = 2
Time-Smoothing = 0.1
Length-Smoothing = 2
Here, SSH has the lowest priority number, meaning SSH traffic has the highest priority. Time-smoothing and length-smoothing options for SSH are the lowest because I don’t want any slow responses when I’m working remotely. I also set a high priority for Web browsing, so I can experience a smooth ride. I gave FTP the lowest priority because downloading stuff is less important for me.
You can also use trickled to set global traffic limits, so that you don’t need to specify each time the maximum upload and download volumes. For instance, if you want to globally set the download limit to 80Kbps and the upload limit to 10Kbps, you can use a command like:
~# trickled -d 80 -u 10 -s
In this example we tell the trickled daemon to use the limitations and to log every notification trickled produces to syslog instead of writing everything on the current terminal screen.
If you want to know more about dynamic linking and technical details behind trickle, read the trickle technical paper. You can read more about the command-line options for trickle and trickled in their man pages.
Despite the fact that trickle can handle only TCP stream connections and services that use dynamic libraries, it’s still a useful tool to give individual users control over traffic.
