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

Blockwise transfer #101

Open
cakekindel opened this issue May 11, 2022 · 6 comments · May be fixed by #274
Open

Blockwise transfer #101

cakekindel opened this issue May 11, 2022 · 6 comments · May be fixed by #274

Comments

@cakekindel
Copy link
Collaborator

No description provided.

@cakekindel cakekindel added this to the rfc7959 milestone May 11, 2022
@cakekindel cakekindel changed the title OBSERVE Blockwise transfer May 12, 2022
@cakekindel
Copy link
Collaborator Author

cakekindel commented Mar 19, 2023

we send a request

  • outbound requests are automatically broken into blocks, default block size 1024
    • when server responds with 2.31 CONTINUE Block1 {num: 0, size: <new_size>, more: true}, break the remainder of the payload into block size <new_size> and restart the process for each block
    • when server responds with 4.08 REQUEST ENTITY INCOMPLETE restart from block 0
    • when server responds with 4.13 REQUEST ENTITY TOO LARGE Block1 {num: 0, size: <new_size>, more: false}, restart from block 0 with size <new_size>
    • when server responds with any other status code and Block1 {num: <acked_num>, size: <size>, more: <more>}, treat this response as the final response to the original request
      • if more was false and we have more blocks to send, store the response and pretend we didn't receive it until all blocks sent
      • if at any time we receive 4.08 REQUEST ENTITY INCOMPLETE discard the stored response

@cakekindel
Copy link
Collaborator Author

cakekindel commented Mar 19, 2023

we get a request

  • inbound request has Block1 {num: 0, size: <size>, more: true}
    • store first block
  • inbound request has Block1 {num: <num>, size: <size>, more: true}
    • if we have not seen num - 1, respond 4.08 REQUEST ENTITY INCOMPLETE
    • if we have seen num - 1, respond 2.31 CONTINUE Block1 {num: <num>, size: <size>, more: true}
  • inbound request has Block1 {num: <num>, size: <rem>, more: false}
    • same checks as more: true
    • let server see assembled request
  • inbound request has Block2 {num: 0, size: <desired_size>, more: false}
    • response should be blocked into this size, else 1024
  • inbound request has Block2 {num: <num>, size: <desired_size>, more: false}
    • send requested block
  • we have communicated all blocks and EXCHANGE_LIFETIME has passed
    • drop response

@cakekindel
Copy link
Collaborator Author

cakekindel commented Mar 19, 2023

we get a response

  • response had Block1 {num: 0, size: <size>, more: true}
    • incr num by 1 and send a duplicate of the original request (stripped of any Block2 options)
  • response had Block1 {num: <num>, size: <size>, more: false}
    • yield assembled response to client

@cakekindel
Copy link
Collaborator Author

Send Size1 and Size2 with all outbound messages

@cakekindel
Copy link
Collaborator Author

when assembled request payload does not agree with Size1, respond 4.08 REQUEST ENTITY INCOMPLETE

wehen assembled response payload does not agree with Size2, discard and restart from scratch

@cakekindel cakekindel linked a pull request Mar 28, 2023 that will close this issue
@cakekindel
Copy link
Collaborator Author

note: make sure this interacts with retry well

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant