The Mozilla Copper plugin only recognizes messages that return from the CoAP port. Previously, responses were returned from a random UDP socket.

I have added a "CoAPResponse" class which is based on the CoAPClient class. This allows for responses from the server to be on the same port that requests were sent to.

Is there any plan to support no_std with this crate since CoAP is heavily used in embedded? There is coap-lite but it's unmaintaned and it handles only packet parsing and creation

The main motivation behind this was that thetokio version being used in this crate was still 0.2 and this was causing major issues in my project. Refactored it to use tokio 1.7*, and also ran cargo fmt (Do tell me if this might cause issues).

I also wanted to ask if this warrants a version bump since the change in tokio versions might cause issues for others.

For some applications it's necessary to have access to the sender from the callback. It would be useful to have the SocketAddr in the handler signature.

Hi!!! I want to use CoAP-rs for voice assistant components, and we need to use observe, however, there's no support for updating the resources from the server anymore and trying to access the same server from a client in the same process (as a workaround) throws:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 11, kind: WouldBlock, message: "Resource temporarily unavailable" }'

Is server-side resource update planned again, or at least, can the workaround be made to work in the meantime?

Still planning to add some tests, but please feel free to review. I can also squash the commits once we are ready (I included them in case you wanted to see the steps).

Previously, in parsing URLs, the latters' domains were considered instead of their literal hosts, which would fail for IPv6 addresses (and presumably also IPv4 addresses) that failed to reverse-look-up.

Now, the literal host is used instead, stripped of encapsulating square brackets (denoting an IPv6 address), if any.

This resolves #24.

The CoAPServer::handle takes a 'static handler.

I'm a bit new to rust, but I believe this means we can only use top level methods as handler, and then all state needed for the server will need to be stored in global variables?

As far as I understand it, this will also make the routing tool in #4 impossible.

Please correct me if I'm wrong!

The observer support today is a very useful start however it's missing a few key APIs to customize it to work similar to other CoAP implementations and, more importantly, generalized to the use cases described in RFC 7641. For example, the support requires that PUT request be issued in order for the system to work, even though we wouldn't normally expect read-only endpoints to have such a feature. Further, the implementation is just a limited replaying of the last PUT payload without any of the handling consideration that you'd get with a GET request (like if the GET response included ContentFormat options, the resulting notification for this resource path would not include that information).

I believe this can be addressed relatively easily but the easy way will break a few implementation assumptions and change the public API. For those reasons I wanted to open a dialog to make sure my assumptions are correct and my goals are consistent with the projects before proceeding to a pull request. Specifically, the following changes should make this possible:

1. A limited portion of the Observer features becomes visible from the Server object such that stateless components can invoke an API like server.resource_changed(path).
2. PUT would no longer automatically affect resources or perform caching, but instead a synthetic GET request would be injected and handled in response to server.resource_changed(path). This response would be cached instead and copied to all observing clients.
3. Resource observing eligibility would be based on the response issued when handling the initial GET {Observe:0} request rather than being assumed valid in response to a PUT. For example, if the initial GET request yields a 4.xx error, the observe would be rejected.

What do you think of these changes? Are you interested in me proceeding with a possible PR?

Thanks for the great project, this is really helping me get a cool project of mine off the ground using an ultra low powered old Lego EV3 brick as the hub!

I've been trying to add a channel to the coapserver message handler, but failing This is as far as I get:

use coap::{CoAPRequest, CoAPResponse, CoAPServer};

use std::sync::mpsc;
use std::sync::mpsc::{Receiver, Sender};

fn request_handler(request: CoAPRequest, channel_tx : Sender<u8>) -> Option<CoAPResponse> {
    None
}

fn main() {
    let addr = "[::]:5683";

    let mut server = CoAPServer::new(addr).unwrap();
    
    let (channel_tx, channel_rx): (Sender<u8>, Receiver<u8>) = mpsc::channel();   
    server.handle( move |request| {
        request_handler(request, channel_tx.clone())
    }).unwrap();
}

Errors when building:

error[E0525]: expected a closure that implements the `Fn` trait, but this closure only implements `FnOnce`
  --> src/main.rs:18:20
   |
18 |     server.handle( move |request| {
   |            ------  ^^^^^^^^^^^^^^ this closure implements `FnOnce`, not `Fn`
   |            |
   |            the requirement to implement `Fn` derives from here
19 |         request_handler(request, channel_tx)
   |                                  ---------- closure is `FnOnce` because it moves the variable `channel_tx` out of its environment

error[E0277]: `std::sync::mpsc::Sender<u8>` cannot be shared between threads safely
  --> src/main.rs:18:12
   |
18 |     server.handle( move |request| {
   |            ^^^^^^ `std::sync::mpsc::Sender<u8>` cannot be shared between threads safely
   |
   = help: within `[closure@src/main.rs:18:20: 20:6 channel_tx:std::sync::mpsc::Sender<u8>]`, the trait `std::marker::Sync` is not implemented for `std::sync::mpsc::Sender<u8>`
   = note: required because it appears within the type `[closure@src/main.rs:18:20: 20:6 channel_tx:std::sync::mpsc::Sender<u8>]`
   = note: required because of the requirements on the impl of `coap::server::CoAPHandler` for `[closure@src/main.rs:18:20: 20:6 channel_tx:std::sync::mpsc::Sender<u8>]`

error[E0277]: the trait bound `std::sync::mpsc::Sender<u8>: std::marker::Copy` is not satisfied in `[closure@src/main.rs:18:20: 20:6 channel_tx:std::sync::mpsc::Sender<u8>]`
  --> src/main.rs:18:12
   |
18 |     server.handle( move |request| {
   |            ^^^^^^ within `[closure@src/main.rs:18:20: 20:6 channel_tx:std::sync::mpsc::Sender<u8>]`, the trait `std::marker::Copy` is not implemented for `std::sync::mpsc::Sender<u8>`
   |
   = note: required because it appears within the type `[closure@src/main.rs:18:20: 20:6 channel_tx:std::sync::mpsc::Sender<u8>]`
   = note: required because of the requirements on the impl of `coap::server::CoAPHandler` for `[closure@src/main.rs:18:20: 20:6 channel_tx:std::sync::mpsc::Sender<u8>]`

error: aborting due to 3 previous errors

Hi, I'm trying to receive multicast coap messages from a thread network. This network is available via wpan0 and has ipv6 addresses. I'm trying the server demo, with the following modification: let addr = ":::0"; Unfortunately, I do not receive any packages. What could be wrong?

Things I've tried:

• set address to 0.0.0.0:5683 and send packages via ipv4 on eth0 -> this works fine
• receive the multicast messages with a node.js implementation -> this works fine

Thanks.

Are there any plans / ideas / thoughts around implementation of Blockwise transfer for Block1 type of requests? I can help with the implementation.

https://datatracker.ietf.org/doc/html/rfc7959#section-2.5

A CoAP server has the choice to either send the response message to a confirmable request as a piggy-backed response (along with the ACK), or as a separate message. When coap-rs is used in a client and the server sends a separate message, the empty ACK is given to the application, where I'd expect the library to give the application the actual response (which is sent later).

If this is not handled in the CoAP library, client applications can easily start breaking once a server is updated to a newer version (that might make better informed decisions on when to send which kind of response), when proxies are in use, or simply when the server is under higher load than usual. I do not think that it is reasonable to expect application code to handle this manually, given the overall high level of abstraction coap-rs provides. Depending on how #79 is implemented, applications might not even have the means to implement the necessary behavior on their own.

RFC 7252 has the precise details, but the rough logic I'm using in other implementations is:

• Send the request, configuring its retransmissions.
• When an empty ACK is received, cease retransmissions. The application configured total timeout is still left active.
• When receiving a response, present it to the application and terminate all timeouts.
  • If the response is sent in a CON, send an ACK.
• When receiving a response that does not match any (or, in a fully serialized library, the) outstanding request, and the response is sent in a CON, send a RST. If ihas any other type, silently ignore it.

(CC @malishav with whom I encountered this).

Hi, I am proprosing the following: coap-rs should recense every implemented IETF standards (i.e. draft, proposed standard rfc and possibly informational standard rfc that updates RFC 7252 Standard) onto the project about section in the topics like on plgd-dev/go-coap

• [X] RFC 7252 CoAP [also describes UDP, DTLS and multicast support]
• [X] RFC 8516 Too Many Requests Response Code
• [X] RFC 7641 Observing Resources in the CoAP
• [ ] RFC 6347 Datagram Transport Layer Security (DTLS) Version 1.2 *
• [x] RFC 7959 Block-Wise Transfers in the CoAP
• [ ] RFC 8323 CoAP over TCP, TLS, and WebSockets
• [ ] RFC 8613 Object Security for Constrained RESTful Environments (OSCORE)

If you have any other standards to suggest, please let a comment.

* DTLS 1.2 is very important to the core standard of CoAP. Please if you are looking for a bounty, I suggest to look for this one. You can even create your own crate on doc.rs and we will help you implementing this.

This is more of a question, rather than an issue, but curious if there are any plans to support TCP RFC (https://datatracker.ietf.org/doc/rfc8323/) for coap-rs.

It appears that the underlying IO library is asynchronous, and the server implementation does indeed expose an asynchronous handler interface.

It would be nice if the client side could also be made to have an asynchronous interface rather than having to do a blocking read.