-
Notifications
You must be signed in to change notification settings - Fork 120
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Token change between each block2 part #16
Comments
On Sun, Feb 15, 2015 at 03:55:53AM -0800, Joakim Gebart wrote:
the token is indeed changed with every block that is transferred. first draft-ietf-core-block-16 says about this:
this was clarified also in the discussion preceding this
with respect to that, it is my impression that aiocoap does the right as for the combination of observe and blockwise: yes, that is so far |
Thank you for the clarifications regarding tokens. Regarding the observe blockwise: I do believe Contiki has the correct behaviour in this situation. It saves the first token it sees for a new subscription to use for each server-side-initiated responses (notifications). https://tools.ietf.org/html/draft-ietf-core-observe-04#section-3.2 |
This does not make observation of multi-block resource work correctly (new observed values have m=1 set and thus ignore the clients' request to see full blocks); fixing that is for later. Thanks to gebart for spotting this. Contributes-To: #16
This has long been fixed, and with other server-observe bugs fixed, can now be closed. |
Outgoing notifications used to be sent as jumbograms; now they properly update the block fragment cache and send only the requested size. Spotted when checking <#16>.
I noticed that the token is increased for each request sent for a new block in a block2 transfer and the observation list contains the latest token. This causes problem with observe requests with block2 responses from Contiki, which uses the token from the initial observe subscription request in each response instead of the token from the last block transferred. From what I can tell from the RFC it seems that the token is expected to be the same for each block in a GET block2 sequence.
The text was updated successfully, but these errors were encountered: