Re: [grpc-io] Local in process server

[christonnavasalo]

Hi All,

I'm in process of creating C++ components but I need 2 suggestions 

will in-process transport will be faster r we can use HTTP/2 and also 
someone please point me to some examples for in-process examples for C++, 
Most of the places I'm seeing only samples for JAVA.

Thanks in advance

On Thursday, 25 January 2018 05:18:06 UTC+5:30, Vijay Pai wrote:
>
> Yes, there has been a C++ in-process transport for about six months now. 
> It is not a perfect replacement for the http2 transport as servers are 
> referenced by pointer and not by name; we have another task in place to add 
> naming for in-process but will probably deal with that after making related 
> changes to better support the UDS transport.
>
> On Monday, January 22, 2018 at 5:55:46 AM UTC-8, Robert Bielik wrote:
>>
>> What is the status of issue https://github.com/grpc/grpc/pull/11145 ? 
>> Does this mean there is now C++ in-process transport ? 
>>
>>
>> Den onsdag 30 augusti 2017 kl. 12:06:39 UTC+2 skrev Craig Tiller:
>>>
>>> There's not currently. That's not to say there can't be, but doing 
>>> better would likely mean someone signs up to design and implement some kind 
>>> of shared memory transport. Such an effort would likely be multi quarter to 
>>> get it done right, and we've currently no plans to do so.
>>>
>>> On Tue, Aug 29, 2017, 7:44 PM  wrote:
>>>
 Hi,

 This might be  somewhat naive questions but are there alternatives to 
 TCP/IP. Basically we are using grpc for embedded system (on Ububtu, 
 currently C++ only) and will want to be communication between *two* 
 processes to be as fast as possible. 
 We have tested with unix domain sockets and results are faster, I am 
 wondering if there is any other means to get even better results. I am 
 assuming since these are two different processes we can't use inprocess 
 transport 

 Regards


 On Wednesday, May 17, 2017 at 10:48:20 AM UTC+5:30, Vijay Pai wrote:
>
> Hello there,
>
> I've recently initiated a pull request on this topic ( 
> https://github.com/grpc/grpc/pull/11145 ) . It should be ready to go 
> in the next week or so as we wrap up the last few corner cases. This is 
> in 
> gRPC C Core and includes a C++ API for starters ; we'd be glad to take 
> input on putting this together as a C# API as well. This is true 
> in-process 
> transport using shared-memory addresses between the client and server, 
> not 
> any kind of file descriptor or pipe.
>
> - Vijay
>
> On Monday, May 1, 2017 at 11:43:06 AM UTC-7, Cole Harrison wrote:
>>
>> Craig, 
>> I notice this tread is almost a year old, has there been any 
>> movement on in process communication? Is there a possibility for Named 
>> Pipe 
>> support with windows systems? My team is interested in using the C# 
>> implementation of gRPC but has a strong desire for Named Pipe support.
>>
>> Thanks for you help,
>> -Cole
>>
>> On Sunday, May 15, 2016 at 9:47:04 AM UTC-7, Craig Tiller wrote:
>>>
>>> For non-windows systems we support Unix domain sockets 
>>> (unix:path-to-socket when adding a port to a server or creating a 
>>> channel). 
>>>
>>> I'd like to get pure in process up and going at some point, but 
>>> there needs to be some design done first. Most of the building blocks 
>>> exist 
>>> however.
>>>
>>> On Sun, May 15, 2016, 9:41 AM Robert Bielik  
>>> wrote:
>>>
 Hi all,

 I'm planning on using gRPC for interaction between different 
 components, however, the client should not be aware of the ultimate 
 location of the server implementation.

 I.e. I want to be able to do a "in process" service implementation 
 that does not need TCP/IP for transport. Is there some other mechanism 
 available, like named pipes ?

 Or other ideas ?

 Regards
 /Robert

 -- 
 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.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/grpc-io/9f315629-dcdc-4cdd-8417-35a8b5886353%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 

