A few clarifications that might help to clarify here:

> I am trying send several hundred packets (each ~1MB) over a stream from a 
client to a server.

Do you know the exact number of packets, and the exact size of each packet?

> Every call to  stream.Write(packet) returns immediately.

Can we measure the amount of time it takes for stream.Write calls to 
complete in terms of microseconds or milliseconds?

 > Watching with Wireshark I can see, that not even the first packet has 
left the sending computer. 

This seems unlikely, as we should at least have seen the initial TCP 
handshake packets when the RPC was started. Are you sure that you're 
sniffing the correct network interface, and looking at the correct TCP 
connection?

On Tuesday, August 3, 2021 at 8:49:38 AM UTC-7 tobias.krueger wrote:

> Hi, 
> we have encountered some strange behaviors using the Write method of the 
> sync API.
>
> I have two effects that might be different, but perhaps some understanding 
> about the sync API might help.
> Both are related to slow / aborting connections.
>
>    1. I am trying send several hundred packets (each ~1MB) over a stream 
>    from a client to a server.
>    The network is using a custom radio module with a very low bandwidth 
>    like Wi-Fi direct.
>    Every call to  stream.Write(packet) returns immediately.
>    Even the stream.WriteLast returns within some seconds.
>    Watching with Wireshark I can see, that not even the first packet has 
>    left the sending computer. 
>    That means all packets are buffered in my system.
>    
>    Is there any way using the sync API to control/limit the buffering?
>    
>    2. In the opposite we encounter sometimes a blocking of the server's 
>    Write method when streaming very small packets to the client.
>    This can be reproduced when I pull the client's network cable.
>    Then the server's Write call is blocked for ~8 seconds
>
> On the on hand I can flood the sync API and get no backpressure at all, on 
> the other hand the Write call gets blocked for several seconds.
>
> Any ideas to get a better understanding of the behavior?
>
> Anything I can do without switching to the async API?
>
> Thanks
> Tobias
>

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/6f376b51-3209-46f8-acc4-4b5ee82074d4n%40googlegroups.com.

Reply via email to