ejona@: "The debug message in GOAWAY has been very helpful for HTTP/2. (Obviously, old clients wouldn't observe any new strings included.)"

I want to avoid restarting client/server when certificates/trust stores are updated periodically. I see certificate provider plugin framework using file_watcher can potentially help me achieve that.

I created the following bootstrap config

{
  "xds_servers": [
    {
      "server_uri": "127.0.0.1:33333",
      "channel_creds": [
        {
          "type": "insecure"
        }
      ],
      "server_features": [
        "xds_v3"
      ]
    }
  ],
  "node": {
    "id": "grpc-proxyless"
  },
  "certificate_providers": {
    "default": {
      "plugin_name": "file_watcher",
      "config": {
        "certificate_file": "/path/to/server-cert.pem",
        "private_key_file": "/path/to//server-key.pem",
        "ca_certificate_file": "/path/to//ca-cert.pem",
        "refresh_interval": "3600s"
      }
    }
  }
}

Since bootstrap file MUST include xds_servers address, I wonder how does this approach makes it a generic alternative to the SDS server/agent based solution and eliminates the dependency on the SDS protocol as claimed here. ANy example to demonstrate that, will help make it clear.

Also, I do NOT want to use xDS control plane. But I am trying to find a way to use file_watcher plugin independent xDS.

.Net core GRPC server is not connected with android and react native client, it throws unavailable, when connected with node js grpc server it works.

From example and kinds of code, I know client setup channel by provide a transport, then call the service. If service want to send data to client at real time, we had to let client maintain the stream call on the channel thru hearbeat. In fact, in most of time, service do not need send data to client. So seemed, it waste some resource to maintain the status in standby.
Also, the API to send data to client seemed not reasonable, and I expect service can call client thru RPC like client did.
So, this is the most popular usecase, However, in my device(run as client), which it has no public ip in internet, so it is no way to setup service (I expect my device run as both client and service) in my device side. Is it possible, client side can setup a service which the server side can call it? In code, Can we setup a service by reuse the channel under a stable transport used already by client call?

I just need a possibility of GRPC protocol, if it is yes, I can deep go thru the grpc core to target this implementation.

Thanks,
Tom Xiao

A few years ago a Peer-to-peer Extension to HTTP/2 was proposed at the IETF. I believe gRPC is often deployed internally, where playing with new features like this is possible.
It may be worth considering there, if this allows optimizations to your protocol, that would make it worth while to try this out and give feedback to the Author.

I wrote up some thoughts on interesting implications it has here for relative URLs.

I found that iana allows registration for custom mime types https://www.iana.org/assignments/media-types/media-types.xhtml#application, should gRPC register their types there?

From https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md#requests this should be "application/grpc", "application/grpc-protobuf", etc.

It's not the proposal, but a comment/suggestion to an existing document which predates grpc/proposal - the service config. I thought that the issue here would be the best medium to discuss it.

  // Load balancing policy name.
  // Supported values are 'round_robin' and 'grpclb'.
  // Optional; if unset, the default behavior is pick the first available
  // backend.
  // Note that if the resolver returns only balancer addresses and no
  // backend addresses, gRPC will always use the 'grpclb' policy,
  // regardless of what this field is set to.
  'loadBalancingPolicy': string,

I find loadBalancingPolicy a bit limiting. First of all, it supports only round_robin and grpclb. Secondly, in the case when it's no present, it users the default of pick_first loadbalancer.

This basically makes it impossible to use with custom load balancer implementations that are not based on grpclb.

Could we relax this requirement and allow arbitrary load balancer names as well as change the default? With the default option, I'm suspecting that the documentation might be just confusing and the default won't be pick_first BUT what's statically set in code (eg.: in java if you set managedChannelBuilder.loadBalancerFactory(new Foobar()) it'll be used as a fallback if servic config doesn't specify override).

@markdroth what do you think?

protocolbuffers/protobuf#16889
@markdroth
@ncteisen

I have addressed some hard problems hardly tracked by grpc group in my personal blog. Here is the relevant article: https://yiakwy.github.io/blog/2017/10/01/gRPC-C-CORE. Feel free to assemble it in.

Hi gRPC folks,

the Bazel team is considering adopting the gRFC workflow to do design reviews. One thing I was wondering about was this part:

Once the APPROVER is assigned, the OWNER needs to start a discussion on grpc-io and update the PR with the discussion link. After this is done, the OWNER should update the gRFC to the state of In Review. It is expected that the APPROVER will help the OWNER along this process as needed.

Question: Why do you separate discussions of the gRFC from the PR and handle them via the mailing list? On a first look, it seems like if you'd do them directly on the PR, you could refer to individual parts of the doc more easily. However, I'm sure you thought this through and have some experience in how these discussions go and thus, why mailing lists are preferable for this.

Could you explain the reasoning behind this, so that we can learn from it?

Greetings,

I want to start a discussion on the following proposal (before I create PR).

Thanks for your time.

GRPC record proposal

RFC 5507 lays down guidelines for how to use the DNS as a service that wants to store information in it. Quoting the Abstract :

Abstract

This note discusses how to extend the DNS with new data for a new
application. DNS extension discussions too often focus on reuse of
the TXT Resource Record Type. This document lists different
mechanisms to extend the DNS, and concludes that the use of a new DNS
Resource Record Type is the best solution.

The whole RFC is a good read, on the topic of prefixing a name, gRPC uses _grpc_config it says in section 3.2 that this creates problems with wildcards.

As such I want to propose we ask IANA for a new RR type with the following name and semantics:

GRPC <version:8 bits> <reserved: 16 bits> <txt-rdata>

Those 8 and 16 bit fields might be overkill and we can just copy the TXT record semantics verbatim.

We drop the _gprc_config prefix and just provision these GRPC records under the name we query. As we own the record type we can also drop the grpc-config= prefix used in the TXT RDATA, simplifying that a bit as well.

I'm willing to do the heavy lifting here and fix up the Go code (I'm most proficient in that
language) and fix a few other inefficiencies in that code path.

Which adds versioning to quickly sort and filter GRPC records. So this new record will only add
a two, one octet fields and for the rest follow the TXT semantics. I.e. intial record will look like:

www.example.org. IN GRPC 0 0 "<json payload>"

if you're initially looking up www.example.org.

Since L38-objc-api-upgrade.md seems merged in first.