Introduction to the development of Coap protocol for Internet of things

Posted by ameen on Wed, 02 Feb 2022 14:41:32 +0100

1, Coap protocol development

COAP (Constrained Application Protocol) is a kind of web like protocol in the world of Internet of things. Its detailed specification is defined in RFC 7252. The name of COAP translates to "restricted application protocol". As the name suggests, it is used on Internet of things devices with limited resources. The ram and rom of IOT devices are usually very small, and running TCP and HTTP is unacceptable.

​

1. Introduction to Coap protocol

1.1 features of Coap protocol

  • The network transport layer of COAP protocol is changed from TCP to UDP.
  • It is based on REST. Like the Internet, the resource address of the server also has a similar url format. The client also has POST, get, put and delete methods to access the server. HTTP is simplified.
  • COAP is in binary format, HTTP is in text format, and COAP is more compact than http.
  • Lightweight, the minimum length of COAP is only 4B, and the header of an HTTP is dozens of B.
  • Support reliable transmission, data retransmission and block transmission. Ensure reliable data arrival.
  • Support IP multicast, that is, you can send requests to multiple devices at the same time.
  • Non long connection communication, suitable for low-power Internet of things scenarios.

1.2. Coap protocol message type

COAP protocol has four message types

  • CON - a request that needs to be confirmed. If the CON request is sent, the other party must respond. This is a bit like TCP. The other party must acknowledge the receipt of the message for reliable message transmission.
  • NON - a request that does not need to be confirmed. If a NON request is sent, the other party does not have to respond. This applies to messages that are sent repeatedly and frequently, and packet loss does not affect normal operation. This is very similar to UDP. Used for unreliable message transmission.
  • ACK -- response message, corresponding to the response of CON message.
  • Rst -- reset message. When the received message is unknown or wrong during reliable transmission, ACK message cannot be returned, but RST message must be returned.

1.3. Coap message format

The message format of CoAP is very compact. It runs on UDP by default (each CoAP message is the data part of UDP packet).
CoAP can also run on DTLS protocol and other transport protocols, such as SMS, TCP or SCTP (CoAP does not support UDP Lite [rfc3828] and UDP zero checksum[RFC6936]).

CoAP messages are encoded in binary format. This message format starts with a fixed 4-byte header.
After that is a Token with a length between 0 and 8 bytes. The Token value is followed by 0 or more options in type length value (TLV) format. After that, there is a payload part at the end of the whole datagram, and the payload can be empty.

The header field is defined as follows:

  • Version number (Ver)
    2-bit unsigned integer, representing CoAP version number. The implementation of this document (7252) must set this field to 0b01. Other values are reserved for future versions. Messages with unknown version numbers must be ignored.

  • Type
    2-bit unsigned integer. The types representing this message are: CON(0), NON(1), ACK(2), or RST(3).

  • Token length (TKL)
    4-bit unsigned integer. Indicates the length of variable Token field (0-8 bytes). The length 9-15 is reserved and cannot be set to 9-15. If the length is set to 9-15, it must be treated as a message format error.

  • Column code
    8-bit unsigned integer. Split into 3-bit classification information and 5-bit details.
    Write "c.dd". C is 3-bit long, which can be a number from 0 to 7, and DD is 5-bit long, which is a two digit number from 00 to 31.
    The classification information c can represent a request (0), a successful response (2), a client error response (4), or a server error response (5).
    All other values are reserved. Code 0.00 is a special case that represents an empty message. When the message is a request, the code field indicates the request method. When responding, the code field represents the response code. All desirable values of the code field are defined in the CoAP code table below.

  • Message ID
    16 bit unsigned integer, network byte order. Used to detect duplicate messages and messages matching ACK/RST type and CON/NON type. The rules for generating message ID s and matching messages are described in Chapter 4.

  • Token value
    After the header is the Token value, which can be 0 to 8 bytes, which is specified by the Token length field. This Token value is used to associate a request with the corresponding response.

  • Options
    After the header and Token, there are 0 or more options (see Section 3.1). After an option, it may be the end of the message, another option, or the payload identifier and payload part.

  • payload section
    After the header, token and option, there is the payload part (there can be no payload).
    If there is a payload and the length is not 0, there is a payload identifier (0xFF) with a fixed length of one byte before the payload, which marks the end of the option part and the beginning of the payload part.
    The payload part starts from the identifier to the end of the UDP datagram, that is, the length of the payload part can be calculated according to the length of the UDP datagram.
    If there is no payload identifier, it means that this is a payload of 0 length. If there is a payload identifier followed by a 0-length payload, it must be treated as a message format error.

    The Coap load includes the content directly related to the specific application. The Coap load includes many different media types, including binary load, text load, XML load, JSON load, CBOR load, etc. The media types supported by Coap do not contain HTML types.

Implementation note: the value 0xFF may appear in the length of an option or the value of an option, so it is not feasible to simply scan 0xFF to find the payload identifier. 0xFF as the payload identifier can only appear after the end of one option and where the next option is likely to start.

