[core] Interest in defining CoAP over Unix Domain sockets?

[Jon Shallow <[e-mail]>]

Hi there,

 

There has been a request for supporting CoAP over Unix Domain sockets -
primarily for a reverse proxy which is secured to the outside world but
wants to distribute the CoAP traffic internally within the appliance to
various server applications.  See https://github.com/obgm/libcoap/issues/958
.

 

With libcoap, I have found that only minimal changes are required to the
library to support Unix Domain sockets (mainly additions of some 'case
AF_UNIX:' when handling the sockets) which then supports CoAP over datagram,
CoAP over stream, CoAP over DTLS over datagram and CoAP over TLS over
stream.

 

As the server can only bind to an unique path, different paths need to be
used for datagram, stream etc.

 

To support multiple clients per server, each client needs to bind to an
unique path (for datagram) so that the server knows where to send responses
to. For stream, having the client bind to an unique path aids logging in the
server for troubleshooting issues.

 

Defining what a Unix Domain CoAP URI looks like for a client to parse is the
more contentious area.  There is a fairly full discussion about this for
http in https://github.com/whatwg/url/issues/577 with no major conclusions
reached.  It all hinges on how best to embed the Unix Domain path into the
URI.

 

For me, something like "coap+unix//[/unix/domain/path]/some/path" makes some
sort of sense, but that does not work for all.

 

There is a footnote for the coap:// etc. schemes in
https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml 

[1] CoAP registers different URI schemes for accessing CoAP resources 

via different protocols. This approach runs counter to the WWW principle
that a URI identifies a resource and that multiple URIs for identifying the
same resource should be avoided
[http://www.w3.org/TR/webarch/#avoid-uri-aliases]

 

Worth pursuing further?

 

Regards

 

Jon