[grpc-io] Some questions after seeing the Grpc concepts...

[coding]

I've seen some GRPC presentations on Youtube and had some questions...

First as a background, https://www.youtube.com/watch?v=RoXT_Rkg8LA shows 
probably my overall understanding of the overall stack.

I'm interested in migrating a project I'm involved in that is currently 
built on top of REST/Swagger towards GRPC.

Here are the questions:

   - RXJS seems like a perfect library to build into this - specifically 
   because it supports returning 1 or a stream of something. Would also handle 
   the timeout case with RX's built in primitives too. How would one go about 
   modifying a code generator (such as the Node/Browser code) to use RX? 
   And/or is that easy? What language and build environment do I need to get 
   involved in?
   - It mentions HTTP/2 as the transport protocol, which requires SSL, 
   which can lead to issues when you don't have a signed cert. What are the 
   steps to go through when you don't have a cert for localhost development?
   - If anyone has experience with Vert.x you may know about something 
   called the Event Bus. The event bus lets you connect many peers that all 
   add to the global pool of available microservices... is there anything 
   equivalent to this in GRPC? For example if I have 10 git repos that each 
   add 4 or 5 rpc services, can you connect to a service by ONE main URL or 
   does each URL need to be configured separately? (is there a way to create a 
   global even bus that the services live on?) Vert.x also provides 
   round-robin features when the same service is deployed to multiple hosts.


Just to clarify not trying to pick on GRPC shortcomings or anything, I'm 
just coming in with my perspective so that others can pick it apart and 
either say - hey this is solved look here - or hey think about it this way 
instead.

Thanks

-- 
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/155e3ffd-0df5-41a6-b554-5eb562831a3c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] What is the behaviour of grpc::ServerContext::IsCancelled()

[Okke Hendriks]

Hello,

I am using the sync grpc C++ API v1.10.0.

Could someone explain to me what the exact behaviour of IsCancelled() 

 is?

Does it evaluate to true if and only if the client sends a TryCancel() 
which was received by the server? 
Or also if a call/stream closed due to another reason (socket closed, OS 
error, etc.)?

If it is NOT the case that it only returns true when a client cancelled, is 
there a way to find the reason of the cancellation, aka the status?

Kind regards,

Okke Hendriks

-- 
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/cbd2da28-ec6f-4ac1-b676-133dc52874b3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: gRPC Java - how to efficiently work with metadata?

['Carl Mastrangelo' via grpc.io]

Responses inline:

On Friday, March 16, 2018 at 5:13:07 PM UTC-7, 
slili...@onemarketnetwork.com wrote:
>
> I have started working with gRPC fairly recently and really like a lot of 
> aspects of it - thanks to all who contributed to it! But a couple of design 
> decisions don't make sense to me (at least not yet!). Any 
> comments/responses to the question in the subject line would be greatly 
> appreciated.
>
> A bit more background. Java server side code generated from proto3 files 
> doesn't have any simple way to access the headers/trailers of the incoming 
> message. It looks like the only way to access them is to create a custom 
> call interceptor, capture and store values in thread-local variables for 
> the subsequent access in the method implementations. It's error prone and 
> rather cumbersome. 
>

Protobuf is gRPC agnostic.   gRPC is protobuf agnostic.  Neither of them 
know about each other, and this allows you to avoid either one if you don't 
want them.   We actually have examples that don't use Protobuf in gRPC, 
particularly in our benchmarks.

The reason metadata is harder to get to is because it would complicate the 
stub API.   gRPC Java opts for extremely simple stubs at the cost of some 
functionality.   Using the Interceptor (or the ClientCall / ServerCall api) 
allows you access to them, presumably so you can modify the call.   

Using them is more advanced, but we have helper classes to avoid errors.  
Take a look at SimpleForwardingClientCall  to help you stub our most of the 
functionality in your interceptor.  It is expected to *not* use thread 
local variables, but the Context, which is propagated correctly across 
thread boundaries.
 

>
> Go's implementation makes it much simpler to do that, thanks to metadata 
> package (
> https://github.com/grpc/grpc-go/blob/master/Documentation/grpc-metadata.md). 
> Any reason why a similar facility doesn't exist in Java? 
> https://github.com/grpc/grpc-java/blob/master/stub/src/main/java/io/grpc/stub/MetadataUtils.java
>  
> provides some options (MetadataCapturingClientInterceptor), but is 
> explicit that it's designed for testing purposes. Or am I missing something?
>
> Thanks,
>
> Sergei
>

-- 
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/4145d3ec-9a88-41dd-8171-cadd78ba4e9f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: [Help] use self-signed cert on Android

['Carl Mastrangelo' via grpc.io]

Are you sure negotiation completed from the Android client POV?  Since the 
android code uses OkHTTP framing and a thread per connection, you should be 
able to see where it is hung up by getting a stack trace.

On Monday, March 19, 2018 at 3:53:16 AM UTC-7, yz wrote:
>
> I am trying to make gRPC over TLS working on Android using a self-signed 
> cert. The code is as following:
>
> InputStream testCA = new ByteArrayInputStream(CA.getBytes("UTF8"));
>> mChannel = ZnzGrpcChannelBuilder.build(mHost, mPort, null, true, testCA, 
>> "alpn");
>> GRPCDummyServerGrpc.GRPCDummyServerBlockingStub stub = 
>> GRPCDummyServerGrpc.newBlockingStub(mChannel);
>> SumRequest sumRequest = SumRequest.newBuilder().setStart(start).setCount(
>> 20).build();
>> SumResponse sumResponse = stub.sum(sumRequest);
>
>
>
> ZnzGrpcChannelBuilder is a customized channel builder to enable self-signed 
> cert. As can be seen from Wireshark, the TLS negotiation has completed and 
> the server starts
>
> to send SETTINGS to the Android client. But the client did not send any 
> SETTINGS frames.
>
> What I am missing here? Thank you very much.
>
>
> public class ZnzGrpcChannelBuilder {
> public static ManagedChannel build(String host, int port, @Nullable String 
> serverHostOverride,
> boolean useTls, @Nullable InputStream testCa, @Nullable String 
> androidSocketFactoryTls) {
> ManagedChannelBuilder channelBuilder = 
> ManagedChannelBuilder.forAddress(host, 
> port);
> if (serverHostOverride != null) {
> // Force the hostname to match the cert the server uses.
> channelBuilder.overrideAuthority(serverHostOverride);
> }
> if (useTls) {
> try {
> SSLSocketFactory factory;
> if (androidSocketFactoryTls != null) {
> factory = getSslCertificateSocketFactory(testCa, androidSocketFactoryTls);
> } else {
> factory = getSslSocketFactory(testCa);
> }
> ((OkHttpChannelBuilder) channelBuilder).negotiationType(NegotiationType.
> TLS);
> ((OkHttpChannelBuilder) channelBuilder).sslSocketFactory(factory);
> } catch (Exception e) {
> throw new RuntimeException(e);
> }
> } else {
> channelBuilder.usePlaintext(true);
> }
> return channelBuilder.build();
> }
> private static SSLSocketFactory getSslSocketFactory(@Nullable InputStream 
> testCa)
> throws Exception {
> if (testCa == null) {
> return (SSLSocketFactory) SSLSocketFactory.getDefault();
> }
> SSLContext context = SSLContext.getInstance("TLS");
> context.init(null, getTrustManagers(testCa), null);
> return context.getSocketFactory();
> }
> @TargetApi(14)
> private static SSLCertificateSocketFactory getSslCertificateSocketFactory(
> @Nullable InputStream testCa, String androidSocketFatoryTls) throws Exception 
> {
> if (Build.VERSION.SDK_INT < Build.VERSION_CODES.ICE_CREAM_SANDWICH /* API 
> level 14 */) {
> throw new RuntimeException(
> "android_socket_factory_tls doesn't work with API level less than 14.");
> }
> SSLCertificateSocketFactory factory = (SSLCertificateSocketFactory)
> SSLCertificateSocketFactory.getDefault(5000 /* Timeout in ms*/);
> // Use HTTP/2.0
> byte[] h2 = "h2".getBytes();
> byte[][] protocols = new byte[][]{h2};
> if (androidSocketFatoryTls.equals("alpn")) {
> Method setAlpnProtocols =
> factory.getClass().getDeclaredMethod("setAlpnProtocols", byte[][].class);
> setAlpnProtocols.invoke(factory, new Object[]{protocols});
> } else if (androidSocketFatoryTls.equals("npn")) {
> Method setNpnProtocols =
> factory.getClass().getDeclaredMethod("setNpnProtocols", byte[][].class);
> setNpnProtocols.invoke(factory, new Object[]{protocols});
> } else {
> throw new RuntimeException("Unknown protocol: " + androidSocketFatoryTls);
> }
> if (testCa != null) {
> factory.setTrustManagers(getTrustManagers(testCa));
> }
> return factory;
> }
> private static TrustManager[] getTrustManagers(InputStream testCa) throws 
> Exception 
> {
> KeyStore ks = KeyStore.getInstance(KeyStore.getDefaultType());
> ks.load(null);
> CertificateFactory cf = CertificateFactory.getInstance("X.509");
> X509Certificate cert = (X509Certificate) cf.generateCertificate(testCa);
> X500Principal principal = cert.getSubjectX500Principal();
> ks.setCertificateEntry(principal.getName("RFC2253"), cert);
> // Set up trust manager factory to use our key store.
> TrustManagerFactory trustManagerFactory =
> TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm
> ());
> trustManagerFactory.init(ks);
> return trustManagerFactory.getTrustManagers();
> }
> }
>
>

