Привет!
Кто у тебя всякий раз добавляет пробелы в сабжекте? ;)
Thu Oct 21 16:21, Boris Tyshkiewitch <bvt@zenon.net> wrote:
> > Если выдавать адрес auth сервером, то впринципе можно продумать алгоритм
> > кеширования и без завершающего сессию маркера (в вашем случае acct-stop).
> > На вскидку -- признаком освобождения может быть и занятие этого же порта
> > следующим клиентом...
>
> ??????? Ты наверно потерял нить дискуссии. Нужно держать выделение
> IP адреса как можно дольше. Указанное событие сводит все усилия на нет.
>
Все в порядке.
Держим их там до тех пор пока не кончился весь пул, вот кончился, значит
надо какие-то ранее выданные освободить, какие? которые имеют маркировку
что они сейчас не заняты и наиболее старые, кто эту маркировку им будет
опеспечивать? тот факт что на такой-то порт зашел другой юзер однозначно
свидетельствует о том что предыдущий с него отпал. Ну и?
> > > Ага, значит лог-файл все-таки есть и мы умеем его парсить? А ради чего
> > > тогда все? Этот лог файл и является буффером. Бери из него в максимальном
> > > темпе. Эффективная реализация tail описана много где. Зачем два механизма?
> > > Чтобы глюки потом искать?
> > >
> > Ради реалтайма.
>
> Почему чтение из socket/pipe претендует на подобие реал-тайма, а чтение
> из такого-же хендла, но связанного с файлом на диске - нет? В чем разница?
>
Нуу, как минимум это лишние операции с диском ;)
> > > У тебя уже есть два надежных, простых, близких к NAS сервера, где ты
> > > предлагаешь вести авторизацию. Отдай туда эккаунтинг и забирай/передавай
> > > дальше. По любому протоколу.
> > >
> > Можно.
> > Только вопрос -- зачем? Повысить надежность. Надежность _чего_?
>
> В данном случае надежность системы эккаунтинга. Если же освобождать
> адреса по событиям эккаунтинга, то и надежность системы авторизации.
>
Освобождать адреса можно и без этого, однозначно.
Только надежность аккаунтинга. Из чего она состоит? И какой процент в ней
приходится на собственно долговременные лежания бекбона?
В идеале, такая схема наверно должна быть построена в виде звезды, с
центром в учетном центре там же где главная магистраль, и если полег луч
до площадки NAS'а с авторизатором, то клиента и тарифицировать не нужно,
услугу он не получил.
Нужно обеспечивать надежность транспорта всего-лишь, в совершенно
конкретном месте. Так или иначе это нужно делать.
> > Точность рассчетов равна кванту времени прерывания на одну сессию. Если
> > сделать прерыватель каждую секунду, то и точность расчетов будет ровно
> > 1 секунда. Можно и каждую микросекунду сделать, если проц успеет, только
> > смысла в этом нет никакого.
>
> Да, точность расчетов равна квантам, которые у тебя 10сек. Я считаю,
> что уже эти 10 сек. создают неоправданную нагрузку, не говоря уже
> о требуемых 1сек.
>
Да нет никакой нагрузки. Не надо шманать оракл всякий раз. Он только
подает исходные данные в начале сессии и получает результаты в конце.
Кто будет создавать нагрузку? Арифметические и логические операции и
работа с памятью что-ли?
Твой любимый tail гораздо больше создает нагрузки.
> Давай. В твоем случае нужен не обратный, а прямой тарификатор. Из секунд
> в деньги.
>
> Этот модуль берет текущее время и позиционируется на абсолютной шкале
> времени, поделенной отрезками различных тарифов (время суток, день недели,
> праздники). После этого он берет _весь_ интервал работы текущего
> пользователя, и применяет этот отрезок к общей шкале времени, осуществляя
> то самое пошаговое интегрирование. Результат - потраченные деньги и
> предоплаченные часы.
>
Постой, попробуй на минуту забыть про любимый тарификатор, деньги и
интегралы. Подумай с чистого листа. Твоя система работает в РЕАЛЬНОМ
времени и работает только со временем же...
> Для каждой структурки ты должен слазить в некую структуру данных,
> где из типа контракта пользователя, текущей позиции на абсолютной шкале
> времени нужно вычислить текущий тариф. Иначе ты не знаешь сколько нужно
> вычесть - 1 или 0 или 0.1 Сделать можно, но это будет существенно более
> сложный код нежли "if (timeleft -= quant <= 0)".
>
Да нет же! Ты загрузил все в начале, по acct-start, жевал это все в
течении всей сессии клиента и выгрузил все в конце по acct-stop.
Кто-то снаружи, пусть это будет cron, меняет тебе твой time quant, time
rate или что там еще тебе надо, прямо в течении сессии клиента.
Какое нахрен интегрирование? Чего в куда? Время у тебя под ногами, везде,
ты прямо в нем!
> Пойми, ты пытаешься осуществить интегрирование в real-time. Не спорю
> - бывает. Летают и самолеты и ракеты. Но тебе это надо? Как насчет
> цены всей этой конструкции?
>
Ничего я не интегрирую. Я живу во времени, и клиент живет рядом со своим
карманом времени, из которого я прямо у него на глазах и вынимаю как
и когда мне захочется...
И стоит это гораздо меньше твоего мудрого тарификатора.
> Плюс вторая проблема - у тебя тарификация идет online, и нет первичного
> документа - основания разборок с пользователем. Возвращаясь к сабжекту
> данной дискуссии, я считаю, что сертифицировать твой алгоритм будет очень
> сложно.
>
Каких разборок? Я говорю клиенту, что один час стоит 18 у.е. по базовому
тарифу, однако вечером время уходит медленней на 1/3, а ночью еще
медленней на 2/3. Он оплатил один час, и работает ночью ровно три часа,
потому что ночью дешевле в три раза! И что тут сертифицировать? Алгоритма
нет никакого. Есть только правила. Которые тщательно отрабатываются в
реалтайме.
> Как тут уже справедливо заметили нельзя сделать реал-тайм алгоритм без
> real-time OS. Еще нужна real-time сеть (QoS как минимум). Поэтому мы
> все-таки говорим о различных уровнях приближения к оному реал-тайму.
>
> Я считаю, что подойти можно очень близко. Но гарантировать нельзя.
>
Чего гарантировать надо? Что в компутере где работает наш демонок
правильно работает системный клокер что-ли? Гарантирую.
А реалтайм OS нужна там, где счет идет на микросекунды. Чтобы вовремя
успеть дернуться. Для наших целей подходит любая OS, лишбы клокер
в ней был, сеть, память и процессор (можно без float;)
Мне все-таки кажется что мы не понимаем друг друга совершенно. Надо
сойти со своей колокольни и взглянуть свежим глазом вокруг и на себя.
=============================================================================
"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
