Re: Re: цены на CGP в России

Здравствуйте!

On Wed, Oct 12, 2005 at 12:48:57AM -0700, Vladimir A. Butenko wrote:

> Тем, что на каждый звонок будет идти HTTP запрос, а потом
> - запускаться отдельная программа (exec).
>
> >В ответ, вместо httpCall предлается helper. ЭТОТ конструктор с helper чем
> >от httpCall отличается ? ( именно от httpCall, а не от cgi - тут понятно
> >).
>
> Именно тем, что нет ни запроса, ни exec()- то есть всё быстро.

Владимир, я, конечно, предложу Вам несколько меньше, чем Вы просили за багу в cgp. Но я точно берусь продемонсрировать, что обработать http запрос даже в open source linux/perl можно и без exec() :)

> >То есть Вы не дали ответ на начальный вопрос, подменив один конструктор
> >другим просто в круге из 5 писем. Ну так не честно :) cgp же архитектутно
> >правильное решение, почему в подобном отказывается остальным с какими то
> >аргументрами про >нагрузку ? :))))))
>
> Да потому что что нормального в том, чтобы слать RADIUS - запросы?! Ну, не
> понимаю я этого. Убогий протокол, никаких стандартов - зачем? Там, где 100
> звонков в секунду - вряд ли будет стоять чья-то прилада, понимающая только
> RADIUS для биллинга.
Вы меня спрашиваете ? Я так в аналоге cgi, но более persistent, или в helper буду сразу back или direct tarifficator запустать, если будет такая возможность. Вот только сложен этот конструктор, не у всех есть такая возможность этот конструктор быстро сделать или внедрить. И соответсвенно, radius тут - некий общий знаменатель для legacy etc systems.

Вы этого правда не видите ?

> Еще раз я не сказал, что RADIUS-клиента вставлять в CG/PL в принципе
> нельзя. Туда можно напихать и TFTP тогда, и еще хрен знает что. И коннекты
> можно вообще туда всунуть, дав Вам возможность открывать TCP куда угодно,
> и делать что угодно, и просто UDP пакеты слать. Всё можно. Но это будет
> совсем конструктор. И каждый шаг в ту сторону будет сделать только после
> того, как будет доказано, что нормально сделать нельзя.

Предложенный вариант с cgi нормальный не является. Потомучто. Все иные варианты - и с httpCall и с helper - вполне нормальны, но перекладывают конструктор на клиента. Цена и тд.

> >>А при нормальном подходе оно через External CDR будет это куда угодно слать.
> >Так и httpCall будет куда угодно слать. Только принять надо не cgi, а чем
> >то более persistent, какая разница то ? :)
>
> Ну и чем оно, если более persistent хуже, чем прямая посылка в этот
> RADIUS? Тем более, насколько я помню, httpCall cоединения кэширует, так

Затрудняюсь ответить чем хуже. Помоему, мы о разных Еремах. С моей точки зрения - так персистент во всем лучше, чем not persistent.

> что все вообще быстренько пойдет. А у кого 1000 каллов в секунду - выкинут
> нафик этот РАДИУС и будут этим persistent писать прямо в заду банных.
> Потому что у них - готов поспорить на что-то мелкое - этот RADIUS сейчас
> именно в базу и пишет всё, и обращается к этой базе (спорить не буду, но
> скорее всего) через тот же HTTP.
Тут нужна "развязка", иначе получается слишком дорогое по надежности базы решение.

Нужно предусматривать ситуации, что базы вот сейчас нет ( например на 30-60 сек ), тогда все сильно дешевле. Поэтому настолько простого решения, как всегда сразу писать/дергать базу - в нормальной production платформе быть не должно.

С уважением,
  Михаил Кулаков Получено Wed Oct 12 08:01:21 2005