Use Cronet underneath GRPC

698 views
Skip to first unread message

ashish tiwari

unread,
Sep 11, 2020, 7:21:56 PM9/11/20
to grpc.io
Is it possible to use Cronet underneath GRPC for quic support?

Yulin Liang

unread,
Sep 11, 2020, 7:53:33 PM9/11/20
to grpc.io
Hi Ashish, if you use gRPC-Objc, you can simply switch to Cronet transport by setting callOptions.transportType == GRPCTransportTypeCronet. If you are using gRPC-C++, you also can use Cronet underneath GRPC, here's an example to use gRPC with Cronet native interface:

```
struct Cronet_Engine* cronetEngine = createEngineFunc(....);
// get stream_engine ptr for gRPC-cronet
stream_engine* stream_engine = Cronet_Engine_GetStreamEngine(cronetEngine);

std::shared_ptr<grpc_impl::ChannelCredentials>credentials = ::grpc::CronetChannelCredentials(stream_engine);

// create cronet channel
std::shared_ptr<::grpc::Channel> channel = ::grpc::CreateCustomChannel(_endpoint, credentials, _args);

// create stub with cronet channel
auto stub = SomeService::NewStub(channel);
// make async RPC calls with stub...
```

ashish tiwari

unread,
Sep 11, 2020, 7:59:08 PM9/11/20
to grpc.io
is Cronet transport available for GRPC C# as well? I am looking into a gaming application where I would like to use GRPC C#. I am looking into a possible ways to use Cronet for Quic. If it is not supported, is there a way that I can use any other UDP client/transport underneath GRPC?

ashish tiwari

unread,
Sep 18, 2020, 1:45:37 PM9/18/20
to grpc.io
Hi,

  Can someone please help with the previous question? I am trying to use GRPC C# on unity for gaming application and looking into possible ways to use Cronet or any other UDP underneath GRPC.

Yulin Liang

unread,
Sep 18, 2020, 2:05:59 PM9/18/20
to ashish tiwari, grpc.io, Jan Tattermusch
Hi Ashish,

I'm not familiar with gRPC C#, I've cced the owner of gRPC-C#, but he's on vacation now. I am not pretty sure but it looks like gRPC-C# doesn't support Cronet transport for now.

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/cce84873-b208-4811-9fca-dcbe08fdbf40n%40googlegroups.com.

ashish tiwari

unread,
Sep 18, 2020, 2:58:52 PM9/18/20
to grpc.io
Thanks for the response!! I will wait for the response. Basically based on document https://grpc.github.io/grpc/core/md_doc_core_transport_explainer.html, Cronet transport is supported or a new transport can be implement. So just to provide more clarification, I am trying to find out if that is possible for GRPC C# as well and if not supported right now is there a plan to support it in future? Also, Since it mentions that we can implement our own custom transport, does that mean we can implement transport based on UDP client and how much effort that would require? Also, is it possible to expose underlying Http Client currently used with GRPC for other purposes as well without have RPC layer?

ashish tiwari

unread,
Sep 28, 2020, 1:19:03 PM9/28/20
to grpc.io
Hi,

   Just wanted to follow up and see if Jan Tattermusch is back from vacation and help me with the query I have.

Eric Gribkoff

unread,
Sep 28, 2020, 1:39:33 PM9/28/20
to ashish tiwari, grpc.io
Hi,

Jan is not back just yet but I believe I can largely answer your questions:

1) gRPC C# does not support using Cronet as the underlying transport (at least, I could not find any API in the C# implementation for enabling Cronet, which I'm pretty sure would be a pre-requisite). I'm not aware of all the architectural details of how C# is built on top of gRPC core, but I think it should be possible to wrap the Cronet transport and expose an API to use it via C# (caveat: this has worked for other languages, but there could be blockers for doing so in C#) . I suggest filing a feature request for Cronet with C# support at github.com/grpc/grpc.

2) Technically you could implement your own transport based on a UDP client, but I'm pretty sure the core APIs for this are not considered public/stable, meaning that they are intended for the interaction between core and the wrapped languages and could potentially change. I would expect this approach to be a significant amount of work requiring detailed knowledge of some gRPC internals. If you do choose to go this route, I would suggest starting another email thread to discuss whether/how it's advised for gRPC users to actually rely on the transport API (I don't primarily work on core so not sure about best practices here).

3) The http/2 client inside of gRPC core is not exposed for use without the RPC layer.

Best,

Eric 

Reply all
Reply to author
Forward
0 new messages