-- 
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/68ae9c07-ffef-4f8b-bfee-854a0e690639%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] [GSoC] Assistance with gRPC Python Ideas

[Sword Chen]

Hi,
I have written a basic proposal 

 
based on my understanding of the 'support static type-checking of gRPC 
Python' project. It is very grateful if you can take a look and give some 
guidance.
Have a good day!

-Sword

在 2018年3月16日星期五 UTC+8上午3:13:50，Nathaniel Manista写道：
>
> On Wed, Mar 14, 2018 at 8:06 AM, Sword Chen  > wrote:
>
>> Thanks for your reply.
>>
>>> Cool! How long? With what programming languages?
>>
>>  I have used gRPC for several weeks, and I have been building the stream 
>> algorithm test environment these weeks with gRPC in Python.  
>>
>>> This sounds like it's going in the right direction - something that I 
>>> think we sort of expect is that there will be a certain incrementality to 
>>> static typing of gRPC Python, and having to add stubs describing the types 
>>> of lower-level systems so that the upper-level systems can have type 
>>> annotations added and checked is not a surprise. mypy and pytype are both 
>>> young enough, and gRPC Python is weird enough, that it is certainly not our 
>>> expectation that we can just throw either tool at our codebase and it will 
>>> figure types out without any further assistance. :-)
>>
>>  You mean the gradual typing, which allows one to annotate only part of a 
>> program, thus leverage desirable aspects of both dynamic and static typing.
>>
>
> Well... I don't think there are desirable aspects of dynamic typing, but 
> not everyone agrees with me. :-P
>
>  PEP483 
>> .  
>> If we don't use the other tools, I have tried some basic type check by 
>> using annotations and decorator PEP 3107 
>> , here is the decorator 
>> function which can do the type check:
>> from inspect import signature
>> from functools import wraps
>>
>>
>> def typeassert(*ty_args, **ty_kwargs):
>> def decorate(func):
>>
>>
>> # Map function argument names to supplied types
>> sig = signature(func)
>> bound_types = sig.bind_partial(*ty_args, **ty_kwargs).arguments
>>
>>
>> @wraps(func)
>> def wrapper(*args, **kwargs):
>> bound_values = sig.bind(*args, **kwargs)
>> # Enforce type assertions across supplied arguments
>> for name, value in bound_values.arguments.items():
>> if name in bound_types:
>> if not isinstance(value, bound_types[name]):
>> raise TypeError(
>> 'Argument {} must be {}'.format(name, 
>> bound_types[name])
>> )
>> return func(*args, **kwargs)
>> return wrapper
>> return decorate
>>
>> Here is the example:
>> @typeassert(int,int z=int)
>> def spam(x, y, z=42):
>> print(x, y, z)
>>
>
> Huh. I actually don't know what the relationship is between 3107 and 
> 483/484, but... we definitely don't want to add dynamic type checks. gRPC 
> needs to be fast; correct code shouldn't have to pay a performance penalty 
> at run-time.
>
> So as you said, if we don't throw other tools into the codebase, I am 
>> considering that we could use this method to help do the type check. But I 
>> still have some confusions:
>> 1.  the idea is  "Support static type-checking of both gRPC Python itself 
>> and of code that uses gRPC Python."  when we use the gPRC python, we can 
>> add the decorator to our own function, but for gPRC Python itself, do we 
>> add type-checker to every defined function? this will 
>> 2.  Does this need to support PEP 484 
>>  or just detect the 
>> errors using the gRPC Python? As I know, mypy verifies standard PEP 484 
>>  type hints.
>>
>
> Yes to supporting what are called "type hints" and defined in 484.
>
> 3. About the grpc structure, actually, I am not quite Clear, is there some 
>> document to help me understand it?
>>
>
> There's not enough! Building, running, and testing the code is probably 
> the best way to get to know it (especially changing parts here and there 
> and seeing what happens). We also have documentation for the gRPC Python 
> API .
>
> These are my thoughts. Hope to get further guidance.
>>
>
> Good to hear from you,
> -N
>

