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

How does burst mode work for FTP? #98

Closed
hamishwillee opened this issue Aug 2, 2018 · 9 comments · Fixed by #445
Closed

How does burst mode work for FTP? #98

hamishwillee opened this issue Aug 2, 2018 · 9 comments · Fixed by #445
Labels

Comments

@hamishwillee
Copy link
Collaborator

How does Burst ReadFile operations/streaming work?

I know that for normal reads, the file is read in chunks, with an ACK before each new chunk is sent. My guess is that for BurstReadFile the file is chunked and sent without waiting for a request - so basically you just send a stream of ACKs, with sequentially incremented sequence numbers. When you've sent everything you send the last ACK with the burst mode complete field set.

  1. Is that correct?
  2. Presumably the recipient is in burst mode, so it is sitting waiting for a bunch of ACKs and re-assembles the message - correct?
  3. How is the recipient expected to cope with missing packets - it looks like after the burst is complete perhaps the recipient individually requests the missing packets - does it use a normal read/ACK process for that?
@hamishwillee
Copy link
Collaborator Author

@bkueng @dayjaby This is a post I created back in 2018. Is this your understanding of burst mode? If so I can take a first shot at docs.

@bkueng
Copy link
Member

bkueng commented Feb 18, 2022

This is how it works on the high level:

  • client requests burst, which is acked
  • server sends individual chunks
  • client receives w/o acks until it sees that burstComplete is set, then requests next chunk
  • client requests individual missing chunks via non-burst normal reads

@hamishwillee
Copy link
Collaborator Author

hamishwillee commented Feb 23, 2022

@bkueng Thanks! Is this correct then?

A few assumptions (reasonable)?

  1. The server decides the size of the chunks it wants to stream during burst, but the client (GCS) gets to decide the size it wants when filling in chunks. I assume it will normally use the maximum size
  2. The client needs to track the missing data chunks based on the offsets and data sent.
  3. There are timeouts for "not got a new packet" while waiting for a new burst payload.

@bkueng
Copy link
Member

bkueng commented Feb 23, 2022

Correct, looks good.

  • You might want to add another BurstReadFile for clarity, or at least mention there can be multiple (there's also an offset specified)
  • Can you use client and server (or similar) instead of GCS and Drone, to be more generic?

@hamishwillee
Copy link
Collaborator Author

hamishwillee commented Feb 23, 2022

Thanks @bkueng

  • I have updated the image above How does burst mode work for FTP? #98 (comment) to use Client/Server and add offset to the final BurstRead call.
  • Where do you mean add an extra burst read? See the ones marked up below (I have updated the missing offset marked in circle above).
    image

@hamishwillee
Copy link
Collaborator Author

PS @bkueng Conversations continues on PR: #445
That might need modification pending your answer to question above.

@bkueng
Copy link
Member

bkueng commented Feb 24, 2022

Where do you mean add an extra burst read? See the ones marked up below (I have updated the missing offset marked in circle above).

After the red arrow

@hamishwillee
Copy link
Collaborator Author

@bkueng That's why I am confused. At this point burst_complete=1. Are you saying that even after complete the server will send BurstReadFile? If so, I presume that it specifies size=0 and an empty data buffer. How many times?

@bkueng
Copy link
Member

bkueng commented Feb 25, 2022

burst_complete=1 does not mean transfer complete. A server can split a transfer into multiple bursts. Let's discuss directly if not clear.

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

Successfully merging a pull request may close this issue.

2 participants