Kavan-M
commented
2 months ago Setting the token on the client side is rather simple: packet.set_token(token);
The token can be generated however to close this issue, as long as different tokens are generated each request.
One way that should make fixing this easy is to clone the incoming subscribe requests and when informing, always send a response message to this request. Not sure if this is a good long-term fix, but it would also likely solve issue 74.
Another possible fix would be to grab only the token information and store that with each subscriber for each resource. Accessing the token is pretty simple, request.message.get_token(), and from a moral point of view this style of solution feels a little better.
In regular observe handling, the token of the original observation request should be used so the client may easily correlate which update belongs to which resource. (https://datatracker.ietf.org/doc/html/rfc7641#autoid-3). Currently no token is set at all in any point of the observe handling.
Not storing the token and reusing it upon notifications means our broker cannot interwork with other CoAP clients.
The underlying datastructures for observe handling must be modified in a way that the token is also stored, and then is set correctly each time in inform_subscriber
The inform_subscriber function should also return a 2.05 to the clients and not a 2.04