Skip to content
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

Use initial block number specified in Block2 request #45

Closed
wants to merge 1 commit into from
Closed

Use initial block number specified in Block2 request #45

wants to merge 1 commit into from

Conversation

wbober
Copy link

@wbober wbober commented Sep 28, 2016

This PR allows the client to specify initial block number that should be transmitted. This is useful in a case when the client is resuming the request for some reason (a reset for example).

@chrysn
Copy link
Owner

chrysn commented Nov 17, 2016

I might be wrong, but AFAICT this would always fail because block message assembly assumes it starts at 0. Do you have a code example that would actually make use of this? (I'd need one for the unit tests anyway.)

@wbober
Copy link
Author

wbober commented Nov 21, 2016

Are you referring to message assembly in aiocoap? I haven't looked into that, so you might be right. I'm using an in-house COAP client running on an embedded device. The scenario that download restarts from non-zero block is not that uncommon, hence the PR.

@chrysn
Copy link
Owner

chrysn commented Nov 22, 2016

if you do blockwise yourself, the application should return False to the resource's needs_blockwise_assembly async method (possibly that should be simplifyed so a class attribute .needs_bockwise_assembly=False or similar can be set); then the server-side block handling code, including the patched line, will not be used.

does that work for your use case?

@wbober wbober closed this Sep 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants