[grpc-io] Re: How to implement asynchronous rpc in grpc?

[qplc]

Thanks Carl. I'm trying to use async calls without streaming.

On Monday, November 12, 2018 at 5:37:56 PM UTC+5:30, qplc wrote:
>
> Hi,
>
> I've implemented below service definition in my grpc server/client 
> application.
>
> service TestService {
>   rpc testRPCCall(stream Test) returns (stream Test) {}
> }
>
> I found below stubs can be implemented on proto file compilation.
> TestServiceGrpc.TestServiceStub
> TestServiceGrpc.TestServiceBlockingStub
> TestServiceGrpc.TestServiceFutureStub
> TestServiceGrpc.TestServiceImplBase
>
> I want to adapt asynchronous behavior of rpc calls. But, I'm not sure 
> which one of above should be implemented. Is it mandatory to stream a rpc 
> call(stream Test) as mentioned in above service definition for asynchronous 
> implementation?
>
>
> Thanks in advance.
>
>

-- 
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/36c4724f-466c-4572-a525-35ea18f9db5e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Re: python quick start "hello world" example fails

['Srini Polavarapu' via grpc.io]

Your connection issue is due to proxy configuration on your machine. As you 
can see gRPC is connecting to a proxy for localhost.
http_connect_handshaker.cc:300] Connecting to server localhost:50051 via 
HTTP proxy ipv4:10.19.8.225:912

Try setting http_proxy= or try no_proxy=localhost.

