[grpc-io] Fwd: Us congress hearing of maan alsaan Money laundry قضية الكونغجرس لغسيل الأموال للمليادير معن الصانع

[Shamy A]

YouTube videos of



 U.S. Congress money laundering hearing


of

Saudi Billionaire  " Maan  Al sanea"

 with *bank of America*


and  The  owner of Saad Hospital and  Schools

 in the Eastern Province in *Saudi Arabia*



and the Chairman of the Board of Directors of Awal Bank  in *Bahrain*


With Arabic Subtitles





*موقع اليوتيوب الذي عرض جلسة استماع الكونجرس الأمريكي *

* لمتابعة نشاطات غسل الأموال ونشاطات*



*السعودي معن عبدالواحد الصانع*



*مالك مستشفى  وشركة سعد  ومدارس سعد بالمنطقة الشرقية بالسعودية   ورئيس مجلس
ادارة بنك اوال البحريني*



*مترجم باللغة العربية*



http://www.youtube.com/watch?v=mIBNnQvhU8s

-- 
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/CAL2L3EK%3DdtNDX5Dez5_LPfaXyifd_ydofZ6WaMe-PL5Eh7%3D2TQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Re: using grpc for push notification

[piratf . me]

Get it! Thank you for your help. You are wonderful.
 

> Oh i think i missed the grpc proto file. But its the same as present in 
> git repository example folder. This code is modification of example present 
> in grpc source. You just need to make a small change, add "stream" keyword 
> in return argument.
>
> https://github.com/grpc/grpc/blob/master/examples/protos/route_guide.proto
>
> -Chaitanya
>
> On Wed, Aug 16, 2017 at 9:21 PM,  wrote:
>
>>
>> 
>>
>>
>> 
>>
>>
>>
>> 
>>
>>
>>
>>
>> Hi Chaitanya,
>>
>> There are two rar files inside the share, I can't find proto directory or 
>> files in both of them. please help me.
>>
>> Thanks
>> Sean
>>
>>
>> proto file is in same folder under proto directory.
>>>
>>> On Wed, Aug 16, 2017 at 8:51 PM,  wrote:
>>>
 Hi Chaitanya,

 Thank you for you sharing! Can you provide the .proto file with it? 
 It's hard to understand without the .proto file, and I can't change the 
 code and recompile it. 

 Thanks
 Sean

 Hi John,
>
> I have added 2 variant of routeguide example, one for asyn stream with 
> one rpc and other for async stream multiple rpc. You can take a look at 
> the 
> code. this was working with grpc 0_11 version. This will give you a good 
> idea of how to use grpc for asyn stream.
>
> https://drive.google.com/open?id=0B1MMqYKUHgtJQWN4cjB6U25LdTQ 
>
> Thanks
> Chaitanya
>
> On Thu, Jun 15, 2017 at 6:39 PM, John Coffey  wrote:
>
>> Chaitanya, 
>>
>> that would be really useful, thanks, I will look forward to seeing 
>> the code.  It is strange that gRPC does not have asynchronous stream 
>> support, you would think this kind of listener/observe pattern would be 
>> a 
>> pretty popular feature.
>>
>> John
>>
>>
>> On Thursday, June 15, 2017 at 12:55:10 AM UTC-4, Chaitanya Gangwar 
>> wrote:
>>>
>>> Hi John,
>>>
>>> When i was working on this, there was no example in grpc package to 
>>> do the same. Actually, what you need here is asynchronous streaming, 
>>> but in 
>>> examples, there are 2 variant, one is synchronous stream (routeguide) 
>>> and 
>>> normal async rpc (helloworld). You have to understand both the examples 
>>> and 
>>> need to implement async stream yourself. I may have some poc code with 
>>> me 
>>> where i tested this functionality. Ill check my repo and will post it 
>>> to 
>>> you. May be that will be of some help for you.
>>>
>>> Thanks
>>> Chaitanya
>>>
>>> On Thu, Jun 15, 2017 at 12:38 AM, John Coffey  
>>> wrote:
>>>
 Josh/Chaitanya, I have a similar application - are there any C++ 
 examples that do this kind of thing?  I just posted a new question to 
 the 
 newsgroup asking and then I found this thread.

 John

 On Friday, January 22, 2016 at 4:53:42 PM UTC-5, Josh Humphries 
 wrote:
>
> There is an example of streaming, at least in a proto file:
>
> https://github.com/grpc/grpc/blob/master/examples/protos/hellostreamingworld.proto
> In this case, the server is expected to just immediately send the 
> requested number of messages.
>
>
> Assuming you had some "registry" of streams that represent clients 
> to which you forward data:
>
> In your server implementation, you'd just register the 
> StreamObserver (that's what its called in the Java runtime 
> 
>  
> anyway).
>
> Here's example generated code for an endpoint with a streaming 
> response: 
> https://github.com/grpc/grpc-java/blob/master/examples/src/generated/main/grpc/io/grpc/examples/routeguide/RouteGuideGrpc.java#L80
> (That's the interface you implement on the server.)
>
> When your server receives data from whatever other source, it can 
> consult this registry of streams and then call onNext to send the 
> client(s) 
> data. Unregister when the stream errors or when you close the stream. 
> You 
> close it via calling onComplete or onError (latter will send error 
> code to 
> the client).
>
>
>
> 
> *Josh Humphries*

Re: [grpc-io] Re: using grpc for push notification

[chaitanya gangwar]

Oh i think i missed the grpc proto file. But its the same as present in git
repository example folder. This code is modification of example present in
grpc source. You just need to make a small change, add "stream" keyword in
return argument.

https://github.com/grpc/grpc/blob/master/examples/protos/route_guide.proto

-Chaitanya

On Wed, Aug 16, 2017 at 9:21 PM,  wrote:

>
> 
>
>
> 
>
>
>
> 
>
>
>
>
> Hi Chaitanya,
>
> There are two rar files inside the share, I can't find proto directory or
> files in both of them. please help me.
>
> Thanks
> Sean
>
>
> proto file is in same folder under proto directory.
>>
>> On Wed, Aug 16, 2017 at 8:51 PM,  wrote:
>>
>>> Hi Chaitanya,
>>>
>>> Thank you for you sharing! Can you provide the .proto file with it? It's
>>> hard to understand without the .proto file, and I can't change the code and
>>> recompile it.
>>>
>>> Thanks
>>> Sean
>>>
>>> Hi John,

 I have added 2 variant of routeguide example, one for asyn stream with
 one rpc and other for async stream multiple rpc. You can take a look at the
 code. this was working with grpc 0_11 version. This will give you a good
 idea of how to use grpc for asyn stream.

 https://drive.google.com/open?id=0B1MMqYKUHgtJQWN4cjB6U25LdTQ

 Thanks
 Chaitanya

 On Thu, Jun 15, 2017 at 6:39 PM, John Coffey  wrote:

> Chaitanya,
>
> that would be really useful, thanks, I will look forward to seeing the
> code.  It is strange that gRPC does not have asynchronous stream support,
> you would think this kind of listener/observe pattern would be a pretty
> popular feature.
>
> John
>
>
> On Thursday, June 15, 2017 at 12:55:10 AM UTC-4, Chaitanya Gangwar
> wrote:
>>
>> Hi John,
>>
>> When i was working on this, there was no example in grpc package to
>> do the same. Actually, what you need here is asynchronous streaming, but 
>> in
>> examples, there are 2 variant, one is synchronous stream (routeguide) and
>> normal async rpc (helloworld). You have to understand both the examples 
>> and
>> need to implement async stream yourself. I may have some poc code with me
>> where i tested this functionality. Ill check my repo and will post it to
>> you. May be that will be of some help for you.
>>
>> Thanks
>> Chaitanya
>>
>> On Thu, Jun 15, 2017 at 12:38 AM, John Coffey 
>> wrote:
>>
>>> Josh/Chaitanya, I have a similar application - are there any C++
>>> examples that do this kind of thing?  I just posted a new question to 
>>> the
>>> newsgroup asking and then I found this thread.
>>>
>>> John
>>>
>>> On Friday, January 22, 2016 at 4:53:42 PM UTC-5, Josh Humphries
>>> wrote:

 There is an example of streaming, at least in a proto file:
 https://github.com/grpc/grpc/blob/master/examples/protos/hel
 lostreamingworld.proto
 In this case, the server is expected to just immediately send the
 requested number of messages.


 Assuming you had some "registry" of streams that represent clients
 to which you forward data:

 In your server implementation, you'd just register the
 StreamObserver (that's what its called in the Java runtime
 
 anyway).

 Here's example generated code for an endpoint with a streaming
 response: https://github.com/grpc/grpc-java/blob/master/exam
 ples/src/generated/main/grpc/io/grpc/examples/routeguide/
 RouteGuideGrpc.java#L80
 (That's the interface you implement on the server.)

 When your server receives data from whatever other source, it can
 consult this registry of streams and then call onNext to send the 
 client(s)
 data. Unregister when the stream errors or when you close the stream. 
 You
 close it via calling onComplete or onError (latter will send error 
 code to
 the client).



 
 *Josh Humphries*
 Manager, Shared Systems  |  Platform Engineering
 Atlanta, GA  |  678-400-4867
 *Square* (www.squareup.com)

 On Fri, Jan 22, 2016 at 3:51 PM, Chaitanya Gangwar <
 chaitany...@gmail.com> wrote:

> Thanks josh 

Re: [grpc-io] Re: using grpc for push notification

[piratf . me]

Hi Chaitanya,

There are two rar files inside the share, I can't find proto directory or 
files in both of them. please help me.

Thanks
Sean


proto file is in same folder under proto directory.
>
> On Wed, Aug 16, 2017 at 8:51 PM,  wrote:
>
>> Hi Chaitanya,
>>
>> Thank you for you sharing! Can you provide the .proto file with it? It's 
>> hard to understand without the .proto file, and I can't change the code and 
>> recompile it. 
>>
>> Thanks
>> Sean
>>
>> Hi John,
>>>
>>> I have added 2 variant of routeguide example, one for asyn stream with 
>>> one rpc and other for async stream multiple rpc. You can take a look at the 
>>> code. this was working with grpc 0_11 version. This will give you a good 
>>> idea of how to use grpc for asyn stream.
>>>
>>> https://drive.google.com/open?id=0B1MMqYKUHgtJQWN4cjB6U25LdTQ 
>>>
>>> Thanks
>>> Chaitanya
>>>
>>> On Thu, Jun 15, 2017 at 6:39 PM, John Coffey  wrote:
>>>
 Chaitanya, 

 that would be really useful, thanks, I will look forward to seeing the 
 code.  It is strange that gRPC does not have asynchronous stream support, 
 you would think this kind of listener/observe pattern would be a pretty 
 popular feature.

 John


 On Thursday, June 15, 2017 at 12:55:10 AM UTC-4, Chaitanya Gangwar 
 wrote:
>
> Hi John,
>
> When i was working on this, there was no example in grpc package to do 
> the same. Actually, what you need here is asynchronous streaming, but in 
> examples, there are 2 variant, one is synchronous stream (routeguide) and 
> normal async rpc (helloworld). You have to understand both the examples 
> and 
> need to implement async stream yourself. I may have some poc code with me 
> where i tested this functionality. Ill check my repo and will post it to 
> you. May be that will be of some help for you.
>
> Thanks
> Chaitanya
>
> On Thu, Jun 15, 2017 at 12:38 AM, John Coffey  
> wrote:
>
>> Josh/Chaitanya, I have a similar application - are there any C++ 
>> examples that do this kind of thing?  I just posted a new question to 
>> the 
>> newsgroup asking and then I found this thread.
>>
>> John
>>
>> On Friday, January 22, 2016 at 4:53:42 PM UTC-5, Josh Humphries wrote:
>>>
>>> There is an example of streaming, at least in a proto file:
>>>
>>> https://github.com/grpc/grpc/blob/master/examples/protos/hellostreamingworld.proto
>>> In this case, the server is expected to just immediately send the 
>>> requested number of messages.
>>>
>>>
>>> Assuming you had some "registry" of streams that represent clients 
>>> to which you forward data:
>>>
>>> In your server implementation, you'd just register the 
>>> StreamObserver (that's what its called in the Java runtime 
>>> 
>>>  
>>> anyway).
>>>
>>> Here's example generated code for an endpoint with a streaming 
>>> response: 
>>> https://github.com/grpc/grpc-java/blob/master/examples/src/generated/main/grpc/io/grpc/examples/routeguide/RouteGuideGrpc.java#L80
>>> (That's the interface you implement on the server.)
>>>
>>> When your server receives data from whatever other source, it can 
>>> consult this registry of streams and then call onNext to send the 
>>> client(s) 
>>> data. Unregister when the stream errors or when you close the stream. 
>>> You 
>>> close it via calling onComplete or onError (latter will send error code 
>>> to 
>>> the client).
>>>
>>>
>>>
>>> 
>>> *Josh Humphries*
>>> Manager, Shared Systems  |  Platform Engineering
>>> Atlanta, GA  |  678-400-4867
>>> *Square* (www.squareup.com)
>>>
>>> On Fri, Jan 22, 2016 at 3:51 PM, Chaitanya Gangwar <
>>> chaitany...@gmail.com> wrote:
>>>
 Thanks josh for the reply. So for this case i need both async 
 server and client. sync rpc will not work. please correct me if i am 
 wrong. 
 also do we have any example which i can look into. i checked async 
 helloworld but that is simple rpc do we have any example for async 
 stream 
 rpc.

 On Friday, 22 January 2016 12:28:18 UTC-8, Chaitanya Gangwar wrote:
>
> Hi,
>
> I have a requirement, where  multiple clients send 

Re: [grpc-io] Re: using grpc for push notification

[chaitanya gangwar]

proto file is in same folder under proto directory.

On Wed, Aug 16, 2017 at 8:51 PM,  wrote:

> Hi Chaitanya,
>
> Thank you for you sharing! Can you provide the .proto file with it? It's
> hard to understand without the .proto file, and I can't change the code and
> recompile it.
>
> Thanks
> Sean
>
> Hi John,
>>
>> I have added 2 variant of routeguide example, one for asyn stream with
>> one rpc and other for async stream multiple rpc. You can take a look at the
>> code. this was working with grpc 0_11 version. This will give you a good
>> idea of how to use grpc for asyn stream.
>>
>> https://drive.google.com/open?id=0B1MMqYKUHgtJQWN4cjB6U25LdTQ
>>
>> Thanks
>> Chaitanya
>>
>> On Thu, Jun 15, 2017 at 6:39 PM, John Coffey  wrote:
>>
>>> Chaitanya,
>>>
>>> that would be really useful, thanks, I will look forward to seeing the
>>> code.  It is strange that gRPC does not have asynchronous stream support,
>>> you would think this kind of listener/observe pattern would be a pretty
>>> popular feature.
>>>
>>> John
>>>
>>>
>>> On Thursday, June 15, 2017 at 12:55:10 AM UTC-4, Chaitanya Gangwar wrote:

 Hi John,

 When i was working on this, there was no example in grpc package to do
 the same. Actually, what you need here is asynchronous streaming, but in
 examples, there are 2 variant, one is synchronous stream (routeguide) and
 normal async rpc (helloworld). You have to understand both the examples and
 need to implement async stream yourself. I may have some poc code with me
 where i tested this functionality. Ill check my repo and will post it to
 you. May be that will be of some help for you.

 Thanks
 Chaitanya

 On Thu, Jun 15, 2017 at 12:38 AM, John Coffey  wrote:

> Josh/Chaitanya, I have a similar application - are there any C++
> examples that do this kind of thing?  I just posted a new question to the
> newsgroup asking and then I found this thread.
>
> John
>
> On Friday, January 22, 2016 at 4:53:42 PM UTC-5, Josh Humphries wrote:
>>
>> There is an example of streaming, at least in a proto file:
>> https://github.com/grpc/grpc/blob/master/examples/protos/hel
>> lostreamingworld.proto
>> In this case, the server is expected to just immediately send the
>> requested number of messages.
>>
>>
>> Assuming you had some "registry" of streams that represent clients to
>> which you forward data:
>>
>> In your server implementation, you'd just register the StreamObserver
>> (that's what its called in the Java runtime
>> 
>> anyway).
>>
>> Here's example generated code for an endpoint with a streaming
>> response: https://github.com/grpc/grpc-java/blob/master/exam
>> ples/src/generated/main/grpc/io/grpc/examples/routeguide/
>> RouteGuideGrpc.java#L80
>> (That's the interface you implement on the server.)
>>
>> When your server receives data from whatever other source, it can
>> consult this registry of streams and then call onNext to send the 
>> client(s)
>> data. Unregister when the stream errors or when you close the stream. You
>> close it via calling onComplete or onError (latter will send error code 
>> to
>> the client).
>>
>>
>>
>> 
>> *Josh Humphries*
>> Manager, Shared Systems  |  Platform Engineering
>> Atlanta, GA  |  678-400-4867
>> *Square* (www.squareup.com)
>>
>> On Fri, Jan 22, 2016 at 3:51 PM, Chaitanya Gangwar <
>> chaitany...@gmail.com> wrote:
>>
>>> Thanks josh for the reply. So for this case i need both async server
>>> and client. sync rpc will not work. please correct me if i am wrong. 
>>> also
>>> do we have any example which i can look into. i checked async helloworld
>>> but that is simple rpc do we have any example for async stream rpc.
>>>
>>> On Friday, 22 January 2016 12:28:18 UTC-8, Chaitanya Gangwar wrote:

 Hi,

 I have a requirement, where  multiple clients send (register) a
 request to server and continue, whenever server have data, server will 
 push
 the data to clients. it may be possible that server may not have data 
 at
 present and will keep pushing data whenever it has. Some other thread 
 is
 providing the data to server.

 Can i do this with grpc without blocking the server and client.
 What i understand from grpc streaming is that client will be waiting 
 for
 data till server sends out the data and after receiving the data it 
 closes
 the connection.

 please help, if i can do this using grpc and if yes how should i
 design this.

 thanks

Re: [grpc-io] [Java] Override authority

[vadim . ivanou]

Thank you, we'll be definitely looking at DNS config changes too.

On Tuesday, August 15, 2017 at 4:32:37 PM UTC-4, Eric Anderson wrote:
>
> Ah, then ManagedChannelBuilder.overrideAuthority() seems to be what you 
> want. Linkerd is acting as a reverse proxy, so it "is" the server as far as 
> gRPC is concerned. Your environment could have been configured by 
> overriding DNS to point to linkerd; that's functionally similar to using 
> overrideAuthority.
>
> On Thu, Aug 10, 2017 at 1:37 PM,  
> wrote:
>
>> I use https://linkerd.io/ for the proxy - it performs load balancing and 
>> name resolution. It is HTTP/2 aware and uses authority header by default to 
>> resolve names.
>>
>> Yes, I use insecure channels and need to route certain connections only 
>> through the proxy, so setting global http proxy will not work.
>>
>> On Thursday, August 10, 2017 at 3:31:29 PM UTC-4, Eric Anderson wrote:
>>>
>>> On Wed, Aug 9, 2017 at 1:56 PM,  wrote:
>>>
 What's the right way to override authority for a channel or stub?

 I see there is withAuthority method in CallOptions, but there is no 
 withAuthority method in AbstractStub and I cannot pass CallOptions to 
 generated stubs.

>>>
>>> The withAuthority in CallOptions is a bit dangerous because it doesn't 
>>> currently verify the TLS certificate when being used.
>>>
>>> There is overrideAuthority method in ManagedChannelBuilder class, but 
 the comment says "Should only used by tests".

 In gRPC C# I can do something like that:

 var channel = new Channel(
 "myproxy:4140",
 ChannelCredentials.Insecure,
 new []{new ChannelOption(ChannelOptions.DefaultAuthority, 
 "original-authority")});

>>>
>>> The equivalent of that in Java 
>>> is ManagedChannelBuilder.overrideAuthority(). The only reason that works 
>>> though is because you are using insecure. I'm assuming that the proxy is a 
>>> TCP-level proxy that knows nothing of HTTP/2.
>>>
>>> How does the proxy know where to proxy to? Normally we'd expect to see 
>>> an HTTPS proxy and we'd use HTTP's CONNECT to form a connection.
>>>
>> -- 
>> 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/446c1de1-11c6-4fef-9480-fbaec7d6fcb5%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/ed009541-884e-4e0f-b356-06a1ebdb0791%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Re: Can someone give me an example with grpc-java and ssl ?

['Eric Gribkoff' via grpc.io]

TLS is on by default for OkHttp channels. See our android-interop-test app

for an example of how to create a secure connection using a test
certificate, or just remove the call to ManagedChannel.usePlaintext(true)
from this line

in
our Android Hello World app to have it use TLS when connecting.

Eric


On Aug 16, 2017 3:18 AM,  wrote:

> Since Netty can't be used in Android, how it should be done in an Android
> Client? I couldn't find any useful example.
>
> On Thursday, January 14, 2016 at 1:43:32 PM UTC+5:30, Young You wrote:
>>
>> It works! Thank you very much!
>>
>> 在 2016年1月14日星期四 UTC+8上午3:44:41，Eric Anderson写道：
>>>
>>> Yep, you need to use GrpcSslContexts
>>> 
>>> :
>>> GrpcSslContexts.forClient().trustManager(...).build();
>>> GrpcSslContexts.forServer(new File...).build();
>>>
>>> Alternatively, you could use GrpcSslContexts.configure(...), but I'd
>>> suggest the easier forms above.
>>>
>>> On Wed, Jan 13, 2016 at 1:35 AM, Young You  wrote:
>>>
 // Server

 SslContext sslContext =  SslContextBuilder.forServer(
   new File("/Users/u/Desktop/api.grpc/src/main/resources/server.crt"),
   new 
 File("/Users/u/Desktop/api.grpc/src/main/resources/private_key_pkcs8.pem"))
   .build();

 server = NettyServerBuilder.forPort(port).sslContext(sslContext)
   .addService(GreeterGrpc.bindService(new GreeterImpl())).build()
   .start();


 // Client
 SslContext sslContext = SslContextBuilder.forClient().trustManager(new 
 File(
   
 "/Users/u/Desktop/api.grpc/src/main/resources/server.crt")).build();
   channel = NettyChannelBuilder.forAddress(host, port)
 .sslContext(sslContext)
 .build();
   blockingStub = GreeterGrpc.newBlockingStub(channel);


 Both server and client do not work, I have tried with another client
 and server written in Ruby.


 在 2016年1月8日星期五 UTC+8上午11:10:59，Young You写道：

> Can someone give me an example with grpc-java and ssl ?
>
> My code returns this error
>
> io.grpc.StatusRuntimeException: UNKNOWN
> at io.grpc.Status.asRuntimeException(Status.java:430)
> at io.grpc.stub.ClientCalls.getUnchecked(ClientCalls.java:156)
> at io.grpc.stub.ClientCalls.blockingUnaryCall(ClientCalls.java:106)
> at ex.grpc.GreeterGrpc$GreeterBlockingStub.sayHello(GreeterGrpc
> .java:109)
> at com.chinark.api.helloworld.HelloWorldClient.greet(HelloWorld
> Client.java:45)
> at com.chinark.api.helloworld.HelloWorldClient.main(HelloWorldC
> lient.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
> ssorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
> thodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.j
> ava:144)
> Caused by: java.lang.Exception: Failed ALPN negotiation: Unable to
> find compatible protocol.
> at io.grpc.netty.ProtocolNegotiators$BufferUntilTlsNegotiatedHa
> ndler.userEventTriggered(ProtocolNegotiators.java:400)
> at io.netty.channel.ChannelHandlerInvokerUtil.invokeUserEventTr
> iggeredNow(ChannelHandlerInvokerUtil.java:75)
> at io.netty.channel.DefaultChannelHandlerInvoker.invokeUserEven
> tTriggered(DefaultChannelHandlerInvoker.java:135)
> at io.netty.channel.AbstractChannelHandlerContext.fireUserEvent
> Triggered(AbstractChannelHandlerContext.java:149)
> at io.netty.channel.ChannelInboundHandlerAdapter.userEventTrigg
> ered(ChannelInboundHandlerAdapter.java:108)
> at io.netty.channel.ChannelHandlerInvokerUtil.invokeUserEventTr
> iggeredNow(ChannelHandlerInvokerUtil.java:75)
> at io.netty.channel.DefaultChannelHandlerInvoker.invokeUserEven
> tTriggered(DefaultChannelHandlerInvoker.java:135)
> at io.netty.channel.AbstractChannelHandlerContext.fireUserEvent
> Triggered(AbstractChannelHandlerContext.java:149)
> at io.netty.handler.ssl.SslHandler.setHandshakeSuccess(SslHandl
> er.java:1240)
> at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1067)
> at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:965)
> at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteT
> oMessageDecoder.java:327)
> at 

Re: [grpc-io] Re: using grpc for push notification

[piratf . me]

Hi Chaitanya,

Thank you for you sharing! Can you provide the .proto file with it? It's 
hard to understand without the .proto file, and I can't change the code and 
recompile it. 

Thanks
Sean

Hi John,
>
> I have added 2 variant of routeguide example, one for asyn stream with one 
> rpc and other for async stream multiple rpc. You can take a look at the 
> code. this was working with grpc 0_11 version. This will give you a good 
> idea of how to use grpc for asyn stream.
>
> https://drive.google.com/open?id=0B1MMqYKUHgtJQWN4cjB6U25LdTQ 
>
> Thanks
> Chaitanya
>
> On Thu, Jun 15, 2017 at 6:39 PM, John Coffey  > wrote:
>
>> Chaitanya, 
>>
>> that would be really useful, thanks, I will look forward to seeing the 
>> code.  It is strange that gRPC does not have asynchronous stream support, 
>> you would think this kind of listener/observe pattern would be a pretty 
>> popular feature.
>>
>> John
>>
>>
>> On Thursday, June 15, 2017 at 12:55:10 AM UTC-4, Chaitanya Gangwar wrote:
>>>
>>> Hi John,
>>>
>>> When i was working on this, there was no example in grpc package to do 
>>> the same. Actually, what you need here is asynchronous streaming, but in 
>>> examples, there are 2 variant, one is synchronous stream (routeguide) and 
>>> normal async rpc (helloworld). You have to understand both the examples and 
>>> need to implement async stream yourself. I may have some poc code with me 
>>> where i tested this functionality. Ill check my repo and will post it to 
>>> you. May be that will be of some help for you.
>>>
>>> Thanks
>>> Chaitanya
>>>
>>> On Thu, Jun 15, 2017 at 12:38 AM, John Coffey  wrote:
>>>
 Josh/Chaitanya, I have a similar application - are there any C++ 
 examples that do this kind of thing?  I just posted a new question to the 
 newsgroup asking and then I found this thread.

 John

 On Friday, January 22, 2016 at 4:53:42 PM UTC-5, Josh Humphries wrote:
>
> There is an example of streaming, at least in a proto file:
>
> https://github.com/grpc/grpc/blob/master/examples/protos/hellostreamingworld.proto
> In this case, the server is expected to just immediately send the 
> requested number of messages.
>
>
> Assuming you had some "registry" of streams that represent clients to 
> which you forward data:
>
> In your server implementation, you'd just register the StreamObserver 
> (that's what its called in the Java runtime 
> 
>  
> anyway).
>
> Here's example generated code for an endpoint with a streaming 
> response: 
> https://github.com/grpc/grpc-java/blob/master/examples/src/generated/main/grpc/io/grpc/examples/routeguide/RouteGuideGrpc.java#L80
> (That's the interface you implement on the server.)
>
> When your server receives data from whatever other source, it can 
> consult this registry of streams and then call onNext to send the 
> client(s) 
> data. Unregister when the stream errors or when you close the stream. You 
> close it via calling onComplete or onError (latter will send error code 
> to 
> the client).
>
>
>
> 
> *Josh Humphries*
> Manager, Shared Systems  |  Platform Engineering
> Atlanta, GA  |  678-400-4867
> *Square* (www.squareup.com)
>
> On Fri, Jan 22, 2016 at 3:51 PM, Chaitanya Gangwar <
> chaitany...@gmail.com> wrote:
>
>> Thanks josh for the reply. So for this case i need both async server 
>> and client. sync rpc will not work. please correct me if i am wrong. 
>> also 
>> do we have any example which i can look into. i checked async helloworld 
>> but that is simple rpc do we have any example for async stream rpc.
>>
>> On Friday, 22 January 2016 12:28:18 UTC-8, Chaitanya Gangwar wrote:
>>>
>>> Hi,
>>>
>>> I have a requirement, where  multiple clients send (register) a 
>>> request to server and continue, whenever server have data, server will 
>>> push 
>>> the data to clients. it may be possible that server may not have data 
>>> at 
>>> present and will keep pushing data whenever it has. Some other thread 
>>> is 
>>> providing the data to server. 
>>>
>>> Can i do this with grpc without blocking the server and client. What 
>>> i understand from grpc streaming is that client will be waiting for 
>>> data 
>>> till server sends out the data and after receiving the data it closes 
>>> the 
>>> connection.
>>>
>>> please help, if i can do this using grpc and if yes how should i 
>>> design this.
>>>
>>> thanks
>>> Chaitanya
>>>
>>> -- 
>> You received this message because you are subscribed to the Google 
>> Groups "grpc.io" group.
>> To unsubscribe from this group and stop receiving emails 

Re: [grpc-io] Re: using grpc for push notification

[piratf . me]

Hi Chaitanya,

Thank you for you share! Can you provide the .proto file with it? It's hard 
to understand without the .proto file, and I can't change the code and 
recompile it. 

Thanks
Sean

在 2017年6月15日星期四 UTC+8下午11:54:52，Chaitanya Gangwar写道：
>
> Hi John,
>
> I have added 2 variant of routeguide example, one for asyn stream with one 
> rpc and other for async stream multiple rpc. You can take a look at the 
> code. this was working with grpc 0_11 version. This will give you a good 
> idea of how to use grpc for asyn stream.
>
> https://drive.google.com/open?id=0B1MMqYKUHgtJQWN4cjB6U25LdTQ 
>
> Thanks
> Chaitanya
>
> On Thu, Jun 15, 2017 at 6:39 PM, John Coffey  > wrote:
>
>> Chaitanya, 
>>
>> that would be really useful, thanks, I will look forward to seeing the 
>> code.  It is strange that gRPC does not have asynchronous stream support, 
>> you would think this kind of listener/observe pattern would be a pretty 
>> popular feature.
>>
>> John
>>
>>
>> On Thursday, June 15, 2017 at 12:55:10 AM UTC-4, Chaitanya Gangwar wrote:
>>>
>>> Hi John,
>>>
>>> When i was working on this, there was no example in grpc package to do 
>>> the same. Actually, what you need here is asynchronous streaming, but in 
>>> examples, there are 2 variant, one is synchronous stream (routeguide) and 
>>> normal async rpc (helloworld). You have to understand both the examples and 
>>> need to implement async stream yourself. I may have some poc code with me 
>>> where i tested this functionality. Ill check my repo and will post it to 
>>> you. May be that will be of some help for you.
>>>
>>> Thanks
>>> Chaitanya
>>>
>>> On Thu, Jun 15, 2017 at 12:38 AM, John Coffey  wrote:
>>>
 Josh/Chaitanya, I have a similar application - are there any C++ 
 examples that do this kind of thing?  I just posted a new question to the 
 newsgroup asking and then I found this thread.

 John

 On Friday, January 22, 2016 at 4:53:42 PM UTC-5, Josh Humphries wrote:
>
> There is an example of streaming, at least in a proto file:
>
> https://github.com/grpc/grpc/blob/master/examples/protos/hellostreamingworld.proto
> In this case, the server is expected to just immediately send the 
> requested number of messages.
>
>
> Assuming you had some "registry" of streams that represent clients to 
> which you forward data:
>
> In your server implementation, you'd just register the StreamObserver 
> (that's what its called in the Java runtime 
> 
>  
> anyway).
>
> Here's example generated code for an endpoint with a streaming 
> response: 
> https://github.com/grpc/grpc-java/blob/master/examples/src/generated/main/grpc/io/grpc/examples/routeguide/RouteGuideGrpc.java#L80
> (That's the interface you implement on the server.)
>
> When your server receives data from whatever other source, it can 
> consult this registry of streams and then call onNext to send the 
> client(s) 
> data. Unregister when the stream errors or when you close the stream. You 
> close it via calling onComplete or onError (latter will send error code 
> to 
> the client).
>
>
>
> 
> *Josh Humphries*
> Manager, Shared Systems  |  Platform Engineering
> Atlanta, GA  |  678-400-4867
> *Square* (www.squareup.com)
>
> On Fri, Jan 22, 2016 at 3:51 PM, Chaitanya Gangwar <
> chaitany...@gmail.com> wrote:
>
>> Thanks josh for the reply. So for this case i need both async server 
>> and client. sync rpc will not work. please correct me if i am wrong. 
>> also 
>> do we have any example which i can look into. i checked async helloworld 
>> but that is simple rpc do we have any example for async stream rpc.
>>
>> On Friday, 22 January 2016 12:28:18 UTC-8, Chaitanya Gangwar wrote:
>>>
>>> Hi,
>>>
>>> I have a requirement, where  multiple clients send (register) a 
>>> request to server and continue, whenever server have data, server will 
>>> push 
>>> the data to clients. it may be possible that server may not have data 
>>> at 
>>> present and will keep pushing data whenever it has. Some other thread 
>>> is 
>>> providing the data to server. 
>>>
>>> Can i do this with grpc without blocking the server and client. What 
>>> i understand from grpc streaming is that client will be waiting for 
>>> data 
>>> till server sends out the data and after receiving the data it closes 
>>> the 
>>> connection.
>>>
>>> please help, if i can do this using grpc and if yes how should i 
>>> design this.
>>>
>>> thanks
>>> Chaitanya
>>>
>>> -- 
>> You received this message because you are subscribed to the Google 
>> Groups "grpc.io" group.
>> To 

Re: [grpc-io] Re: Can someone give me an example with grpc-java and ssl ?

[karthik . periasami]

Since Netty can't be used in Android, how it should be done in an Android 
Client? I couldn't find any useful example.

On Thursday, January 14, 2016 at 1:43:32 PM UTC+5:30, Young You wrote:
>
> It works! Thank you very much!
>
> 在 2016年1月14日星期四 UTC+8上午3:44:41，Eric Anderson写道：
>>
>> Yep, you need to use GrpcSslContexts 
>> 
>> :
>> GrpcSslContexts.forClient().trustManager(...).build();
>> GrpcSslContexts.forServer(new File...).build();
>>
>> Alternatively, you could use GrpcSslContexts.configure(...), but I'd 
>> suggest the easier forms above.
>>
>> On Wed, Jan 13, 2016 at 1:35 AM, Young You  wrote:
>>
>>> // Server
>>>
>>> SslContext sslContext =  SslContextBuilder.forServer(
>>>   new File("/Users/u/Desktop/api.grpc/src/main/resources/server.crt"),
>>>   new 
>>> File("/Users/u/Desktop/api.grpc/src/main/resources/private_key_pkcs8.pem"))
>>>   .build();
>>>
>>> server = NettyServerBuilder.forPort(port).sslContext(sslContext)
>>>   .addService(GreeterGrpc.bindService(new GreeterImpl())).build()
>>>   .start();
>>>
>>>
>>> // Client
>>> SslContext sslContext = SslContextBuilder.forClient().trustManager(new File(
>>>   
>>> "/Users/u/Desktop/api.grpc/src/main/resources/server.crt")).build();
>>>   channel = NettyChannelBuilder.forAddress(host, port)
>>> .sslContext(sslContext)
>>> .build();
>>>   blockingStub = GreeterGrpc.newBlockingStub(channel);
>>>
>>>
>>> Both server and client do not work, I have tried with another client and 
>>> server written in Ruby.
>>>
>>>
>>> 在 2016年1月8日星期五 UTC+8上午11:10:59，Young You写道：
>>>
 Can someone give me an example with grpc-java and ssl ?

 My code returns this error

 io.grpc.StatusRuntimeException: UNKNOWN
 at io.grpc.Status.asRuntimeException(Status.java:430)
 at io.grpc.stub.ClientCalls.getUnchecked(ClientCalls.java:156)
 at io.grpc.stub.ClientCalls.blockingUnaryCall(ClientCalls.java:106)
 at 
 ex.grpc.GreeterGrpc$GreeterBlockingStub.sayHello(GreeterGrpc.java:109)
 at 
 com.chinark.api.helloworld.HelloWorldClient.greet(HelloWorldClient.java:45)
 at 
 com.chinark.api.helloworld.HelloWorldClient.main(HelloWorldClient.java:60)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:497)
 at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
 Caused by: java.lang.Exception: Failed ALPN negotiation: Unable to find 
 compatible protocol.
 at 
 io.grpc.netty.ProtocolNegotiators$BufferUntilTlsNegotiatedHandler.userEventTriggered(ProtocolNegotiators.java:400)
 at 
 io.netty.channel.ChannelHandlerInvokerUtil.invokeUserEventTriggeredNow(ChannelHandlerInvokerUtil.java:75)
 at 
 io.netty.channel.DefaultChannelHandlerInvoker.invokeUserEventTriggered(DefaultChannelHandlerInvoker.java:135)
 at 
 io.netty.channel.AbstractChannelHandlerContext.fireUserEventTriggered(AbstractChannelHandlerContext.java:149)
 at 
 io.netty.channel.ChannelInboundHandlerAdapter.userEventTriggered(ChannelInboundHandlerAdapter.java:108)
 at 
 io.netty.channel.ChannelHandlerInvokerUtil.invokeUserEventTriggeredNow(ChannelHandlerInvokerUtil.java:75)
 at 
 io.netty.channel.DefaultChannelHandlerInvoker.invokeUserEventTriggered(DefaultChannelHandlerInvoker.java:135)
 at 
 io.netty.channel.AbstractChannelHandlerContext.fireUserEventTriggered(AbstractChannelHandlerContext.java:149)
 at 
 io.netty.handler.ssl.SslHandler.setHandshakeSuccess(SslHandler.java:1240)
 at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1067)
 at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:965)
 at 
 io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:327)
 at 
 io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:230)
 at 
 io.netty.channel.ChannelHandlerInvokerUtil.invokeChannelReadNow(ChannelHandlerInvokerUtil.java:83)
 at 
 io.netty.channel.DefaultChannelHandlerInvoker.invokeChannelRead(DefaultChannelHandlerInvoker.java:153)
 at 
 io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:157)
 at 
 io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:946)
 at 
 io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125)
 at 
 io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:510)
 at 
 io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:467)
 at 
 

