protokoll kiválasztása
protokoll kiválasztása
S.Kadakov
[email protected]
SMS-alkalmazás. 1. rész 1. fejezet Protokoll kiválasztása.
Nos, ez itt az ideje, hogy írjon az első igazi futó SMS-alkalmazás, mint fognak csinálni. Mert „udobovareniya” bontottuk ezt a cikket több részre: Nézzük először néhány elméleti kérdéseket (például teljes képtelenség - leírja a protokoll :), majd anélkül, hogy zavart, hadd kódolás.
Múltkor megmutattuk, hogyan kell kommunikálni a szolgáltató központ, de most meg kell tanulni, hogyan működik megfelelően a protokoll - a forma és a „szétszedni” csomagokat. De az első, mivel lehet kitalálni, ki kell választania a protokollt. Ez a kihívás, akkor vigyázni;), és elsősorban a SMPP (rövid szöveges üzenetek Peer-to-Peer). Ennek érdekében választás mondjuk nem csak a személyes preferenciák, hanem az a tény, hogy ez a protokoll széles körben naiblee mindenütt, jól megtervezett és szépen dokumentált. Továbbá, nem zárja ki annak lehetőségét, hogy az olvasók, hogy szembenézzen a valósággal más protokollokkal, tudomásul vesszük, hogy a helyzet hasonlít az idegen nyelvek tanulása könnyebb megtanulni egy második, mint az első, a harmadik, mint a második, és így tovább ..
2. fejezet jegyzőkönyv SMPP. Áttekintése.
SMPP protokoll segítségével. nem nehéz kitalálni a „külső” eszközök közötti üzenetváltást a mobil hálózat (PLMN) keresztül SMSC és meghatározza: A műveletek sorozata közötti cseréjét az SMSC és az ESME, más néven „parancs” (parancs). A formátum az átvitt csomag (PDU - Protocol Data Unit), melyek az egyes műveletek. A formátum a válasz csomagot (ACK vagy responce) minden egyes PDU. Az adatok, hogy kell kommunikálni ESME SMSC ilyen műveletek során.
Így a hívás parancs megfelel a PDU küldésére, ezért néha helyett „mert a submit_sm” azt mondja: „Levél a submit_sm”, és fordítva. Azt is meg kell figyelni, hogy az a tény, hogy az egyes csapatok keretében az ülés meg kell erősíteni a válasz csomag (ACK), az egyetlen kivétel - alert_notification PDU (azonban ez a csapat, akkor először nem kell).
Az inicializálási eljárást végzi a hívást az egyik csapat bind_ *. bind_receiverbind_transmitterbind_tranceiver formátum, amely meg fogja vizsgálni az alábbiakban. Így a munkamenet a következő állapotok: OPEN - socket kapcsolat jön létre, és küldött egy lekérdezést bind_ *. BOUND_RX | BOUND_TX | BOUND_TRX - Kész az egyik csapat bind_ *. A kapcsolat fogadására kész | transzfer | fogadása és továbbítása. Zárt - a parancs végrehajtásához unbind (megvitatják később), és a kapcsolat le van zárva. Ezen túlmenően, az SMSC bármikor csapatot küldeni outbind. A válasz erre a parancs szükséges ESME ismét hajtsa végre bind_ * kéréseket. Azonban a gyakorlatban ez a csapat ritka, de a kezelést fel kell készülnie.
Parancsok (PDU) SMPP
SMPP protokoll verzió 3.4 kínálja a következő parancsokat:
SMPP PDU Név Kötelező SMPP Session állam által kibocsátott ESME által kibocsátott SMSC
Csapatok utótaggal _resp jelent responce, t. E. ACK (azért használjuk a kifejezést átvételét, és azt mondják, hogy az ACK „elismeri” parancs). Bold jelölt csapat, nézzük (a többiek már nem szükséges a legegyszerűbb eset).
Módok (mód) üzenet.
SMPP v3.4 protokoll támogatja a három mód üzenetküldés. Nem fogunk ezen az adott megálló, csak annyit, hogy folytatni fogjuk a munkát t. N. Tárolására és továbbítására üzenet mód. Ebben az üzemmódban az első üzenet tárolása az SMSC adatbázist, majd megpróbálja hozza, és attól függően, kérelmére, a ESME értesítik az üzenet eléri a végleges állapotát (az értesítés / nem jelentett). Szintén támogatja adatcsomag üzemmódban és Tranzakciós mód. amely megtalálható a vonatkozó dokumentációt.
Adattípusok SMPP
Minden PDU meghatározott protokoll egy sor területen bizonyos típusú sorakoznak egymás mögött egy bizonyos sorrendben. Ha hálózaton dolgozik, úgy döntött, hogy a koncepció egy oktett (oktett) - egy sor nyolc bitet (azaz az úgynevezett byte-programozás), annak érdekében, hogy hangsúlyozzák a „oktett”. Minden SMPP definiált típusok vannak kötve oktett. Itt vannak: Egész - előjel nélküli egész szám megadva minden esetben oktett hosszú. C-string Oktett - ASCII betűk sorozat, elkészült nulla. C-Oktett String (Decimális) - Egy sor karakter (0-9), nulla befejezett C-oktett String (Hex) - Egy sor karakter (0-F), befejezett nulla. Oktett karakterlánc - Egy sor oktett, nem fejezte be a nulla kötelező. TLV - Tag-hossz-érték. Használt opcionális paramétereket. Ez a fajta származik, nem fogunk, mert az kell bővíteni a jelenlegi csapat, miközben visszafelé sovmestimosti.Poskolku bármilyen használata :), majd laknak nem fog, de a kérdés az, általánosságban elmondható, hogy fontos. Mintegy TLV megtalálható a protokoll specifikáció.
Minden csomag (PDU) két részből áll: a fejléc (header). Obyazatelnaya.Telo (test). Nem kötelező. élőfejformátumot közös az összes PDU.
A fejléc hossza 16 oktett áll, és 4 területek: Command hossza - hossza. 4 oktett. Meg kell tartalmaznia a teljes hossza a csomag, beleértve ezen a területen. Command id - parancs azonosítója. 4 oktett. Ez azt jelzi, hogy milyen típusú parancs. Ez az a 0x0 0x1FF parancsok és 0x800000000 0x8000001FF válaszolni (ACK). Mindegyik csomag, amely az ACK command_id megegyezik nyugtázandó csapat, de a kitett 31. bit Command állapota - a csapat állapotát. 4 oktett. Használt ACK'ah, a csapat kiállított 0x0. Szekvencia szám - A sorszám. Minden esetben tartalmaz egy egyedi szám egy adott parancs (nem tévesztendő össze a command_id), és lehetővé teszi, hogy társítani ACK utasítás. Nevezi őket a kibocsátó oldalon véletlenszerűen 0x1-0x7FFFFFFF tartományban. Ismételjük meg ezt a számot egy session, általában nem érvényes. ACK kell azonos számú, mint az nyugtázandó csapat. Néhány PDU (különösen a többségi ACK'ov) kizárólag az alábbiak fejléc és az információ is elég.
3. fejezet Részösszeg
Ebben a cikkben megtárgyaltuk a nagyon fontos kérdés, nevezetesen a szerkezet a protokollt. Remélhetőleg, míg a félreértések merültek.