Re: [grpc-io] GSOC 2018 ideas

['Nathaniel Manista' via grpc.io]

On Mon, Mar 12, 2018 at 12:07 PM, Nathaniel Manista 
wrote:

> There's not a whole lot of documentation around the proposed feature,
> because it's not so much a new feature as much as filling in a missing
> corner. Consider a two-by-two matrix of "have read all requests/have not
> read all requests" and "respond with not-OK status/respond with OK status".
> It is currently the case that a service-side application:
>
> 1) after having read all requests can respond with not-OK status,
> 2) after having read all requests can respond with OK status,
> 3) without having read all requests can respond with not-OK status,
> 4) without having read all requests *cannot* respond with OK status.
>
> So there's not a whole lot of documentation needed to say "this fourth
> case should be made to work like the other three".
>

Aww fiddlesticks: I really liked this explanation of the behavior to be
changed but it turns out that a gRPC team member implemented Early OK last
December and failed to update the bug about it
. The idea has been removed from
our ideas page . My apologies!
-Nathaniel

-- 
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/CAEOYnASJqK-g%3DAP2msVgj%3DghhccXhxH1ZAjopMQsdeefBOtKOw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] Re: Non-blocking single-threaded streaming C++ server

['Yang Gao' via grpc.io]

Maybe you are over simplifying the code but the snippet does not look
correct to me.

1. Your Read call is async, meaning it is more like StartRead and tell me
via tag when there is something. So it does not make sense to log the args
on its return.
2. You request a MdtDialOut but you do not seem to handle its tag.
3. You only request a MdtDialOut once which means you will only ever get
one incoming RPC
4. You cannot issue a second Read before the first one's tag comes back.
5. As I mentioned, using time_0 may not be sufficient for gRPC to do
background work.

On Mon, Mar 12, 2018 at 12:55 PM, Todd Defilippi 
wrote:

> Thanks!
>
> I have been messing around with using AsyncNext.  My long-term plan is to
> have some timer that calls back and checks if there is anything in the
> completion queue via AsyncNext.  For now, I've just been trying to get some
> basics to work.  Below I have the code I'm using.  (Ignore the sleeping for
> now, that's just so it loops a little slower for debugging purposes.)  The
> issue is, while I do get AsyncNext returning with ok=true and a valid tag,
> I do not get anything when I try to read from the stream.  Am I not using
> the stream correctly?
>
> std::unique_ptr service2;
> service2.reset(new gRPCMdtDialout::AsyncService());
>
> ServerBuilder builder;
> builder.AddListeningPort(addr, grpc::InsecureServerCredentials());
> builder.RegisterService(service2.get());
> std::unique_ptr cq =
> builder.AddCompletionQueue();
> std::unique_ptr server(builder.BuildAndStart());
>
> ServerContext ctx_;
> ServerAsyncReaderWriter
> stream_(_);
> service2->RequestMdtDialout(_, _, cq.get(), cq.get(),
> this);
>
> while (true) {
> void *tag = NULL;
> bool ok = false;
> bool ret = cq->AsyncNext(, , gpr_time_0(GPR_CLOCK_REALTIME)
> );
> if (ret == 1 && ok) {
> MdtDialoutArgs args;
> stream_.Read(, tag);
> cout << " read " << args.ByteSizeLong() << " " << args.reqid()
> << endl;
> }
> sleep(5);
> }
>
> Thanks,
> Todd
>
>
> On Monday, March 12, 2018 at 12:14:46 PM UTC-7, Yang Gao wrote:
>>
>> Hi Todd,
>>
>> Sorry for the late reply.
>>
>> You are right that Next will block until next event is coming out.
>> For your purpose, you may want to use AsyncNext with a deadline for a
>> server with async service.
>> The deadline should be the next time point that you want to break out to
>> do something else on the server.
>> Note grpc library needs to use the thread donated via Next or AsyncNext
>> to do some background work and thus only AsyncNext infrequently with very
>> short deadline may not be a good idea.
>> Also, regarding the single-threadedness, the current grpc implementation
>> creates internal threads to do background work such as timer handling and
>> others. As a result, you will not have a truly single-threaded server even
>> if you only use one thread for the server.
>> This may not be the final form as we intended to support threading model
>> fully controlled by the user. However, there is no timeline for those
>> background threads to be removed at the moment.
>>
>> On Thursday, February 22, 2018 at 11:01:37 AM UTC-8, Todd Defilippi wrote:
>>>
>>> I am trying to write a streaming server as part of implementing a gRPC
>>> dial-out collector for Cisco's model-driven telemetry (
>>> https://github.com/cisco/bigmuddy-network-telemetry-proto/
>>> blob/master/proto_archive/mdt_grpc_dialout/mdt_grpc_dialout.proto).
>>>
>>> Is there a way to create the gRPC server with C++ that does not require
>>> blocking?  The basic synchronous examples all require blocking, which will
>>> not work, so I have been looking at the various asynchronous examples.  I
>>> haven't been able to get those to work but I'm not sure I'm doing it
>>> correctly.
>>>
>>> It seems like I would want to in some way use the CompletionQueues to
>>> hold messages that come in and process them when I can.  Is there a reason
>>> I would want to use Next() versus AsyncNext() (it seems the former blocks
>>> and the latter does not but I'm not sure)?  How does the combination of
>>> RegisterService() and AddCompletionQueue() work?
>>>
>>> Thanks,
>>> Todd
>>>
>> --
> 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/9a3c9ab2-d4a3-4c98-aec2-600112218124%40googlegroups.com
> 
> .
>
> For more options, visit 

[grpc-io] [grpc c++] sending requests immediately - avoid batching

[Mass]

I have been doing some latency measurement with different modes of grpc. 
The application that I have is time critical, and I need to ensure that 
requests are being completed in sub millisecond delay. In my test runs, I 
noticed that the average latency that I get for number of calls is around 
300us, but there are number of request that are completed around 10 ms 
which are not acceptable. 
I have been trying to find a way to optimize for latency, and it seems to 
me the source of this jitter is batching that it is done in grpc. Hence, I 
found out in streaming mode you can give WriteOptions().set_write_through() 
when 
making the write call in order to send the packet instantly. But it didn't 
really help, I can still see that packets are sent in batches.

Is set_write_through() the right option to use? or there exist a better way 
to achieve this?
 

-- 
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/7d2cc8b9-28b0-4d08-acc7-571bbb11c730%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] gsoc 2018 - "Make channel-connectivity-watching cancellable" insights requested

[kaustubh . kapileshwar]

Hi gRPC community,

My name is Kaustubh and I am a graduate student at Texas A University. I 
have a background in Distributed systems and have enjoyed using gRPC and 
Protbuf in my project. This summer I look forward to contribute to the 
current idea in gRPC of "Make channel-connectivity-watching cancellable".

I have read about the issue on github but I believe I need more insights to 
create a thorough proposal for the same. Will appreciate any documentation 
or code repos links which can be useful for coming up with a plan for 
implementation of this idea.

Hope to hear soon !

Regards,
Kaustubh Kapileshwar

-- 
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/5a2e1f67-9893-4236-b6fe-28b709ef9e5d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] GRPC using UDP

[Harish Patil]

Hi,
Do we have an existing implementations of GRPC using UDP as the underlying 
transport protocol? 
If so, please provide the pointers.

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/7af20161-5766-452c-808a-ad0e933e1e5a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: Compiling with Emscripten to Web Assembly

[Matthew Avery]

I did get grpc and protobuf  compiles to WASM but it is not working yet, 
even after enabling SharedArrayBuffer on my browser.  I'm getting a type 
exception on the first call to Atomics.store() that is trying to allocate 
memory for pthread support.

On Friday, March 9, 2018 at 11:16:28 AM UTC-5, Matthew Avery wrote:
>
> I just started looking at this today.  Any progress on your end?
>
> On Friday, January 19, 2018 at 6:03:04 AM UTC-5, andro...@gmail.com wrote:
>>
>> Hi,
>> I'm trying to compile grpc with Emscripten 
>>  to WebAssembly 
>>  - trying to get a 
>> C++-based grpc client working in the browser. 
>>
>> Does anyone know if getting this working is even feasible and has anyone 
>> else tried it? I'm having issues compiling (mostly Protobuf) which I think 
>> I'll be able to solve, but I'd like to know if the effort is worth it.
>>
>

-- 
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/83f83b99-5360-4076-b49c-69a8c7c1536b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] grpc.max_metadata_size

[aamit via grpc.io]

Hi,

Had 2 questions regarding using "grpc.max_metadata_size"

1. It was not clear to me that `max_metadata_size` takes into account size 
of "detail" part of response. Can we allow setting "max_metadata_size" to 
-1 to represent unlimited as with `max_send_message_length` and 
`max_receive_message_length`? 

The exception that gets raised (at least from python) when you try and 
return with details larger then `max_metadata_size` is 
`(StatusCode.RESOURCE_EXHAUSTED, to-be-sent trailing metadata size exceeds 
peer limit` which imo is somewhat confusing as I didn't consider "details" 
to be trailing metadata, and it does not show up under the response call 
trailing metadata.

2. Is the equivalent of "max_metadata_size" exposed anywhere in grpc-go? As 
far as I can tell Java does expose it through netty params 
`maxHeaderListSize`.

Thanks,
Ashwin

-- 
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/31385f13-7406-4af5-b124-f511098074f3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.