rust-tcpstream-demo icon indicating copy to clipboard operation
rust-tcpstream-demo copied to clipboard

Couple of questions on Protocol

Open oren0e opened this issue 3 years ago • 1 comments

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.

oren0e avatar Jul 21 '22 17:07 oren0e

  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! :)

thepacketgeek avatar Jul 22 '22 02:07 thepacketgeek