trickled usa a mesma técnica para limitar a largura de banda de trickle . Apenas escuta em um soquete de domínio UNIX em /tmp para outros trickle processos. Quando outro processo trickle for iniciado, ele solicitará trickled (se estiver em execução) para as configurações globais e as definirá como padrão, a menos que tenha substituições individuais para essa instância específica de trickle .
Um executável totalmente estaticamente vinculado (significando que tudo, incluindo libc, é estaticamente compilado no binário) não pode ser usado com um processo de espaço do usuário como trickle . O que eventualmente acontece com um executável vinculado estaticamente é que ele faz chamadas do sistema diretamente para o usuário estável do kernel do Linux < - > kernel Application Binary Interface (ABI). Ele não tenta carregar nenhuma biblioteca dentro de /lib , /usr/lib , /usr/local/lib , etc. para resolver símbolos.
A mágica de trickle é que efetivamente injeta código customizado nos processos que fazem carregam dinamicamente a biblioteca C do sistema. Processos que não , ou processos que são setuid root, não podem ter seu código modificado dessa maneira.
Para realmente controlar todos os processos no sistema, esse nível de limitação de largura de banda precisaria ser feito no próprio kernel.
Existem algumas implementações de kernel, tanto antigas quanto novas, da funcionalidade de modelagem de tráfego (modelagem de tráfego é o termo generalizado para limitação de largura de banda, e geralmente significa modificar o tempo ou o agendamento de pacotes) no próprio kernel Linux, e estes são muito mais confiáveis. aqui é um exemplo mais recente baseado na estrutura nf, que está programada para substituir o iptables como a política da camada 3 e pilha de controle para o Linux moderno.