Re: [grpc-io] Re: grpcio wheel build

['Lidi Zheng' via grpc.io]

Did the C-Core build succeed? Can you provide specific command and logs?

On Wednesday, August 21, 2019 at 12:40:11 PM UTC-7, Ioannis Vogiatzis 
Oikonomidis wrote:
>
> Yes I did. The files are there.I checked. 
> I more or less copy pasted the build scripts from the links 
> --
> *From:* 'Lidi Zheng' via grpc.io >
> *Sent:* Wednesday, August 21, 2019 8:06:17 PM
> *To:* grpc.io >
> *Subject:* [grpc-io] Re: grpcio wheel build 
>  
> Did you pull in the submodules? 
>
> git submodule update --init
>
> It looks like those third_party files are missing.
>
> On Friday, August 16, 2019 at 8:28:19 AM UTC-7, ioannis.vogia...@ansys.com 
> wrote: 
>>
>> I am trying to build grpcio against an already build protobuf version 
>>
>> I am first building grpc core according to these instructions 
>>
>> https://github.com/grpc/grpc/blob/e6cd312346655d9a936acfb97927dbcd35615623/test/distrib/cpp/run_distrib_test_cmake.bat
>>  
>>
>> then I am moving on to the wheel build according to these instructions 
>>
>> https://github.com/grpc/grpc/blob/7f32b96e3d9093dff6f0584ad605a2f10a744ec8/tools/run_tests/artifacts/build_artifact_python.bat
>>
>> However the build keeps failing (with or without cython) with the 
>> following error
>> [Errno 2] No such file or directory: 
>> 'third_party\\protobuf\\src\\google\\protobuf\\wrappers.proto'
>>
>> My build tooldchain is the following:
>> - MSVC 2017
>> - Python 3.6
>> - setuptools  40.8.0
>> - cython 0.29.13
>>
>> -- 
> 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/brh7Jj7Dso0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> grp...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/grpc-io/cd77608f-6628-40bd-a852-ce147e681738%40googlegroups.com
>  
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/b6ba10d0-5005-44c9-b36f-bb023bbb%40googlegroups.com.

Re: [grpc-io] Re: grpcio wheel build

[Ioannis Vogiatzis Oikonomidis]

Yes I did. The files are there.I checked.
I more or less copy pasted the build scripts from the links

From: 'Lidi Zheng' via grpc.io 
Sent: Wednesday, August 21, 2019 8:06:17 PM
To: grpc.io 
Subject: [grpc-io] Re: grpcio wheel build

Did you pull in the submodules?

git submodule update --init

It looks like those third_party files are missing.

On Friday, August 16, 2019 at 8:28:19 AM UTC-7, ioannis.vogia...@ansys.com 
wrote:
I am trying to build grpcio against an already build protobuf version

I am first building grpc core according to these instructions
https://github.com/grpc/grpc/blob/e6cd312346655d9a936acfb97927dbcd35615623/test/distrib/cpp/run_distrib_test_cmake.bat

then I am moving on to the wheel build according to these instructions
https://github.com/grpc/grpc/blob/7f32b96e3d9093dff6f0584ad605a2f10a744ec8/tools/run_tests/artifacts/build_artifact_python.bat

However the build keeps failing (with or without cython) with the following 
error
[Errno 2] No such file or directory: 
'third_party\\protobuf\\src\\google\\protobuf\\wrappers.proto'

My build tooldchain is the following:
- MSVC 2017
- Python 3.6
- setuptools  40.8.0
- cython 0.29.13


--
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/brh7Jj7Dso0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 
grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/cd77608f-6628-40bd-a852-ce147e681738%40googlegroups.com.

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/MN2PR01MB5952ED490122348C5E3BC4DB8BAA0%40MN2PR01MB5952.prod.exchangelabs.com.

Re: [grpc-io] Re: grpc server shutdown

