CoAP
CoAP
O CoAP (Constrained Application Protocol) (RFC7252) é uma alternativa mais leve ao HTTP, com alvo nos dispositivos limitados em termos de energia e comunicação (redes LLN). O CoAP usa UDP, ao invés do TCP usado pelo HTTP, reduzindo o overhead de mensagens ocasionado pela abertura e encerramento de uma conexão TCP.
O CoAP provê interação usando um modelo pedido/resposta (request/response) entre aplicações, com comunicação assíncrona por meio de mensagens UDP. Este modelo é semelhante ao modelo cliente/servidor usado no HTTP, porém, ambas as máquinas podem atuar nas duas funções, diferente do HTTP. O CoAP apresenta baixo overhead de cabeçalho e processamento e suporta URI (Uniform Resource Identifier) e Content-type.
Pode-se visualizar o CoAP em duas camadas, uma camada de mensagens interagindo de forma assíncrona com o UDP e uma camada de interações pedido/resposta usando métodos e códigos de resposta.
+----------------------+ | Application | +----------------------+ \ | Requests/Responses | | |----------------------| | CoAP | Messages | | +----------------------+ / | UDP | +----------------------+
Modelo de mensagens
O CoAP usa mensagens curtas com cabeçalho de tamanho fixo (4 bytes) que podem ser seguidas por opções e dados (payload). Cada mensagem contém um identificador (Message ID) usado para implementar o serviço de entrega garantida de mensagens.
Para a entrega garantida uma mensagem é marcada como confirmável (CON). Uma mensagem confirmável é retransmitida, usando um temporizador, até receber uma reconhecimento (ACK). Se o receptor não estiver habilitado a fornecer uma resposta adequada ele responde com a mensagem de reset (RST).
Client Server | | | CON [0x7d34] | +----------------->| | | | ACK [0x7d34] | |<-----------------+ | |
Uma mensagem que não requer confirmação é marcada como não confirmável (NON).
Client Server | | | NON [0x01a0] | +----------------->| | |
Modelo pedido/resposta
Os pedidos e respostas são carregados por mensagens CoAP, as quais incluem o código do método e da resposta.
Os métodos utilizados pelo CoAP são GET, PUT, POST, e DELETE de modo similar ao HTTP.
Os métodos podem usar mensagens confirmáveis (CON) ou não confirmáveis (NON). A resposta, se tiver disponível, pode ser enviada imediatamente, confirmável ou não confirmável.
Client Server Client Server | | | | | CON [0xbc90] | | CON [0xbc91] | | GET /temperature | | GET /temperature | | (Token 0x71) | | (Token 0x72) | +----------------->| +----------------->| | | | | | ACK [0xbc90] | | ACK [0xbc91] | | 2.05 Content | | 4.04 Not Found | | (Token 0x71) | | (Token 0x72) | | "22.5 C" | | "Not found" | |<-----------------+ |<-----------------+ | | | |
Client Server | | | NON [0x7a11] | | GET /temperature | | (Token 0x73) | +----------------->| | | | NON [0x23bc] | | 2.05 Content | | (Token 0x73) | | "22.5 C" | |<-----------------+ | |
Se a resposta não estiver disponível imediatamente, pode ser enviada posteriormente em mensagem separada.
Client Server | | | CON [0x7a10] | | GET /temperature | | (Token 0x74) | +----------------->| | | | ACK [0x7a10] | |<-----------------+ | | ... Time Passes ... | | | CON [0x23bb] | | 2.05 Content | | (Token 0x74) | | "22.5 C" | |<-----------------+ | | | ACK [0x23bb] | +----------------->| | |
Formato das mensagens
As mensagens CoAP são codificadas em binário, iniciando com um cabeçalho fixo de 4 bytes.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver| T | TKL | Code | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Token (if any, TKL bytes) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options (if any) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 1 1 1 1 1| Payload (if any) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Campos:
- Ver: 1
- T (Type): CON (0), NON (1), ACK (2) ou RST (3)
- TKL: Comprimento variável do Token (0 a 8 bytes).
- Code: Código da mensagem:
- Class (3 bits): request (0), success response (2), client error response (4), server error response (5) ou signaling codes (7)
- Detail (5 bits): Em caso de pedido, indica o método. Em caso de resposta indica o código da resposta.
Method:0.XX Success:2.XX Client Error:4.XX Server Error: 5.XX Signaling Codes: 7.XX 0 EMPTY 1 Created 0 Bad Request 0 Internal Server Error 0 Unassigned 1 GET 2 Deleted 1 Unauthorized 1 Not Implemented 1 CSM 2 POST 3 Valid 2 Bad Option 2 Bad Gateway 2 Ping 3 PUT 4 Changed 3 Forbidden 3 Service Unavailable 3 Pong 4 DELETE 5 Content 4 Not Found 4 Gateway Timeout 4 Release 5 FETCH ... 5 Proxying Not Supported 5 Abort 6 PATCH 7 iPATCH
- Message ID: Identificador da mensagem, usado para detectar duplicatas ou correspondências entre uma mensagem CON com a mensagem ACK/RST ou entre uma mensagem NON com uma mensagem RST (caso o nó não possa processar a mensagem).
Campos opcionais:
- Token: Usado para correlacionar pedidos e respostas
- Options: A especificação CoAP define um conjunto de opções, identificadas por números, para serem utilizadas nas mensagens.
- Payload: Dados
REST (Representational State Transfer)
As mensagens CoAP seguem a arquitetura REST (Representational State Transfer) para ler, atualizar, criar ou apagar de dados de aplicação em servidores remotos.
Na arquitetura REST um servidor REST simplesmente provê acesso a recursos e um cliente REST acessa e apresenta os recursos. Cada recurso é identificado por uma URI (Uniform Resource Identifier), que é sua identidade global.
Um sistema com capacidade de aplicar os princípios de REST é chamado de RESTful.
- Métodos RESTful
- GET - ler informação
- PUT - atualizar informação
- POST - criar uma nova informação
- DELETE - apagar informação
A arquitetura REST usa várias representações para representar um recurso, como texto, JSON e XML, sendo o formato JASON o mais popular em Web Services.
- Formato XML:
<endereco>
<rua>
JK
</rua>
<cidade>
Foz do Iguaçu
</cidade>
</endereco>
- Formato JASON:
{ endereco:
{
rua: JK,
cidade: Foz do Iguaçu
}
}
A arquitetura REST é fortemente influenciada pelas tecnologias Web, sendo o HTTP uma de suas instâncias mais relevantes.
Muitas aplicações de IoT que utilizam protocolos IP fazem uso publicadores MQTT (sensores) e subscritores MQTT (atuadores), mas podem também utilizar REST Web Services.
O CoAP é um protocolo de transferência RESTful para nós e redes com recursos restritos em termos de processamento, memória e consumo de energia.
URI (Uniform Resource Identifier)
Estrutura de uma URI:
coap:// host [:port] path [? query]
Parâmetros query :
?key1=value1&key2=value2
- lista de chave/valor separados por &.
#SomewhereInTheDocument
- é um marcador para outra parte do próprio recurso.
Biblioteca CoAP para Arduíno
Artigo: (Porciúncula etal, 2018) [3]
Video: [4]
Referências
- ↑ https://www.rfc-editor.org/info/rfc7252
- ↑ https://en.wikipedia.org/wiki/Constrained_Application_Protocol
- ↑ Cleber B. da Porciúncula, Sílvio Beskow, Daniel Stefani Marcon e Jéferson Campos Nobre. Constrained Application Protocol (CoAP) no Arduino UNO R3: Uma Análise Prática, Anais do V Workshop Pré-IETF, 2018.
- ↑ https://www.youtube.com/watch?v=pfG8uEDZj5g
Evandro.cantu (discussão) 15h22min de 14 de maio de 2020 (-03)
