IPN: кто как решает неправильный подсчет?

[chtito]

Разница в том, что не все пользователи в онлайне 100% времени и провайдер сам решает насколько большой пул адресов необходимо выделить.

Пожалуйста, если у кого то есть комментарии по существу о проблеме неправильного подсчета с IPN, буду рад выслушать.

[sopov]

Удачи Потом раскажете как 1000 онлайн на одной машине будут работать с exppp. Обратите внимание на подвисшие тюны и звонки в саппорт о пропадании мониторчиков под стол

Мало того exppp на x64 себя очень некорректно ведет и выпадает иногда в корку.

У меня пока нет 1000 онлайн, поэтому спорить не буду, но Асмодеус гарантировал 1000 в одной из тем.... Да пусть будет даже 10 насов по 500 юзеров - тут денег уже и на джун хватит... А pppoe мне нравиться простотой и универсальностью...

[chtito]

Ап. Баг чересчур актуален чтобы о нем забыть.

[~AsmodeuS~]

У меня пока нет 1000 онлайн, поэтому спорить не буду, но Асмодеус гарантировал 1000 в одной из тем.... Да пусть будет даже 10 насов по 500 юзеров - тут денег уже и на джун хватит... А pppoe мне нравиться простотой и универсальностью...

на одном если exppp то еколо 500 потом начинаются непонятные глуки

[chtito]

Интересно это ошибки exppp или самого Абиллса? Интересно ожидаются ли те же баги с большим количеством клиентов под Cisco PPPoE?

[~AsmodeuS~]

Интересно это ошибки exppp или самого Абиллса? Интересно ожидаются ли те же баги с большим количеством клиентов под Cisco PPPoE?

exppp

[chtito]

Касательно проблемы сабжа: слышал некоторые люди используют собственное решение этого бага. Оно не очень сложное: в пул с адресами каждому адресу присваивается статус например is_clean; когда приходит RADIUS stop пакет этот адрес возвращается в пул, но помечается как is_clean=false. Раз в 5 минут traffic2sql делает свое дело и в конце всем is_clean==false адресам меняет на true. Новым подключениям выделяется адрес только имеющий is_clean == true.

Это в кратце. Есть у кого-нибудь такое или более лучшее решение в виде патчика?

[ran]

у Асмодеуса за пазухой небось всё есть
а я б на твоём месте арендовал нужное количество адресов у независимого регистратора (фигню ведь щас стоит), насроил BGP4 маршрутизацию в арендованные подсети и раздавал бы статические адреса а не геморроился

[chtito]

у Асмодеуса за пазухой небось всё есть

Асмодеус говорит что пока баг фиксить не собирается

А адресов 4000 есть. Просто адресам есть лучшее применение, чем простаивать, учитывая, что сидит одновременно в пиковые моменты меньше 3/4 клиентской базы. Ну я уже говорил о нерентабельности этого, не буду повторяться.

[ran]

Асмодеус говорит что пока баг фиксить не собирается

и правильно делает ибо это не баг а особенность данной биллинговой системы. не устраивает - ищи другую.

[chtito]

Ап. У кого нибудь есть идеи или какие-то обходные пути? Только строго по теме пожалуйста.

[ran]

Ап. У кого нибудь есть идеи или какие-то обходные пути? Только строго по теме пожалуйста.

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

[chtito]

А вдруг кто-то еще знает?

[ran]

А вдруг кто-то еще знает?

думаю что никто

[V1talya]

Касательно проблемы сабжа: слышал некоторые люди используют собственное решение этого бага. Оно не очень сложное: в пул с адресами каждому адресу присваивается статус например is_clean; когда приходит RADIUS stop пакет этот адрес возвращается в пул, но помечается как is_clean=false. Раз в 5 минут traffic2sql делает свое дело и в конце всем is_clean==false адресам меняет на true. Новым подключениям выделяется адрес только имеющий is_clean == true.

Это в кратце. Есть у кого-нибудь такое или более лучшее решение в виде патчика?

Думаю можно договориться с разработчиком за $ и он реализует для Вас такое... ( если такое возможно )