1.4. Coap code registration

The sub registry of method codes is "CoAP Method Codes". Each time you enter this sub registry, you must include the Method Code in the range of 0.01-0.31, the name of the method, and the reference of the method document.
Initialize the sub registry as follows:

     +------+--------+-----------+---------------+                       
     | Code | Name   | Reference |  description  |           
     +------+--------+-----------+---------------+                        
     | 0.01 | GET    | [RFC7252] |  Used to obtain a resource  |                    
     | 0.02 | POST   | [RFC7252] |  Used to create a resource  |                    
     | 0.03 | PUT    | [RFC7252] |  Used to update a resource  |                   
     | 0.04 | DELETE | [RFC7252] |  Used to delete a resource  |                   
     +------+--------+-----------+----------------+
                Table 5: CoAP Method Codes

Other Method Codes are not arranged. Each method that cannot be recognized or supported by the server usually results in a 4.05 response code.

The additional definition of Internet number assignment policy for this sub registry in the future is described in "IETF Review or IESG Approval" [RFC5226]

The document of the method code needs to specify the semantics of the request, including the following attributes:

  • 1. The response code of this method is returned successfully.
  • 2. Whether this method is idempotent, safe or both.

The name of the sub registry is "CoAP Response Codes"
Each sub registry must contain the response code in the range of 2.00-5.31, the description of the response code and the document reference of the response code.

Initialize the sub registry as follows:

+------+------------------------------+-----------+ 
   | Code | Description                  | Reference |
   +------+------------------------------+-----------+
   | 2.01 | Created                      | [RFC7252] | 
   | 2.02 | Deleted                      | [RFC7252] |
   | 2.03 | Valid                        | [RFC7252] |
   | 2.04 | Changed                      | [RFC7252] |
   | 2.05 | Content                      | [RFC7252] |
   | 4.00 | Bad Request                  | [RFC7252] |
   | 4.01 | Unauthorized                 | [RFC7252] | 
   | 4.02 | Bad Option                   | [RFC7252] |
   | 4.03 | Forbidden                    | [RFC7252] | 
   | 4.04 | Not Found                    | [RFC7252] | 
   | 4.05 | Method Not Allowed           | [RFC7252] | 
   | 4.06 | Not Acceptable               | [RFC7252] | 
   | 4.12 | Precondition Failed          | [RFC7252] | 
   | 4.13 | Request Entity Too Large     | [RFC7252] |  
   | 4.15 | Unsupported Content-Format   | [RFC7252] |  
   | 5.00 | Internal Server Error        | [RFC7252] |
   | 5.01 | Not Implemented              | [RFC7252] | 
   | 5.02 | Bad Gateway                  | [RFC7252] |  
   | 5.03 | Service Unavailable          | [RFC7252] | 
   | 5.04 | Gateway Timeout              | [RFC7252] | 
   | 5.05 | Proxying Not Supported       | [RFC7252] | 
   +------+------------------------------+-----------+ 
             Table 6: CoAP Response Codes

Response codes 3.00-3.31 are reserved for future use. All other response codes were not scheduled.

The Internet number assignment policy is the sub registry. The additional definitions are described in "IETF Review or IESG Approval" [RFC5226]

The response code document needs to specify the semantics of the response, including the following attributes:

  • Application mode of response code.
  • Whether to carry payload and option.
  • The semantics of payload. For example, the payload of 2.05 (content) response is the display of target resources; Payload is readable and diagnostic in the wrong response.
  • Format of payload. For example, the response of this format in 2.05 (content) is represented by the content format option; The format of payload is in a wrong format
  • Net Unicode text is always in the response
  • Whether the response can be buffered depends on the freshness model
  • Whether the response passes the validity check depends on the validation model
  • Whether the response causes a cache to mark that the response has been stored, indicating that the URI of the request is not up-to-date.

1.5 Coap media type

Content format number

  • [text/plain] if the number is 0, it means that the load is in string form, and the default is UTF8 encoding.
  • [application / link format] number is 40, and the definition is added in the CoAP resource discovery protocol. This media type is unique to the CoAP protocol.
  • The [application/xml] number is 41, indicating that the load type is in XML format.
  • [application / octet stream] number is 42, indicating that the load type is in binary format.
  • The [application/exi] number is 47, which indicates that the load type is in "reduced XML" format.
  • In addition, there is another format recognized by IANA and widely used in CoAP protocol, that is CBOR format, which can be understood as binary JSON format.
  • [applicaiton/cbor] number is 60.

1.5. Coap URL

The url of coap is very similar to that of HTTP. The beginning is "coap" corresponding to "HTTP" or "coaps" corresponding to "https".

The default port of HTTP is tcp 80, and the default port of coap is udp 5683 (coaps is 5684).

2. Introduction to California framework

California framework is a Coap technology framework based on Java implementation. The project implements various request response definitions of Coap protocol and supports different reliability transmission modes of CON/NON. California is based on a layered design and is highly scalable. In the implementation of Coap technology of the same type, the performance of California is outstanding, as shown in the following figure:

