[binder] Handle inbound flow control#27228
Conversation
TaWeiTu
added
the
release notes: no
TaWeiTu
force-pushed
the
flow-control-inbound
branch
from
752f832 to
5e18e35
Compare
|
I think we will want to raise this topic with Java team first before we commit an implementation. Can you open a PR at grpc/proposal to add this flow control spec to the wire format doc? (I think 4~5 sentences to briefly explain this should be enough) |
| } | ||
| gpr_log(GPR_INFO, "msg_data = %s", msg_data.c_str()); | ||
| transport_stream_receiver_->NotifyRecvMessage(code, std::move(msg_data)); | ||
| message_buffer_[code] += msg_data; |
There was a problem hiding this comment.
I wonder if there exists a hint somewhere (ex. initial metadata) telling us expected total message size? So that we don't need to resize the message buffer
There was a problem hiding this comment.
I'm not sure if there's any since this hint won't make sense in streaming call scenario.
| return binder_->Transact(BinderTransportTxCode(tx.GetTxCode())); | ||
| } | ||
|
|
||
| absl::Status WireWriterImpl::Ack(size_t num_bytes) { |
There was a problem hiding this comment.
We reports total number of bytes received in this RPC call?
Again, we better document this in wire format doc..
There was a problem hiding this comment.
Yeah I didn't find any document about this behavior. This is just what the Java implementation did.
There was a problem hiding this comment.
I've added this to the gRFC PR.
Opened grpc/proposal#258. |
TaWeiTu
force-pushed
the
flow-control-inbound
branch
4 times, most recently
from
755d547 to
f830398
Compare
TaWeiTu
force-pushed
the
flow-control-inbound
branch
from
f830398 to
d9cb0f9
Compare
copybara-service
bot
added
the
imported
2 participants
Tested locally with a Java server.