zrlw opened a new issue, #15520: URL: https://github.com/apache/dubbo/issues/15520
### Pre-check - [x] I am sure that all the content I provide is in English. ### Search before asking - [x] I had searched in the [issues](https://github.com/apache/dubbo/issues?q=is%3Aissue) and found no similar feature requirement. ### Apache Dubbo Component Java SDK (apache/dubbo) ### Descriptions When a server sends a large volume of data over a stream (e.g., gRPC or HTTP/2) and abruptly closes the stream after transmission, the client may encounter data reception issues (like #15501) due to the following reasons: Premature Stream Closure vs. Graceful Termination: Abrupt Closure (e.g., TCP RST, RST_STREAM in HTTP/2): If the server forcibly terminates the stream (via close() or socket-level resets), pending data in OS/kernel buffers may be discarded. The client detects an unexpected stream reset, treating it as an error (e.g., ECONNRESET). Graceful Closure: The server should signal "end-of-stream" (e.g., END_STREAM flag in HTTP/2, gRPC trailing metadata) to notify the client that transmission is complete. Skipping this step causes the client to await more data indefinitely. Flow Control and Backpressure: Protocols like HTTP/2 use flow-control windows to prevent overwhelming the receiver. If the server sends data faster than the client can process it: The client’s receive window fills, forcing the server to pause. If the server ignores this and closes the stream mid-transmission, the client may miss data still in transit or encounter protocol errors (e.g., FLOW_CONTROL_ERROR). Data Buffering and Fragmentation: Large data is split into smaller frames/packets. If the server closes prematurely: The client may receive partial/incomplete messages (e.g., corrupted gRPC messages missing length prefixes). The client’s parser fails to deserialize fragmented data, throwing exceptions. Protocol-Specific Constraints: gRPC: Requires a trailing metadata frame (with status code) to end the stream. Closing without this frame leaves the client in an ambiguous state (waiting for status). HTTP/2: Abrupt RST_STREAM interrupts mid-flow, signaling CANCEL or INTERNAL_ERROR. The client discards buffered data. Resource Cleanup Timing: When the server closes immediately after sending: Network packets may be lost/reordered (especially under high load). The client’s OS/kernel buffers might not have delivered all data before the closure notification arrives. Solution: Graceful Stream Termination To avoid client-side issues: Signal Completion Explicitly: Use protocol-specific end markers (e.g., gRPC trailing headers, HTTP/2 END_STREAM). Respect Flow Control: Ensure all data is acknowledged by the client before closing. Avoid Forceful Closure: Replace close()/RST_STREAM with a two-step close: Send all data + end-of-stream marker. Wait for client acknowledgment (if applicable). Then close the connection cleanly. In addition to the issue #15501 mentioned above, other modules may exhibit similar vulnerabilities and require thorough investigation. ### Related issues _No response_ ### Are you willing to submit a pull request to fix on your own? - [ ] Yes I am willing to submit a pull request on my own! ### Code of Conduct - [x] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