-- 
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/37089101-0a32-4f8f-b882-77f2522ade92%40googlegroups.com.
For more options, visit 

[grpc-io] Re: CallCredentials on "Insecure" Channels (in C-based implementatons)

[colin . morelli]

Sorry for the quick double post here, but just wanted to clarify point #3 
above. I understand JWTs are still private in the sense that you could beat 
the caller to the server with the same credentials it is trying to use (or 
rely on the fact that the service isn't using the JTI as a nonce). In any 
case, my point was that the attack vector is significantly reduced with 
short lived cryptographic tokens compared to, for example, bearer tokens. I 
believe the other points still remain strong.

Best,
Colin

On Monday, March 26, 2018 at 3:14:03 PM UTC-4, colin@gmail.com wrote:
>
> Hey group,
>
> I've seen discussions before about CallCredentials and their ability to be 
> used on insecure channels. It seems that, at least today, they can't be 
> used for any C-based implementations of gRPC. I wanted to propose a change 
> to that, and suggest CallCredentials should be able to be used on insecure 
> channels (even if an option is required to enable this behavior). There are 
> a couple of reasons I think this should be changed:
>
> 1) At least gRPC-java does support this. At best, the inconsistency is 
> strange, at worst it could learn to painful realizations down the road if 
> starting on gRPC and assuming that similar patterns will "just work" on 
> other languages. This is what happened in my case, where our gRPC-Java 
> implementations worked fine, but attempting to do the same thing in Node 
> did not work and took a while before I realized this was the reason.
> 2) While I understand gRPC's belief that it's insecure to exchange tokens 
> over plaintext channels, the reality is that the application-level 
> implementation really has no idea what channel the data will actually be 
> exchanged over. For example, in Istio deployments, the application may 
> think it's communicating insecurely (and thus not allow CallCredentials to 
> be sent), when in fact the traffic is going to hit an external container 
> that will perform mTLS auth with the destination service. From the client 
> and server perspective, this is an insecure channel, but in reality - it's 
> not (unless you're concerned about the ability to tcpdump the loopback 
> interface - at which point you're probably screwed anyway).
> 3) There are plenty of cases where the CallCredentials themselves are not 
> necessarily private, and thus may be fine to exchange over plaintext (think 
> JWTs). This could be the case in scenarios where the services themselves 
> are not dealing with private information, but perhaps they perform an 
> action that should still be authenticated. Understandably, everything 
> should be TLS anyway, but see point #2 for cases in which the service might 
> be using TLS in ways that gRPC may not know about.
> 4) Finally, from a developer experience perspective, it's still possible 
> to send this information anyway - but it results in more fragile 
> implementations of gRPC clients. For example, in Node, I've worked around 
> this limitation by simply pre-generating Metadata instances that can be 
> passed to calls (instead of using CallCredentials), but this requires me to 
> take care to ensure that, at all call-sites, I have valid metadata (i.e. it 
> hasn't expired since it was generated). CallCredentials provide a single 
> way for me to do this, but it's currently not possible because of the 
> restriction to use secure channels.
>
> Hopefully, these are some compelling reasons to consider it. But, if not, 
> at least this should hopefully start a conversation about the topic.
>
> Best,
> Colin
>

-- 
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/16e328d5-49bb-426d-aaa1-4c3a02cacad9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: grpc python streaming response order

[rvshah825]

Sorry wanted to clarify by the way, when I run `client.py` against server, 
I get an rpc error raised on the *first* `next` call, rather then on the 
2nd one as I'd expect.

```
(grpc110) vagrant@vagrant:/vagrant$ python client.py
Traceback (most recent call last):
  File "client.py", line 34, in 
make_requests(make_client())
  File "client.py", line 26, in make_requests
next(resp)
  File 
"/home/vagrant/grpc110/lib/python3.6/site-packages/grpc/_channel.py", line 
347, in __next__
return self._next()
  File 
"/home/vagrant/grpc110/lib/python3.6/site-packages/grpc/_channel.py", line 
330, in _next
raise self
grpc._channel._Rendezvous: <_Rendezvous of RPC that terminated with 
(StatusCode.INVALID_ARGUMENT, test)>
```



On Friday, March 23, 2018 at 4:48:33 AM UTC-7, rvsh...@gmail.com wrote:

> I was trying out python server streaming, and it is unclear to me if there 
> is a guarantee that the client will receive all messages the server sent. I 
> have a test setup here 
> https://github.com/rvshah825/grpc-python/tree/5f306d820458b539187a6c7fa80f7d3e7d2bed87
>  
> (client.py, server.py)
>
> The setup is that the client opens a stream request to server, and the 
> server returns a value then aborts the call. It seems that if I wait a 
> second on client before looking for replies on the stream, I never seen the 
> initial value, and instead only get abort.
>
> The reason I am opening in forum rather than as bug on tracker is that it 
> is unclear to me what is the expected behavior. Naively, I would assume 
> that if I consume the stream response in client calling `next` repeatedly 
> will give me the results that the server sent in order. I would consider 
> aborting to be a value, so in this test I assume that the stream of values 
> from server is [Response, Abort]. What is a little ambiguous is that since 
> the server is sending replies without waiting for requests from client, 
> maybe I cannot expect this?
>
>
>
> Platform I am testing on if relevant is:
> ```
> (grpc110) vagrant@vagrant:/vagrant$ python
> Python 3.6.4 (default, Jan 28 2018, 17:52:01)
> (grpc110) vagrant@vagrant:/vagrant$ lsb_release -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description:Ubuntu 16.04.3 LTS
> Release:16.04
> Codename:   xenial
> (grpc110) vagrant@vagrant:/vagrant$ pip list
> DEPRECATION: The default format will switch to columns in the future. You 
> can use --format=(legacy|columns) (or define a format=(legacy|columns) in 
> your pip.conf under the [list] section) to disable this warning.
> grpcio (1.10.0)
> grpcio-tools (1.10.0)
> pip (9.0.3)
> protobuf (3.5.2.post1)
> setuptools (39.0.1)
> six (1.11.0)
> wheel (0.30.0)
>
> ```
>

-- 
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/73ccca5a-511d-443a-aca6-34bf2a542009%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: Problem with the design of the async grpc model

[Arpit Baldeva]

Check out the example I added 
at https://groups.google.com/forum/#!topic/grpc-io/T9u2TejYVTc 

As for 300-400 rpcs, you can write a custom code generator that plugs in to 
ProtoC (much like grpc_cpp_plugin) and have it generate additional code 
that you may need (like auto "requesting" your server to enable these rpcs 
at the start up). I have similar sort of set up. I did not write the code 
generator plugin I suggest here because my application already had one 
(grpc support was an addition).

On Friday, March 16, 2018 at 3:13:02 AM UTC-7, qgrav...@gmail.com wrote:
>
> My team is designing a scalable solution with micro-services architecture 
> and planning to use gRPC as the transport communication between layers. And 
> we've decided to use async grpc model. The design that example(
> greeter_async_server.cc 
> )
>  
> provides doesn't seem viable if I scale the number of RPC methods, because 
> then I'll have to create a new class for every RPC method, and create their 
> objects in `HandleRpcs()` like this Pastebin 
>  (complete code).
>
> 
> void HandleRpcs() {
> new CallDataForRPC1(&service_, cq_.get());
> new CallDataForRPC2(&service_, cq_.get());
> new CallDataForRPC3(&service, cq_.get());
> // so on...
> }
>
>
>
> It'll be hard-coded, all the flexibility will be lost.
>
> I've around 300-400RPC methods to implement and having 300-400 classes 
> will be cumbersome and inefficient when I'll have to handle  >100K RPC 
> requests/sec and this solution is a very bad design. I can't bear the 
> overhead of creation of objects this way on every single request. Can 
> somebody kindly provide me a workaround for this. Can async grpc c++ not be 
> simple like its sync companion?
>
> TIA
>

-- 
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/fe4607d9-1606-461d-a7a4-de79ee259a76%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: grpc python streaming response order

['Srini Polavarapu' via grpc.io]

If your goal is to notify an invalid argument why not use 
context.set_code(grpc.StatusCode.INVALID_ARGUMENT) instead of abort.

On Friday, March 23, 2018 at 4:48:33 AM UTC-7, rvsh...@gmail.com wrote:
>
> I was trying out python server streaming, and it is unclear to me if there 
> is a guarantee that the client will receive all messages the server sent. I 
> have a test setup here 
> https://github.com/rvshah825/grpc-python/tree/5f306d820458b539187a6c7fa80f7d3e7d2bed87
>  
> (client.py, server.py)
>
> The setup is that the client opens a stream request to server, and the 
> server returns a value then aborts the call. It seems that if I wait a 
> second on client before looking for replies on the stream, I never seen the 
> initial value, and instead only get abort.
>
> The reason I am opening in forum rather than as bug on tracker is that it 
> is unclear to me what is the expected behavior. Naively, I would assume 
> that if I consume the stream response in client calling `next` repeatedly 
> will give me the results that the server sent in order. I would consider 
> aborting to be a value, so in this test I assume that the stream of values 
> from server is [Response, Abort]. What is a little ambiguous is that since 
> the server is sending replies without waiting for requests from client, 
> maybe I cannot expect this?
>
>
>
> Platform I am testing on if relevant is:
> ```
> (grpc110) vagrant@vagrant:/vagrant$ python
> Python 3.6.4 (default, Jan 28 2018, 17:52:01)
> (grpc110) vagrant@vagrant:/vagrant$ lsb_release -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description:Ubuntu 16.04.3 LTS
> Release:16.04
> Codename:   xenial
> (grpc110) vagrant@vagrant:/vagrant$ pip list
> DEPRECATION: The default format will switch to columns in the future. You 
> can use --format=(legacy|columns) (or define a format=(legacy|columns) in 
> your pip.conf under the [list] section) to disable this warning.
> grpcio (1.10.0)
> grpcio-tools (1.10.0)
> pip (9.0.3)
> protobuf (3.5.2.post1)
> setuptools (39.0.1)
> six (1.11.0)
> wheel (0.30.0)
>
> ```
>

