Is your feature request related to a problem?
Yes. Senders can trivially OOM a peer with an unending sequence of non-empty stream transactions with the FLAG_MESSAGE_DATA_IS_PARTIAL flag set.
Describe the solution you'd like
grpc-binder should establish a default value for client and server maxInboundMessageSize(). If a receiver sees a transaction that would cause the next message to exceed this limit, it should "out of band close" the stream with RESOURCE_EXHAUSTED.
Describe alternatives you've considered
None
Additional context
Even with stream flow control receivers must ack transactions whenever the application has request()ed at least one message. That design had been relying on this message-layer limit but grpc-binder doesn't seem to implement one.
Is your feature request related to a problem?
Yes. Senders can trivially OOM a peer with an unending sequence of non-empty stream transactions with the
FLAG_MESSAGE_DATA_IS_PARTIALflag set.Describe the solution you'd like
grpc-binder should establish a default value for client and server
maxInboundMessageSize(). If a receiver sees a transaction that would cause the next message to exceed this limit, it should "out of band close" the stream withRESOURCE_EXHAUSTED.Describe alternatives you've considered
None
Additional context
Even with stream flow control receivers must ack transactions whenever the application has
request()ed at least one message. That design had been relying on this message-layer limit but grpc-binder doesn't seem to implement one.