[grpc-io] Re: [grpc-java] Deadline issues with broken connections

[Uli Bubenheimer]

Carl, thanks for your input.

In client-server development, especially for mobile, I can control certain 
things better than others. I have control over the server and can make it 
very reliable, so that I can mostly rule it out as a point of failure. By 
contrast, the network is chaotic. Network communication is going over the 
cellular network in my case, and I have to design for substantial 
connectivity problems because the app is generally used in remote 
locations. So usually the blame for communications problems in my case lies 
on the client-side network.

How can you tell if a connection is broken?  Unless you receive a packet 
> saying the host isn't reachable, its possible the remote endpoint is just 
> taking a long time.  It can't be distinguished from radio silence.
>

That's the crux of the problem - I usually can't tell if the connection is 
broken in a timely manner when a Deadline expires. So I have to use good 
heuristics (make informed guesses) in a way that minimizes the impact on 
app users. If I take an optimistic stance and reissue calls on an existing 
yet broken connection, I will waste time because all I may get at the 
application level is silence and another expired Deadline. If instead I 
take a pessimistic stance and assume that the connection is broken (whether 
or not that actually is the case), I can try a new connection (if it 
appears that I am online) and minimize the downtime. Doing one retry on the 
old connection can be a good idea, but if it fails I am still facing the 
same problem.