On Monday, November 12, 2018 at 1:49:22 PM UTC-8, ankitpa...@gmail.com 
wrote:
>
> Today i tried this example on Centos 7.5 machine and i had same issue. 
>
> On Friday, November 9, 2018 at 3:54:50 PM UTC-8, Lidi Zheng wrote:
>
> Hi Ankit,
>
> Thanks for providing the trace log. I will look into it and update if I 
> found anything.
>
> Lidi Zheng
>
> On Fri, Nov 9, 2018 at 3:04 PM  wrote:
>
> here is server log; i killed server at the end by cntrl+c
>
> I1109 15:02:26.154260194   13636 ev_epoll1_linux.cc:116] grpc epoll 
> fd: 3
> D1109 15:02:26.154434159   13636 ev_posix.cc:169]Using polling 
> engine: epoll1
> D1109 15:02:26.154530558   13636 dns_resolver.cc:338]Using native 
> dns resolver
> I1109 15:02:26.155007186   13636 init.cc:153]
> grpc_init(void)
> I1109 15:02:26.155213454   13636 completion_queue.cc:474]
> grpc_completion_queue_create_internal(completion_type=0, polling_type=0)
> I1109 15:02:26.155388910   13636 init.cc:153]
> grpc_init(void)
> I1109 15:02:26.155498555   13636 server.cc:994]  
> grpc_server_create((nil), (nil))
> I1109 15:02:26.155608844   13636 server.cc:979]  
> grpc_server_register_completion_queue(server=0x10423b0, cq=0x10e4590, 
> reserved=(nil))
> I1109 15:02:26.156318834   13636 server_chttp2.cc:34]
> grpc_server_add_insecure_http2_port(server=0x10423b0, addr=[::]:50051)
> I1109 15:02:26.156495695   13636 socket_utils_common_posix.cc:310] 
> TCP_USER_TIMEOUT not supported for this platform
> I1109 15:02:26.156648253   13636 init.cc:153]
> grpc_init(void)
> I1109 15:02:26.156761086   13636 completion_queue.cc:474]
> grpc_completion_queue_create_internal(completion_type=0, polling_type=1)
> I1109 15:02:26.156907935   13636 server.cc:979]  
> grpc_server_register_completion_queue(server=0x10423b0, cq=0x10b5210, 
> reserved=(nil))
> I1109 15:02:26.157128476   13636 server.cc:1089]
>  grpc_server_start(server=0x10423b0)
> I1109 15:02:26.157323173   13636 completion_queue.cc:956]
> grpc_completion_queue_next(cq=0x10b5210, deadline=gpr_timespec { tv_sec: 
> 1541804546, tv_nsec: 157310009, clock_type: 1 }, reserved=(nil))
> I1109 15:02:26.158580160   13636 init.cc:153]
> grpc_init(void)
> I1109 15:02:26.158879985   13636 init.cc:153]
> grpc_init(void)
> I1109 15:02:26.159027389   13636 call_details.cc:31]
>  grpc_call_details_init(cd=0x7fdfe3e076d0)
> I1109 15:02:26.159205197   13636 metadata_array.cc:29]  
>  grpc_metadata_array_init(array=0x7fdfe3dd52f0)
> I1109 15:02:26.159393998   13636 server.cc:1417]
>  grpc_server_request_call(server=0x10423b0, call=0x7fdfe3dc85e0, 
> details=0x7fdfe3e076d0, initial_metadata=0x7fdfe3dd52f0, 
> cq_bound_to_call=0x10e4590, cq_for_notification=0x10e4590, 
> tag=0x7fdfe3dd52c0)
> I1109 15:02:26.159928640   13641 completion_queue.cc:956]
> grpc_completion_queue_next(cq=0x10e4590, deadline=gpr_timespec { tv_sec: 
> 1541804546, tv_nsec: 359917975, clock_type: 1 }, reserved=(nil))
> I1109 15:02:26.360656578   13641 completion_queue.cc:956]
> grpc_completion_queue_next(cq=0x10e4590, deadline=gpr_timespec { tv_sec: 
> 1541804546, tv_nsec: 560638312, clock_type: 1 }, reserved=(nil))
> I1109 15:02:26.561583802   13641 completion_queue.cc:956]
> grpc_completion_queue_next(cq=0x10e4590, deadline=gpr_timespec { tv_sec: 
> 1541804546, tv_nsec: 761562116, clock_type: 1 }, reserved=(nil))
> I1109 15:02:26.763345769   13641 completion_queue.cc:956]
> grpc_completion_queue_next(cq=0x10e4590, deadline=gpr_timespec { tv_sec: 
> 1541804546, tv_nsec: 963336198, clock_type: 1 }, reserved=(nil))
> I1109 15:02:26.965018149   13641 completion_queue.cc:956]
> grpc_completion_queue_next(cq=0x10e4590, deadline=gpr_timespec { tv_sec: 
> 1541804547, tv_nsec: 165008451, clock_type: 1 }, reserved=(nil))
> I1109 15:02:27.165804716   13641 completion_queue.cc:956]
> grpc_completion_queue_next(cq=0x10e4590, deadline=gpr_timespec { tv_sec: 
> 1541804547, tv_nsec: 365797710, clock_type: 1 }, reserved=(nil))
> I1109 15:02:27.367464272   13641 completion_queue.cc:956]
> grpc_completion_queue_next(cq=0x10e4590, deadline=gpr_timespec { tv_sec: 
> 1541804547, tv_nsec: 567454529, clock_type: 1 }, reserved=(nil))
> I1109 15:02:27.569251508   13641 completion_queue.cc:956]
> grpc_completion_queue_next(cq=0x10e4590, deadline=gpr_timespec { tv_sec: 
> 1541804547, tv_nsec: 769241829, clock_type: 1 }, reserved=(nil))
> I1109 15:02:27.771057300   13641 completion_queue.cc:956]
> grpc_completion_queue_next(cq=0x10e4590, deadline=gpr_timespec { tv_sec: 
> 1541804547, tv_nsec: 

[grpc-io] gRFC L43: Node Message Type Information

['Michael Lumish' via grpc.io]

This is the discussion thread for gRFC L43:
https://github.com/grpc/proposal/pull/116.

This gRFC proposes a new standard for sharing/handling message type
information for gRPC methods in the Node libraries.

-- 
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-4fJJ1pQ_0hY%3DCqRp_xOfAVYC-8-6fcYpSQ5QQgOO7pKTA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] Any alternative to SetSslTargetNameOverride?

[Robert Engels]

I don’t know the C++ gRPC api but would assume there is a method to configure 
and control the SSL transport layer. Almost have to be otherwise you need to 
duplicate the entire SSL api. 

> On Nov 19, 2018, at 2:55 PM, solomon lifshits  wrote:
> 
> You got totally right what I was asking about, the question is whether there 
> is any plan to make that support on grpc/c++ legit, rather than test only. 
> 
>> On Monday, November 19, 2018 at 3:00:07 PM UTC-5, eagle wrote:
>> Robert Engels  writes: 
>> 
>> > I’m not sure I follow. The client knows the host it is expecting to 
>> > contact and verified that the certificate sent matches that host. As I 
>> > said in a later email there is almost certainly a way to bypass the 
>> > check but not sure you can change the setting while going through gRPC 
>> > layer. 
>> 
>> There are two parameters here: the hostname or IP address to which to 
>> connect, and the FQDN used for SNI and for certificate verification. 
>> 
>> The request, at least if I understand it correctly, is to support 
>> decoupling them in the API so that the client can specify an IP address to 
>> connect to and separately specify the FQDN in SNI and certificate 
>> verification, because the client knows (via some mechanism outside the 
>> scope of the API) that it wants to connect to some specific IP that isn't 
>> associated in DNS with the FQDN, but knows what certificate identity to 
>> expect. 
>> 
>> This is a quite common problem with any software using SSL.  There are 
>> often reasons why you want to connect to some internal IP that isn't in 
>> DNS or has the wrong DNS or whatever, but you know as the client what the 
>> certificate will and should be. 
>> 
>> -- 
>> Russ Allbery (ea...@eyrie.org)   
> 
> -- 
> 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/d453f639-f617-495f-b1ff-4f0028ab2120%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 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/20FD2894-B080-48DC-BB59-78E308715470%40earthlink.net.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Any alternative to SetSslTargetNameOverride?

[solomon lifshits]

You got totally right what I was asking about, the question is whether 
there is any plan to make that support on grpc/c++ legit, rather than test 
only. 

On Monday, November 19, 2018 at 3:00:07 PM UTC-5, eagle wrote:
>
> Robert Engels > writes: 
>
> > I’m not sure I follow. The client knows the host it is expecting to 
> > contact and verified that the certificate sent matches that host. As I 
> > said in a later email there is almost certainly a way to bypass the 
> > check but not sure you can change the setting while going through gRPC 
> > layer. 
>
> There are two parameters here: the hostname or IP address to which to 
> connect, and the FQDN used for SNI and for certificate verification. 
>
> The request, at least if I understand it correctly, is to support 
> decoupling them in the API so that the client can specify an IP address to 
> connect to and separately specify the FQDN in SNI and certificate 
> verification, because the client knows (via some mechanism outside the 
> scope of the API) that it wants to connect to some specific IP that isn't 
> associated in DNS with the FQDN, but knows what certificate identity to 
> expect. 
>
> This is a quite common problem with any software using SSL.  There are 
> often reasons why you want to connect to some internal IP that isn't in 
> DNS or has the wrong DNS or whatever, but you know as the client what the 
> certificate will and should be. 
>
> -- 
> Russ Allbery (ea...@eyrie.org )  <
> http://www.eyrie.org/~eagle/> 
>

-- 
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/d453f639-f617-495f-b1ff-4f0028ab2120%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Any alternative to SetSslTargetNameOverride?

[Robert Engels]

Here is how to do it with Go

https://stackoverflow.com/questions/44295820/disable-common-name-validation-go-http-client

> On Nov 19, 2018, at 2:00 PM, Russ Allbery  wrote:
> 
> Robert Engels  writes:
> 
>> I’m not sure I follow. The client knows the host it is expecting to
>> contact and verified that the certificate sent matches that host. As I
>> said in a later email there is almost certainly a way to bypass the
>> check but not sure you can change the setting while going through gRPC
>> layer.
> 
> There are two parameters here: the hostname or IP address to which to
> connect, and the FQDN used for SNI and for certificate verification.
> 
> The request, at least if I understand it correctly, is to support
> decoupling them in the API so that the client can specify an IP address to
> connect to and separately specify the FQDN in SNI and certificate
> verification, because the client knows (via some mechanism outside the
> scope of the API) that it wants to connect to some specific IP that isn't
> associated in DNS with the FQDN, but knows what certificate identity to
> expect.
> 
> This is a quite common problem with any software using SSL.  There are
> often reasons why you want to connect to some internal IP that isn't in
> DNS or has the wrong DNS or whatever, but you know as the client what the
> certificate will and should be.
> 
> -- 
> Russ Allbery (ea...@eyrie.org)  

-- 
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/560BAAF8-F612-4822-98FC-B0F1F4F20CF0%40earthlink.net.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Any alternative to SetSslTargetNameOverride?

[Russ Allbery]

Robert Engels  writes:

> I’m not sure I follow. The client knows the host it is expecting to
> contact and verified that the certificate sent matches that host. As I
> said in a later email there is almost certainly a way to bypass the
> check but not sure you can change the setting while going through gRPC
> layer.

There are two parameters here: the hostname or IP address to which to
connect, and the FQDN used for SNI and for certificate verification.

The request, at least if I understand it correctly, is to support
decoupling them in the API so that the client can specify an IP address to
connect to and separately specify the FQDN in SNI and certificate
verification, because the client knows (via some mechanism outside the
scope of the API) that it wants to connect to some specific IP that isn't
associated in DNS with the FQDN, but knows what certificate identity to
expect.

This is a quite common problem with any software using SSL.  There are
often reasons why you want to connect to some internal IP that isn't in
DNS or has the wrong DNS or whatever, but you know as the client what the
certificate will and should be.

-- 
Russ Allbery (ea...@eyrie.org)  

-- 
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/87pnv0ltx7.fsf%40hope.eyrie.org.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Any alternative to SetSslTargetNameOverride?

[Robert Engels]

I’m not sure I follow. The client knows the host it is expecting to contact and 
verified that the certificate sent matches that host. As I said in a later 
email there is almost certainly a way to bypass the check but not sure you can 
change the setting while going through gRPC layer. 

> On Nov 19, 2018, at 1:52 PM, Russ Allbery  wrote:
> 
> Robert Engels  writes:
> 
>> The certificate has the domain in it. So, think of the reverse. Someone
>> highjacks the domain and uses a bogus certificate (valid but not for the
>> real company) If the two weren’t linked there would be no way to stop
>> this (as the certificate is still valid)
> 
>> By linking the certificate and the domain it is that much harder to
>> break - both need to be compromised.
> 
> That's why the goal is to change the hostname used for SNI and certificate
> verification, not blindly trust any certificate the remote server
> presents.
> 
> Explicitly setting the hostname used for SNI and certificate verification
> instead of implicitly using the hostname given to connect to should not
> create any new security problems, as long as the hostname passed in is the
> correct one (the calling application has to figure that out in some way
> outside the scope of the API).
> 
> -- 
> Russ Allbery (ea...@eyrie.org)  

-- 
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/E7B08276-8CB4-4B19-864A-AA3283DCAD3D%40earthlink.net.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Any alternative to SetSslTargetNameOverride?

[Russ Allbery]

Robert Engels  writes:

> The certificate has the domain in it. So, think of the reverse. Someone
> highjacks the domain and uses a bogus certificate (valid but not for the
> real company) If the two weren’t linked there would be no way to stop
> this (as the certificate is still valid)

> By linking the certificate and the domain it is that much harder to
> break - both need to be compromised.

That's why the goal is to change the hostname used for SNI and certificate
verification, not blindly trust any certificate the remote server
presents.

Explicitly setting the hostname used for SNI and certificate verification
instead of implicitly using the hostname given to connect to should not
create any new security problems, as long as the hostname passed in is the
correct one (the calling application has to figure that out in some way
outside the scope of the API).

-- 
Russ Allbery (ea...@eyrie.org)  

-- 
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/87tvkcluaj.fsf%40hope.eyrie.org.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Any alternative to SetSslTargetNameOverride?

[Robert Engels]

Also, when this happens in a browser there will be security warnings, but the 
user can still bypass it. With automated systems this is harder to do, there 
may be an option with the underlying SSL provider on the platform being used to 
perform a similar bypass (since the browser can bypass it and they almost 
always use the same subsystems)

> On Nov 19, 2018, at 1:47 PM, Robert Engels  wrote:
> 
> The certificate has the domain in it. So, think of the reverse. Someone 
> highjacks the domain and uses a bogus certificate (valid but not for the real 
> company) If the two weren’t linked there would be no way to stop this (as the 
> certificate is still valid)
> By linking the certificate and the domain it is that much harder to break - 
> both need to be compromised. 
> 
>> On Nov 19, 2018, at 1:42 PM, solomon lifshits  wrote:
>> 
>> Thank you for reply. The only thing I am trying to "bypass" is the DNS 
>> resolution, so could you please elaborate how DNS resolution contributes to 
>> SSL security? 
>> 
>>> On Monday, November 19, 2018 at 2:06:31 PM UTC-5, Robert Engels wrote:
>>> I’m pretty sure what you are asking breaks the security of using SSL... the 
>>> certificates are issued to a domain for that reason, otherwise any valid 
>>> certificate would be acceptable to the caller. 
>>> 
 On Nov 19, 2018, at 12:33 PM, solomon lifshits  wrote:
 
 Since the function SetSslTargetNameOverride is marked as test only, I am 
 asking whether there is any "legal" alternative to connect to  a server 
 with specific IP address, while using a host name for server name 
 indication? Any possibility for forced resolution of a hostname? If a tls 
 certificate is issued for a hostname, but an rpc call has to be done on 
 specific machine? Any ideas? Thanks in advance!
 -- 
 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/c5c3c642-1317-41fe-afd4-d7ff8c117585%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 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/14e8e820-3e37-471c-95f8-de2027ae3ef8%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 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/251287BC-A2B9-44B7-834C-85BA4EFB7D94%40earthlink.net.
> 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/149D6A0C-CD3A-424B-8DCA-F85C276F1EB6%40earthlink.net.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Any alternative to SetSslTargetNameOverride?

[Robert Engels]

The certificate has the domain in it. So, think of the reverse. Someone 
highjacks the domain and uses a bogus certificate (valid but not for the real 
company) If the two weren’t linked there would be no way to stop this (as the 
certificate is still valid)
By linking the certificate and the domain it is that much harder to break - 
both need to be compromised. 

> On Nov 19, 2018, at 1:42 PM, solomon lifshits  wrote:
> 
> Thank you for reply. The only thing I am trying to "bypass" is the DNS 
> resolution, so could you please elaborate how DNS resolution contributes to 
> SSL security? 
> 
>> On Monday, November 19, 2018 at 2:06:31 PM UTC-5, Robert Engels wrote:
>> I’m pretty sure what you are asking breaks the security of using SSL... the 
>> certificates are issued to a domain for that reason, otherwise any valid 
>> certificate would be acceptable to the caller. 
>> 
>>> On Nov 19, 2018, at 12:33 PM, solomon lifshits  wrote:
>>> 
>>> Since the function SetSslTargetNameOverride is marked as test only, I am 
>>> asking whether there is any "legal" alternative to connect to  a server 
>>> with specific IP address, while using a host name for server name 
>>> indication? Any possibility for forced resolution of a hostname? If a tls 
>>> certificate is issued for a hostname, but an rpc call has to be done on 
>>> specific machine? Any ideas? Thanks in advance!
>>> -- 
>>> 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/c5c3c642-1317-41fe-afd4-d7ff8c117585%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 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/14e8e820-3e37-471c-95f8-de2027ae3ef8%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 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/251287BC-A2B9-44B7-834C-85BA4EFB7D94%40earthlink.net.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Any alternative to SetSslTargetNameOverride?

[solomon lifshits]

Thank you for reply. The only thing I am trying to "bypass" is the DNS 
resolution, so could you please elaborate how DNS resolution contributes to 
SSL security? 

On Monday, November 19, 2018 at 2:06:31 PM UTC-5, Robert Engels wrote:
>
> I’m pretty sure what you are asking breaks the security of using SSL... 
> the certificates are issued to a domain for that reason, otherwise any 
> valid certificate would be acceptable to the caller. 
>
> On Nov 19, 2018, at 12:33 PM, solomon lifshits  > wrote:
>
> Since the function SetSslTargetNameOverride is marked as test only, I am 
> asking whether there is any "legal" alternative to connect to  a server 
> with specific IP address, while using a host name for server name 
> indication? Any possibility for forced resolution of a hostname? If a tls 
> certificate is issued for a hostname, but an rpc call has to be done on 
> specific machine? Any ideas? Thanks in advance!
>
> -- 
> 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/c5c3c642-1317-41fe-afd4-d7ff8c117585%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 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/14e8e820-3e37-471c-95f8-de2027ae3ef8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Any alternative to SetSslTargetNameOverride?

[Robert Engels]

I’m pretty sure what you are asking breaks the security of using SSL... the 
certificates are issued to a domain for that reason, otherwise any valid 
certificate would be acceptable to the caller. 

> On Nov 19, 2018, at 12:33 PM, solomon lifshits  wrote:
> 
> Since the function SetSslTargetNameOverride is marked as test only, I am 
> asking whether there is any "legal" alternative to connect to  a server with 
> specific IP address, while using a host name for server name indication? Any 
> possibility for forced resolution of a hostname? If a tls certificate is 
> issued for a hostname, but an rpc call has to be done on specific machine? 
> Any ideas? Thanks in advance!
> -- 
> 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/c5c3c642-1317-41fe-afd4-d7ff8c117585%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 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/FEBE5313-5115-4208-A6B8-F1B58A987020%40earthlink.net.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Any alternative to SetSslTargetNameOverride?

[solomon lifshits]

Since the function SetSslTargetNameOverride is marked as test only, I am 
asking whether there is any "legal" alternative to connect to  a server 
with specific IP address, while using a host name for server name 
indication? Any possibility for forced resolution of a hostname? If a tls 
certificate is issued for a hostname, but an rpc call has to be done on 
specific machine? Any ideas? Thanks in advance!

-- 
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/c5c3c642-1317-41fe-afd4-d7ff8c117585%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: Guidance on implementing support for authenticated and secure client connections

[Benjamin Krämer]

Yang Gao is right, those get intentionally dropped. You should not 
workaround that and send them over a unsecured medium if you are not 
absolutely sure this is no security risk: Like when this application never 
gets in contact with the internet and only runs inside of a company network.

-- 
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/b2072497-e024-411d-8189-bb56619d111a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Re: Future of github.com/grpc-ecosystem/grpc-opentracing/go/otgrpc?

[Tom Wilkie]

Thanks for update on this!

Can someone merge https://github.com/grpc-ecosystem/grpc-opentracing/pull/43 to
prevent confusion?

Thanks

Tom

On Mon, Nov 19, 2018 at 8:43 AM Benjamin Krämer 
wrote:

> Hi Tom,
>
> https://github.com/grpc-ecosystem/grpc-opentracing is not maintained
> anymore. So please use https://opentracing.io/ as main source. This will
> forward you to https://github.com/opentracing-contrib/ (that you already
> found). There we maintain all of the OpenTracing related contributions,
> independant of gRPC or the frameworks. All repositories there follow the
> structure -.
>
> I'm with you that this is confusing, and there already is a PR for this at
> https://github.com/grpc-ecosystem/grpc-opentracing/pull/43 which was not
> merged since May 2018... I also left some messages at the locations that I
> found. I hope this will be cleared soon so that others don't have to
> stumple over it.
>
> Best regards,
> Benjamin
>
> --
> 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/9196c457-336c-43ae-8b23-7afe02d3a474%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 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/CAB58Z11wEPprcNn7ixTAECo8A%3DrkG7Cwp%2BPiKGKRwkgnge%3DGHQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Retrieve Server Reply before client streams terminates.

[mendola]

I can read from documentation:

"A client-streaming RPC is also similar to our simple example, except the 
client sends a stream of requests to the server instead of a single 
request. The server sends back a single response, typically but not 
necessarily after it has received all the client’s requests, along with its 
status details and optional trailing metadata."

Usually the client does:

- create channel
- creaet stub
- perform the writer = stub->foo(context, reply);
- loop on:
 writer->Write(request)
- writer->Done()
- writer->Finish()
- At this point I can read the reply


now my question is how can I read the reply before the loop is over? Some 
time the server indeed stops performing the read loop notifying that there 
is no need for more requests.

-- 
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/1b8afe4c-088d-47dd-90e8-7f5cd0949c6d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: Future of github.com/grpc-ecosystem/grpc-opentracing/go/otgrpc?

[Benjamin Krämer]

Hi Tom,

https://github.com/grpc-ecosystem/grpc-opentracing is not maintained 
anymore. So please use https://opentracing.io/ as main source. This will 
forward you to https://github.com/opentracing-contrib/ (that you already 
found). There we maintain all of the OpenTracing related contributions, 
independant of gRPC or the frameworks. All repositories there follow the 
structure -.

I'm with you that this is confusing, and there already is a PR for this at 
https://github.com/grpc-ecosystem/grpc-opentracing/pull/43 which was not 
merged since May 2018... I also left some messages at the locations that I 
found. I hope this will be cleared soon so that others don't have to 
stumple over it.

Best regards,
Benjamin

-- 
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/9196c457-336c-43ae-8b23-7afe02d3a474%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.