Перейти до

vop

Сitizens
  • Всього повідомлень

    1 339
  • Приєднався

  • Останній візит

  • Дней в лидерах

    35

Сообщения додав vop

  1. хочется пожелать автору Nodeny, чтобы следующай версия его биллинга избавилась от одноранговости :lol:

     

    Почему-то мне кажется, что бесполезно. Я лично Стасу объяснял, что это такое, как достить многоуровневости. Похоже, он просто не понял этого...

  2. Господа, еще раз замечу, если вы не продаете канал, то нехрен писать в договорах "безлимит" и заниматься маркетинговым нажучиванием. Пишите ограничения (100 Гиг, 40%), но не старайтесь обмануть сами себя. А то получается полная хренотень, типа, и "безлимит" продали, и не такой уж он и безлимит...

  3. Что есть неодноранговый биллинг и что конкретно (на примерах) он даст персоналу сети, скажем из 300 абонентов?

     

    Двууровневый (многоуровневый) биллинг предназначен для продажи услуг, а не интернета. Что он даст персоналу из, скажем, сколько угодно абонентов? Ну не знаю. Как минимум, возможность вести учет продажам не только IP подключениями (в любом количестве и конфигураций), но и другими услугами, характерными для провайдера, но о которых, почему-то создатели биллингов практически не думают. Например, почтовый ящик(и), домен(ы), виртулальный хост, доступ к игровому серверу или хранилищу файлов, и т. д, не говоря уже об iptv и voip. Когда авторам биллингов приходит это понимание, то начинают появлятся прилёпки в виде "дополнительных услуг" и т.д. И это при золотом правиле, что дополнительных услуг не может быть, ибо все услуги основные.

     

    Так вот оба упомянутых биллинга предназначены для торговли ip-подключением.

  4. Оба, и STG и NoDeny - одноранговые биллинги (т.е. считалки трафика с "умножением" на стоимость). У STG в принципе, самая неудачная структура, которую только можно было придумать. Поэтому, если нет никаких предубеждений перед перловым скриптом, наверно, лучше пользоваться им.

  5. Я не продал полосу, я сделал пребывание в интернете комфортным. Думаю, если ты такой умный, знаешь чем отличается корпоративный безлимит от домашнего :huh:

     

    В приличных домах Утрехтщины в договорах клиентов пишут, (в вольном переводе) "предоставляется канал со скоростью 4 мегабита с максимальной загрузкой не более 25%". Ибо там же для офиса продается "гарантированый" канал без ограничения. Вот в этом случае есть отличие домашнего от корпоративного, в том числе и по цене. Это именно тот случай, при котором клиент по сути получает безлимит на 1м, но со скоростью в 4м - тот самый "комфортный" интернет. Если в договоре нет такого пояснения, то и отличия нет, а все остальное - мелкое мошенничество со стороны провайдера :)

  6. У меня в доме два кабельных ТВ провайдера. В принципе, набор каналов одинаковый, и цены примерно равные... Только вот один хочет денег за "дополнительный телевизор", а второй говорит - подключайте сколько хотите через сплиттеры, только не увлекайтесь, ибо, сигнал не резиновый, слабеет... ;) К какому я подключился, гадать не стоит. ;)

  7. Ідеальним рішенням було б налаштувати автоматичну синхронізацію часу на сервері (про це можна почитати в інтернеті).

     

    Это, как бы, не то, что "идеальным", а просто "обязательно" должно быть. Как можно делать клиентские начисления, привязанные ко времени на сервере, на котором время болтается, как ему угодно?

  8. И на этом форуме подскажу. Я бы сделал порт-прокси при помощи netcat'а.

     

    Для этого на машинке 192.168.0.1 В файлик /etc/inetd.conf добавляем строчку, типа:

     

    9770 stream tcp nowait nobody /bin/nc nc 192.168.0.2 9770

     

    Не забыть перезапустить inetd (killall -HUP inetd). Это существенно проще, нежели поднимать влан с форвардингом портов.

     

    ;)

     

    не работает

     

    Что именно не работает? Что говорит telnet 192.168.0.1 9770 ?

  9. И на этом форуме подскажу. Я бы сделал порт-прокси при помощи netcat'а.

     

    Для этого на машинке 192.168.0.1 В файлик /etc/inetd.conf добавляем строчку, типа:

     

    9770 stream tcp nowait nobody /bin/nc nc 192.168.0.2 9770

     

    Не забыть перезапустить inetd (killall -HUP inetd). Это существенно проще, нежели поднимать влан с форвардингом портов.

     

    :)

  10. Это типа если я даю доверенность на вождение без права передачи, то юридически я не могу заставить машину водить только одному человеку ?

     

    Достаточно не путать коммерческий договор с гражданской доверенностью. Тогда все встанет на свои места.

  11. 1. Указываем в договоре, заборону передачи послуги 3 особам.

     

    Передача услуги третьим лицам наступает только в момент подписания договора клиента с этими третьими лицами. Т.е. такой пункт в свой договор писать нужно, но только для другого - что бы избежать ответственность перед третьими лицами за "плохую услугу". Реально, юридически, запретить пользоваться интернетом нескольким человекам невозможно.

  12. К стати, еще по поводу п. 3. Т.к. ФС сейчас умные, журналируемые, с отложенной записью и т.д. - катаклизмы типа Reset или пропадания питания все равно могут привести к потере данных. А делать постоянный sync - это очень сильно скажется на производительности системы.

     

    Исторический вопрос пропадания данных в старгейзере никак не связан с аварийными ситуациями, такими, как резет или пропадание питания. При существующей схеме данные пропадают при штатном завершенни работы приложения по sigint. Правда, нынешняя подпорочка минимизирует эту проблему, но вовсе не устраняет. Вот в чем там проблема.

     

    А вот по поводу финансовой модели, загляни на мою страничку, там достаточно логично реализована финансовая модель. Кстати, которая соверешнно спокойно работает и со старгейзером (от которого, в основном, нужен только аторизатор ;). Я предлагал Борису много лет назад выделить финансовые функции внешнему софту, но что-то он решил, что теряется тогда весь смысл старгейзера, так ничего и не получилось. Я ни в коем случае не навязываю свою софтину, но добродушно предлагаю драть отуда идеи (что, собственно говоря, делают очень многие ;) ).

  13. 1. У тебя потери происходят только при преобразовании в целочисленную переменную. На самом деле деньги хранят в целочисленных переменных по другому поводу. А именно - для точного округления до двух знаков после запятой (чтобы не оставалось вещественного "хвоста").

     

    Вообще-то, деньги хранят в целых величинах только потому, что это целочисленные вещи. По крайней мере, мне не известно ни одной финансовой системы (бухгалтерский софт, банкинги и т.д.), где бы использовались плавающая арифметика, хотя бы потому, что в в ней закладывается практически обязательная погрешность. Мой пример вовсе не говорит о существовании проблем с потерей данных, но показывает, что они потенциально всегда существуют в системах, в которых смешивается целочисленная и плавающая арифметика.

     

    2. То что ты описал - это просто post-paid. Stargazer сейчас, фактически, работает по pre-paid-системе. Не всем удобно post-paid. И можно тут раскрыть момент про "уплывающий" трафик?

     

    Вообще-то к "пре" и "пост" паиду это не имеет никакого отношения. Финансовая модель должна быть отделена логически вообще от считалки байтов, и быть самодостаточной. Просто никто не отменял учет текушего затратного баланса с блокировочной суммой. Система совершенно аналогична работе расчетов банковскими картами - текущая аторизация затрат с блокировкий суммы и дальнейший батч (рельное списание) суммы.

     

    Про уплывающий трафик - накопление погрешностей атомарного начисления. Реально должна быть одна погрешность - меньше копейки в месяц, или где-то так. ;)

     

    3. В целом я согласен с твоей позицией. Вопросы возникают только по поводу SIGINT, но тут надо подумать, покурить маны, потестировать... В любом случае существующая система не хуже предлагаемой.

     

    Вообще-то, существующая схема хуже, так-как она реализует исчезающее изменение данных. А неисчезающая схема только одна - та, про которую я написал, и та, которая гарантируется реализацией любой OS. Именно такая схема и реализуется в разного рода системных утилитах, типа rsync или scp.

  14. 1. Мы люди необразованные, деньги до сих пор как double считаем. ;)

     

    Совершенно зря. Байты - вещи целочисленные. Рубли-копейки - тем более. Тут нет места для даблов, тем более, можно хорошо на конвертах пролететь. Для прикола, простой примерчик залета.

     

    // gcc -o aaa aaa.c ; ./aaa
    #include <stdio.h>
    #include <stdlib.h>
    #include <stdint.h>
    
    
    int main(int argc, char *argv[]) {
       int traf=70;
       double cost=.6;
       int sum;
    
       sum=traf*cost;
    
       printf("%d\n", sum);
    
       return(0);
    }
    

     

    Я Борису об этом говорил еще в те времена, когда старгейзер еще не назывался старгейзером. Зря, что он проигнорировал.

     

    2. Что есть "накопительная система рассчета"?

     

    Это значит, что в течении месяца количественные показания услуг (напр, трафик) накапливаются, а расчет происходит при закрытии месяца. В этом случае, баланс не "уплывает". Прим. уплывший баланс, по сути, обман клиента. При бориной системе расчета, взявши сумаррный месячный трафик (по категориям) и умноживши на его стоимость (так же по категориям) мы не получим сумму:, которую "снял" старгейзер. "Обман" может достигать до 15%.

     

    3. В последней версии используется rename вместо copy. И вобще, витает в воздухе идея складывать данные в BerkleyDB а уже оттудова - хоть в sql.

     

    Заглянул для любопытство. Не то. :) Ну, в принципе, rename используется, но не там, так-как не достигается главная цель - надежное неисчезающее хранение данных. Мое многолетнее взывание к Борису, все же, в ключевом моменте заключалось не в команде rename, а немного в дрогом. Правило простое - ни при каких условиях, ни в каком случае, ну просто никогда нельзя открывать файл данных на запись, ибо, это означает обнуление данных. А это означает, что если в этот момент старгейзер завершит работу, причем, нормльно, по sigint, данные пропадут (а вовсе не при повреждении файловой системы, как Борис настаивал). оэтому алгоритм работы с файлом данных очень простой. Если хотим что-то изменить в файле данных, то поступаем просто:

    1. создаем временный файл рядышком с файлом данных, в которых складываем всю информацию, включая необходимые изменения (если этот файл поломается - пофиг, он никому не нужен).

    2. Закрываем файл, и проверяем, как минимум, размер созданного файла (желательно, при создании, мониторим количество записываемой информации).

    3. Вот тут уже делаем rename временного файла на постоянный файл.

    Это и будет неисчезающее изменение файла данных. И в этом случае ему ничего не гроизт, ни ^C, ни падение, ни конец места на диске или упор в квоту, ни падение сервера.

     

    Честно говоря, я так и не доехал, почему Борис столько лет так упорно сопротивлялся в понимании такого простого алгоритма, который используют многие программы (тот же rsync).

     

    Мораль тут немоног другая. Если не хватает сил сделать элементарную работу с данными, то переход на более технологичные способы хранения в базах данных не спасет. Ибо, подход тот же :)

     

    4. Файрвол и так отдельная структура дергает.

     

    А кто эту структуру дергает? ;)

     

    Вообще, структурная путаница в старгейзере играет плохую шутку во всем этом деле. Продукт усложняется гораздо быстрее, чем растет функционал. Ну да ладно, это уже вопросы политики, тут мне посоветовать нечего. :)

  15. Не волнуйся, Борис сюда уже давно не заглядывает :rolleyes:

     

    Ну вот, нам его будет сильно не хватать? Ну раз нету, значит можно поглумиться над продуктом немного? :D Я какое-то время не наблюдал за продуктом, посему задам пару актуальных вопросов:

     

    1. Арифметику перевели уже на целчисленное исчисление, или все так же флоатами мутим?

    2. Сделали накопительную систему расчета денег за предоставленные услуги, или так и продолжается "снятие" маленькими кусочками?

     

    Вопрос про добровольное убиваение старгейзером своих файлов пропускаем. Раз уж добавили еще одно звено нестабильности - sql :D

     

    Ну и классический вопрос - не пора ли исправить изначальную логическую ловушку: т.е. разнести разные задачи в разные программные структуры - I meant учет клиентов и денег отдельно, считание байтов и дергание фаервола - отдельно?

  16. По образу и подобию можно сделать модуль для ЛЮБОЙ платежной системы, нужно только знать механизмы ее работы.

     

    Разумеется, для этого платежные системы и делают, что бы ими пользовались, и делали модули :rolleyes:

     

    Проблема, в общем-то, не совсем в модуле, как таковом. Но я не буду развивать тут эту тему и действовать на нервы Борису :D

×
×
  • Створити нове...