Добавление префикса конечно упрощает ситуацию, но проблема с синхронизацией базы остается. Нельзя ли действительно использовать dns? К примеру каждому оператору выдать свою зону вида prefix.npdb.ru и он туда фигачит записи number.prefix.npdb.ru TXT "operator". С одной стороны это породит меньше проблем, с другой стороны больше. Но это всяко лучше централизованной базы, опять же учитывая что миграция происходит достаточно редко кеширование в 3 часа вполне себе приемлемо.
То что ENUM существует я знаю :) Тут больше вопрос можно ли это употребить для целей биллинга.
А чем DNS концептуально от централизованной базы то отличается? Кроме того, что здесь 3 запроса может понадобиться
Тем что во первых децентрализован, во вторых меньше головняком с обеспечением безопасности. У каждого есть своя база мигрантов которые используют их номерную емкость и они их туда добавляют. В случае централизованной базы надо будет решать проблему доступа на запись и разграничения доступа. Ну и в случае DNS содержимое кешируется локальным сервером, как результат уменьшение задержки и меньшее влияние на упала у кого-то база как нам быть.
Чем же это он децентрализован? Он жестко иерархичен. И если недоступен сервер зоны .com, то все, что под ним для вас будет недоступно после expiration. Проблема разграничения прав на запись решается установкой слоя бизнес-логики на стороне центральной базы, которая принимает только один запрос типа "Оператор А принял абонента ххх от оператора Б". Она (логика) может еще и, например, подтверждать, что оператор Б готов отдать абонента.
По поводу "своей базы". А как например, оператору А определить для целей биллинга из базы "только своих мигрантов" что номер, принадлежащий оператору B мигрировал к оператору C? Тут придется или не запариваться этим (скажем, имея тарифы без дифференциации по конкретной сети) совсем или решать вопрос с обменом информацией в реальном времени (для PrP).
Comments 16
Reply
2) А чем DNS концептуально от централизованной базы то отличается? Кроме того, что здесь 3 запроса может понадобиться сделать?
Reply
Это ENUM называется
То что ENUM существует я знаю :) Тут больше вопрос можно ли это употребить для целей биллинга.
А чем DNS концептуально от централизованной базы то отличается? Кроме того, что здесь 3 запроса может понадобиться
Тем что во первых децентрализован, во вторых меньше головняком с обеспечением безопасности. У каждого есть своя база мигрантов которые используют их номерную емкость и они их туда добавляют. В случае централизованной базы надо будет решать проблему доступа на запись и разграничения доступа. Ну и в случае DNS содержимое кешируется локальным сервером, как результат уменьшение задержки и меньшее влияние на упала у кого-то база как нам быть.
Reply
Проблема разграничения прав на запись решается установкой слоя бизнес-логики на стороне центральной базы, которая принимает только один запрос типа "Оператор А принял абонента ххх от оператора Б". Она (логика) может еще и, например, подтверждать, что оператор Б готов отдать абонента.
По поводу "своей базы". А как например, оператору А определить для целей биллинга из базы "только своих мигрантов" что номер, принадлежащий оператору B мигрировал к оператору C?
Тут придется или не запариваться этим (скажем, имея тарифы без дифференциации по конкретной сети) совсем или решать вопрос с обменом информацией в реальном времени (для PrP).
Reply
Leave a comment