SMPP - Maikling Mensahe Peer-to-Peer Protocol

Kamusta! Bagaman pinapalitan ng mga mensahero at mga social network ang mga tradisyonal na pamamaraan ng komunikasyon araw-araw, hindi ito nakakabawas sa katanyagan ng SMS. Ang pag-verify sa isang sikat na site, o ang notification ng isang transaksyon ay paulit-ulit, sila ay nabubuhay at mabubuhay. Naisip mo na ba kung paano gumagana ang lahat? Kadalasan, ang SMPP protocol ay ginagamit upang magpadala ng mga mass message, na tatalakayin sa ibaba.

Nagkaroon na ng mga artikulo sa HabrΓ© tungkol sa smpp, 1,2, ngunit ang kanilang layunin ay hindi upang ilarawan ang protocol mismo. Siyempre, maaari kang magsimula kaagad mula sa orihinal na pinagmulan - mga pagtutukoy, ngunit sa tingin ko ay magiging maganda kung mayroong maikling buod nito. Ipapaliwanag ko gamit ang v3.4 bilang isang halimbawa. Ako ay natutuwa para sa iyong layunin na pagpuna.

Ang SMPP protocol ay isang peer-to-peer messaging protocol. Nangangahulugan ito na ang bawat peer/hub server ay may pantay na karapatan. Sa pinakasimpleng kaso, ganito ang hitsura ng scheme ng pagmemensahe ng SMS:

SMPP - Maikling Mensahe Peer-to-Peer Protocol

Gayunpaman, kung ang pambansang operator ay walang ruta sa ilang liblib na rehiyon, humihingi siya ng isang tagapamagitan para dito - isang SMS hub. Minsan, upang magpadala ng isang SMS, kailangan mong bumuo ng isang chain sa pagitan ng ilang mga bansa, o kahit na mga kontinente.

Tungkol sa protocol

Ang SMPP ay isang application layer protocol na nakabatay sa PDU exchange at ipinapadala sa TCP / IP, o mga X25 session para sa pagpapadala ng mga mensahe ng SMS at ussd. Kadalasan, ginagamit ang SMPP sa persistent mode, na nakakatulong na makatipid ng oras. Gumagamit ang SMPP ng modelo ng komunikasyon ng client-server.

Mode ng komunikasyon

SMPP - Maikling Mensahe Peer-to-Peer Protocol

Ang pagpapalitan ng mga mensahe sa pagitan ng nagpadala at ng SMS center sa pamamagitan ng SMPP ay maaaring isagawa sa mga sumusunod na mode:

Transmitter (transmitter) - pagpapadala ng mensahe sa isang direksyon, paisa-isa
Receiver - nakakatanggap lamang ng mensahe mula sa SMS center.
Transreceiver (transceiver) - Pagpapalitan ng mga mensahe sa pagitan ng SMS center at ng user

Kaayusan

SMPP - Maikling Mensahe Peer-to-Peer Protocol

Haba ng mensahe

Ang isang SMS na mensahe ay maaaring maglaman ng 70 character kapag nagta-type sa Cyrillic at hindi hihigit sa 157 Latin character + 3 UDH Kung magpadala ka ng SMS na may malaking bilang ng mga character, mahahati ito sa ilang mga segment at pagsasama-samahin sa receiving device. Sa kaso ng segmentation, ang bilang ng mga character ay binabawasan ng mga header ng mensahe, na nagpapahiwatig ng bahagi ng mensahe. Samakatuwid, kapag nagpapadala ng malaking SMS na mensahe, naglalaman ito ng maximum na 153 Latin na character o 67 hindi tipikal na character.

Data Coding Scheme

Gayunpaman, ang mga simbolo ay nangangailangan ng pag-encode upang maihatid ang isang mensahe. Sa SMPP protocol, isang espesyal na field ang responsable para sa pag-encode - Data Coding Scheme, o DCS. Ito ay isang field na tumutukoy kung paano dapat makilala ang mga mensahe. Bilang karagdagan, kasama sa field ng DCS ang:

  • ang set ng character na tumutukoy sa pag-encode;
  • klase ng mensahe;
  • kahilingan para sa awtomatikong pagtanggal pagkatapos basahin;
  • indikasyon ng pag-compress ng mensahe;
  • wika ng broadcast message;

Karaniwang 7-bit na alpabeto (GSM 03.38). Ito ay binuo para sa GSM messaging system. Ang pag-encode na ito ay angkop para sa Ingles at isang bilang ng mga wikang Latin. Ang bawat karakter ay binubuo ng 7 bits at naka-encode sa isang octet.

UTF-16 (sa GSM UCS2) Upang maisama ang mga nawawalang character sa 7-bit na alpabeto, binuo ang UTF-16 encoding, na nagdaragdag ng mga karagdagang character (kabilang ang Cyrillic) sa pamamagitan ng pagbabawas ng laki ng mensahe mula 160 hanggang 70; ang ganitong uri ng pag-encode ay halos ganap na kinokopya ang Unicode.

8-bit na data na tinukoy ng gumagamit. Kabilang dito ang KOI8-R at Windows-1251. Kahit na ang solusyon na ito ay tila mas matipid kumpara sa parehong UTF-16. Ang isang makatwirang tanong ay lumitaw tungkol sa pagiging tugma sa iba't ibang mga device. Dahil sa kasong ito, ang parehong mga aparato ay dapat na i-configure nang maaga.