The real strategy may be a little more complex, but in the end I still need 
the ability to request a reconnect when my strategy dictates it (and when 
the Channel has no indication of recent data received). The current Channel 
design is overbearing when connections are not reliable.

The deadline mechanism isn't really for connection level usage, it's for 
> RPC level usage.
>
 
Agreed. From the application level perspective, however, an expired 
Deadline can simultaneously be an indicator of a broken or unavailable 
connection, so to take action it is important to have the ability to signal 
this problem to the connection/channel level right away, without having to 
wait for a keep alive ping and lack of response at their regularly 
scheduled intervals. That kind of wait may be fine on the server side, but 
it's not feasible for my interactive user-facing app. And expired Deadlines 
can cancel out KeepAlive pings due to no active calls, which exacerbates 
the problem.

I mean, I can work around the problem on the client side, but for my use 
case this means potentially issuing very frequent pings and doing so 
regardless of the existence of open calls. It's not a great design. I 
wouldn't have to do either of these things if I could signal to the Channel 
to reconnect when the Deadline expires.

If you can listen for OS updates on Android, why not just kill the RPCs 
> your self when you get notified?
>

Good idea - doing more proactive OS listening & killing RPCs could come in 
useful. My question in this regard was more about how to best kill all 
existing RPCs in grpc-java while minimizing races, and the general 
feasibility of attempting to hide the messiness of Channel recreation by 
using Subchannels.