[Jeff Steger]

That’s like saying, ‘why would u want to call delete on a null pointer’ (in
C++). Well, because in some cases it is convenient to do so (rather than
pathologically checking for null every single time you delete something).
Deleting a null pointer is harmless, and shutting down a server that is
already shutdown should imo also be harmless. But there is no documentation
I have read that makes it clear either way, and there really should be.
Does anyone have a definitive answer to this?

On Wed, Aug 21, 2019 at 1:15 PM 'Juanli Shen' via grpc.io <
grpc-io@googlegroups.com> wrote:

> It's definitely not the expected usage. And from the API comment, I
> believe there is no guarantee that this will work in the future even if it
> worked now.
>
> Why would you want to shut down a sever multiple times?
>
> On Tuesday, August 20, 2019 at 3:18:52 PM UTC-7, Jeff wrote:
>>
>> If shutdown is called on a server more than once, is the behavior
>> defined? Is it safe to do this or is there a chance of a crash?
>
> --
> You received this message because you are subscribed to the Google Groups "
> grpc.io" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to grpc-io+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/52288c69-b39e-4dde-ae62-85c0014c4638%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CAA-WHukPTFhBH6vmrnYT4wc9scZZEjKXsacJCEqZNSMFeHqvug%40mail.gmail.com.

Re: [grpc-io] Build Process When Using Multitude Languages

['Eric Anderson' via grpc.io]

You may be interested in
https://github.com/googleapis/gapic-generator/tree/master/rules_gapic .
Granted, that is only really intended for googleapi's usage, but it is
solving the same basic problem. Biggest issue is probably that it does a
lot more than you are wanting. It creates a native package for various
languages, which then can be uploaded to the appropriate language-specific
repositories. You can find the .snip files in the repository, which are
templates.

On Mon, Aug 19, 2019 at 7:06 AM Joey  wrote:

> Hello everyone :-)
>
>
> The company I'm working with embraced gRPC a while ago (micro-service
> architecture). The gRPC implementation we use in the official Java
> implementation, and here's how our build process looks like:
>
> - Each micro-service has it own git repository.
>
> - If Micro-service (named '*A*') protobuf files depends on another
> Micro-service (named '*B*') protobuf files to be compiled - upon building
> Micro-service *A*, a Gradle plug-in will reach and grab Micro-service *B*
> protobuf files.
>
> - When all the dependencies exists, the same Gradle plug-in will use
> protoc to generate the gRPC stub and compile the micro-service* A*.
> Additional steps like create Docker image and deploying the service also
> happen.
>
> - Because some of our UI service using rest API, along with compiling the
> stubs and service - we use the gRPC gateway to generate a REST API gateway,
> along with Swagger JSON files, and deploy those separately.
>
> This worked well, but it suffer from two problems:
>
> 1. Each build require the project to reach external project in order to
> get the latest Protobuf files, and this might take time.
> 2. The protobuf code is being generated over and over. What would be
> better, is to have a JAR already out-there for each Micro-service. So
> Micro-service *A* can just reach and consume the Micro-service *B* Jar.
>
> Also lately - more people are embracing gRPC, and this including more
> language like Python and Go. So a broader build process is needed to
> support multitude of languages. Following Google foot-steps and using
> "googleapi" repository as guideline, we decided to have a single repo that
> will host all the company protobuf files. So building will now happen in a
> single places rather than every project. Now what need to be done - is to
> implement a unified solution to build generated protobuf code in multiple
> languages, publish the artifacts (in package when possible like for example
> JAR), build a gRPC gateway for each service and the Swagger files. Here's
> two approach:
>
> 1. Create a basic 'non-language specific *makefile* (Shell script of a
> sort). It will probably just visit each directory (directory per service),
> use protoc couple of times (one per language), create Packages if possible
> along with the gateway and swagger. I can even call directly to the Gradle
> plug-in when building the Java artifacts, but that's a bit hacky.
>
> 2. Use *Bazel* - googleapi use *bazel-tools *and *rules-go* to create
> artifacts in Java and Go. But I couldn't find a plug-in that handles the
> creation of the gRPC gateway or the Swagger. I did find another repository
> that have couple of Bazel rules called "rules_proto" (
> https://github.com/stackb/rules_proto) that do have support in Swagger
> and gRPC gateway - but it wasn't able to make it work out of the box (but I
> didn't fully debugged what went wrong yet). So Bazel is an option, but it
> feels like it's not really a mature solution, as it require tailoring a
> specific setup - and it's not streamlined yet (for example, there no way to
> create a single JAR with dep-tree between services, only jar per
> micro-service).
>
> So before I'm investing more time writing an external Makefile, or
> tweaking/writing Bazel plugins - I figured I'll come ask here - because I
> probably not the only one trying to do something like that.
>
> Thank you!
>
> --
> You received this message because you are subscribed to the Google Groups "
> grpc.io" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to grpc-io+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/7c4408c7-ae28-4aac-8133-78a933342c9f%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2B4M1oNtp-icMZMJSuMcp2f8LGknGhK9J7g2mO2pqMQKQDrw_g%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

