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

Couple of questions on Protocol #2

Open
oren0e opened this issue Jul 21, 2022 · 1 comment
Open

Couple of questions on Protocol #2

oren0e opened this issue Jul 21, 2022 · 1 comment

Comments

@oren0e
Copy link

oren0e commented Jul 21, 2022

Hi again,
2 questions about the protocol part:

  1. Why does the length of the thing we are going to write to the buffer is u16?
  2. If you would have wanted to add a retrying mechanism to keep writing for n times to the buffer if there's an error (e.g. in the real world - server downtime) - how would have you done it?

It's interesting, if you give a very large number to jumble there is an error and not a buffer overflow, is that a feature of Rust as well here or am I missing something?

Great tutorial, learned a lot! Thank you.

@thepacketgeek
Copy link
Owner

  1. Is this regarding the amount field?. Assuming yes, that's just an arbitrary integer size I picked. It likely could have been a u8, but I wanted to make sure that the example was writing more than a single byte for that field.

  2. For this specific case of writing to the buffer, it's mostly likely that an error would not be recoverable with a retry. It would most likely be due to running out of memory locally or some memory allocation error that wouldn't be worth trying to work around.

However, the stream.flush() operation could be retryable as a full queue might eventually get more space. In this case (or any general case where you're wanting to retry failed operations), I would look to one of the following options:

  • Use a retry library specifically for this use case.
    • There can be many edge cases around retrying and work to make retrying ergonomic, best to use a battle-tested library for this purpose.
    • Use something like retry for sync code or tokio_retry for async code.
  • If you really want to do your own retry functionality, you can write your own and even use macros to make it more ergonomic: retry macro example

Great questions, keep them coming! :)

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

No branches or pull requests

2 participants