Klase ng mensahe

  • Class0, o flash, na mensahe na nakaimbak sa memorya ng telepono sa pagpapasya ng user;
  • Class1, o ang mga nakaimbak sa memorya ng telepono;
  • Class1, o ang mga nakaimbak sa memorya ng telepono;
  • Dapat tiyakin ng Class2 na ang mensahe ay nai-save sa memorya ng mobile terminal, kung hindi, dapat itong alertuhan ang SMS center tungkol sa imposibilidad ng pag-save;
  • Class3 - sa kasong ito, ang telepono ay dapat magpadala ng isang abiso na ang mensahe ay maaaring maimbak, anuman ang dami ng memorya sa device. Ang ganitong uri ng mensahe ay nagpapahiwatig na ang mensahe ay nakarating sa tatanggap;

Uri ng Mensahe

Silent message (SMS0) Uri ng SMS message na walang nilalaman. Dumarating ang SMS na ito nang walang abiso at hindi ipinapakita sa screen ng device.

Mga PDU

Ang bawat pdu operation ay ipinares at binubuo ng isang kahilingan at isang tugon. Halimbawa: isang utos na nagsasabing ang isang koneksyon ay naitatag (bind_transmitter / bind_transmitter_resp), o na ang isang mensahe ay naipadala na (deliver_sm / deliver_sm_resp)

SMPP - Maikling Mensahe Peer-to-Peer Protocol

Ang bawat pdu packet ay binubuo ng dalawang bahagi - isang header at isang katawan. Ang istraktura ng header ay pareho para sa anumang pdu packet: ang haba ng command ay ang haba ng packet, ang id ay ang pangalan ng packet, at ang status command ay nagpapahiwatig kung matagumpay na naipadala ang mensahe o may error.

Mga karagdagang parameter ng TLV

TLV (Tag Length Value), o mga karagdagang field. Ang ganitong mga parameter ay ginagamit upang palawakin ang pag-andar ng protocol at hindi kinakailangan. Lumilitaw ang field na ito sa dulo ng field ng pdu. Bilang halimbawa, gamit ang TLV dest_addr_np_information, maaari mong ayusin ang paghahatid ng impormasyon tungkol sa portability ng isang numero.

Ton at Npi

Ang parameter ng TON (Type of Number) ay nagpapaalam sa SMSC tungkol sa format ng addressing at uri ng network.
Parameter ng NPI (Numbering Plan Identification) na nagsasaad ng numbering plan.

SMPP - Maikling Mensahe Peer-to-Peer Protocol

Address ng pinagmulan ng mensahe, o pangalan ng alpha

Ang mga mensaheng ipinadala sa iyong telepono ay may dalawang uri: digital at alphabetic. Ang mga digital na numero ay maaaring mahaba (katulad ng isang numero ng telepono) o maikli. Minsan ang mga operator ay may mga paghihigpit sa pagpapadala mula sa mga neutral na pangalan, halimbawa Infosms, Alert atbp. Minsan hindi papayagan ng mga operator ang trapiko kung hindi nakarehistro ang pangalan sa kanilang network. Gayunpaman, ito ay mga katangian ng operator.

Mga yugto ng pagsusumite

SMPP - Maikling Mensahe Peer-to-Peer Protocol

SMS-SUBMIT - ito ay nagpapadala ng MO FSM message (maikling mensahe mula sa isang mobile terminal)
SMS-SUBMIT REPORT β€” kumpirmasyon na ang mensahe ay ipinadala ng SMSC
SRI SM (SendRoutingInfo) - Tumatanggap ang SMSC ng impormasyon mula sa HLR tungkol sa lokasyon ng MSC / VLR ng subscriber
SRI SM RESP β€” tugon mula sa HLR tungkol sa karne ng posisyon ng subscriber
MT-FSM β€” pagkatapos matanggap ang lokasyon, isang mensahe ang ipapadala gamit ang operasyong β€œIpasa ang Maikling Mensahe”.
MT-FSM ACK β€” tugon mula sa SMSC na naipadala na ang mensahe
ULAT sa SMS-STATUS β€” Nagpapadala ang SMSC ng katayuan ng paghahatid ng mensahe.

Katayuan ng paghahatid ng mensahe

ULAT sa SMS-STATUS maaaring tumagal ng ilang halaga:
DELIVRD matagumpay na naihatid ang mensahe
TINANGGIHAN β€” mensaheng tinanggihan ng SMS center
MAHAL KITA β€” ang mensahe ay tinanggal mula sa pagpapadala ng queue pagkatapos ng pagtatapos ng TTL (message lifetime)
UNDELIV - ibang mga kaso ng hindi paghahatid
HINDI KILALA-walang natanggap na tugon patungkol sa pagpapadala.

Mga error sa paglilipat

Minsan may mga dahilan kung bakit hindi naihatid ang mga mensaheng SMS sa subscriber. Ang kinahinatnan ng mga kadahilanang ito ay ang paglitaw ng mga pagkakamali. Ibinabalik ang mga error sa PDUs_sms_resp. Ang lahat ng mga error ay maaaring hatiin sa pansamantalang (Pansamantala) at permanenteng (Permanent).

Bilang halimbawa, ang absent_subscriber ay maaaring uriin bilang pansamantala - ang subscriber ay hindi available o hindi online, at permanente - ang subscriber ay wala. Depende sa mga error na nangyari, isang patakaran para sa muling pagpapadala ng mga mensaheng ito ay nabuo.

Halimbawa, kung ang subscriber ay abala sa isang tawag at natanggap ang error na MT handset ay abala, ang mensahe ay maaaring ipadala muli pagkatapos ng ilang minuto, gayunpaman, kung ang serbisyo ng pagtanggap ng mensahe ng subscriber ay na-block, ang muling pagpapadala ay hindi magkakaroon ng kahulugan. Makakahanap ka ng listahan ng mga error sa mga pahina ng SMSC, halimbawa, tulad ng ito.

Pinagmulan: www.habr.com

Magdagdag ng komento