[grpc-io] Re: grpcio wheel build

['Lidi Zheng' via grpc.io]

Did you pull in the submodules?

git submodule update --init

It looks like those third_party files are missing.

On Friday, August 16, 2019 at 8:28:19 AM UTC-7, ioannis.vogia...@ansys.com 
wrote:
>
> I am trying to build grpcio against an already build protobuf version
>
> I am first building grpc core according to these instructions 
>
> https://github.com/grpc/grpc/blob/e6cd312346655d9a936acfb97927dbcd35615623/test/distrib/cpp/run_distrib_test_cmake.bat
>  
>
> then I am moving on to the wheel build according to these instructions 
>
> https://github.com/grpc/grpc/blob/7f32b96e3d9093dff6f0584ad605a2f10a744ec8/tools/run_tests/artifacts/build_artifact_python.bat
>
> However the build keeps failing (with or without cython) with the 
> following error
> [Errno 2] No such file or directory: 
> 'third_party\\protobuf\\src\\google\\protobuf\\wrappers.proto'
>
> My build tooldchain is the following:
> - MSVC 2017
> - Python 3.6
> - setuptools  40.8.0
> - cython 0.29.13
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/cd77608f-6628-40bd-a852-ce147e681738%40googlegroups.com.

[grpc-io] Re: what is use case for streaming rpc?

['Juanli Shen' via grpc.io]

A real life example of using streaming RPC is load reporting: 
https://github.com/grpc/grpc/tree/master/src/cpp/server/load_reporter

In that case, the server may send multiple updates about load reporting 
config, and the client can send multiple reports periodically. 

But streaming RPCs are not intended to use for streaming video services 
though. I think such streaming support is covered in a different area.

On Sunday, August 18, 2019 at 7:45:31 PM UTC-7, Robert Qiu wrote:
>
> Hi There, 
>
> I am pretty interested in "Server Streaming RPC", "Client Streaming RPC" 
> as well as "Bidirectional RPC" which is clearly depicted in the link 
> itemized below:
>
> https://grpc.io/docs/guides/concepts/
>
>
> I wonder what the use cases are for "Server Streaming RPC", "Client 
> Streaming RPC" as well as "Bidirectional RPC"?Streaming video service, 
> like Google youtube, Netflix?
>
>
> Best,
> Robert Qiuxin
>

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/b869f796-af61-4e86-96d3-72ee0edc7e47%40googlegroups.com.

[grpc-io] Flowcontrol settings in grpc C++

[Sree Kuchibhotla]

Hi folks,
I had a few questions about Flow control settings in C++.

- What is the default flow control window size? (as per the RFC, the
initial flow control window size (per connection) is 64k which could be
later adjusted with WINDOW_UPDATE messages). Does gRPC also use this as the
default window size per connection ?

