IOSOR

IOSOR ความรู้

ข้อจำกัดเซสชันและ Bind Window ของ SMPP

เรียนรู้วิธีการกำหนดค่า SMPP bind window ข้อจำกัดเซสชัน และบัฟเฟอร์ข้อความที่ยังไม่ได้ยืนยันสำหรับปริมาณข้อความแบบเติมเงินบนแพลตฟอร์ม IOSOR

ข้อจำกัดเซสชันและ Bind Window ของ SMPP.

กลไก SMPP Windowing กับการจัดระเบียบอัตรา Throughput

ขนาด SMPP bind window กำหนดจำนวน PDU 'submit_sm' ที่ยังไม่ได้รับการยืนยันสูงสุดที่ ESME สามารถส่งผ่านเซสชัน TCP ก่อนที่จะรอการตอบกลับ ต่างจาก HTTP endpoints แบบซิงโครนัส SMPP v3.4 อนุญาตให้ทำ pipelining แบบอะซิงโครนัสได้ ขนาด window เท่ากับ 1 จะอนุญาตให้มีข้อความค้างอยู่ได้เพียง 1 ข้อความ ซึ่งถูกจำกัดโดยความล่าช้าของเครือข่าย ขนาด window เท่ากับ 50 อนุญาตให้มีเฟรมที่ยังไม่อยู่ในสถานะยืนยันได้ถึง 50 เฟรมพร้อมกัน

การเสนอราคา Bind ปริมาณสูงบนบัญชีแยกประเภทแบบเติมเงิน

การเสนอราคาผ่าน SMPP สำหรับลูกค้าแบบเติมเงินต้องรักษาสมดุลระหว่างการทำงานพร้อมกันของเซสชันและความปลอดภัยของยอดเงินในบัญชีแยกประเภท ทุก PDU ที่ยังไม่ได้ยืนยันใน window จะแทนการสำรองเครดิตที่ใช้งานอยู่ หากผู้ใช้นำส่ง 100 SMS ต่อวินาทีผ่าน window ขนาด 200 ใน 5 ช่องทาง มีคำขอ 1,000 รายการเข้าสู่พายไลน์พร้อมกัน บนบัญชีแยกประเภทแบบเติมเงิน แพลตฟอร์มต้องอายัดเงินก่อนที่จะยืนยันการรับเฟรมผ่าน 'submit_sm_resp'

การกำหนดขีดจำกัดเซสชัน TRX, TX และ RX ใน IOSOR

ภายในเอนจินการกำหนดเส้นทางของ IOSOR ผู้ดูแลระบบสามารถกำหนดค่าการเชื่อมโยงเซสชันตามประเภทเซสชันและการจำกัดอัตรา throughput การเชื่อมโยงแบบ TX และ RX จะแยกการส่งออกออกจากรับรายงาน DLR ในขณะที่ TRX จะจัดการการไหลของเฟรมแบบสองทิศทาง ในคอนโซล IOSOR สามารถกำหนด ตัวจำกัดอัตรา (TPS) เฉพาะสำหรับแต่ละบัญชี และตั้งค่าเพดานสูงสุดสำหรับขนาด window (โดยปกติอยู่ที่ 10 ถึง 50 สำหรับบัญชีมาตรฐาน และสูงสุด 100 สำหรับปริมาณการรับส่งข้อมูลสูง)

การลดการสูญเสียการซิงค์ของบัญชีแยกประเภทและภาระบัฟเฟอร์

ขีดจำกัด window ที่สูงจะทำให้เกิดความล่าช้าของบัฟเฟอร์ระหว่างการรับข้อความและการหักยอดเงิน หากการประมวลผล 'submit_sm_resp' ล่าช้า เฟรมที่ยังไม่ได้ยืนยันจะยังคงอยู่ในบัฟเฟอร์ หากกระเป๋าเงินของลูกค้าหมดลงระหว่างการส่งข้อมูล ระบบจะเปิดใช้งานการจำกัด window การเชื่อมโยงที่ใช้งานอยู่จะหยุดรับ PDU 'submit_sm' ใหม่ และส่งคืนสถานะคำสั่ง 'ESME_RTHROTTLED'

โทโพโลยีสถาปัตยกรรมและการรวมโปรโตคอล

บทความที่เกี่ยวข้อง: การสร้างสมดุลระหว่างขีดจำกัด Concurrency ของ API และ Throughput ของเครือข่าย · การสร้างสมดุลระหว่างการจัดกลุ่มชุดข้อมูลและปริมาณงาน API คำขอเดี่ยว · การตรวจสอบสิทธิ์ SIP Digest และกฎการกันยอดเงินสำหรับการกำหนดเส้นทางเสียงเติมเงิน.

เริ่มต้นกับ IOSOR

เปิดคอนโซลการกำหนดเส้นทาง IOSOR แล้วตั้งค่าขีดจำกัด TPS แยกตามเซสชัน รวมถึงกำหนดความลึกของหน้าต่างการส่งสำหรับทุกการเชื่อมต่อ TRX และ TX พร้อมทั้งปรับระยะเวลาจองเครดิตให้สอดคล้องกับความเร็วในการซิงค์บัญชีแยกประเภท เพื่อป้องกันไม่ให้เฟรม submit_sm ที่ยังไม่ได้รับการยืนยันเกินยอดเงินที่ชำระไว้ล่วงหน้าในช่วงที่มีปริมาณรับส่งข้อมูลสูง นอกจากนี้ ควรตั้งค่าระบบควบคุมหน้าต่างแบบอัตโนมัติเพื่อหยุดการรับส่งข้อมูลขาเข้าชั่วคราวเมื่อยอดเงินในกระเป๋าเงินของลูกค้าใกล้ถึงขีดจำกัดวิกฤต

สรุป IOSOR

ปริมาณการส่งข้อความ SMPP จำนวนมากจำเป็นต้องอาศัยการประสานกลไกการเปิดหน้าต่างรับส่งข้อมูลแบบอะซิงโครนัสเข้ากับการบัญชีแบบเรียลไทม์ที่เข้มงวด การกำหนดขนาดหน้าต่างขนาดใหญ่โดยไม่คำนึงถึงบัฟเฟอร์เฟรมที่ยังไม่ได้รับการยืนยันจะทำให้บัญชีที่ชำระเงินล่วงหน้ามีความเสี่ยงต่อการใช้เครดิตเกินวงเงินอย่างรุนแรง ในขณะที่หน้าต่างที่มีขนาดเล็กเกินไปจะทำให้ช่องทางการเชื่อมส่งข้อมูลไม่มีประสิทธิภาพ

โปรดกำหนดขีดจำกัดหน้าต่างที่ชัดเจนและจับคู่ระบบจำกัดอัตรา TPS เข้ากับตรรกะการจองเครดิตในคอนโซล IOSOR ก่อนอนุมัติการเชื่อมต่อความเร็วสูง ห้ามอนุญาตให้มีการทำงานพร้อมกันของเซสชันแบบไม่จำกัดหรือท่อส่ง PDU ที่ลึกสำหรับบัญชีที่ชำระเงินล่วงหน้าโดยไม่มีระบบควบคุมการซิงค์บัญชีแยกประเภทที่ใช้งานอยู่

คู่มือนี้มีประโยชน์ไหม?

คู่มือที่เกี่ยวข้อง