>
> Кто у тебя всякий раз добавляет пробелы в сабжекте? ;)
Не знаю. За elm не замечено.
> Thu Oct 21 16:21, Boris Tyshkiewitch <bvt@zenon.net> wrote:
> > > Если выдавать адрес auth сервером, то впринципе можно продумать алгоритм
> > > кеширования и без завершающего сессию маркера (в вашем случае acct-stop).
> > > На вскидку -- признаком освобождения может быть и занятие этого же порта
> > > следующим клиентом...
> >
> > ??????? Ты наверно потерял нить дискуссии. Нужно держать выделение
> > IP адреса как можно дольше. Указанное событие сводит все усилия на нет.
> >
> Все в порядке.
> Держим их там до тех пор пока не кончился весь пул, вот кончился, значит
> надо какие-то ранее выданные освободить, какие? которые имеют маркировку
> что они сейчас не заняты и наиболее старые, кто эту маркировку им будет
> опеспечивать? тот факт что на такой-то порт зашел другой юзер однозначно
> свидетельствует о том что предыдущий с него отпал. Ну и?
Да, будет работать.
> > > > Ага, значит лог-файл все-таки есть и мы умеем его парсить? А ради чего
> > > > тогда все? Этот лог файл и является буффером. Бери из него в максимальном
> > > > темпе. Эффективная реализация tail описана много где. Зачем два механизма?
> > > > Чтобы глюки потом искать?
> > > >
> > > Ради реалтайма.
> >
> > Почему чтение из socket/pipe претендует на подобие реал-тайма, а чтение
> > из такого-же хендла, но связанного с файлом на диске - нет? В чем разница?
> >
> Нуу, как минимум это лишние операции с диском ;)
Так ты все равно на диск пишешь этот-же лог. А считается он у меня скорее
всего из дискового кеша, а не с диска.
> Только надежность аккаунтинга. Из чего она состоит? И какой процент в ней
> приходится на собственно долговременные лежания бекбона?
Заметим не бекбона, а любого элемента сети от NAS до центрального сервера.
> В идеале, такая схема наверно должна быть построена в виде звезды, с
> центром в учетном центре там же где главная магистраль,
Очень спорный тезис про главную магистраль и ее местоположение. У нас
например расчетный центр в оффисе, а все магистрали на M9. И это
достаточно обычное явление, расчетный центр может быть где угодно.
> и если полег луч
> до площадки NAS'а с авторизатором, то клиента и тарифицировать не нужно,
> услугу он не получил.
Это слишком упрощенная схема. В нашей ситуации клиент получил услугу
полностью, за исключением доступа к серверу статистики.
> Нужно обеспечивать надежность транспорта всего-лишь, в совершенно
> конкретном месте. Так или иначе это нужно делать.
Нужно, мы делаем, двумя путями, плюс маниакальное резервирование
свичей. Но все бывает. Люди.....
> > > Точность рассчетов равна кванту времени прерывания на одну сессию. Если
> > > сделать прерыватель каждую секунду, то и точность расчетов будет ровно
> > > 1 секунда. Можно и каждую микросекунду сделать, если проц успеет, только
> > > смысла в этом нет никакого.
> >
> > Да, точность расчетов равна квантам, которые у тебя 10сек. Я считаю,
> > что уже эти 10 сек. создают неоправданную нагрузку, не говоря уже
> > о требуемых 1сек.
> >
> Да нет никакой нагрузки. Не надо шманать оракл всякий раз. Он только
> подает исходные данные в начале сессии и получает результаты в конце.
> Кто будет создавать нагрузку? Арифметические и логические операции и
> работа с памятью что-ли?
> Твой любимый tail гораздо больше создает нагрузки.
>
> > Давай. В твоем случае нужен не обратный, а прямой тарификатор. Из секунд
> > в деньги.
> >
> > Этот модуль берет текущее время и позиционируется на абсолютной шкале
> > времени, поделенной отрезками различных тарифов (время суток, день недели,
> > праздники). После этого он берет _весь_ интервал работы текущего
> > пользователя, и применяет этот отрезок к общей шкале времени, осуществляя
> > то самое пошаговое интегрирование. Результат - потраченные деньги и
> > предоплаченные часы.
> >
> Постой, попробуй на минуту забыть про любимый тарификатор, деньги и
> интегралы.
Нет. Давай-ка всетаки зафиксируем, что все программы и алгоритмы
строятся на некой математической модели. Их можно пытаться не замечать
и делать все как захочеться и покажеться на манер русского самородка
Левши. Но они (мат. модели) все равно есть, и имеет смысл их выявлять.
В случае тарификатора - это интегрирование. И не важно, какой алгоритм
используется, все одно смысл его интегрирование - площадь под кривой
изменения тарифа от абсолютного времени.
> Подумай с чистого листа. Твоя система работает в РЕАЛЬНОМ
> времени и работает только со временем же...
Да, мы с тобой изначально не сошлись именно в этом вопросе.
Я продолжаю утверждать, что ты используешь не время, а юниты.
Днем у тебя 1 unit = 1 hour, ночью 1 unit = 0.5 hour.
Эта схема вполне применима в телко биллинге, например в Израиле
что-то типа: 1 unit днем - это 1 мин., вечером 15 мин, ночью -
1 звонок. Я обдумывал эту систему, и решил пока не связываться.
Не суть. Когда ты говоришь, что "вечером время уходит медленней
на 1/3", ты говоришь о юнитах, а не о времени.
> > Для каждой структурки ты должен слазить в некую структуру данных,
> > где из типа контракта пользователя, текущей позиции на абсолютной шкале
> > времени нужно вычислить текущий тариф. Иначе ты не знаешь сколько нужно
> > вычесть - 1 или 0 или 0.1 Сделать можно, но это будет существенно более
> > сложный код нежли "if (timeleft -= quant <= 0)".
> >
> Да нет же! Ты загрузил все в начале, по acct-start, жевал это все в
> течении всей сессии клиента и выгрузил все в конце по acct-stop.
> Кто-то снаружи, пусть это будет cron, меняет тебе твой time quant, time
> rate или что там еще тебе надо, прямо в течении сессии клиента.
> Какое нахрен интегрирование? Чего в куда? Время у тебя под ногами, везде,
> ты прямо в нем!
То, что это время, я по прежнему не согласен. Можно я все-таки буду
считать это юнитом?
Что касается переключения тарифа по cron, то тут есть здравая идея.
Данный алгоритм [интегрирования] будет работать. Но как с ним жить?
Что будет, если STOP запоздает? Начислиться лишних юнитов? А если
STOP совсем потеряется? А как потом с этим разобраться? Как сделать
пересчет по логу? Реализовывать отдельный алгоритм? Что делать,
если разные алгоритмы дадут разный результат.
> > Пойми, ты пытаешься осуществить интегрирование в real-time. Не спорю
> > - бывает. Летают и самолеты и ракеты. Но тебе это надо? Как насчет
> > цены всей этой конструкции?
> >
> Ничего я не интегрирую. Я живу во времени, и клиент живет рядом со своим
> карманом времени, из которого я прямо у него на глазах и вынимаю как
> и когда мне захочется...
Все здорово, пока не начнется реальная жизнь, с реальными проблемами,
и занудными пользователями, которые с калькулятором считают свою сессию.
> И стоит это гораздо меньше твоего мудрого тарификатора.
Не может. Отдельный тарификатор (не реал-тайм) все равно нужен для
пересчета логов и прочих разборок. Так что это _дополнительные_
затраты на попытку реал-тайма.
> > Плюс вторая проблема - у тебя тарификация идет online, и нет первичного
> > документа - основания разборок с пользователем. Возвращаясь к сабжекту
> > данной дискуссии, я считаю, что сертифицировать твой алгоритм будет очень
> > сложно.
> >
> Каких разборок? Я говорю клиенту, что один час стоит 18 у.е. по базовому
> тарифу, однако вечером время уходит медленней на 1/3, а ночью еще
> медленней на 2/3. Он оплатил один час, и работает ночью ровно три часа,
> потому что ночью дешевле в три раза! И что тут сертифицировать? Алгоритма
> нет никакого. Есть только правила. Которые тщательно отрабатываются в
> реалтайме.
Насколько тщательно, и что делать при сбоях? Где первичный документ -
основание для списания денег? Я тут уже рассказывал про тетушку из
сертификационного центра АДЭ, которая руками правит такаксовый лог и
просит пропустить его через тарификатор.
> > Как тут уже справедливо заметили нельзя сделать реал-тайм алгоритм без
> > real-time OS. Еще нужна real-time сеть (QoS как минимум). Поэтому мы
> > все-таки говорим о различных уровнях приближения к оному реал-тайму.
> >
> > Я считаю, что подойти можно очень близко. Но гарантировать нельзя.
> >
> Чего гарантировать надо? Что в компутере где работает наш демонок
> правильно работает системный клокер что-ли? Гарантирую.
> А реалтайм OS нужна там, где счет идет на микросекунды. Чтобы вовремя
> успеть дернуться. Для наших целей подходит любая OS, лишбы клокер
> в ней был, сеть, память и процессор (можно без float;)
В реал-тайм системе нужно гарантировать любое время обслуживания.
Если такой гарантии нет, то все начинает разваливаться как карточный
домик. В твоем случае хороший пример - запаздывание STOP записи, вызывающей
начисление дополнительных юнитов.
>
> Мне все-таки кажется что мы не понимаем друг друга совершенно. Надо
> сойти со своей колокольни и взглянуть свежим глазом вокруг и на себя.
Не знаю. Мне кажеться, что я достаточно хорошо понял твои тезисы, и
вынес из них немало полезного - иной алгоритм тарификации. Алгоритм
красивый и изящный, но я все равно не понимаю как его использовать
в коммерческой эксплуатации. В том числе как сертифицировать.
Boris.
=============================================================================
"inet-admins" Internet access mailing list. Maintained by East Connection ISP.
Mail "unsubscribe inet-admins" to Majordomo@info.east.ru if you want to quit.
Archive is accessible on