And, even if you did do this, how can you tell if the connection is failed? 
>  For example, if the OS tells you the antenna is turned off, it may be 
> temporary and could turn on again with neither endpoint being the wiser. 
>  The connection is still active.
>

 Very true, there is no telling if the connection broke.

So in summary I think the ability to signal to the Channel to reconnect is 
still needed for the Android use case. I recall that one of the official 
grpc design documents (connection backoff document perhaps) mentions to 
just continue using the old connection instead if it recovers before the 
new connection is ready; the same could be true here.

There are already enhancement requests for RPC retries and reconnection 
backoff improvements, which I also sorely need.

Should I create an issue about the undocumented problem of expiring 
Deadlines interfering with KeepAlives? Maybe even just to add something to 
the Javadoc? While logical, I found this quite surprising.

 

> On Friday, August 11, 2017 at 6:24:48 PM UTC-7, Uli Bubenheimer wrote:
>>
>> I am seeing issues with how Deadline works at present in the presence of 
>> failing connections. What I found in my tests & research regarding my 
>> Android use case:
>>
>>
>>- I am missing an option to explicitly fail a connection (signal that 
>>the connection is broken) when a Deadline expires. An expired Deadline in 
>>my Android use case would typically mean that the connection is broken, 
>> and 
>>reconnecting may help.
>>- Detecting broken connections with Keep-Alives does not work so well 
>>in conjunction with Deadlines. If all RPCs have failed due to expired 
>>Deadlines