I believe that we use PING frames to keep connections alive while they are otherwise idle. I wouldn't expect to need any PINGs when other data is moving across the connection. Have you tried observing an otherwise idle channel for PING frames?
On Fri, Feb 17, 2017 at 11:08 AM Francesco Lazzarino <flazzar...@gmail.com>
wrote:
> Michael,
>
> Thanks for the reply, I tried passing those options thusly:
>
> var sClient = new services.SClient('localhost:50051',
> grpc.credentials.createInsecure(), {
> "grpc.http2.min_time_between_pings_ms": 100,
> "grpc.http2.max_pings_without_data": 0
> });
>
> I connected to the server for 10 seconds, I observed (via wireshark http2)
> DATA frames from an rpc call, but no PING frames. I had expected to see
> about 200 PING frames: 10 seconds * 10 per second * 2 (req and rep)
>
> To verify the ability to observe PING frames I ran the following go code
> against the same server (nodejs + gRPC)
>
> package main
>
> import (
> "context"
> "fmt"
> "log"
> "net"
>
> "golang.org/x/net/http2"
> )
>
> func main() {
> fmt.Println("PING")
> tp := http2.Transport{}
>
> log.Println("dialing server")
> conn0, err := net.Dial("tcp", "localhost:50051")
> if err != nil {
> log.Fatal(err)
> }
>
> conn, err := tp.NewClientConn(conn0)
> if err != nil {
> log.Fatal(err)
> }
>
> for i := 0; i < 2; i++ {
> log.Println("PING", i)
> if err := conn.Ping(context.TODO()); err != nil {
> log.Fatal(err)
> }
> }
> }
>
> I observed 4 PING frames as expected.
>
> Am I doing something wrong?
>
> On Thursday, February 16, 2017 at 8:25:12 PM UTC-6, Michael Lumish wrote:
>
> You should have no problems with this approach, but it also shouldn't be
> necessary. gRPC already uses HTTP2 pings to keep channels alive while
> they're otherwise idle. If you're still seeing disconnects, there are a
> couple of channel options you can set (they go into an object in the third
> argument to the Client constructor). The list of them is defined here:
> https://github.com/grpc/grpc/blob/master/include/grpc/impl/codegen/grpc_types.h#L148.
> Specifically, modifying "grpc.http2.min_time_between_pings_ms"
> and "grpc.http2.max_pings_without_data".
>
> In addition, gRPC automatically reconnects dropped TCP connections, so if
> your channel is idle with no ongoing calls, you shouldn't even notice
> connection drops.
>
> On Tue, Feb 14, 2017 at 7:36 PM Francesco Lazzarino <flazz...@gmail.com>
> wrote:
>
> Hi,
>
> The current node.js module doesn't allow one to pass a Channel object to
> build a client, but it does allow one to access a channel via
> grpc.getClientChannel(…) and .$channel on a client object.
>
> In lieu of an exposed interface to pass a connection or channel, I tried
> out the following hack to allow two clients to share the same channel.
>
> function combineChannels(aClient, bClient) {
> var aChan = grpc.getClientChannel(aClient);
> var bChan = grpc.getClientChannel(bClient);
> if (aChan.getTarget() != bChan.getTarget()) {
> throw "different targets: " + " (a) " + aChan.getTarget() + "; (b)
> " + bChan.getTarget();
> }
>
> if (aChan.getConnectivityState() != 0) {
> throw "bad connectivity state (a): " +
> aChan.getConnectivityState();
> }
>
> if (bChan.getConnectivityState() != 0) {
> throw "bad connectivity state (b): " +
> bChan.getConnectivityState();
> }
>
> bChan.close();
> bClient.$channel = aChan;
> }
>
> Observing with nettop (macOS) shows only 1 connection when hack is in use,
> and 1 per client otherwise. It seems to work as expected, but is any danger
> in doing so? Is there a better way to accomplish this in node.js?
>
>
> FWIW my goal is to have a healthcheck client keep the TCP socket alive in
> case a LB or FW wants to close idle-long-running connections.
>
> Thanks in advance,
>
> – Franco
>
> --
> 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+u...@googlegroups.com.
> To post to this group, send email to grp...@googlegroups.com.
>
>
> Visit this group at https://groups.google.com/group/grpc-io.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/a5f6c9ea-48e4-4d68-a5ab-322c55c15f21%40googlegroups.com
> <https://groups.google.com/d/msgid/grpc-io/a5f6c9ea-48e4-4d68-a5ab-322c55c15f21%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
> --
> 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 post to this group, send email to grpc-io@googlegroups.com.
> Visit this group at https://groups.google.com/group/grpc-io.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/bc92e3c4-b513-419e-bc54-0b7fd27522e7%40googlegroups.com
> <https://groups.google.com/d/msgid/grpc-io/bc92e3c4-b513-419e-bc54-0b7fd27522e7%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
--
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 post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit
https://groups.google.com/d/msgid/grpc-io/CAPK2-4cvm1MptzbcrKrQp2JrRy4gU2B-u9%2ByXpKmvaQkJtbpAA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
smime.p7s
Description: S/MIME Cryptographic Signature
