Az SMPP ( Short Message Peer-to-Peer ) rövid üzenetek peer-to-peer átvitele . Ez egy nyílt protokoll a távközlési iparágban, amelyet kifejezetten arra terveztek, hogy rugalmas interfészt biztosítson SMS-üzenetküldéshez SMS-alkalmazásplatformok ( ESME ), útválasztók (RE-k) és rövid üzenetküldő központok ( SMSC ) között. [egy]
Az SMPP-t gyakran használják harmadik felek, például értéknövelt szolgáltatók, hírügynökségek SMS -üzenetek küldésére – gyakran tömegesen. Ezzel a protokollal küldhet SMS -t , EMS -t , hangposta-értesítéseket, mobiltelefonos műsorszórást , WAP -üzeneteket, USSD -üzeneteket stb. Sokoldalúságának köszönhetően, amely a GSM , UMTS , IS-95 ( CDMA ), CDMA2000 , ANSI 136 támogatásából áll. ( TDMA ) és hasonlók, az SMPP a legszélesebb körben használt rövid üzenet protokoll az SS7 ( SS7 ) hálózatokon kívül.
1995 novemberében az ETSI beépítette az SMPP protokollt a TR 03.39-be. [2]
Az SMPP kliens-szerver működési modellt használ. Az Üzenetközpont ( SMSC ) általában kiszolgálóként működik, és egy ügyfél - ESME - kapcsolatra vár . Ha az SMPP-t SMS társviszony-létesítésre használjuk, a küldő MC általában kliensként működik.
A protokoll a 4. OSI-rétegben ( TCP -munkamenetek vagy X25 SVC3) a kérés-válasz PDU -k (protokoll adategységek vagy -csomagok) párjainak cseréjén alapul. [3] Az IANA által az SMPP-hez rendelt jól ismert port, amikor TCP -n dolgozik, 2775, de gyakran tetszőleges portszámokat használnak.
Üzenetváltás előtt a bind parancsot el kell küldeni és nyugtázni. A bind parancs határozza meg, hogy az üzenetek milyen irányban küldhetők; A bind_transmitter lehetővé teszi, hogy a kliens csak üzeneteket küldjön a szervernek, a bind_receiver azt jelenti, hogy a kliens csak üzeneteket kap, a bind_transceiver pedig (az SMPP 3.4-ben [4] ) lehetővé teszi az üzenetek mindkét irányba történő küldését. A bind parancs elküldésekor az ESME - nek azonosítania kell magát a system_id, system_type és jelszó paraméterekkel; A címtartomány egy ESME-címet jelöl, de általában üresen adják át. Ezenkívül a kötési parancsban szerepel az interface_version, amely a munkamenet során használt protokoll verzióját jelzi.
Az üzenetküldés lehet szinkron, ahol minden csomópont PDU-nként választ vár, vagy aszinkron, ahol több kérés is küldhető válaszra várás nélkül; a meg nem erősített kérések számát "ablaknak" nevezik; a legjobb élmény érdekében mindkét oldalon azonos ablakméret-beállításokkal kell rendelkeznie.
Az SMPP-ben a PDU-k binárisan vannak kódolva a maximális hatékonyság érdekében. PDU fejléccel kezdődnek, amelyet egy PDU törzs követhet.
| SMPP PDU | ||||
| PDU fejléc (kötelező) | PDU törzs (opcionális) | |||
| parancs hossz |
parancs ID |
parancs Állapot |
Sorrend ID |
PDU törzs |
| 4 oktett | Hossz = (Parancshossz értéke - 4) oktett | |||
Minden PDU fejléccel kezdődik. A fejléc 4 mezőből áll, amelyek mindegyike 4 oktett hosszú.
parancs_hossza A PDU teljes hossza oktettben (beleértve magát a hosszmező parancsot is); a minimális érték 16, mivel minden PDU-nak tartalmaznia kell egy 16 oktettből álló fejlécet parancsazonosító Megad egy SMPP műveletet (vagy parancsot) parancs_állapota Mindig 0-ra állítsa a lekérdezéseket; a válasz információkat tartalmaz a művelet eredményéről sorszám A kérések és válaszok összekapcsolására szolgál egy SMPP-munkameneten belül; aszinkron kommunikációt biztosít ("csúsztatható ablak" módszerrel)Az SMPP összes numerikus mezője a magastól az alacsonyig ( angol big endian ) sorrendben jelenik meg , vagyis az első oktett a legjelentősebb bájt (MSB).
Ez egy példa egy 60 oktettes submit_sm PDU-ra . Az adatok hexadecimális formátumban jelennek meg. A PDU fejléce és törzse külön jelenik meg, és PDU mezőkre lebontva.
Javasoljuk, hogy ezt a példát illessze az SMPP specifikációnak az submit_sm PDU -ra vonatkozó definíciójával, hogy megértse, hogyan felel meg az egyes mezők kódolása a specifikációnak.
Az egyes PDU mezők értékei zárójelben decimális formában, utánuk pedig hexadecimális formában jelennek meg. Ha egy mező egynél több oktettre terjed ki, akkor az összes megfelelő hexadecimális oktett egyetlen sorban jelenik meg.
Ismét olvassa el az submit_sm definícióját az SMPP specifikációban a nagyobb érthetőség érdekében.
Vegye figyelembe, hogy a short_message mezőben lévő szöveg formátumának meg kell egyeznie a data_coding mező értékével . Ha a data_coding értéke 8 ( UCS2 ), a szövegnek UCS-2BE-ben (vagy annak kiterjesztésében, UTF-16BE-ben ) kell lennie. Amikor a data_coding 7 bites kódolást jelez, minden szeptet külön oktettként tárolja a short_message mezőben (a legjelentősebb bit 0-ra van állítva). Az SMPP 3.3-as verziójában a data_coding értékek pontosan megduplázzák a GSM 03.38 szabvány TP-DCS értékeit, így ez a verzió csak GSM 7 bites ábécé, UCS2 és bináris üzenetekhez alkalmas. Az SMPP 3.4 új data_coding értékeket vezetett be :
| data_coding | Jelentése |
|---|---|
| 0 | SMSC alapértelmezett ábécé (SMPP 3.4) / MC-specifikus (SMPP 5.0) |
| egy | IA5 (CCITT T.50)/ ASCII (ANSI X3.4) |
| 2 | Meghatározatlan oktett (8 bites bináris) |
| 3 | Latin 1 ( ISO-8859-1 ) |
| négy | Meghatározatlan oktett (8 bites bináris) |
| 5 | JIS (X0208-1990) |
| 6 | Cirill ( ISO-8859-5 ) |
| 7 | latin/héber ( ISO-8859-8 ) |
| nyolc | UCS2 (ISO/IEC-10646) |
| 9 | Piktogram kódolás |
| tíz | ISO-2022-JP (zenei kódok) |
| tizenegy | Fenntartott |
| 12 | Fenntartott |
| 13 | Kiterjesztett Kanji JIS (X0212-1990) |
| tizennégy | KS C 5601 |
| 15-191 | Fenntartott |
| 192-207 | GSM MWI vezérlés - lásd GSM 03.38 |
| 208-223 | GSM MWI vezérlés - lásd GSM 03.38 |
| 224-239 | Fenntartott |
| 240-255 | GSM üzenetosztály vezérlés - lásd GSM 03.38 |
A data_coding 4-es és 8- as értéke megegyezik az SMPP minden verziójával. Az 1-15 tartományban lévő egyéb értékek az SMPP 3.3-ban vannak fenntartva. Sajnos, ellentétben az SMPP 3.3-mal, ahol a data_coding = 0 egyedileg azonosítja a GSM 7 bites ábécéjét, az SMPP 3.4 és újabb verzióinál a GSM 7 bites ábécé nem szerepel ebben a listában, és a data_coding = 0 eltérő lehet a különböző SMSC -k esetén – ez lehet az ISO -8859-1 , ASCII , GSM 7 bites ábécé, UTF-8 vagy bármilyen más alapértelmezett kódolás. A data_coding = 0 használatakor mindkét félnek (ESME és SMSC) biztosnak kell lennie abban, hogy ezt ugyanarra a kódolásra mutató mutatónak tekinti. Ellenkező esetben jobb, ha nem használja a data_coding = 0. Ez megnehezítheti a GSM 7 bites ábécé használatát, mivel egyes SMSC- knél a data_coding = 0 , másoknak, például a data_coding = 241-nek kell lennie.
Az SMPP-t Java nyelven a jSMPP projekt implementálta . Az Apache Camelben és számos más népszerű ingyenes SMS üzenetküldő szoftverprojektben használják. A Java nmote-smpp alternatív megvalósítása . A python-SMPP projekt SMPP-t biztosít a Python -felhasználók számára . A PHP-SMPP projekt SMPP-t biztosít a PHP felhasználók számára .
Széles körben elterjedt használata ellenére az SMPP-nek számos problémás funkciója van:
Az SMPP 3.3-ban az összes data_coding értéket a GSM 03.38 szerint kezeli, de az SMPP 3.4 óta nincs data_coding érték a GSM 7 bites ábécéjéhez.
Az SMPP 3.4 és 5.0 szerint a data_coding =0 jelentése ″SMSC Default Alphabet″. Az, hogy valójában melyik kódolás, az SMSC típusától és konfigurációjától függ.
A CDMA C.R1001 szabvány egyik kódolása a Shift-JIS , amelyet japán nyelven használnak . Az SMPP 3.4 és 5.0 három kódolást határoz meg a japán nyelvhez (JIS, ISO-2022-JP és JIS Extended Kanji ), de egyik sem azonos a CDMA MSG_ENCODING 00101 kóddal. A piktogram kódolását a Shift-JIS üzenetek küldésére kell használni. SMPP ( adatkódolás =9).
Az SMPP 3.3-ban csak a short_message szövegmezőn keresztül lehet megerősíteni az üzenet kézbesítését a delivery_sm PDU -ban . Ennek a szövegnek a formátuma azonban az SMPP 3.4 specifikáció "B" függelékében van leírva, bár az SMPP 3.4 használhatja (és használhatja) a nyugta_üzenet_azonosítója és a message_state TLV mezőket erre a célra . Az SMPP 3.3 meghatározza, hogy az üzenetazonosító egy legfeljebb 8 hexadecimális karakterből álló C- karakterlánc (plusz egy '\0' karakter). Az SMPP 3.4 azonban meghatározza, hogy egy adott azonosító C-string formátumban legfeljebb 10 decimális karaktert tartalmazhat. Ez 2 csoportra osztja az SMPP implementációkat:
Az SMPP 3.4 specifikáció azonban kimondja, hogy a Delivery Confirmation PDU formátuma az SMSC szolgáltatótól függ. Ezért a specifikációban leírt formátum csak egy a lehetséges opciók közül. Ahogy fentebb megjegyeztük, az SMPP 3.4 használatakor a nyugta_üzenetazonosító és a message_state TLV-ket KELL használni az üzenet kézbesítésének megerősítésére .
| Alapvető TCP / IP protokollok az OSI modell rétegei szerint | |
|---|---|
| Fizikai | |
| csatornázott | |
| hálózat | |
| Szállítás | |
| ülés | |
| Reprezentáció | |
| Alkalmazott | |
| Egyéb alkalmazva | |
| A TCP és UDP portok listája | |