Re: [grpc-io] Flush dnsmasq cache on IP address failure

[Frédéric Martinsons]

Yes, as you tell, if an upstream server have the entry in cache, this will
not renew anything until the next ttl expiration.

Le lun. 17 juil. 2023, 19:49, 'apo...@google.com' via grpc.io <
grpc-io@googlegroups.com> a écrit :

> I agree that this seems outside of the scope of the grpc library.
>
> But +1 that you could in theory use a custom name resolver to implement
> some behavior like this.
>
> Also +1 that the --clear-on-reload plus SIGHUP option may be useful here.
>
> I'm curious though: suppose you can flush the local DNS cache, can you
> guarantee that there are no more caches upstream?
> On Wednesday, July 12, 2023 at 10:38:27 AM UTC-7 Richard Belleville wrote:
>
>>
>> Depending on which language you're using, you could use the custom name
>> resolver interface <https://grpc.io/docs/guides/custom-name-resolution/>
>> to implement this behavior yourself.
>> On Wednesday, July 5, 2023 at 12:53:43 PM UTC-7 Gmail wrote:
>>
>>> Thanks Frederic
>>> I understand that. But I only want to do it when grpc has a connection
>>> failure. Is there an already existing mechanism to do that.?
>>>
>>> On Jul 5, 2023, at 12:37 PM, Frédéric Martinsons 
>>> wrote:
>>>
>>> 
>>>
>>> I think this is totally unrelated to grpc but for what it worth, if you
>>> control your dnsmasq, you can use --clear-on-reload option and send a
>>> SIGHUP to dnsmasq process to reload the cache.
>>>
>>> Le mer. 5 juil. 2023, 21:24, Ramanujam Jagannath  a
>>> écrit :
>>>
>>>> Backgrounder - Our device connects to an AWS static IP. We use dnsmasq
>>>> on device to provide lookup services for downstream devices. Currently we
>>>> are planning to use a long. DNS TTL on AWS to avoid too many DNS lookups
>>>> from on field devices. The on-field devices use a grpc  connection to
>>>> maintain long standing tcp connections. We do have multiple availability
>>>> zones and so a DNS resolution does return 4 IP addresses
>>>>
>>>> Problem - When an IP address fails(on AWS) the grpc client will retry
>>>> and re-resolve. But because we have dnsmasq on device it will send a cached
>>>> address - which is potentially faulty.
>>>>
>>>> Solution - This can be resolved by flushing the dnsmasq cache on
>>>> device. But is there a way to flush the dnsmasq cache on device on
>>>> connection failure only? grpc under the hood uses c-ares which in our case
>>>> goes to the dnsmasq proxy on device.
>>>>
>>>> Any solutions/thoughts. Someone must have encountered this problem
>>>> before?
>>>>
>>>> --
>>>> 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/75d68762-eb58-4400-b8e1-3584f6bd6e51n%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/grpc-io/75d68762-eb58-4400-b8e1-3584f6bd6e51n%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>> --
> 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/4a0815f5-f70a-4ee4-8b8c-77e8ea8a7909n%40googlegroups.com
> <https://groups.google.com/d/msgid/grpc-io/4a0815f5-f70a-4ee4-8b8c-77e8ea8a7909n%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
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/CA%2BcAkeqbUwBZK_cf040LQqT0Ss6-zxN-7%2BxchVmRRQN0zU%2B5kQ%40mail.gmail.com.

Re: [grpc-io] Flush dnsmasq cache on IP address failure

[Frédéric Martinsons]

I think this is totally unrelated to grpc but for what it worth, if you
control your dnsmasq, you can use --clear-on-reload option and send a
SIGHUP to dnsmasq process to reload the cache.

Le mer. 5 juil. 2023, 21:24, Ramanujam Jagannath  a
écrit :

> Backgrounder - Our device connects to an AWS static IP. We use dnsmasq on
> device to provide lookup services for downstream devices. Currently we are
> planning to use a long. DNS TTL on AWS to avoid too many DNS lookups from
> on field devices. The on-field devices use a grpc  connection to maintain
> long standing tcp connections. We do have multiple availability zones and
> so a DNS resolution does return 4 IP addresses
>
> Problem - When an IP address fails(on AWS) the grpc client will retry and
> re-resolve. But because we have dnsmasq on device it will send a cached
> address - which is potentially faulty.
>
> Solution - This can be resolved by flushing the dnsmasq cache on device.
> But is there a way to flush the dnsmasq cache on device on connection
> failure only? grpc under the hood uses c-ares which in our case goes to the
> dnsmasq proxy on device.
>
> Any solutions/thoughts. Someone must have encountered this problem before?
>
> --
> 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/75d68762-eb58-4400-b8e1-3584f6bd6e51n%40googlegroups.com
> 
> .
>

