Admittedly, set_buffer_hint() is not used much, and all it does is to
sometimes avoid immediate writes by the HTTP/2 transport in gRPC. Your
usecase does not seem one where this behavior is going to be useful.
To be clear, a write is considered to be "committed" when it passes flow
control in
What is the point of WriteOptions::set_buffer_hint() then? If only one
write can be outstanding anyway, then I cannot simply fill-up the socket
buffer for WriteOptions::set_buffer_hint() to work, because the second
write can only happen after the first write has been committed and then
*acked
What is the point of WriteOptions::set_buffer_hint() then? If only one
write can be outstanding anyway, then I cannot simply fill-up the socket
buffer for WriteOptions::set_buffer_hint() to work, because the second
write can only happen after the first write has been committed and then
*acked
What it is the point of WriteOptions::set_buffer_hint() then? If only one
write can be outstanding anyway, then I cannot simply fill-up the socket
buffer for WriteOptions::set_buffer_hint() to work, because the second
write can only happen after the first write has been committed and then *acke
Hi,
>From what I understand, it seems that you are getting bottlenecked by the
network. You are right that gRPC allows only one outstanding write at any
given time but that decision itself probably won't affect the throughput
much. If the application does not buffer the messages, it would inste
