IOSOR Знания
Прозорци за SMPP Bind и Лимити на Сесиите
Научете как да оразмерявате и конфигурирате SMPP bind прозорци, лимити на сесиите и буфери за непотвърдени съобщения за предплатени съобщения с висок обем в платформата IOSOR.
Прозорци за SMPP Bind и Лимити на Сесиите.
Механика на SMPP прозорците срещу регулиране на пропускливостта
Размерът на SMPP bind прозореца определя максималния брой непотвърдени 'submit_sm' PDU, които даден ESME може да препредава през TCP сесия, преди да изчака отговори. За разлика от синхронните HTTP крайни точки, SMPP v3.4 позволява асинхронна обработка. Прозорец с размер 1 позволява само 1 чакащо съобщение, което създава забавяне поради мрежовото време (RTT).
Оразмеряване на binds с висок обем в предплатени счетоводни книги
Оразмеряването на SMPP пропускливостта за предплатени клиенти изисква балансиране между паралелността на сесиите и сигурността на кредитите. Всички непотвърдени PDU в отворен прозорец представляват активна резервация на кредит. Ако даден акаунт изпраща 100 SMS в секунда през прозорец от 200 на 5 свързани канала, 1 000 заявки влизат в системата едновременно.
Конфигуриране на лимити за TRX, TX и RX сесии в IOSOR
В маршрутизиращия модул на IOSOR администраторите конфигурират връзките с изрични типове сесии и ограничение на пропускливостта. TX и RX свързванията разделят изходящото изпращане от входящото получаване на DLR, докато TRX управлява двупосочния поток. В конзолата присвоете лимити на скоростта (TPS) за всеки акаунт и поставете твърди тавани за размера на прозорците (обикновено 10 до 50 за стандартни акаунти, до 100 за висок обем).
Намаляване на десинхронизацията на сметките и буферния разход
Големите лимити на прозорците въвеждат забавяне в буфера между получаването на съобщението и удържането на сумата. Ако изпълнението на 'submit_sm_resp' се забави от фонови опашки, непотвърдените рамки остават в буфера. Ако балансът на клиента се изчерпи по време на пик, системата задейства ограничаване: активните връзки спират да приемат нови 'submit_sm' PDU и връщат статус 'ESME_RTHROTTLED'.
Архитектурни топологии и интеграция на протоколи
Свързани материали: Балансиране на лимитите за едновременност и пропускателна способност на IOSOR… · Балансиране на пакетирането на полезния товар и пропускателната способност пр… · SIP Digest удостоверяване и правила за задържане на баланс за предоплатено гл….
Започнете с IOSOR
Отворете конзолата за маршрутизация на IOSOR и задайте изрични ограничения на TPS за всяка сесия, заедно с ограничени дължини на прозорците за всички TRX и TX връзки. Съгласувайте задържането на кредитни резервации със скоростта на синхронизиране на вашата счетоводна книга, така че непотвърдените submit_sm кадри да не надвишават предплатените баланси по време на пикови обеми. Конфигурирайте автоматизирани портове за ограничаване на прозорците, за да паузирате входящия трафик, когато балансите по портфейлите на наемателите наближат критични прагове.
Обобщение IOSOR
Високообемната SMPP пропускателна способност изисква съгласуване на асинхронните механизми за прозорци със строго счетоводно отчитане в реално време. Осигуряването на големи размери на прозорците без отчитане на буферите за непотвърдени кадри излага предплатените сметки на сериозни кредитни превишения, докато прекалено малките прозорци лишават от ресурс пропускателната способност през свързаните канали.
Задайте изрични лимити на прозорците и сдвоете ограниченията на скоростта на TPS с логика за кредитна резервация в конзолата на IOSOR, преди да одобрявате високоскоростни връзки. Не предоставяйте неограничена сесийна едновременност или дълги PDU конвейери на предплатени сметки без активни порти за синхронизация на счетоводната книга.
Полезно ли беше ръководството?
Свързани ръководства
- SMPP Binds срещу REST API ключове
Сравнете SMPP сесиите и REST API ключовете в IOSOR. Научете механиката на плъзгащите се прозорци, работните процеси за ротация на ключове и управлението на удостоверения в Разработчици.
- SMPP enquire_link грешките не се доставят като трафик
Научете как мъртвите SMPP сесии и неотговорените enquire_link пингове се обработват в IOSOR за предотвратяване на фалшиви DLR и грешни дебити.