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

nanocoap: add serverside block1 support #8788

Merged
merged 2 commits into from
Apr 16, 2018

Conversation

kaspar030
Copy link
Contributor

@kaspar030 kaspar030 commented Mar 16, 2018

Contribution description

This PR makes use of the new option handling (introduced in #8772) and adds support for server-side blockwise (block1) support.

Issues/PRs references

Waiting for #8772.

@kaspar030 kaspar030 added Area: network Area: Networking Type: new feature The issue requests / The PR implemements a new feature for RIOT State: waiting for other PR State: The PR requires another PR to be merged first CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR labels Mar 16, 2018
@kaspar030 kaspar030 force-pushed the nanocoap_add_serverside_block1 branch from ad95389 to 9558aab Compare April 4, 2018 14:56
Copy link
Member

@bergzand bergzand left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Initial review, I'll do a bit more thorough review as soon as #8772 is merged

unsigned szx; /**< szx value */
int more; /**< -1 for no option, 0 for last block,
1 for more blocks coming */
} coap_block1_t;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can be reused for block2? If so, can it be changed to coap_block_t?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably. I propose renaming at that point.

@kaspar030 kaspar030 force-pushed the nanocoap_add_serverside_block1 branch from bea5296 to eaea004 Compare April 10, 2018 19:14
@kaspar030 kaspar030 added CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR and removed State: waiting for other PR State: The PR requires another PR to be merged first CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR labels Apr 10, 2018
@kaspar030
Copy link
Contributor Author

@kaspar030 kaspar030 added CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR and removed CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR labels Apr 10, 2018
@bergzand
Copy link
Member

I'm doing some extensive testing (feeding gigabyte size data to the sha256 tester) and I'm seeing some weird things:

_sha256_handler(): received data: offset=6080 len=64 blockwise=1 more=1
_sha256_handler(): received data: offset=6144 len=64 blockwise=1 more=1
_sha256_handler(): received data: offset=6208 len=65440 blockwise=1 more=1
_sha256_handler(): received data: offset=6272 len=64 blockwise=1 more=1
_sha256_handler(): received data: offset=6336 len=64 blockwise=1 more=1
_sha256_handler(): received data: offset=6400 len=65440 blockwise=1 more=1
_sha256_handler(): received data: offset=6464 len=64 blockwise=1 more=1
_sha256_handler(): received data: offset=6528 len=64 blockwise=1 more=1

snip

_sha256_handler(): received data: offset=52160 len=64 blockwise=1 more=1
_sha256_handler(): received data: offset=52224 len=26111 blockwise=1 more=1
_sha256_handler(): received data: offset=52288 len=64 blockwise=1 more=1
_sha256_handler(): received data: offset=52352 len=26111 blockwise=1 more=1
_sha256_handler(): received data: offset=52416 len=64 blockwise=1 more=1
_sha256_handler(): received data: offset=52480 len=26111 blockwise=1 more=1
_sha256_handler(): received data: offset=52544 len=64 blockwise=1 more=1

This is produced with the nanocoap_server example on native using libcoaps coap-client to feed it data:
coap-client coap://[fe80::c0dd:c1ff:fe29:833b%tapbr0]/sha256 -m POST -f ~/$LARGE_FILE -b 64

I've wiresharked the packets, they all have size 64 there.

/* must be sorted by path (alphabetically) */
const coap_resource_t coap_resources[] = {
COAP_WELL_KNOWN_CORE_DEFAULT_HANDLER,
{ "/sha256", COAP_POST | COAP_PUT, _sha256_handler, NULL },
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comparing 5.8.2 and 5.8.3 of the CoAP rfc, I think this should only have COAP_POST as COAP_PUT is specified that the payload is stored as is and COAP_POST is used to indicate that the payload should be processed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

int coap_get_blockopt(coap_pkt_t *pkt, uint16_t option, uint32_t *blknum, unsigned *szx);

/**
* @brief Block1 helper
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Block1 helper" sounds a bit too generic to me. Maybe "Block1 option getter" is more clear.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok

* @param[out] block1 ptr to preallocated coap_block1_t structure
*
* @returns 0 if block1 option not present
* @returns 1 if structure has been filles
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

filles -> filled

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

int coap_get_block1(coap_pkt_t *pkt, coap_block1_t *block1);

/**
* @brief Insert block1 option into buffer
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"into the buffer"?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To me "the buffer" implies a specific buffer, but the function can insert the option in any buffer.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok

size_t coap_put_option_block1(uint8_t *buf, uint16_t lastonum, unsigned blknum, unsigned szx, int more);

/**
* @brief Insert block1 option into buffer (from coap_block1_t)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"into the buffer"?

*
* @param[in] szx SZX value to convert
*
* @returns size
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe expand a bit to "size in bytes" to clarify a bit.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

* @param[in] pkt pkt to work on
* @param[in] option actual block option number to get
* @param[out] blknum block number
* @param[out] szx SZX value
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe clarify here that these parameters are modified to zero if the option is not found.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

did

@kaspar030
Copy link
Contributor Author

I'm doing some extensive testing (feeding gigabyte size data to the sha256 tester) and I'm seeing some weird things:

Does this happen a lot? I've been feeding q couple hundred jiggabytes through the tester and so far, I cannot reproduce.

@bergzand
Copy link
Member

Does this happen a lot? I've been feeding q couple hundred jiggabytes through the tester and so far, I cannot reproduce.

After testing a bit more this appears to be a variant of #6123, except that I'm hammering the instance here with CoAP packets instead of ping floods. This results in sock returning a far too large packet size (several times more than the mtu size). So this issue is unrelated to this PR.

@bergzand
Copy link
Member

Ack, please squash

@kaspar030 kaspar030 force-pushed the nanocoap_add_serverside_block1 branch from 8aef938 to b42159d Compare April 16, 2018 10:32
@bergzand
Copy link
Member

@kaspar030 It looks like the commits are in the wrong order, could you rebase it to first the block1 support and then the commit adding example. Otherwise people are going to complain when bisecting.

@kaspar030
Copy link
Contributor Author

@bergzand github often messes up the order. the actual commit order in the branch is as you suggested.

@bergzand
Copy link
Member

Ah, you're right, never mind then

@bergzand bergzand merged commit 635e72d into RIOT-OS:master Apr 16, 2018
maxvankessel pushed a commit to maxvankessel/RIOT that referenced this pull request Apr 20, 2018
…e_block1

nanocoap: add serverside block1 support
@kaspar030 kaspar030 deleted the nanocoap_add_serverside_block1 branch January 22, 2019 10:22
@danpetry danpetry modified the milestone: Release 2019.04 Mar 12, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: network Area: Networking CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR Type: new feature The issue requests / The PR implemements a new feature for RIOT
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants