RP
Не прийти оно может только если вы потеряете коннект с ами, либо проблемы используемой либы
Size: a a a
2020 April 13
OS
делайте как хотите )
OS
вы можете потерять коннект, вы можете криво считать событие, потому что события прилетают блоками (и много нюансов в реализации), вы можете криво хранить
OS
делайте как считаете правильным
RP
вы можете потерять коннект, вы можете криво считать событие, потому что события прилетают блоками (и много нюансов в реализации), вы можете криво хранить
Не, это не про меня, точно
OS
отлично
OS
а чем sip subscribe хуже вашего метода?
RP
Мы его не обсуждали)
OS
да, но если мы говорим о правильности, нам нужно рассмотреть все варианты
OS
тот метод конечно деревянный как валенок, но он надежный и простой
RP
тот метод конечно деревянный как валенок, но он надежный и простой
У того метода явные минусы
1. Точность доступности абонента ограничено частотой выполнения командой
2. Чем больше абонов и чем больше запросов тем больше нагрузка.
3. Нет смысла запрашивать статус 1000 абонов если измениния только у одного и астер об этом сам сообщит нужным событием.
1. Точность доступности абонента ограничено частотой выполнения командой
2. Чем больше абонов и чем больше запросов тем больше нагрузка.
3. Нет смысла запрашивать статус 1000 абонов если измениния только у одного и астер об этом сам сообщит нужным событием.
OS
да, согласен
OS
это все верно
OS
но у вашего метода тоже масса своих недостатков
OS
вы на чем реализуете?
RP
python + асинхронная либа под AMI
OS
ами передает данные стримом, и разработчик должен уметь делить данные на события
OS
это не тривиальная задача
OS
плюс выше уровень подготовки - больше времени на тестирование, сложнее отладка
RP
ами передает данные стримом, и разработчик должен уметь делить данные на события
есть куча библиотек под разные языки, уже все придумано и сделано