Selectați Protocolul
S.Kadakov
[email protected]
SMS-aplicație. Partea 1. Capitolul 1 Selectarea protocolului.
Ei bine, acum este momentul să scriem prima noastră aplicație SMS cu adevărat funcțională, ceea ce vom face. Pentru "săpare" am împărțit acest articol în mai multe părți: în primul rând vom aborda câteva întrebări teoretice (de exemplu, vom descrie protocolul pe scurt) și apoi, fără distragere, vom fi implicați în codificare.
Ultima dată când am arătat cum să stabiliți o conexiune cu Centrul de servicii, acum este necesar să învățați cum să lucrați cu protocolul însuși - pentru a forma și "dezasambla" pachetele. Dar înainte, după cum puteți ghici cu ușurință, trebuie să selectați un protocol. Vom prelua această sarcină cea mai complicată;) și ne vom opri pe SMPP (Scurt Mesaje Peer-to-Peer). În favoarea acestei alegeri, se spune nu numai preferințele personale, ci și faptul că acest protocol este cel mai răspândit, bine conceput și bine documentat. În plus, fără a exclude posibilitatea ca cititorii să se confrunte în realitate cu alte protocoale, observăm că situația este asemănătoare studiului limbilor străine: al doilea este mai ușor de învățat decât primul, al treilea, al doilea, etc.
Capitolul 2. Protocolul SMPP. Prezentare generală.
Protocolul SMPP permite. deoarece nu este greu de ghicit, dispozitivele "externe" fac schimb de mesaje cu rețeaua mobilă (PLMN) prin SMSC și definesc: Un set de operațiuni de schimb între SMSC și ESME, numite și "comenzi". PDU este unitatea de date protocol asociată fiecărei operațiuni. Formatul pachetului de răspuns (ACK sau răspuns) pentru fiecare PDU. Datele pe care ESME ar trebui să le facă cu SMSC în timpul acestor operațiuni.
Astfel, trimiterea PDU corespunde apelului comenzii, deci uneori vom spune "send submit_sm" în loc de "call submit_sm" și invers. De asemenea, trebuie să fiți atenți la faptul că fiecare dintre comenzile din cadrul sesiunii trebuie să fie confirmată de un pachet de răspuns (ACK), singura excepție fiind PDU alert_notification (cu toate acestea, această comandă nu va fi necesară la început).
Procedura de inițializare se realizează prin apelarea uneia dintre comenzile bind_ *. bind_receiverbind_transmitterbind_tranceiver format pe care îl vom discuta mai jos. Astfel, sesiunea poate fi în următoarele stări: DESCHIS - A fost stabilită o conexiune socket și a fost trimisă una dintre cererile bind_ *. BOUND_RX | BOUND_TX | BOUND_TRX - A fost executată una din comenzile bind_ *. Conexiunea este pregătită să primească | transfer | recepție și transmitere. ÎNCHIS - Comanda de dezbinare a fost executată (vom discuta mai târziu) și conexiunea este închisă. În plus, SMSC poate trimite ambalaje în orice moment. Ca răspuns la această comandă, ESME trebuie să execute din nou una dintre cererile bind_ *. Adevărat, în practică, această comandă este rară, dar procesarea ei ar trebui să fie gata.
Comenzile SMPP (PDU)
SMPP versiunea 3.4 oferă următorul set de comenzi:
SMPP PDU Nume Necesar SMPP Sesiune de Stat Eliberat de ESME Emis de SMSC
Comenzile cu sufixul _resp înseamnă răspuns, adică ACK (de asemenea, folosim termenul chitanță și spunem că ACK "recunoaște" comanda). Echipe marcate îndrăznețe pe care le vom lua în considerare (restul în cel mai simplu caz pe care încă nu avem nevoie).
Modurile de mesaje.
SMPP v3.4 acceptă trei moduri de mesagerie. Nu vom mai vorbi despre asta, doar menționăm că în viitor vom lucra în așa-numitele. Memorare și redirecționare mesaj. În acest mod, mesajul este mai întâi stocat în baza de date SMSC și apoi sunt făcute încercări de aducere a acestuia și, în funcție de solicitare, ESME este notificat atunci când mesajul ajunge la starea finală (actualizat / neactualizat). Modul Datagram și modul de tranzacționare sunt, de asemenea, acceptate. care pot fi citite în documentația relevantă.
Tipurile de date SMPP
Toate PDU-urile definite de protocol sunt o colecție de câmpuri de anumite tipuri, aranjate unul după altul într-o anumită ordine. Când lucrăm la rețea, este obișnuit să folosim conceptul de octet (o colecție de opt biți (ceea ce se numește de obicei în byte de programare) pentru a sublinia "opt biți". Toate tipurile definite de SMPP sunt legate de un octet. Aici sunt: Integer - Un întreg nesemnificat cu lungimea specificată în fiecare caz special în octeți. C-Octet String - seria de caractere ASCII, completat cu zero. C-Octet String (Zecimal) - O serie de litere (0-9), completate cu un zero C-Octet String (Hex) - O serie de litere (0-F), completate cu zero. Octet String - O serie de octeți neapărat completate de zero. TLV - Tag-Length-Value. Folosit pentru parametrii opționali. Acest tip a apărut din cauza necesității de a extinde comenzile existente, menținând în același timp compatibilitatea înapoi. Din moment ce nu le vom folosi pe acestea, nu ne vom ocupa de acest lucru, deși întrebarea este în general importantă. TLV poate fi citit în specificația protocolului.
Fiecare pachet (PDU) este format din două părți: un antet. Obligatoriu. Opțional. Formatul antetului este comun tuturor PDU-urilor.
Antetul are o lungime de 16 octeți și constă din 4 câmpuri: Lungime comandă - Lungime. 4 octeți. Trebuie să conțină lungimea totală a pachetului, inclusiv acest câmp. ID de comandă - Identificatorul comenzii. 4 octeți. Indică tipul de comandă. Este nevoie de valori de la 0x0 la 0x1FF pentru comenzi și de la 0x800000000 la 0x8000001FF pentru răspunsuri (ACK). Fiecare pachet reprezentând ACK are o comanda_id la fel ca comanda recunoscuta, dar cu statutul de comanda pe 31 de biți setat la starea comenzii. 4 octeți. Folosit în ACK-uri, în comenzi este setat la 0x0. Numărul secvenței - Numărul secvenței. În fiecare caz, conține numărul unic al unei comenzi separate (care nu trebuie confundat cu command_id) și permite asocierea unui ACK cu o comandă. Este atribuită arbitrar de partea de emisie din intervalul 0x1-0x7FFFFFFF. Repetarea acestui număr într-o sesiune, în general, nu este permisă. ACK trebuie să aibă același număr ca și comanda confirmată. Unele unități PDU (în special, majoritatea ACK-urilor) constau doar dintr-un antet și această informație este suficientă.
Capitolul 3. Subtotal
În această parte am discutat o problemă extrem de importantă, și anume: structura protocolului. Sperăm, în timp ce nu există neînțelegeri.