-- 
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/CA%2BcAkepsZcb7wzSE%2Bp61%3D%3DGNW8mSaeoLvNp2tM9r6dU8fF-yBQ%40mail.gmail.com.

Re: [grpc-io] Re: USB transport

[Frédéric Martinsons]

Hello Tom,

Two years ago, I managed to get an USB channel based on grpc 1.35 , you can
see this work on my personal grpc fork:
https://github.com/fmartinsons/grpc/tree/grpc-usb-1.35.0

Sadly, from what I remember, I didn't manage to make it work on my target
machine (I got spurious USB disconnections).
I didn't have the time to continue and I don't plan to work on it again but
feel free to get the code and try it by yourself.

I'd appreciate it greatly if you manage to have a working code and publish
it.

Have a nice day.

On Wed, 10 May 2023 at 05:26, Tom Stoffer  wrote:

> Hi Frédéric
>
> I would be interested in seeing this MR, we are looking at implementing
> something like this. Did your code get used in production?
>
> Tom
>
> On Thursday, February 25, 2021 at 12:07:01 AM UTC+13 Frédéric Martinsons
> wrote:
>
>>
>> Anybody there ?
>>
>> I think I'll made the above mentionned merge request and we will see if
>> it is accepted or not.
>> On Saturday, 13 February 2021 at 11:49:05 UTC+1 Frédéric Martinsons wrote:
>>
>>>
>>> There is another thread talking about USB support:
>>> https://groups.google.com/g/grpc-io/c/MZCVUShRMkM/m/y3T_fs8iAQAJ but I
>>> cannot answer there since my messages are automatically deleted (don't know
>>> why)
>>>
>>>
>>> On Saturday, 13 February 2021 at 09:55:42 UTC+1 Frédéric Martinsons
>>> wrote:
>>>
>>>> Hello all,
>>>>
>>>> Some years ago we had the exact same use case where we have an android
>>>> application which drive an embedded devices (in USB Accessory Mode). The
>>>> only way to communicate with this device is through USB channel and we
>>>> wanted to use gRPC.
>>>> So we develop the USB transport channel in gRPC bask in 2018 (based on
>>>> gRPC v1.13.0).
>>>> The guy from our teams that made these patches had now leaved but I'll
>>>> be glad to submit a patch series if the USB support is still foreseen to be
>>>> support but I may not be able to answer all the questions about tricks that
>>>> came in this code.
>>>>
>>>> Do you want to receive a merge request ?
>>>>
>>>> Thanks for the good works gRPC guru.
>>>>
>>>> On Thursday, 8 February 2018 at 17:18:21 UTC+1 robert...@gmail.com
>>>> wrote:
>>>>
>>>>> Mark, as Abhishek mentioned, it is quite useful in cases where a
>>>>> target device (usually embedded) has no networking. Thanks Vijay, I'll 
>>>>> have
>>>>> a look at your suggestions.
>>>>>
>>>>> Regards
>>>>> /Robert
>>>>>
>>>>> 2018-02-07 22:31 GMT+01:00 'Vijay Pai' via grpc.io <
>>>>> grp...@googlegroups.com>:
>>>>>
>>>>>> As Mark mentioned, it's not on our roadmap, but if you wanted to put
>>>>>> one together, I can suggest
>>>>>> https://github.com/grpc/grpc/blob/master/doc/core/transport_explainer.md
>>>>>> for an idea of what transports need to do. If the goal is a simple
>>>>>> message-oriented transport without reference to complex flow control, I 
>>>>>> can
>>>>>> suggest using the in-process transport as a model for how to build a
>>>>>> transport, as it's only a few hundred lines of code and implements the
>>>>>> transport ops required to actually have working RPCs for its context; 
>>>>>> this
>>>>>> might make a lot of sense if your controller is memory-mapped.
>>>>>> Alternatively, if your controller is mapped as a file, a path forward 
>>>>>> might
>>>>>> be to make a new endpoint akin to the UDS endpoint. This would mean that
>>>>>> you'd be speaking HTTP/2 over your HID, but again it may be a fairly 
>>>>>> simple
>>>>>> integration.
>>>>>>
>>>>>> Good luck!
>>>>>>
>>>>>> - Vijay
>>>>>>
>>>>>> On Friday, February 2, 2018 at 8:51:23 PM UTC-8, Robert Bielik wrote:
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Has there been any work on using USB HID as a gRPC transport ?
>>>>>>>
>>>>>>> Regards
>>>>>>> /Robert
>>>>>>>
>>>>>>> --
>>>>>> You received this message because 

