ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 

  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: Inet-Admins
Inet-Admins mailing list archive (inet-admins@info.east.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [inet-admins] =?KOI8-R?Q?=D3=C5=D2=D4=C9=C6=C9=CB=C1=C3=C9=D1?= =?KOI8-R?Q?_=C2=C9=CC=CC=C9=CE=C7=CF=D7=CF=CA?= =?KOI8-R?Q?_=D3=C9=D3=D4=C5=CD=D9?=



> 
> Кто у тебя всякий раз добавляет пробелы в сабжекте? ;)

  Не знаю. За 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 http://info.east.ru/rus/inetadm.html



 




Copyright © Lexa Software, 1996-2009.