​

California defines a three-tier architecture

  1. The network layer is responsible for handling port monitoring and network data sending and receiving;
  2. The protocol layer is responsible for analyzing and encapsulating Coap protocol packets, and realizing message routing, reliable transmission, Token processing, observer model, etc;
  3. The logical layer is responsible for resource definition and mapping. A resource corresponds to a URL, which can independently implement Coap request processing. For ease of understanding, resource can be regarded as a servlet or controller.

For us, the development work is mainly in the logic layer.

The three-tier architecture can support independent thread pools, in which the thread pools of network layer and protocol layer remain independent;

The logic layer can specify an independent thread pool for each Resource and support the mechanism of parent inheritance, that is, if the current Resource is not defined, the thread pool of the parent Resource will be used;

If the logical layer does not specify a thread pool, the thread pool of the protocol layer is used by default.

2.1 introduction to main interfaces of California

The use of California framework is not complicated. We mainly call some classes in the logic layer. Some of the most commonly used classes and interfaces are as follows:

  • CoapClient: the entrance of the client. The client sends data to the server by implementing CoapClient.
  • CoapServer: the portal of the server, which starts the server and receives the data transmitted by the client.
  • Endpoint: defined as an endpoint, which usually corresponds to an IP and port. It shields the network transmission details during the interaction between client and server. For the client, the endpoint represents the address port of the communication server; For the server, it represents the address and port of binding listening. Coalendpoint implements the endpoint interface.
  • Exchange: exchange describes the Request Response model. An exchange will correspond to a Request, a corresponding Response, and the current Endpoint.
  • Coappresource: the class that ultimately processes the message. It inherits the coappresource class to process the request sent by the client. It rewrites the corresponding methods to process GET,POST and other requests. When implementing the Resource, you need to specify the name of the Resource. This name is very important. When the client requests, you need to bring the name of the Resource in the uri, In this way, the framework will point the request to the corresponding Resource.

3. Examples of using the California framework

The example introduces the application of a simple framework. The client sends a message to the server, and the server receives and returns a successful message. The code is based on jdk1 8.

3.1. Server

import org.eclipse.californium.core.CoapResource;
import org.eclipse.californium.core.CoapServer;
import org.eclipse.californium.core.coap.CoAP;
import org.eclipse.californium.core.server.resources.CoapExchange;

import java.text.SimpleDateFormat;
import java.util.Date;

public class CoapServerTest
{
    public static void main(String[] args) {
        // The host is localhost and the port is the default port 5683
        final CoapServer server = new CoapServer();

        // By default, udp implements the transport layer
        server.add(new CoapResource("hello"){
            // Create a resource request in the form of host: port \ hello
            @Override
            public void handleGET(CoapExchange exchange) {
                //  Rewrite the method of processing GET requests
                exchange.respond(CoAP.ResponseCode.CONTENT, "Hello CoAP!");
            }
        });

        server.add(new CoapResource("time"){
            // Create a resource request in the format of host: port \ time
            @Override
            public void handleGET(CoapExchange exchange) {
                Date date = new Date();
                exchange.respond(CoAP.ResponseCode.CONTENT,
                        new SimpleDateFormat("yyyy-MM-dd HH:mm:ss").format(date));
            }
        });
        // Start service
        server.start();
    }
}

3.2 client

import org.eclipse.californium.core.CoapClient;
import org.eclipse.californium.core.CoapResponse;
import org.eclipse.californium.core.Utils;
import org.eclipse.californium.core.coap.MediaTypeRegistry;

import java.net.URI;

public class CoapClientTest {
    public static void main(String[] args) throws Exception {
        hello();
        //time();
    }

    public static void hello() throws Exception {
        URI uri = null;
        // Create a resource request hello resource. Note that the default port is 5683
        uri = new URI("localhost:5683/hello");
        CoapClient client = new CoapClient(uri);
        CoapResponse response = client.get();
        if(response !=null){
            // Print request status code
            System.out.println(response.getCode());
            // Option parameters
            System.out.println(response.getOptions());
            // Get content text information
            System.out.println(response.getResponseText());
            System.out.println("\nAdvanced\n");
            // Print well formed output
            System.out.println(Utils.prettyPrint(response));
        }
    }


    public static void time() throws Exception {
        URI uri = null;
        // Create a resource request hello resource. Note that the default port is 5683
        uri = new URI("localhost:5683/time");
        CoapClient client = new CoapClient(uri);
        CoapResponse response = client.post("", MediaTypeRegistry.TEXT_PLAIN);
        if(response !=null){
            // Print request status code
            System.out.println(response.getCode());
            // Option parameters
            System.out.println(response.getOptions());
            // Get content text information
            System.out.println(response.getResponseText());
            System.out.println("\nAdvanced\n");
            // Print well formed output
            System.out.println(Utils.prettyPrint(response));
        }
    }
}

Hot Topics

©2025 Programmer Think