-- 
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/6f648fa6-1147-444d-a1e1-da836420ef1b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: How to configure nginx to serve as a load balancer for gRPC?

[mschonwetter]

Announced 17-Mar-2018: native support for gRPC traffic in NGINX 1.13.10 : 
https://www.nginx.com/blog/nginx-1-13-10-grpc/


On Tuesday, August 29, 2017 at 12:54:08 PM UTC-5, alexm...@gmail.com wrote:
>
>
> I understand that the question is more appropriate for nginx group, but 
> still... Does anyone have a _working_ nginx.conf file that does the job?
> I ended up with 404 from nginx sending gRPC requests (yes, valid requests, 
> verified) with the following nginx.conf:
>
> events {
>   worker_connections  4096;  ## Default: 1024
> }
>
> http {
>   upstream ip-10-100-30-92 {
> server ip-10-100-30-147:50101;
> server ip-10-100-130-12:50101;
>   }
>
>   server {
> listen 50101;
> server_name ip-10-100-30-92;
> location / {
>   proxy_pass http://ip-10-100-30-92;
> }
>   }
> }
>
>
> This file produces 404 response and a line in /var/log/nginx/access.log:
>
> 192.168.13.238 - - [29/Aug/2017:16:56:34 +] "PRI * HTTP/2.0" 400 173 
> "-" "-"
>
>
> Actually, I try to use SSL, and a _working_ example of nginx.conf would be 
> _really_ appreciated.
>