- Can a C++ application change the flow control window sizes ? (per
connection and per stream sizes)? - I remember there was a channel arg for
this but can't find details in the code.

We are trying to debug a performance issue with large 1MB messages in a
bidi stream and want to rule out that possibility that this is due to grpc
flow control (i.e we'd like to set a very large window size).

thanks,
Sree

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CAPc1iOmAq7puGEcb8OFFVdaPV_cDXTtkyNgvqtb_E4HQ%2B-3PhQ%40mail.gmail.com.

[grpc-io] Re: Error in compile grpc c++ version， help

['Juanli Shen' via grpc.io]

Issue filed here: https://github.com/grpc/grpc/issues/19997

On Tuesday, August 20, 2019 at 3:24:56 AM UTC-7, Robert Qiu wrote:
>
> Hi there ,
>
> I follow the instruction from the installation link:   
> https://github.com/grpc/grpc/blob/master/BUILDING.md
>
> Encounter the following errors, some help! Many thanks in advance!
>
>
> root@parallels-Parallels-Virtual-Platform:/usr/local/grpc# bazel build :all
> ERROR: 
> /root/.cache/bazel/_bazel_root/416e294999b2f0ca85243bb61458d7d2/external/io_bazel_rules_python/python/pip.bzl:39:25:
>  
> Traceback (most recent call last):
> File 
> "/root/.cache/bazel/_bazel_root/416e294999b2f0ca85243bb61458d7d2/external/io_bazel_rules_python/python/pip.bzl",
>  
> line 37
> repository_rule(attrs = {"requirements": attr.la...")}, ...)
> File 
> "/root/.cache/bazel/_bazel_root/416e294999b2f0ca85243bb61458d7d2/external/io_bazel_rules_python/python/pip.bzl",
>  
> line 39, in repository_rule
> attr.label(allow_files = True, mandatory = Tr..., ...)
> 'single_file' is no longer supported. use allow_single_file instead. You 
> can use --incompatible_disable_deprecated_attr_params=false to temporarily 
> disable this check.
> ERROR: error loading package '': Extension file 'python/pip.bzl' has errors
> ERROR: error loading package '': Extension file 'python/pip.bzl' has errors
> INFO: Elapsed time: 0.283s
> INFO: 0 processes.
> FAILED: Build did NOT complete successfully (0 packages loaded)
>
>
>
>
> root@parallels-Parallels-Virtual-Platform:/usr/local/grpc# bazel build 
> :all --incompatible_disable_deprecated_attr_params=false
> Killed non-responsive server process (pid=29096)
> Starting local Bazel server and connecting to it...
> DEBUG: Rule 'org_pubref_rules_protobuf' indicated that a canonical 
> reproducible form can be obtained by modifying arguments commit = 
> "1623a5a083f2a702bd62692d059353b4e06f3a5e", shallow_since = "1532967846 
> +" and dropping ["tag"]
> DEBUG: Call stack for the definition of repository 
> 'org_pubref_rules_protobuf' which is a git_repository (rule definition at 
> /root/.cache/bazel/_bazel_root/416e294999b2f0ca85243bb61458d7d2/external/bazel_tools/tools/build_defs/repo/git.bzl:181:18):
>  - /usr/local/qiuxin/grpc/WORKSPACE:54:1
> ERROR: 
> /root/.cache/bazel/_bazel_root/416e294999b2f0ca85243bb61458d7d2/external/org_pubref_rules_protobuf/protobuf/internal/proto_compile.bzl:771:21:
>  
> name 'FileType' is not defined
> ERROR: error loading package '': in 
> /root/.cache/bazel/_bazel_root/416e294999b2f0ca85243bb61458d7d2/external/org_pubref_rules_protobuf/python/rules.bzl:
>  
> in 
> /root/.cache/bazel/_bazel_root/416e294999b2f0ca85243bb61458d7d2/external/org_pubref_rules_protobuf/protobuf/rules.bzl:
>  
> Extension 'protobuf/internal/proto_compile.bzl' has errors
> ERROR: error loading package '': in 
> /root/.cache/bazel/_bazel_root/416e294999b2f0ca85243bb61458d7d2/external/org_pubref_rules_protobuf/python/rules.bzl:
>  
> in 
> /root/.cache/bazel/_bazel_root/416e294999b2f0ca85243bb61458d7d2/external/org_pubref_rules_protobuf/protobuf/rules.bzl:
>  
> Extension 'protobuf/internal/proto_compile.bzl' has errors
> INFO: Elapsed time: 35.712s
> INFO: 0 processes.
> FAILED: Build did NOT complete successfully (0 packages loaded)
>
>
> Best,
> Robert Qiuxin
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/ca1b0998-1749-431e-9ec2-8b42e6fc8725%40googlegroups.com.

[grpc-io] Re: grpc server shutdown

['Juanli Shen' via grpc.io]

It's definitely not the expected usage. And from the API comment, I believe 
there is no guarantee that this will work in the future even if it worked 
now.

Why would you want to shut down a sever multiple times?

On Tuesday, August 20, 2019 at 3:18:52 PM UTC-7, Jeff wrote:
>
> If shutdown is called on a server more than once, is the behavior defined? 
> Is it safe to do this or is there a chance of a crash?

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/52288c69-b39e-4dde-ae62-85c0014c4638%40googlegroups.com.

[grpc-io] Re: grpc server shutdown

['Yang Gao' via grpc.io]

It is safe to call Shutdown more than once.

On Tuesday, August 20, 2019 at 3:18:52 PM UTC-7, Jeff wrote:
>
> If shutdown is called on a server more than once, is the behavior defined? 
> Is it safe to do this or is there a chance of a crash?

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/11476a56-022d-4f9f-a659-8dde808da0eb%40googlegroups.com.

[grpc-io] Re: Report vulnerability

[jiangtao via grpc.io]

Thank you very much for keeping us in the loop.

Could you please email detailed vulnerabilities to the private 
grpc-secur...@googlegroups.com list? Production security engineers will 
evaluate the vulnerability within 3 workdays.

gRPC CVE process can be found in 
https://github.com/grpc/proposal/blob/master/P4-grpc-cve-process.md

Thanks,
Jiangtao


On Wednesday, August 21, 2019 at 3:18:58 AM UTC-7, u...@curv.co wrote:
>
> Hi,
>
> Our team has recently discovered a Null Pointer Dereference security 
> vulnerability in gRPC.
>
> How do we disclose it and open a CVE.
>
> 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/e43d36ab-5a99-46bc-b654-a24ea984a6a8%40googlegroups.com.

Re: [grpc-io] Report vulnerability

['Srini Polavarapu' via grpc.io]

Hi,

Thanks for reaching out. Please follow the CVE process here:
https://github.com/grpc/proposal/blob/master/P4-grpc-cve-process.md.

Thanks.

On Wed, Aug 21, 2019 at 3:19 AM  wrote:

> Hi,
>
> Our team has recently discovered a Null Pointer Dereference security
> vulnerability in gRPC.
>
> How do we disclose it and open a CVE.
>
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/850291a3-0eef-4455-8748-1cacb3a2ceda%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CAP2DVw0TaOLq_qcZF4mhA%3DdyUUbSDXNbYfj1K%3DGSnMXac0U19A%40mail.gmail.com.

Re: [grpc-io] Re: gRPC for embedded systems( for example - RTOS like ThreadX, FreeRTOS etc. )

[Dharam Kumar]

Hello Jaehong,
I've been able to put grpc framework on wiced rtos 
APIs. Basically, Wiced SDK 
from Cypress provides abstracted RTOS/Networking APIs which is underneath 
implemented by different rtos/network stacks. For example - Expresslogic's 
ThreadX/NetX, FreeRTOS/lwip etc. I was able to get threads running, start grpc 
core service, create grpc endpoints(tcp) etc...

Please note that grpc library does not support embedded TLS stacks like 
mbed-tls(from ARM). Also, default grpc transports module(chttp2?)might be too 
heavy for your embedded platform.  So, you may have to work on these aspect. So 
be remindful of how "embedded" you can go. For example - it probably won't work 
on a board/platform with 256KB of RAM.

In nutshell, putting grpc framework is totally possible.
@Nicolas Noble - I'm not sure about the grpc 
being intertwined with posix part - as i recollect there are pretty good grpc 
abstractions for different platforms(windows, unix, posix etc.) - i just built 
on that and was able to get the grpc core up and running.

Br,
Dharam


From: grpc-io@googlegroups.com  on behalf of Nicolas 
Noble 
Sent: Wednesday, August 21, 2019 12:31 AM
To: jaehong park 
Cc: grpc.io 
Subject: Re: [grpc-io] Re: gRPC for embedded systems( for example - RTOS like 
ThreadX, FreeRTOS etc. )

We have no plans for that, and the current codebase is way too intertwined with 
posix to ever work on FreeRTOS / lwip. A full third party implementation of 
grpc would be needed for that at this point.

On Tue, Aug 20, 2019 at 10:23 AM jaehong park 
mailto:jhpark...@gmail.com>> wrote:
Hello Dharam,

I'm having a similar project like below question.
(III.Any effort in community in bringing gRPC for embedded devices(for RTOSes) 
? )
Do you have any progress this issue?

Could you let me know where I can find the answer for this?

Thanks,
Jaehong



On Tuesday, January 23, 2018 at 9:39:07 PM UTC-8, 
dhara...@cypress.com wrote:

Hello folks,
I'm working on a project where we are planning to create a Google Assistant 
service instance on embedded/deeply embedded devices( non-linux, ARM processors 
running RTOS like ThreadX, FreeRTOS etc. )
Our system has support for building executables for c/c++ etc. but it is not 
same as linux( for example - no posix availability ).
Of course, like RTOSes these days, we have wrappers for providing OS/Networking 
functionality for applications/libraries to use.

My questions are:

i.   How fit gRPC is for embedded devices? I can see abstraction for different 
platforms in "port_platform.h" file used to build grpc-core with options given 
in the file.
 My first thought is it should be doable if I adapt port_platform.h and 
build grpc-core with the capabilities provided by our system.

ii.  How deep gRPC's love is for posix? If any platform/devices does not 
provide any posix-like high level APIs, will gRPC still work as expected? How 
straight-forward such a task is going to be?

iii. Any effort in community in bringing gRPC for embedded devices(for RTOSes) 
? Would not it be great to have a tiny(and limited) gRPC library which can be
easily integrated to embedded devices ? And such a thing supported by gRPC 
community/authors ?

I understand that I can get most of the answers from reading the code 
itself(which I'm doing btw).
But it would be nice to know insights/perspective of gRPC authors and community 
folks who understands gRPC better than me.

Open for suggestions/feedback.

Best regards,
Dharam

--
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/5a72e682-031f-415b-830f-7818810f434f%40googlegroups.com.

--
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/A0PlDMi2an8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 
grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CAEvr0PEr7TM5m3JUtP04Jgc3tZj6zSx%2BmfRdGJNh5hwsB0HH6Q%40mail.gmail.com.

This message and any attachments may contain confidential information from 
Cypress or its subsidiaries. If it has been received in error, please advise 
the 

[grpc-io] Report vulnerability

[uri]

Hi,

Our team has recently discovered a Null Pointer Dereference security 
vulnerability in gRPC.

How do we disclose it and open a CVE.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/850291a3-0eef-4455-8748-1cacb3a2ceda%40googlegroups.com.