реализовал представленое по ссылке
http://www.opennet.me/base/dev/traffic_analyze.txt.
c маленькими изменениями
грубо говоря фиксирует объемы входящего трафика на каждую подсеть
раз в секунду отправляет данные на другую машину.do {
rec = recvfrom(eth0_if, (__u8 *)buff, ifp.mtu + 18, 0, NULL, NULL);
if(rec < 0 || rec > ETH_FRAME_LEN) {
perror("recvfrom\n");
return -1;
}
eth=buff;
ip=buff + ETH_HLEN;
__u8 net;
net=(__u8)((ip->daddr & 0x00fe0000)>>16);
counter_net[net]+=rec;
}
counter_proto[ip->protocol]++;
t=time(NULL);
et=t;
counter_net[256]=0;
counter_proto[256]=1;
counter_packet_size[256]=2;
counter_packet_size[(rec>>6)&0x00ff]++;
int i=0;
for (i=0;i<256;i++){
counter_net[i]=0;
counter_proto[i]=0;
counter_packet_size[i]=0;
}
}
}
} while(1);
проблема в том, что это я запускаю на гигабитном интерфейсе и данный цикл грузит проц на 90-95 процентовкак окозалось, даже вот такое упрощение
do {
rec = recvfrom(eth0_if, (__u8 *)buff, ifp.mtu + 18, 0, NULL, NULL);
if(rec < 0 || rec > ETH_FRAME_LEN) {
perror("recvfrom\n");
return -1;
}
} while(1);грузит проц на 80%
зато iptables на 3000 правил, практически не грузит процессор, хотя через него пролетает гигабит/с в обоих направлениях
шейпер с использованием хеша, также не грузитктонибудь подскажет как реализовать более производительную схему?
обрабатывать мне нужно каждый пакет проходящий через интерфейсЗЫ: и ipcad грузит процесор поменьше
м.б. дело в promiscuous mode?и это, режим часом не O_NONBLOCK ?)
>м.б. дело в promiscuous mode?
>
>и это, режим часом не O_NONBLOCK ?)promiscuous mode
проверюа можно подробнее про O_NONBLOCK
>>м.б. дело в promiscuous mode?
>>
>>и это, режим часом не O_NONBLOCK ?)
>
>promiscuous mode
>проверю
>
>а можно подробнее про O_NONBLOCKну-у, мы не знаем какие опции у вас на сокет проставлены.
>м.б. дело в promiscuous mode?
>
>и это, режим часом не O_NONBLOCK ?)promiscuous mode отключил, результата практически нету!
а это для чего ? ( непонятно ;-) )
int i=0;
for (i=0;i<256;i++){
counter_net=0;
counter_proto=0;
counter_packet_size=0;
}
>[оверквотинг удален]
>
> counter_net=0;
>
>
> counter_proto=0;
>
>
> counter_packet_size=0;
>
> }ошибка при копировании
counter_net[i]=0;
counter_proto[i]=0;
counter_packet_size[i]=0;
>[оверквотинг удален]
>
>
>зато iptables на 3000 правил, практически не грузит процессор, хотя через него
>пролетает гигабит/с в обоих направлениях
>шейпер с использованием хеша, также не грузит
>
>ктонибудь подскажет как реализовать более производительную схему?
>обрабатывать мне нужно каждый пакет проходящий через интерфейс
>
>ЗЫ: и ipcad грузит процесор поменьшепочитайте книжку Вани Склярова Программирование боевого софта под Linux
там все понятно объяснено в 9 главе почему iptables не грузит проц.если коротко, то все действия iptables осуществляются в ядре, и копирование данных в юзерское пространство не выполняется. при этом работают фильтры, которые быстренько отсекает ненужные данные.
у вас же валиться весь трафик в юзерское пространство. что достаточно накладно.
>[оверквотинг удален]
>почитайте книжку Вани Склярова Программирование боевого софта под Linux
>там все понятно объяснено в 9 главе почему iptables не грузит проц.
>
>
>если коротко, то все действия iptables осуществляются в ядре, и копирование данных
>в юзерское пространство не выполняется. при этом работают фильтры, которые быстренько
>отсекает ненужные данные.
>
>у вас же валиться весь трафик в юзерское пространство. что достаточно накладно.
>так то оно так, вот только ipcad не являющийся частью ядра, не грузит так проц, и врядли мой код намного сложнее фильтров которые отсекаю не нужные пакеты
к томуже , сама процедура выборки без кода обработки грузит проц не намного меньше, вот я и скланяюсь к мысли, что выборку можно делать както под другому, вот только не пойму как
>так то оно так, вот только ipcad не являющийся частью ядра, не
>грузит так проц,
>к томуже , сама процедура выборки без кода обработки грузит проц не
>намного меньше, вот я и скланяюсь к мысли, что выборку можно
>делать както под другому, вот только не пойму какpcap
или ULOG (в этом случае и фильтровать можешь предварительно)