-- 
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/278fa78c-6d80-4fc4-a507-0a87efe1836e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Re: [C++] SSL certificate reload api

[Arpit Baldeva]

Hi Justin,

Is there a tracking issue for this that I can follow?

Thanks.

On Thursday, March 8, 2018 at 12:54:14 PM UTC-8, Justin Burke wrote:
>
> Hi Arpit,
>
> Thanks for bringing this to our attention. A C++ API update wasn't in 
> scope for the initial set of work. I'm working on finding developer time to 
> work on this, but currently do not have an ETA to provide to you.
>
> Justin
>
>
> On Thu, Mar 8, 2018 at 10:43 AM, Arpit Baldeva  > wrote:
>
>> Any information on this?
>>
>> Thanks.
>>
>> On Thursday, March 1, 2018 at 3:41:58 PM UTC-8, Arpit Baldeva wrote:
>>>
>>> Hi,
>>>
>>> Looks like C core added cert reload support (
>>> https://github.com/grpc/grpc/pull/12644)  but C++ api does not expose 
>>> the functionality? Am I missing something here or this is in the works?
>>>
>>> Thanks.
>>>
>> -- 
>> 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/TUsC_MTIv2U/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/44324693-39eb-41bd-a028-131aacf6337a%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/71d6d581-e731-4b8d-b46f-703e550871e7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: gRPC calls from a Web App (in browser)?

['Srini Polavarapu' via grpc.io]

Yes. See this https://github.com/grpc/grpc-web


On Saturday, March 24, 2018 at 11:20:08 AM UTC-7, amer...@gmail.com wrote:
>
> Hi. 
>
> Is there any way to call a gRPC back-end service from a web browser 
> application (say using Dart or JavaScript)?
>
> Thanks.
>

-- 
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/8b8adda5-8993-4ad0-a34f-0ce0ebfce61e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: Trouble cross-compilling gRPC for an older platform

[embeddedguy1138]

I was able to move past this error by adding $(TARGET_MAKE_ENV) before 
$(MAKE) in the buildroot grpc.mk file.  The next error I encountered 
regarding ‘EPOLL_CLOEXEC’ undeclared has been documented and resolved here 
.

Presently, I am stumped on the following:

The target you are trying to run requires protobuf 3.0.0+
Your system doesn't have it, and neither does the third_party directory.

Up to this point I have been using protobuf 2.5.0.  It took a little extra 
work, but I am able to cross-compile protobuf 3.0.0 for my system.  However 
I am still getting the same error message when building grpc.  This 
suggests to me that my buildroot makefile is not picking up the target 
protoc and protobuf path.  

Would anyone be able to provide some advice?

On Thursday, March 22, 2018 at 12:54:47 PM UTC-4, embedde...@gmail.com 
wrote:
>
> Hi all,  
>
> I am looking for some help in cross-compiling gRPC for an ARM7 using 
> Buildroot-2014 and an older codesourcery toolchain with gcc-4.3.3.  I 
> intend to use gRPC++ and Google's Cloud Speech API to add voice-to-text 
> support to my board.  Because my compiler does not support c++11, I am only 
> interested in using gRPC versions 1.0.0 and lower (
> https://github.com/grpc/grpc/issues/10036).  I was able to build 
> protobuf-2.5.0 but ran into difficulties building with higher versions. 
>  The gRPC buildroot config and makefile came from here 
> . 
>
> During the build phase, I am getting the following error:
>
> >>> grpc release-0_11_0 Building
>
> [MAKE]Generating cache.mk
> [C]   Compiling src/core/support/alloc.c
> [C]   Compiling src/core/support/cmdline.c
> [C]   Compiling src/core/support/cpu_iphone.c
> [C]   Compiling src/core/support/cpu_posix.c
> [C]   Compiling src/core/support/cpu_linux.c
> [C]   Compiling src/core/support/cpu_windows.c
> [C]   Compiling src/core/support/env_linux.c
> cc1: warnings being treated as errors
> *cc1: error: include location "/usr/local/include" is unsafe for 
> cross-compilation*
>
> First, what is the correct method to disable Werror?  I've tried adding 
> *-Wno-implicit-fallthrough* to my CFLAGS and also *GRPC_CONF_OPT = 
> --disable-Werror* but the issue remains.
>
> Best I can tell, buildroot should isolate the target files from the host. 
>  So where is this coming from?  I've tried removing references to 
> /usr/local/include from the top level Makefile and 
> templates/Makefile.template with no change.  Has anyone run into similar 
> build issues before? 
>
> I would like to stick with buildroot as my method of cross-compiling, but 
> if anyone has alternative suggestions I am all ears. 
>
> Thanks for the help!
>

-- 
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/4da80586-1d7e-4623-bf83-960c02608de7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: Problem with the design of the async grpc model

[Arpit Baldeva]

You say micro-services and then say your server will have 300-400 rpcs? Are 
they part of the same service or many independent services and you are just 
trying to get a common framework together?

I had a similar problem in my application which is/was largely a monolith 
and I had to add gRPC support to it. The async example seems more of a 
simple to understand (a bit odd however until you get familiar with async 
model) code that can be used to implement a service with few rpcs. Anyhow, 
I posted my working code 
at https://groups.google.com/forum/#!topic/grpc-io/T9u2TejYVTc (and in some 
other posts) for this particular problem. You can check it out. 

I was helped by the fact that my application had a code generator 
(different from grpc code generator) where I could plug-in and generate all 
of the "request rpc" calls. When my server starts up, it automatically 
makes those "request rpc" calls for each rpc without every service writer 
needing to make/add the call. If you don't have a code generator already, 
you could probably write a custom code generator plugin for Protoc (much 
like grpc code generator) and can automate this stuff.

Hope that helps.

Arpit




On Friday, March 16, 2018 at 3:13:02 AM UTC-7, qgrav...@gmail.com wrote:
>
> My team is designing a scalable solution with micro-services architecture 
> and planning to use gRPC as the transport communication between layers. And 
> we've decided to use async grpc model. The design that example(
> greeter_async_server.cc 
> )
>  
> provides doesn't seem viable if I scale the number of RPC methods, because 
> then I'll have to create a new class for every RPC method, and create their 
> objects in `HandleRpcs()` like this Pastebin 
>  (complete code).
>
> 
> void HandleRpcs() {
> new CallDataForRPC1(&service_, cq_.get());
> new CallDataForRPC2(&service_, cq_.get());
> new CallDataForRPC3(&service, cq_.get());
> // so on...
> }
>
>
>
> It'll be hard-coded, all the flexibility will be lost.
>
> I've around 300-400RPC methods to implement and having 300-400 classes 
> will be cumbersome and inefficient when I'll have to handle  >100K RPC 
> requests/sec and this solution is a very bad design. I can't bear the 
> overhead of creation of objects this way on every single request. Can 
> somebody kindly provide me a workaround for this. Can async grpc c++ not be 
> simple like its sync companion?
>
> TIA
>

-- 
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/0e469a44-aba9-407b-9dea-12f89f9acf28%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.