Skip to content
This repository has been archived by the owner on Aug 30, 2022. It is now read-only.

Block2 random access bypass for GET #7

Open
mkovatsc opened this issue Jun 10, 2014 · 1 comment
Open

Block2 random access bypass for GET #7

mkovatsc opened this issue Jun 10, 2014 · 1 comment

Comments

@mkovatsc
Copy link

When requested out-of-order, Cf can skip the (atomic) buffering and just return the block without creating transfer state for the client.

@mkovatsc mkovatsc changed the title Block2 random access bypass Block2 random access bypass for GET Jun 10, 2014
martinlanter added a commit to martinlanter/californium that referenced this issue Jul 24, 2014
…GET). Users can now

create requests that only retrieve a single block from the destination.
@martinlanter
Copy link
Contributor

I dealt with this issue (https://github.com/Lanterm/californium/tree/memorytest). The client still creates transfer state, though. The reason is that when receiving the response block, the client has to remember that it only asked for this single block and that it was not the server that opted for the blockwise transfer. Sure, the client could also derive this information by checking the request it previously sent, however, I favored explicitly setting a boolean that the exchange is a random access.

The user now can write code such as the following:

Request request = Request.newGet();
request.setURI("coap://localhost:5683/resource");
request.getOptions().setBlock2(BlockOption.size2Szx(64), false, 7); // access block 7
Response response = request.send().waitForResponse();

There remains one problem: Assume the code above but instead we want to access block 0 instead of 7. When the client processes the request in the BlockwiseLayer, it does not know, however, if the user wanted to

  • a) Perform a random access and only retrieve the first 64 bytes of the full response payload.
  • b) Just limit the block size the target is allowed to use to 64 bytes but actually wants to retrieve the full response (= early block size negotiation).

We could of course just define that the second scenario is no longer possible with Cf as scenario a) seems to be more expedient then b). Tell me what you think.

sbernard31 pushed a commit to sbernard31/californium that referenced this issue Dec 23, 2016
sbernard31 pushed a commit to sbernard31/californium that referenced this issue Dec 23, 2016
sbernard31 pushed a commit to sbernard31/californium that referenced this issue Dec 23, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants