File List
Not logged in

Files of check-in [d26d71cd86] in directory wiki_references/2019/software/mail_and_messaging/matrix_org/src_from_GitHub/the_repository_clones/coap-proxy   [history]

CoAP <-> HTTP proxy


coap-proxy is a proof of concept experiment for converting normal Matrix HTTPS+JSON traffic into an ultra-low-bandwidth CoAP+CBOR+Flate+Noise+UDP network transport. The resulting transport typically uses 35x-70x less bandwidth than HTTPS+JSON, and attempts to fit typical Matrix transactions into a single roundtrip on a 100bps network link.

coap-proxy depends heavily on our experimental fork of go-ocf/go-coap, which implements Noise-based encryption, compression hooks and retry semantics.

More details on the transport can be found in our "Breaking the 100 bits per second barrier with Matrix" FOSDEM 2019 talk:

The typical way to run coap-proxy is via docker using the meshsim network simulator, which fires up docker containers in a simulated bad network environment containing both synapse and coap-proxy configured such that coap-proxy intercepts both client-server and server-server traffic.


As a proof-of-concept, coap-proxy currently has some major limitations:

Development of coap-proxy is dependent on commercial interest - please contact support at if you're interested in a production grade coap-proxy!


This uses the new go mod. Build with go build.


Once built, the proxy's binary is located in bin/coap-proxy. You can give it the following flags:

If no flag is provided, the proxy <!-- will use CBOR for every CoAP request, and -->will listen for both HTTP and CoAP requests on port:

How it works

The proxy works as follows:

---------------            ----------------            ----------------            ---------------
| HTTP client | <--------> | HTTP to CoAP | <--------> | CoAP to HTTP | <--------> | HTTP server |
|             |    HTTP    |     proxy    |   CoAP +   |     proxy    |    HTTP    |             |
---------------            ----------------    CBOR    ----------------            ---------------


Run the proxy for meshsim

./bin/coap-proxy --coap-target localhost:20001 # Ports are 20000 + hsid


Whenever it's possible, the proxy will try to reuse existing connections (connect()ed UDP sockets) to specific destinations when sending CoAP requests.

The only reasons that can lead it to (re)create a connection to a given destination are:

The reason why we currently re-handshake after the 180s sync timeout is:

  1. the server (and client) track sessions in networksession, which keys them based on a given {srcport, dstport} tuple.
  2. the client, having connect()ed its socket, will not change src port.
  3. the server always has the same dest port (5683).
  4. the traffic may be NATed however, which means that after a ~180s gap in traffic, the srcport that the server sees may change, making the server see it as a new session (unless we do something to tie sessions to CoAP IDs rather than srcport/dstport tuples)
  5. therefore the behaviour here probably is right (for now) and we should handshake after 180s of any pause of traffic.


Copyright 2019 New Vector Ltd

This file is part of coap-proxy.

coap-proxy is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

coap-proxy is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with coap-proxy. If not, see