Adding compiler options for enabling/disabling network layer

[jqiaobln]

Is your feature request related to a problem? Please describe.

Coap is a transport layer protocol. It should be fully functional without assumptions of underlying security and network layer.

Libcoap has options to compile without TLS libraries; however it always includes networking layer code, i.e. coap_io.c and address.c, etc.

Describe the solution you'd like

Libcoap will improve its reusability and modulization if there are compiler options which can enable/disable the network layer code.

E.g. a project whose TLS and networking layer are handled by some other libraries, can integrate libcoap without including coap_io.c, address.c and the system networking libraries: socket, tcp, etc.

[obgm]

@jqiaobln There is a defined interface for the underlying read/write operations on the network. Ports for non-POSIX platforms show how to replace them. Data structures such as coap_address_t can be replaced to serve special needs as well. DTLS and TLS can be switched off (there is no point in abstracting these away because the supported DTLS and TLS libraries address very specific transport layer characteristics). Therefore, it is fairly easy to port the networking code to different transport layer abstractions by replacing certain. c files as done for the existing ports.

[mrdeep1]

@jqiaobln libcoap is now broken down into protocol layers, making it much easier to intercept at the level appropriate for your application.

So, in your cited case, the coap_netif_*() functions (in src/coap_netif.c) can call whatever is appropriate. You may also want to adjust the indexing table coap_layers_coap[] in src/coap_io.c (or its equivalent in one of your files) to point into your equivalent functions.

Each layer function calls the next function in the protocol stack (when it has finished processing) with its level as an index - e.g. session->sock.lfunc[COAP_LAYER_WS].write(session, (uint8_t*)buf, strlen(buf)); for invoking the next layer down when doing a write having completed the COAP_LAYER_WSwrite logic.

[M1cha]

@mrdeep1 What if I don't have socket-style communication? The API in coap_netif.c Still seems to assume that I have network interfaces, addresses and sockets. It assumes that you need listen and connect.

But what if I want to do point-to-point CoAP communication via e.g. UART? Is there a way to do that already?

[mrdeep1]

Interesting question. Simple answer is a bit of work is required.

The support for AF_UNIX style sockets goes someway to what you are looking for as a starting model. libcoap relies on a socket structure coap_socket_tbeing there, but (with code additions/modifications for a new socket type) does not really care as to what the socket type is.

So UART specific information can sit in coap_socket_t (as is done for LwIP, Contiki or RIOT O/S). Where connect(), bind(), accept() and setsocketopt() are used, these will need additional UART 'protocol' checks (as is done in some cases for the AF_UNIX support).

If you look at coap_layers.c, for each of the supported CoAP protocols there is a set of coap_layer_func_t entries which define read/write/establish/close functions to use for the appropriate layer. Depending on CoAP protocol one of thecoap_layers_coap entries is copied into coap_socket_t for the coap_session_t for use for the duration of that CoAP session.

So, you will need your UART read/write/establish/close functions defined that work for your UART.

[mrdeep1]

Furthermore, if you look at the socket specifics in coap_io_lwip.c (copied into, say, coap_io_uart.c) which handles the LwIP O/S, you may be able to simply drop your UART specifics int the coap_socket_recv(), coap_socket_send_pdu(), coap_socket_send(), coap_socket_bind_udp(), and coap_socket_connect_udp() (coap_socket_t will need updating as well). You should then be able to just use the regular coap:// type URIs with UDP formatted CoAP packets - just the Host portion of hte URI wouold then get ignored as you are doing P-T-P.