Traffcounter

[Silitra]

#define FLUSH_TIME (10)

#define REMOVE_TIME (15)

 

FlushAndRemove() packets: 35053(rem 10738) ip2packets: 61106(rem 18476)

 

если массив ip2packets содержит более 70К (может и боелее, в выводе не видел значения выше 70К) элементов поток зависает.

какова причина ? на сколько помню размер массива в Cи не ограничен. как победит траблу?

[madf]

Во первых, размер массива в С ограничен доступной памятью.

Во вторых, тут не С а С++.

В третьих, тут не массив а std::map.

Но наблюдение, несомненно, интересное...

[Silitra]

ну это все понятно. как лечить ?

[madf]

Я вобще не вижу, почему тут может быть проблема. Возможно, совпадение?

[Silitra]

что имеется в виду под совпадением ?

а проблема есть и остается. достаточо увеличить #define REMOVE_TIME (15) и тут же попадаем на зависание потока.

[den68]

Ураа !! наконец-то кто-то взялся за Traffcounter !!

как показывали эксперементы у меня, именно в нем есть зацикливание и повышение нагрузки на проц.

[Silitra]

2den68

[Silitra]

тебе скорей всего поможет

user.cpp
-lastWriteStat = stgTime + random() % settings->GetStatWritePeriod();
+lastWriteStat = stgTime + settings->GetStatWritePeriod();

если поток не слишком велик

[den68]

тебе скорей всего поможет

user.cpp
-lastWriteStat = stgTime + random() % settings->GetStatWritePeriod();
+lastWriteStat = stgTime + settings->GetStatWritePeriod();

....

 

Спасибо, это реализовано давно, чтоб поток не затыкался и все не вставало колом:

 

#define FLUSH_TIME (3)

#define REMOVE_TIME (5)

 

понимаю что мало и неправильно но .. как-то работает, пока ...

косяки где-то глубже, в идеологии сбора траффа + накопления детайл стат ...

[Silitra]

2den68

а можешь показать вывод FlushAndRemove() ?

[madf]

Проблема трафкаунтера сейчас в том, что при любых операциях с деревом пакетов все действия блокируются. Так, например, как уже было верно подмечено den68, при FlushAndRemove лочится прием трафика. И наоборот - при приеме лочится FlushAndRemove.

Решается эта проблема введением 2-х промежуточных буферов: на прием пакета и на его отдачу юзеру. При этом функции FlushAndRemove делегируются либо классу USER либо классу USERS.

Этот вариант решения мы с Борей обсуждали на прошлой неделе. Сейчас он в процессе проектирования. Изменений все-таки надо будет много сделать.

Кроме того я хочу полностью "отвязать" TRAFFCOUNTER от юзеров и от захватчика трафика - чтобы на него можно было написать нормальный юнит-тест. Кому интересно - могу дать текущие исходники того, что я хочу реализовать. Ели бы у нас не лежал основной канал в инет - можно было бы попробовать реализовать это вместе, используя CVS.

[Silitra]

могу выделить отдельную машину с широким каналом и поднятым cvs. +

[madf]

Широкий канал здесь и даром не нужен - нужен нормальный программист

[Silitra]

гдеж его взять? Может вакансию откроем?

[madf]

Если нет - то я и сам справлюсь. Правда это будет несколько медленно - занимаюсь проблемой по вечерам...

Да и вобще, OpenSource-проекты всегда развивали энтузиасты, а не наемные работники

[Silitra]

уже офтоп попер

но всеравно не плохо, когда этот "энтузиазизм" стимулируется $. 200-300$ в месяц, на пиво ни когда не помешают

[den68]

Кому интересно - могу дать текущие исходники того, что я хочу реализовать. Ели бы у нас не лежал основной канал в инет - можно было бы попробовать реализовать это вместе, используя CVS.

 

Давай, попробую с радостью поучаствовать, правда время не вагон ...

[madf]

Напомни, плиз, почту...

[Silitra]

ну как там?

дела идут ?

[madf]

Потихоньку. На быстрый результат не рассчитывайте - рук не хватает.

[Silitra]

2madf

просил нароботки выслать. смотри лс.