Constrained Application Protocol

Ključne riječi:

U zadnjih 10 godina možemo se sve češće susresti s pojmom Internet Stvari. Uređaji koje svakodnevno koristimo postaju “pametniji” povezivanjem na internet, te počinju pružati korisniku puno širi spektar mogućnosti. Iako postoje razni protokoli za komunikaciju između uređaja i poslužitelja, s potpuno različitim mogućnostima i karakteristikama u posljednje vrijeme počinje se sve češće koristiti CoAP.

CoAP (Constrained Application Protocol) zasniva se na klijent-poslužitelj modelu komunikacije. Temelji se na REST-u (Representational state transfer) te se resursi identificiraju pomoću URI-ja. Za pristup resursima koristi se asinkroni mehanizam te za samu razmjenu podataka UDP protokol s dodatnim slojem za retransmisiju podataka u slučaju da je došlo do gubljenja istih.

CoAP se zasniva na komunikacijskom modelu klijent-poslužitelj. Model se sastoji od dva entiteta, klijenta i poslužitelja. Klijent šalje zahtjeve poslužitelju nakon čega dobiva odgovor odmah ili naknadno, ovisno o načinu na koji su se zatražili podaci. Odgovor od strane poslužitelja može biti sadržan u jednoj ili više poruka, ovisno o vrsti zahtjeva i frekvenciji kojom se mijenjaju vrijednosti traženih resursa.

Postoje četiri različita tipa poruka koje CoAP implementira.

• Confirmable poruka (CON)
  • Poruka koja se mora potvrditi s Acknowledgement (ACK) ili Reset porukom nakon što se primi.

• Non-Confirmable poruka (NON)
  • Poruka koja ne zahtjeva potvrdu nakon primitka.

• Acknowledgement poruka (ACK)
  • Poruka koja se šalje nakon primitka CON poruke. Ne označava nikakav uspjeh izvršavanja zahtjeva, već samo da je on zaprimljen.

• Reset poruka (RESET)
  • Poruka koja se šalje nakon primitka CON ili NON poruke u kojoj fali neki kontekst kako bi se pravilno procesuirala.

CoAP implementira četiri osnovne HTTP metode.

• GET
  • Metoda vraća reprezentaciju stanja koji se nalazi na URI-u danom u zahtjevu klijenta.
  • Metoda je sigurna i idempotentna.

• POST
  • Metoda zahtjeva da se resurs koji se nalazi unutar zahtjeva obradi te da mu se dodjeli odgovarajući URI.
  • Metoda nije niti sigurna niti idempotentna.

• PUT
  • Metoda zahtjeva da resurs koji odgovara URI-ju danom unutar zahtjeva promjeni sa reprezentacijom resursa koji se također nalazi unutar zahtjeva.
  • Metoda nije sigurna ali je idempotentna.

• DELETE
  • Metoda zahtjeva da se obriše resurs na URI-ju danom unutar zahtjeva.
  • Metoda nije sigurna ali je idempotentna.

Unutar CoAP protokola svaki resurs ima svoj URI. On se definira na sljedeći način:

• coap[s]:/<host>[:<port>]/<path>[?<query>]

gdje je:

• coap[s] - URI schema, može biti secure
• <host>[:<port>] - authority, sastoji se od imena poslužitelja i definiranog porta
• <path> - path, najčešće ime samog senzora ili aktuatora
• [?<query>] - query, dodatni parametri ako su potrebni

Primjer pravilno definiranog URI-ja:

• coap:/example.smartfarm.com:5683/temperatureSensor

Sadržaj svakog okvira CoAP poruke definiran je u standardu RFC 7252.

Dijelova okvira su:

• Version (Ver)
  • 2-bitni prirodni broj koji predstavlja verziju CoAP protokola
  • U slučaju da verzija ne odgovara trenutno specificiranoj verziji, poruka mora biti ignorirana

• Type (T)
  • 2-bitni prirodni broj koji predstavlja o kojoj vrsti poruke se radi
  • Confirmable (0), Non-confirmable (1), Acknowledgement (2), Reset (3)

• Token Length (TKL)
  • 4-bitni prirodni broj koji predstavlja duljinu polja varijabli
  • Mogu se koristiti brojevi od 0 do 8, u slučaju da se koriste broj 9 do 15 moraju biti tretirani kao pogrešno definirane poruke

• Code
  • 8-bitni prirodni broj koji se dijeli na najznačajnije bitove (prva 3 bita) i manje značajne brojeve (drugih 5 bitova) predstavlja kod zahtjeva i odgovora
  • Request (0), Success response (2), Client error response (4), Server error response (5)
  • U slučaju da se radi o poruci koja predstavlja zahtjev, kod odgovara jednom od kodova zahtjeva, suprotno radi se o kodu odgovora

• Message ID
  • 16-bitni prirodni broj koji se koristi za detekciju višestrukih poruka te povezivanje CON i NON-CON poruka sa ACK i REST porukama

• Token + Options
  • opcionalan dio okvira
  • sastoji se od rednog broja opcije (4-bitni prirodni broj), duljine opcije (4-bitni prirodni broj) i vrijednosti opcije
    • Empty - niz bitova duljine 0
    • Opaque - nedifinirana struktura niza okteta
    • Uint - konačan niz okteta
    • String - niz znakova kodiran pomoću UTF8

Nakon slanja poruke očekuje se odgovor. U slučaju da se odgovor ne primi, poruka se ponovno šalje.

Nakon slanja poruke ne očekuje se odgovor.

U slučaju da želimo konstantno primati podatke kao što su npr. očitanja senzora, možemo koristiti mehanizam opservacije. U odgovoru (ACK) se prenose očitanja, a sljedeći odgovori se šalju bez ponovnih zahtjeva sve dok ne dobijemo poruku za otkazivanje pretplate.