> может кто уже находил доку нормальную как им рулить с помощью си ? (то есть просто доку по его библиотекам и функциям и как это вообще можно заиспользовать)

system("iproute2 params to iproute");

В этом есть проблема в програмке уже 6 потоков и если вызываеш system то начинаются проблемы Да и не выход это, исполнять через вызов командной оболочки :)

Re^2: С/C++ - шейпинг iproute2

> В этом есть проблема

> в програмке уже 6 потоков и если вызываеш system то начинаются проблемы

ну тогда fork()/exec()/wait()

> Да и не выход это, исполнять через вызов командной оболочки :)

Вполне себе unix way.

>> Вполне себе unix way.

Это не "unix way", это быдлокод с костылями =). Ты представляешь сколько затрат идёт на создание нового процесса? А на преобразование данных (параметры вызова iproute) в текст с одной стороны и обратно с другой? А как отлавливать ошибки?

iproute2 это набор утилит для управления сетевой подсистемой линукс, тоесть копать вам надо чуть дальше, а имено ядро. хотябы в википедию заглянули бы http://ru.wikipedia.org/wiki/Iproute2

> Ты представляешь сколько затрат идёт на создание нового процесса?

Вполне.

> А на преобразование данных (параметры вызова iproute) в текст с одной стороны и обратно с другой?

Это надо делать 10^6 раз в минуту? :)

> А как отлавливать ошибки?

Вот уж ошибки-то тут как нельзя лечге ловятся.

>> Это надо делать 10^6 раз в минуту? :)

А вдруг? В любом случае, даже если вызов утилит будет происходить не так часто, всёравно часть русурсов системы уходит совершенно впустую. Лично мне подобный подход очень не нравится.

если использовать структуры и api ядра - придётся перекомпилировать программу при их изменении, а то и переписывать. используя же system("iproute2 params to iproute"); такой проблемы не будет. да и зачем писать и поддерживать ещё раз то, что уже написано и поддерживается в актуальном состоянии (iproute2) ?

>> если использовать структуры и api ядра - придётся перекомпилировать программу при их изменении, а то и переписывать. используя же system("iproute2 params to iproute"); такой проблемы не будет. да и зачем писать и поддерживать ещё раз то, что уже написано и поддерживается в актуальном состоянии (iproute2) ?

А если изменится интерфейс утилит iproute2? Те же яйца... Кстати вероятность изменения API значительно меньше, чем изменения параметров вызова этих утилит и возвращаемых ими сообщений/кодов возврата.

>Кстати вероятность изменения API значительно меньше, чем изменения >параметров вызова этих утилит и возвращаемых ими сообщений/кодов >возврата.

знаетели както честно говоря совсем не очевидно,
API и интерфейс утилиты вполне могут очень мало
коррелировать между собой..

Описали бы лучше задачу, узкие места...А то 
может неожиданно оказаться, что скрипт на bash 
позволит реализовать решение куда гибче чем на C/++ 

Заглядывал конечно :) Только вот проблема, я ищу что то типа как iptables -> ip_queue что бы можно было иметь что то что работает в ядре и даёт возможность управлять чем то из простанства приложения. Можно конечно устроить шейпинг своими силами, сделать очереди обрабатывать временные интервалы и осуществлять перестановку и задержки но зачем изобретать велосипед если есть уже готовое, сейчас немного переключился на другую задачу, но всё равно придётся возвращаться к шейперу, пока ни чего не нашёл. Думаю придётся всё таки разрывать исходники iproute и tc :(