Hello! Sanajan utusan lan jaringan sosial ngganti cara komunikasi tradisional saben dina, iki ora nyuda popularitas SMS. Verifikasi ing situs populer, utawa kabar saka transaksi bola, padha manggon lan bakal urip. Apa sampeyan tau kepingin weruh carane iku kabeh bisa? Asring banget, protokol SMPP digunakake kanggo ngirim pesen massal, sing bakal dibahas ing ngisor iki.
Habré wis duwe artikel babagan smpp, ,, nanging tujuane ora kanggo njlèntrèhaké protokol kasebut. Mesthi, sampeyan bisa langsung miwiti saka sumber - , nanging aku rumangsa apik yen ana ringkesan isine. Aku bakal nerangake nggunakake v3.4 minangka conto. Aku bungah kanggo kritik obyektif.
Protokol SMPP minangka protokol olahpesen peer-to-peer. Iki tegese saben server peer / hub padha. Ing kasus sing paling gampang, skema olahpesen SMS katon kaya iki:
Nanging, yen operator nasional ora duwe rute, takon perantara kanggo sawetara wilayah remot - hub SMS. Kadhangkala, kanggo ngirim siji SMS, sampeyan kudu nggawe rantai antarane sawetara negara, utawa malah bawana.
Babagan protokol
SMPP minangka protokol lapisan aplikasi sing adhedhasar ijol-ijolan PDU lan ditularake liwat TCP / IP, utawa sesi X25 kanggo ngirim pesen sms lan ussd. Biasane, SMPP digunakake ing mode sambungan terus-terusan, sing ngirit wektu. SMPP nggunakake model komunikasi klien-server.
Mode komunikasi
Ijol-ijolan pesen antarane pangirim lan pusat SMS liwat SMPP bisa ditindakake kanthi mode ing ngisor iki:
Transmitter (pemancar) - transmisi pesen ing siji arah, ing siji
Panrima (panrima) - mung nampa pesen saka pusat SMS.
Transreceiver (transceiver) - ijol-ijolan pesen antarane pusat SMS lan pangguna
struktur
Dawane pesen
Siji pesen SMS bisa ngemot 70 karakter nalika ngetik Cyrillic lan ora luwih saka 157 karakter Latin + 3 UDH Yen sampeyan ngirim SMS kanthi akeh karakter, bakal dipΓ©rang dadi sawetara segmen lan digabungake ing piranti panampa. Ing kasus segmentasi, jumlah karakter dikurangi dening header pesen, sing nuduhake bagean pesen. Mula, nalika ngirim pesen SMS gedhe, maksimal 153 karakter Latin utawa 67 karakter non-khas.
Skema Pengkodean Data
Nanging, karakter kudu dienkode kanggo ngirim pesen. Ing protokol SMPP, lapangan khusus tanggung jawab kanggo enkoding - Skema Coding Data, utawa DCS. Iki minangka lapangan sing nemtokake carane pesen kudu diakoni. Kajaba iku, lapangan DCS kalebu:
- set karakter sing nemtokake enkoding;
- kelas pesen;
- njaluk pambusakan otomatis sawise maca;
- indikasi kompresi pesen;
- basa pesen siaran;
Alfabet 7-bit standar (GSM 03.38). Iki dikembangake kanggo sistem olahpesen ing GSM. Encoding iki cocok kanggo basa Inggris lan sawetara basa Latin. Saben karakter kasusun saka 7 bit lan dienkode dadi oktet.
UTF-16 (ing GSM UCS2) Kanggo nyakup karakter sing ilang ing alfabet 7-bit, enkoding UTF-16 dikembangake, sing nambah karakter tambahan (kalebu Cyrillic) kanthi nyuda ukuran pesen saka 160 dadi 70, jinis enkoding iki. meh rampung mbaleni Unicode.
8-dicokot data pangguna ditetepake. Iki kalebu KOI8-R lan Windows-1251. Senajan solusi iki misale jek dadi luwih ekonomi dibandhingake UTF-16 padha. Ana pitakonan cukup kompatibilitas ing piranti beda. Wiwit ing kasus iki, piranti loro kasebut kudu dikonfigurasi luwih dhisik.
Kelas pesen
- Class0, utawa lampu kilat, pesen sing disimpen ing memori telpon kanthi panjaluk pangguna;
- Class1, utawa sing disimpen ing memori telpon;
- Class1, utawa sing disimpen ing memori telpon;
- Class2, kudu mesthekake yen pesen kasebut disimpen ing memori terminal seluler, yen ora kudu menehi kabar menyang pusat SMS babagan impossibility nyimpen;
- Class3 - ing kasus iki, telpon kudu ngirim kabar yen pesen bisa disimpen, preduli saka jumlah memori ing piranti. Pesen jinis iki nuduhake manawa pesen wis tekan tujuane;
Jinis pesen
Pesen bisu (SMS0) jinis pesen SMS tanpa isi. SMS kasebut teka tanpa kabar lan ora ditampilake ing layar piranti.
PDU
Saben operasi pdu dipasangake lan kalebu panyuwunan lan tanggapan. Contone: printah sing nyatakake sambungan wis digawe (bind_transmitter / bind_transmitter_resp), utawa pesen wis dikirim (deliver_sm / deliver_sm_resp)
Saben paket pdu dumadi saka rong bagean - header (header) lan awak (body). Struktur header padha kanggo paket pdu: dawa printah dawa paket, id jeneng paket, lan printah status nuduhake yen pesen wis kasil utawa gagal.
Paramèter TLV tambahan
TLV (Tag Length Value), utawa kolom tambahan. Parameter kasebut digunakake kanggo nggedhekake fungsi protokol lan ora dibutuhake. Kolom iki katon ing mburi lapangan pdu. Contone, nggunakake TLV dest_addr_np_information, sampeyan bisa ngatur transmisi informasi babagan portabilitas nomer.
Ton lan Npi
Parameter TON (Type of Number) ngandhani SMSC babagan format alamat lan jinis jaringan.
Parameter NPI (Numbering Plan Identification) sing nuduhake rencana penomoran.
Alamat sumber pesen, utawa jeneng alpha
Pesen sing dikirim menyang telpon ana rong jinis: numerik lan alfabet. Nomer bisa dawa (padha karo nomer telpon) utawa cendhak. Kadhangkala operator duwe watesan kanggo ngirim saka jeneng netral, kayata Infosms, Lansiran lsp. Kadhangkala operator ora ngidini lalu lintas yen jeneng kasebut ora didaftar ing jaringan. Nanging, iki luwih saka fitur operator.
Tahapan pengajuan
SMS-SUBMIT ngirim pesen MO FSM (pesen singkat saka terminal seluler)
SMS-SUBMIT LAPORAN - konfirmasi yen pesen kasebut dikirim dening SMSC
SRI SM (SendRoutingInfo) - SMSC nampa informasi saka HLR babagan lokasi MSC/VLR saka pelanggan
SRI SM RESP - respon saka HLR babagan daging posisi pelanggan
MT-FSM - sawise nampa lokasi, pesen dikirim nggunakake operasi "Forward Short Message".
MT-FSM-ACK - respon saka SMSC yen pesen wis dikirim
LAPORAN STATUS SMS β SMSC ngirim status pangiriman pesen.
Status pangiriman pesen
LAPORAN STATUS SMS bisa njupuk sawetara nilai:
DELIVRD pesen kasil dikirim
TOLAK β pesen ditolak dening pusat SMS
GAMPANG - pesen dibusak saka antrian kirim sawise mburi TTL (urip pesen)
UNDELIV - kasus non-pangiriman liyane
UNKNOWN- Ora ana respon sing ditampa.
Kasalahan transmisi
Kadhangkala alesan kanggo pesen SMS ora dikirim menyang pelanggan. Akibat saka alasan kasebut yaiku kedadeyan kesalahan. Kasalahan bali ing PDUs_sms_resp. Kabeh kesalahan bisa dipΓ©rang dadi sak wentoro (Sauntara) lan permanen (Permanent).
Contone, absent_subscriber sementara, pelanggan ora kasedhiya utawa ora online, lan permanen - pelanggan ora ana. Gumantung saka kesalahan sing kedadeyan, kabijakan kanggo ngirim maneh pesen kasebut dibentuk.
Contone, yen pelanggan sibuk ngomong lan nampa handset MT minangka kesalahan sibuk, pesen bisa resent sawise sawetara menit, Nanging, yen pelanggan wis diblokir layanan nampa pesen, ngirim maneh ora bakal nggawe raos. Sampeyan bisa nemokake dhaptar kasalahan ing kaca SMSC, contone, minangka .
Source: www.habr.com