-
First I would like to clarify that this question is NOT about "gRPC streaming". The following question regards sending the response to a single unary RPC. I am asynchronously reading a large number of entries from a database query into a response message. I would like to avoid buffering the entire response in memory before sending it. It seems like the Body::wrap_stream method should allow me to stream those results as they become available, but I'm not sure how to use it. If I use the default Prost codegen for a |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 2 replies
-
You have to send or return a stream to avoid buffering everything all at once. There are some examples here. |
Beta Was this translation helpful? Give feedback.
-
So, hypothetically, if I had a body that was a 4GB stream of u8s, and I used Body::wrap_stream to generate the body from that, Tonic would still completely buffer the entire 4GB message into memory before sending any packets over the wire? |
Beta Was this translation helpful? Give feedback.
-
That's what I'm asking you. How can I, as a user, make use of the Body::wrap_stream method? If I cannot, then what is the purpose of this method? In general, how can I send a large unary response (likely a repeated field) without needing to buffer the entire response in memory before sending? Is there a solution that could be implemented by just modifying the generated code? Or is this behavior buried deeper inside the Tonic internals? |
Beta Was this translation helpful? Give feedback.
-
Due to the fact that the encoding of a repeated field requires the length value at the beginning, for the use case where I am receiving an unknown number of entries from the database (and each individual entry may be of a variable size due to varint encoding), they cannot be serialized and transmitted "on-demand" within the context of a single message. I would need to receive all of the entries first, calculate the length properly, and then serialize them. This seems to be a restriction of the Protobuf format itself, not of Tonic. Thus I will need to use a gRPC server-side streaming RPC. |
Beta Was this translation helpful? Give feedback.
Due to the fact that the encoding of a repeated field requires the length value at the beginning, for the use case where I am receiving an unknown number of entries from the database (and each individual entry may be of a variable size due to varint encoding), they cannot be serialized and transmitted "on-demand" within the context of a single message. I would need to receive all of the entries first, calculate the length properly, and then serialize them. This seems to be a restriction of the Protobuf format itself, not of Tonic.
Thus I will need to use a gRPC server-side streaming RPC.