I created a PR for this:
https://github.com/grpc/grpc/pull/28506
Op donderdag 6 januari 2022 om 15:02:11 UTC+1 schreef John Forensics:
> Still getting closed:
>
> On windows gRPC is handled using WSASend asynchronous IO. When reaching a
> TCP congested situation WSASend should report *WSAEWOU
Still getting closed:
On windows gRPC is handled using WSASend asynchronous IO. When reaching a
TCP congested situation WSASend should report *WSAEWOULDBLOCK *however in
WINE, the gRPC usage of WSASend always reports "0"
grep "Ret ws2_32.WSASend" /tmp/stderr | sort | uniq -c
1 0d4:
Could one of the developers please elaborate on the case where:
* The sender has been blocked (shortly) on a closed TCP Window leaving a
large set of gRPC chunks waiting at the HTTP2 stream sender side
* The receiver has not send a OUTBOUND WINDOW_UPDATE to signal its OK to
send more data.
My c
So the stream is stalled as the congestion window is closed. Just verified
with tcpdump and tcptrace, and can confirm thats the problem.
https://github.com/grpc/grpc/blob/2e3e3ccc3d5c40010a6ad6f824a5024176a7/src/core/ext/transport/chttp2/transport/writing.cc#L449
This explains why excessive
After sending some data (about 4 chunks of 16k of a single 1Mb gRPC
message) the HTTP2-stream seems to be put on the "stalled" list. (Whatever
that may be).
World.Hello World.Hello World.Hello World.Hello
World.Hello World.Hello World.Hello World.Hello
World
I managed to extract some logging, the python side seems to send a too
large frame.
[id: 0x0e0792ca, L:/127.0.0.1:43718 - R:localhost/127.0.0.1:60630] Sent
GOAWAY: lastStreamId '2147483647', errorCode '6', debugData 'Frame length:
2165320 exceeds maximum: 16384'. Forcing shutdown of the connect