Re: [grpc-io] USB as a transport channel for gRPC

[Frédéric Martinsons]

Hello Thong,

Sure, you can find a work in progress on my personnal fork (branch
grpc-usb-1.35.0: https://github.com/fmartinsons/grpc/tree/grpc-usb-1.35.0) .

The code compils and run on my target machine (an embedded linux box with a
core i3) but for the moment I'm not able to make my android client talk
with the server (I have spurious USB disconnection at server side).  I had
not the time to go further on my investigations but I'm willing to pursue
as soon as possible.

Anyway feel free to use this code but be warned it may not work out of the
box. I you find bug or improvements on that, I will be very happy to  get
them in a merge request (or by other means).

On Tue, 20 Apr 2021 at 04:15, Thong Nguyen  wrote:

> Hi  Frédéric Martinsons,
>
> I have need to use grpc over usb and it is very interesting that you had
> done it. Could you please share it with us?
> Many thanks!
>
> Thong.
>
> On Saturday, February 27, 2021 at 3:00:34 AM UTC+9 frederic@gmail.com
> wrote:
>
>> Thanks Nicolas, I will read the doc you pointed and make the fork in the
>> coming days (weeks maybe :p).
>>
>> One last question that come to my mind. Like I said in the above
>> mentioned thread, the person who develop the patch is gone and I'm taking
>> responsability for the code.
>> I can make it compile on Linux, test it for our use cases (Android device
>> in accessory mode) but I don't know if the patches will be correct towards
>> coding rules or grpc philosophy.
>> And, if I understood correctly, doing the fork means that no peer review
>> will be done to comment and accept the patches but I'm willing to have
>> advices about how to do better integration inside gRPC world.
>> Si here is my question (finally) : do you think it is possible to have
>> review from gRPC devs people?
>>
>>
>>
>>
>>
>> Le ven. 26 févr. 2021 à 18:23, Nicolas Noble  a
>> écrit :
>>
>>> I would direct you to
>>> https://github.com/grpc/grpc-community/blob/master/grpc_ecosystem.md
>>> for details on how to proceed, but, in short:
>>>
>>> - transfer of ownership is a very straightforward process using github:
>>> https://docs.github.com/en/github/administering-a-repository/transferring-a-repository
>>> - being in the ecosystem organization means way less stringent rules;
>>> you get to decide what's best for building and distributing your version.
>>> If you wish to restrict it to Linux, and remove all of the wrapped
>>> languages but C/C++, go for it.
>>>
>>> On Thu, Feb 25, 2021 at 10:13 PM Frédéric Martinsons <
>>> frederic@gmail.com> wrote:
>>>
>>>> Ok I understand the point but I missed some details:
>>>>- I can fork grpc to my github account but how to give it to the
>>>> grpc-ecosystem ?
>>>>- For adding libusb dependency, am I obliged to go through
>>>> third_party git submodule and compile libusb from sources ? Or can I only
>>>> relies on system package (if so , where do I put it, directly in
>>>> CMakeLists.txt) ?
>>>>- I have only a test setup running on unix , will it be acceptable
>>>> for this fork to be only unix compatible ? Or do I need to support windows,
>>>> apple ... ?
>>>>
>>>> Thanks again for your quick answer by the way. Have a nice day !
>>>>
>>>> On Friday, 26 February 2021 at 04:12:32 UTC+1 pixel...@gmail.com wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>>   While the idea is interesting and has merit, adding a libusb
>>>>> dependency into a network-oriented library seems counter productive and
>>>>> would likely complexify our build, test, distribution, and maintenance
>>>>> burden. This seems like an endeavor that'd be much more appropriate as a
>>>>> specific fork; call it grpc-usb if you want, and it'd ONLY have USB as a
>>>>> transport mechanism. We wouldn't mind hosting it in our grpc-ecosystem
>>>>> organization for instance.
>>>>>
>>>>> On Thu, Feb 25, 2021 at 8:35 AM Frédéric Martinsons <
>>>>> frederic@gmail.com> wrote:
>>>>>
>>>>>> Hello guys, like I said in a previous message (
>>>>>> https://groups.google.com/g/grpc-io/c/rCOTPM65A7U) , back in the
>>>>>> day, in my company there was a use cases to having gRPC work through usb.
>>>>>> We made patches for that and we would like to submit it to the project.
>>>>>>
>>>>>> Two questio

Re: [grpc-io] USB as a transport channel for gRPC

[Frédéric Martinsons]

Thanks Nicolas, I will read the doc you pointed and make the fork in the
coming days (weeks maybe :p).

One last question that come to my mind. Like I said in the above mentioned
thread, the person who develop the patch is gone and I'm taking
responsability for the code.
I can make it compile on Linux, test it for our use cases (Android device
in accessory mode) but I don't know if the patches will be correct towards
coding rules or grpc philosophy.
And, if I understood correctly, doing the fork means that no peer review
will be done to comment and accept the patches but I'm willing to have
advices about how to do better integration inside gRPC world.
Si here is my question (finally) : do you think it is possible to have
review from gRPC devs people?





Le ven. 26 févr. 2021 à 18:23, Nicolas Noble  a
écrit :

> I would direct you to
> https://github.com/grpc/grpc-community/blob/master/grpc_ecosystem.md for
> details on how to proceed, but, in short:
>
> - transfer of ownership is a very straightforward process using github:
> https://docs.github.com/en/github/administering-a-repository/transferring-a-repository
> - being in the ecosystem organization means way less stringent rules; you
> get to decide what's best for building and distributing your version. If
> you wish to restrict it to Linux, and remove all of the wrapped languages
> but C/C++, go for it.
>
> On Thu, Feb 25, 2021 at 10:13 PM Frédéric Martinsons <
> frederic.martins...@gmail.com> wrote:
>
>> Ok I understand the point but I missed some details:
>>- I can fork grpc to my github account but how to give it to the
>> grpc-ecosystem ?
>>- For adding libusb dependency, am I obliged to go through third_party
>> git submodule and compile libusb from sources ? Or can I only relies on
>> system package (if so , where do I put it, directly in CMakeLists.txt) ?
>>- I have only a test setup running on unix , will it be acceptable for
>> this fork to be only unix compatible ? Or do I need to support windows,
>> apple ... ?
>>
>> Thanks again for your quick answer by the way. Have a nice day !
>>
>> On Friday, 26 February 2021 at 04:12:32 UTC+1 pixel...@gmail.com wrote:
>>
>>> Hi,
>>>
>>>   While the idea is interesting and has merit, adding a libusb
>>> dependency into a network-oriented library seems counter productive and
>>> would likely complexify our build, test, distribution, and maintenance
>>> burden. This seems like an endeavor that'd be much more appropriate as a
>>> specific fork; call it grpc-usb if you want, and it'd ONLY have USB as a
>>> transport mechanism. We wouldn't mind hosting it in our grpc-ecosystem
>>> organization for instance.
>>>
>>> On Thu, Feb 25, 2021 at 8:35 AM Frédéric Martinsons <
>>> frederic@gmail.com> wrote:
>>>
>>>> Hello guys, like I said in a previous message (
>>>> https://groups.google.com/g/grpc-io/c/rCOTPM65A7U) , back in the day,
>>>> in my company there was a use cases to having gRPC work through usb. We
>>>> made patches for that and we would like to submit it to the project.
>>>>
>>>> Two questions though:
>>>>   - Is is wanted and will it be acceptable for the project (does it
>>>> worth the shot to rebase and clean ourpatches) ?
>>>>   - If yes, then our patches introduced a libusb dependency (
>>>> https://libusb.info/) and I'm wondering what is the best way to
>>>> introduce that ? In a new third party submodule ? Is there documentation
>>>> about integrating a new submodule because I read
>>>> https://github.com/grpc/grpc/blob/master/third_party/README.md and
>>>> there is not much details except that it trigs a lot of work and
>>>> maintenance.
>>>>
>>>> Thanks in advance for all the insights.
>>>>
>>>> --
>>>> 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/a0f856e9-dc0d-4f5f-82f1-ee2efef6ecd3n%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/grpc-io/a0f856e9-dc0d-4f5f-82f1-ee2efef6ecd3n%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "grpc.io" group.
>> To unsubscribe from this

Re: [grpc-io] USB as a transport channel for gRPC

[Frédéric Martinsons]

Ok I understand the point but I missed some details:
   - I can fork grpc to my github account but how to give it to the 
grpc-ecosystem ?
   - For adding libusb dependency, am I obliged to go through third_party 
git submodule and compile libusb from sources ? Or can I only relies on 
system package (if so , where do I put it, directly in CMakeLists.txt) ?
   - I have only a test setup running on unix , will it be acceptable for 
this fork to be only unix compatible ? Or do I need to support windows, 
apple ... ?

Thanks again for your quick answer by the way. Have a nice day !

On Friday, 26 February 2021 at 04:12:32 UTC+1 pixel...@gmail.com wrote:

> Hi,
>
>   While the idea is interesting and has merit, adding a libusb dependency 
> into a network-oriented library seems counter productive and would likely 
> complexify our build, test, distribution, and maintenance burden. This 
> seems like an endeavor that'd be much more appropriate as a specific fork; 
> call it grpc-usb if you want, and it'd ONLY have USB as a transport 
> mechanism. We wouldn't mind hosting it in our grpc-ecosystem organization 
> for instance.
>
> On Thu, Feb 25, 2021 at 8:35 AM Frédéric Martinsons <
> frederic@gmail.com> wrote:
>
>> Hello guys, like I said in a previous message (
>> https://groups.google.com/g/grpc-io/c/rCOTPM65A7U) , back in the day, in 
>> my company there was a use cases to having gRPC work through usb. We made 
>> patches for that and we would like to submit it to the project.
>>
>> Two questions though:
>>   - Is is wanted and will it be acceptable for the project (does it worth 
>> the shot to rebase and clean ourpatches) ?
>>   - If yes, then our patches introduced a libusb dependency (
>> https://libusb.info/) and I'm wondering what is the best way to 
>> introduce that ? In a new third party submodule ? Is there documentation 
>> about integrating a new submodule because I read 
>> https://github.com/grpc/grpc/blob/master/third_party/README.md and there 
>> is not much details except that it trigs a lot of work and maintenance.
>>
>> Thanks in advance for all the insights.
>>
>> -- 
>> 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/a0f856e9-dc0d-4f5f-82f1-ee2efef6ecd3n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/grpc-io/a0f856e9-dc0d-4f5f-82f1-ee2efef6ecd3n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/634fd52a-e24b-4959-9fad-fa4a4e2080c3n%40googlegroups.com.

Re: [grpc-io] Can we skip Validation of IP or Hostname info within the Cert during the grpc SSL secure connection??

[Frédéric Martinsons]

Sorry I forgot the reply all :(

Le lun. 22 févr. 2021 à 19:58, Frédéric Martinsons <
frederic.martins...@gmail.com> a écrit :

> Overriding (or worst, ignoring) the CN is a bad security practice.
>  It's far better to generate the correct certificate with the correct
> Common Name (or use the SAN, subject alternative name to match the host you
> attend to talk)
>
> Le lun. 22 févr. 2021 à 19:43, Sachin Bharadwaj S <
> ssachinbharad...@gmail.com> a écrit :
>
>> Hi Yang,
>>
>> Have a CN in the certificate and then use SetSslTargetNameOverride()
>> For example, if CN is "test"
>> args.SetSslTargetNameOverride("test");
>>
>> Regards,
>> Sachin
>>
>> On Wed, Feb 10, 2021 at 8:10 AM yang ma  wrote:
>>
>>> *- **Abstract*
>>>
>>> Using the C++ interface, if I setup a server using SslServerCredentials
>>> and just give the grpc::ServerBuilder instance a IP to create the Listening
>>> Port.
>>>
>>> The code of *server-side* is shown below:
>>>
>>>
>>> // Ssl-Cert info of server side encapsulation
>>> grpc::SslServerCredentialsOptions::PemKeyCertPair pkcp = {
>>> serverKey.c_str(), serverCert.c_str() };
>>> grpc::SslServerCredentialsOptions
>>> ssl_opts(GRPC_SSL_REQUEST_CLIENT_CERTIFICATE_BUT_DONT_VERIFY);
>>> ssl_opts.pem_root_certs = clientCert;
>>> ssl_opts.pem_key_cert_pairs.push_back(pkcp);
>>> std::shared_ptr creds;
>>> creds = grpc::SslServerCredentials(ssl_opts);
>>> // Create server listening port
>>> std::string server_address("127.0.0.1:50051");
>>> ServerBuilder builder;
>>> builder.AddListeningPort(server_address, creds);
>>>
>>> And the code of *client-side* is shown below:
>>> // Ssl-Cert info of client side encapsulation
>>> grpc::SslCredentialsOptions ssl_opts;
>>> ssl_opts.pem_root_certs = servercert;
>>> ssl_opts.pem_private_key = clientkey;
>>> ssl_opts.pem_cert_chain = clientcert;
>>> // Client side IP and params setup
>>> std::string hostname{"127.0.0.1:50051"};
>>> std::shared_ptr creds =
>>> grpc::SslCredentials(ssl_opts); grpc::ChannelArguments args;
>>> auto channel = grpc::CreateCustomChannel(hostname creds, args);
>>>
>>> My question is that, the grpc connection between server and client
>>> using IP only works fine without the Ssl secure channel inserted.
>>>
>>> But if I insert the Ssl Credential info as above, error found as below.
>>>
>>>
>>> *- Error Found*
>>>
>>>
>>> *client_side:*
>>>
>>> (base) user@user-machine:~/grpc/examples/cpp/helloworld$GRPC_VERBOSITY=DEBUG
>>> ./greeter_client
>>>
>>>
>>> D0207 16:02:57.197850779 16548 dns_resolver_ares.cc:504] Using ares dns
>>> resolver
>>>
>>> D0207 16:02:57.204809585 16548 security_handshaker.cc:184] Security
>>> handshake failed: {"created":"@1612684977.204796431","description":"Peer
>>> name 127.0.0.1 is not in peer
>>> certificate","file":"~/grpc/src/core/lib/security/security_connector/ssl/ssl_security_connector.cc","file_line":57}
>>>
>>> I0207 16:02:57.204886270 16548 subchannel.cc:1033] Connect failed:
>>> {"created":"@1612684977.204796431","description":"Peer name 127.0.0.1 is
>>> not in peer
>>> certificate","file":"~/grpc/src/core/lib/security/security_connector/ssl/ssl_security_connector.cc","file_line":57}
>>>
>>> I0207 16:02:57.204919892 16548 subchannel.cc:972] Subchannel
>>> 0x55f0ee4cb360: Retry in 993 milliseconds
>>>
>>> 14: failed to connect to all addresses
>>>
>>> Greeter received: RPC failed
>>>
>>>
>>> *server_side:*
>>>
>>> (base) user@user-machine:~/grpc/examples/cpp/helloworld$
>>> GRPC_VERBOSITY=DEBUG ./greeter_server
>>>
>>>
>>> D0207 16:02:43.985391400 16542 dns_resolver_ares.cc:504] Using ares dns
>>> resolver
>>>
>>> I0207 16:02:43.985475962 16542 server_builder.cc:332] Synchronous
>>> server. Num CQs: 1, Min pollers: 1, Max Pollers: 2, CQ timeout (msec): 1
>>>
>>> Server listening on 127.0.0.1:50051
>>>
>>> E0207 16:02:57.200528351 16546 ssl_transport_security.cc:1723] No match
>>> found for server name: 127.0.0.1.
>>>
>>

[grpc-io] USB as a transport channel for gRPC

[Frédéric Martinsons]

Hello guys, like I said in a previous message 
(https://groups.google.com/g/grpc-io/c/rCOTPM65A7U) , back in the day, in 
my company there was a use cases to having gRPC work through usb. We made 
patches for that and we would like to submit it to the project.

Two questions though:
  - Is is wanted and will it be acceptable for the project (does it worth 
the shot to rebase and clean ourpatches) ?
  - If yes, then our patches introduced a libusb dependency 
(https://libusb.info/) and I'm wondering what is the best way to introduce 
that ? In a new third party submodule ? Is there documentation about 
integrating a new submodule because I 
read https://github.com/grpc/grpc/blob/master/third_party/README.md and 
there is not much details except that it trigs a lot of work and 
maintenance.

Thanks in advance for all the insights.

-- 
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/a0f856e9-dc0d-4f5f-82f1-ee2efef6ecd3n%40googlegroups.com.

Re: [grpc-io] Re: USB transport

[Frédéric Martinsons]

Anybody there ? 

I think I'll made the above mentionned merge request and we will see if it 
is accepted or not.
On Saturday, 13 February 2021 at 11:49:05 UTC+1 Frédéric Martinsons wrote:

>
> There is another thread talking about USB support: 
> https://groups.google.com/g/grpc-io/c/MZCVUShRMkM/m/y3T_fs8iAQAJ but I 
> cannot answer there since my messages are automatically deleted (don't know 
> why)
>
>
> On Saturday, 13 February 2021 at 09:55:42 UTC+1 Frédéric Martinsons wrote:
>
>> Hello all,
>>
>> Some years ago we had the exact same use case where we have an android 
>> application which drive an embedded devices (in USB Accessory Mode). The 
>> only way to communicate with this device is through USB channel and we 
>> wanted to use gRPC.
>> So we develop the USB transport channel in gRPC bask in 2018 (based on 
>> gRPC v1.13.0).
>> The guy from our teams that made these patches had now leaved but I'll be 
>> glad to submit a patch series if the USB support is still foreseen to be 
>> support but I may not be able to answer all the questions about tricks that 
>> came in this code.
>>
>> Do you want to receive a merge request ?
>>
>> Thanks for the good works gRPC guru.
>>
>> On Thursday, 8 February 2018 at 17:18:21 UTC+1 robert...@gmail.com wrote:
>>
>>> Mark, as Abhishek mentioned, it is quite useful in cases where a target 
>>> device (usually embedded) has no networking. Thanks Vijay, I'll have a look 
>>> at your suggestions.
>>>
>>> Regards
>>> /Robert
>>>
>>> 2018-02-07 22:31 GMT+01:00 'Vijay Pai' via grpc.io <
>>> grp...@googlegroups.com>:
>>>
>>>> As Mark mentioned, it's not on our roadmap, but if you wanted to put 
>>>> one together, I can suggest 
>>>> https://github.com/grpc/grpc/blob/master/doc/core/transport_explainer.md 
>>>> for an idea of what transports need to do. If the goal is a simple 
>>>> message-oriented transport without reference to complex flow control, I 
>>>> can 
>>>> suggest using the in-process transport as a model for how to build a 
>>>> transport, as it's only a few hundred lines of code and implements the 
>>>> transport ops required to actually have working RPCs for its context; this 
>>>> might make a lot of sense if your controller is memory-mapped. 
>>>> Alternatively, if your controller is mapped as a file, a path forward 
>>>> might 
>>>> be to make a new endpoint akin to the UDS endpoint. This would mean that 
>>>> you'd be speaking HTTP/2 over your HID, but again it may be a fairly 
>>>> simple 
>>>> integration.
>>>>
>>>> Good luck!
>>>>
>>>> - Vijay
>>>>
>>>> On Friday, February 2, 2018 at 8:51:23 PM UTC-8, Robert Bielik wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> Has there been any work on using USB HID as a gRPC transport ? 
>>>>>
>>>>> Regards
>>>>> /Robert
>>>>>
>>>>> -- 
>>>> You received this message because you are subscribed to a topic in the 
>>>> Google Groups "grpc.io" group.
>>>> To unsubscribe from this topic, visit 
>>>> https://groups.google.com/d/topic/grpc-io/rCOTPM65A7U/unsubscribe.
>>>>
>>> To unsubscribe from this group and all its topics, 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/e25acae8-c505-47f6-a108-23d4d5d61a83%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/grpc-io/e25acae8-c505-47f6-a108-23d4d5d61a83%40googlegroups.com?utm_medium=email_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 view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/3c71a03a-53d7-4011-ad65-f60e6fadb152n%40googlegroups.com.

Re: [grpc-io] Re: USB transport

[Frédéric Martinsons]

There is another thread talking about USB support: 
https://groups.google.com/g/grpc-io/c/MZCVUShRMkM/m/y3T_fs8iAQAJ but I 
cannot answer there since my messages are automatically deleted (don't know 
why)


On Saturday, 13 February 2021 at 09:55:42 UTC+1 Frédéric Martinsons wrote:

> Hello all,
>
> Some years ago we had the exact same use case where we have an android 
> application which drive an embedded devices (in USB Accessory Mode). The 
> only way to communicate with this device is through USB channel and we 
> wanted to use gRPC.
> So we develop the USB transport channel in gRPC bask in 2018 (based on 
> gRPC v1.13.0).
> The guy from our teams that made these patches had now leaved but I'll be 
> glad to submit a patch series if the USB support is still foreseen to be 
> support but I may not be able to answer all the questions about tricks that 
> came in this code.
>
> Do you want to receive a merge request ?
>
> Thanks for the good works gRPC guru.
>
> On Thursday, 8 February 2018 at 17:18:21 UTC+1 robert...@gmail.com wrote:
>
>> Mark, as Abhishek mentioned, it is quite useful in cases where a target 
>> device (usually embedded) has no networking. Thanks Vijay, I'll have a look 
>> at your suggestions.
>>
>> Regards
>> /Robert
>>
>> 2018-02-07 22:31 GMT+01:00 'Vijay Pai' via grpc.io <
>> grp...@googlegroups.com>:
>>
>>> As Mark mentioned, it's not on our roadmap, but if you wanted to put one 
>>> together, I can suggest 
>>> https://github.com/grpc/grpc/blob/master/doc/core/transport_explainer.md 
>>> for an idea of what transports need to do. If the goal is a simple 
>>> message-oriented transport without reference to complex flow control, I can 
>>> suggest using the in-process transport as a model for how to build a 
>>> transport, as it's only a few hundred lines of code and implements the 
>>> transport ops required to actually have working RPCs for its context; this 
>>> might make a lot of sense if your controller is memory-mapped. 
>>> Alternatively, if your controller is mapped as a file, a path forward might 
>>> be to make a new endpoint akin to the UDS endpoint. This would mean that 
>>> you'd be speaking HTTP/2 over your HID, but again it may be a fairly simple 
>>> integration.
>>>
>>> Good luck!
>>>
>>> - Vijay
>>>
>>> On Friday, February 2, 2018 at 8:51:23 PM UTC-8, Robert Bielik wrote:
>>>>
>>>> Hi all,
>>>>
>>>> Has there been any work on using USB HID as a gRPC transport ? 
>>>>
>>>> Regards
>>>> /Robert
>>>>
>>>> -- 
>>> You received this message because you are subscribed to a topic in the 
>>> Google Groups "grpc.io" group.
>>> To unsubscribe from this topic, visit 
>>> https://groups.google.com/d/topic/grpc-io/rCOTPM65A7U/unsubscribe.
>>>
>> To unsubscribe from this group and all its topics, 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/e25acae8-c505-47f6-a108-23d4d5d61a83%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/grpc-io/e25acae8-c505-47f6-a108-23d4d5d61a83%40googlegroups.com?utm_medium=email_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 view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/b3520456-c4cf-4473-8725-13592a281e02n%40googlegroups.com.

Re: [grpc-io] Re: USB transport

[Frédéric Martinsons]

Hello all,

Some years ago we had the exact same use case where we have an android 
application which drive an embedded devices (in USB Accessory Mode). The 
only way to communicate with this device is through USB channel and we 
wanted to use gRPC.
So we develop the USB transport channel in gRPC bask in 2018 (based on gRPC 
v1.13.0).
The guy from our teams that made these patches had now leaved but I'll be 
glad to submit a patch series if the USB support is still foreseen to be 
support but I may not be able to answer all the questions about tricks that 
came in this code.

Do you want to receive a merge request ?

Thanks for the good works gRPC guru.

On Thursday, 8 February 2018 at 17:18:21 UTC+1 robert...@gmail.com wrote:

> Mark, as Abhishek mentioned, it is quite useful in cases where a target 
> device (usually embedded) has no networking. Thanks Vijay, I'll have a look 
> at your suggestions.
>
> Regards
> /Robert
>
> 2018-02-07 22:31 GMT+01:00 'Vijay Pai' via grpc.io <
> grp...@googlegroups.com>:
>
>> As Mark mentioned, it's not on our roadmap, but if you wanted to put one 
>> together, I can suggest 
>> https://github.com/grpc/grpc/blob/master/doc/core/transport_explainer.md 
>> for an idea of what transports need to do. If the goal is a simple 
>> message-oriented transport without reference to complex flow control, I can 
>> suggest using the in-process transport as a model for how to build a 
>> transport, as it's only a few hundred lines of code and implements the 
>> transport ops required to actually have working RPCs for its context; this 
>> might make a lot of sense if your controller is memory-mapped. 
>> Alternatively, if your controller is mapped as a file, a path forward might 
>> be to make a new endpoint akin to the UDS endpoint. This would mean that 
>> you'd be speaking HTTP/2 over your HID, but again it may be a fairly simple 
>> integration.
>>
>> Good luck!
>>
>> - Vijay
>>
>> On Friday, February 2, 2018 at 8:51:23 PM UTC-8, Robert Bielik wrote:
>>>
>>> Hi all,
>>>
>>> Has there been any work on using USB HID as a gRPC transport ? 
>>>
>>> Regards
>>> /Robert
>>>
>>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "grpc.io" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/grpc-io/rCOTPM65A7U/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> grpc-io+unsubscr...@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/e25acae8-c505-47f6-a108-23d4d5d61a83%40googlegroups.com
>>  
>> 
>> .
>
>
>> 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/d17b530d-4c59-47c5-baa6-18fd93738f2cn%40googlegroups.com.