Jump to content
Калькуляторы

vop

VIP
  • Content Count

    1528
  • Joined

  • Last visited

1 Follower

About vop

  • Rank
    Доцент

Контакты

  • Сайт
    http://topola.unity.net/
  • ICQ
    0

Информация

  • Пол
    Не определился

Recent Profile Visitors

2532 profile views
  1. Недостаточно просто выбрать целочисленную арифметику для учета целочисленных величин. Надо еще и разрабатывать схему расчетов, которая не теряет набегающие/убегающие "копейки". Сложного тут вообще ничего нет.
  2. Такое есть в очень многих биллингах из-за идеологической ошибки просчитывать целочисленные величины (копейки, минуты, байты) не целочисленной арифметикой (плаваающей).
  3. Глупый вопрос, а sqlippool подключен в mods-enabled?
  4. При изменении баланса услуги и прочего биллинг изменяет статус (в переводе означает "состояние" :) ) предоставляемой услуги. А там "обработчик" или кто у вас может быть - это уже детали реализации разной степени надежности и логичности. Железобетонно одно - в любой случайный момент у каждого ресурса должен быть известный статус, а сервисный агент, при наличии биллинга либо без его, должен этот статус отслеживать, изменять его, и восстанавливать, в случае чего. Во многих популярных биллингах с обработчикам, почему-то, этого не делается.
  5. Вообще, биллинг должен не просто начислять деньги. Он должен обладать набором инструментов, помогающим провайдеру строить свой бизнес, включающем гибкий набор вариантов тарификации, акции, бонусы, платежные системы, условные виды начислений и т.д. (дофига что есть в наличии) Я уже не вспоминаю про кабинет администратора, но некоторые считают, что это именно биллинг и есть.:) Совершенно отдельная задача - кабинет клиента. Его функция - отображать необходимые клиенту данные, которые выбирает по своим нуждам провайдер, и прием от клиента разрешенных управляющих заданий (типа, поменять тариф, заказать отпуск, использовать бонусы и т.д). Следующая задача - управление услугами. Это разумно поручать совершенно самостоятельному блоку программ (сервисный агент), который умеет получать статусную информацию из биллинга по подключенным услугам, и управлять услугами, исходя из из особенностей оборудования. Ну и в конце концов необходима система электронного делопроисзводства, в которую входит система управления персоналом, заявки, наряды, договора, ну и всё остальное кабаре, напрямую не связанное со спецификой бизнеса. Наличие унифицированных API между этими модулями заметно изменили бы рынок биллинговых систем, на котором могли бы появится и независимые разработчики того же личного кабинета. PS Я пользуюсь услугами 6-ти провайдеров и 4-х хостеров. У всех свои кабинеты. Уже в печенках сидит этот зоопарк разнобойных и недоделанных личных кабинетов. Хочу иметь все в одном месте. Не можете сделать кабинет - дайте API, буду сам все в комплексе смотреть. Или закажу унифицированный кабинет своему любимому веб-программисту.
  6. В это основная проблема практически всех биллингов. Кабинет клиента должны делать рабработчики, которые в этом разбираются. Не в настройках свичей, а в обслуживании клиентов. :)
  7. Лет 20 назад были придуманы примитивные пинговалки. https://www.nag.ru/articles/reviews/15745/opisanie-protokola-snmp-avtomaticheskaya-pingovalka-.html
  8. Carrier Grade NAT IPv6

    "обычно", и "как минимум" - то разные предложения про разные варианты. Там еще 3-й вариант был - /48. :)
  9. Carrier Grade NAT IPv6

    Как я понял, то вся идея этого ipv6 в том, что бы роутеры, у которых одна задача - роутить трафик на соседние ноды, а не лазить в интернет, работали по линк-локал адресам. Заодно получается пассивная защита от внешних хакеров не хуже ната в v4. Поэтому там адреса как бы вообще не нужны, все и без них работает автоматически без особых настроек. А внешние адреса нужны только тем устройствам, которым нужен выход в сеть. Ну обычно не меньше /60. Считается, что у обычного клиента как минимум 3 сетки - 2 проводные и одна wifi. Или 2 wifi и одна проводная. Поэтому, как минимум, 4 префикса на клиента не плохо бы давать ему для slaac его домашних кофеварок. Мне дали /48. :)
  10. Carrier Grade NAT IPv6

    Да, хотел еще подсказать. Клиентский девайс принимает RA, пришедшего от линк-локал адреса, и настраивает у себя дефолтный роутинг на этот линк-локал адрес. Он даже не знает, есть ли реальный адрес на интерфейсе у гейтвея, и какой это адрес. В больинстве лупошим дефолт-роутинг на fe80::1 :) Вроде ничег оне перепутал.
  11. Carrier Grade NAT IPv6

    Ну как бы вipv6 именно это и сделано. :) Делегируем префикc клиентскому роутеру (а он роутер уже с этого момента). Убрали dhcp по mac адресу, придумали интерфейс-независимый duid в v6. Для того, что бы не заморачиваться с mac-адресами, а работать в той же pv6 парадигме, делаем link-local addressing. Один фиг в ether они генерируются на основе mac (lladdr почти во всех вредах имеют свои правила генерации). И спокойно роутим на этот клиентский роутер делегированный ему префикс. По хорошему, клиенсткий роутер может через свой RA рассказать всем в сегменте (включая дефолтному(-ным) роутеру(-ам), что бы его префикс отдавали ему, но по умолчанию эта фишка везде отключена, и по умолчанию системы принимают только дефолтный роутинг (accept_rs_rt_*_plen). В принципе, если туда записать нужный prefixlen, оно анонсится нормально. Просто надо помнить, что в ipv6 все же хосты отличаются своими роялми - кто роутер, кто просто поинт.
  12. Carrier Grade NAT IPv6

    Так там же есть делегированная сеть на клиента, которую ему отдали по dhcpv6 на его duid (или карандашиком на бумажке - не важно), и реальный адрес у него уже стоит на внутреннем интерфесе (если говорить условно). Зачем такому клиентскому роутеру еще и /128 давать то? Это атавизм из мира ipv4, не? :)
  13. Carrier Grade NAT IPv6

    Если делегировать клиентам сетки, то на доступе там вообще не нужны реальные адреса. Или раздавать по dhcpv6. Или на бумажке писать... карандашиком. :)
  14. У меня провайдер так настроил полисер, что каждый второй ssh заканчивается, не начавшись: ssh_exchange_identification: Connection closed by remote host
  15. Уже давно писал, что время создания унифицированного кабинета клиента провайдера давно наступило. Ибо сложно заниматься одновременно несколькими делами хорошо. Но пока не нашлось таких добрых людей. А был бы хороший кабинет с открытым API, биллнгбилдеры уже давно бы поприделывали бы в свои биллинг эти API, Было полно юных и жарких писателей разны ифнормеров. И информеры, вроде бы, не плохие. Но проблема в том, что они не общались в торговцами услуг.