Would disabling the keepalive option on the server side not resolve the
issue? If the server is sending a keepalive, which the client is not
replying to, causing the server to close the transport, then it seems
disabling keepalive on the server (which is enabled by default every 2
hours) can resolve the issue. Is there a timeout on long-lived streams?
Because if there isn't, and I can just keep the stream open, then I don't
need keepalive to be enabled on the server.
In my situation above the server and client are both on the same machine
that is being put to sleep (the server is just a Windows service). So the
"other side" is just the same laptop.
Thanks.
On Tuesday, 19 October 2021 at 07:19:27 UTC+1 mor...@gmail.com wrote:
> I believe it's an expected behavior: your laptop cannot correctly reply to
> any messages or HTTP/2 control frames while sleeping, so terminating a call
> seems like a quite reasonable thing to do.
> I don't know low level details of HTTP/2 stream control, though, so
> hopefully someone with a better knowledge in this area can give a better
> answer.
> Furthermore, it may depend on TCP socket options: if the other side
> performs TCP keep-alive checks and notices that your laptop is gone, then
> it will terminate the connection.
>
> Cheers!
> On Monday, October 18, 2021 at 6:38:38 PM UTC+7 IIFE wrote:
>
>> Hi,
>>
>> I've got a sync C++ client that opens a long lived bidirectional stream
>> to a sync C++ server. I'm seeing an issue where if I keep my client open
>> and then put my machine to sleep, the connection is terminated a number of
>> hours. Here are the logs I got.
>>
>> I connected the client at 00:25, and then got the following log:
>> 18/10/2021 03:07:48.578
>> File: src\core\ext\transport\chttp2\transport\chttp2_transport.cc
>> Line: 2871
>> Message: ipv4:127.0.0.1:51656: Keepalive watchdog fired. Closing
>> transport.
>>
>> Then at the time I woke up my machine from sleep mode, I saw the
>> following log:
>> 18/10/2021 09:22:15.372
>> src\core\lib\security\transport\security_handshaker.cc
>> Line: 183
>> Message: Security handshake failed:
>> {"created":"@1634545335.372000000","description":"Handshake read
>> failed","file":"src\17cc203898-db2679e7f2.clean\src\core\lib\security\transport\security_handshaker.cc","file_line":425,"referenced_errors":[{"created":"@1634545335.372000000","description":"TCP
>>
>> stream shutting
>> down","file":"src\17cc203898-db2679e7f2.clean\src\core\lib\iomgr\tcp_windows.cc","file_line":228,"referenced_errors":[{"created":"@1634545334.503000000","description":"Handshake
>>
>> timed
>> out","file":"src\17cc203898-db2679e7f2.clean\src\core\lib\channel\handshaker.cc","file_line":163}]}]}
>>
>> I haven't set GRPC_ARG_KEEPALIVE_TIME_MS on the client channel, which
>> according to the documentation is disabled by default. Do I need to
>> configure keepalive settings on the client to resolve this issue, or is
>> there something else going on?
>>
>> Thanks
>>
>>
--
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/grpc-io/bbc4c880-0530-44c7-96fd-9e5ecffd4817n%40googlegroups.com.
