[grpc-io] Re: Multiple grpc connections using python

2023-07-04 Thread Saurav Pawar
Can anyone please help me with this?

On Tuesday, July 4, 2023 at 11:38:20 PM UTC+4 Saurav Pawar wrote:

> Hi,
>
> I want to create multiple grpc connections instead of one. I am using 
> Flower which is a federated learning framework and it uses grpc for the 
> communication. This (Link provided below) is the line where they are 
> creating 1 grpc connection and I want to create 3. Can I please get some 
> help?
>
> Link to the line of code - 
> https://github.com/adap/flower/blob/f139930bd9329ffce6b3c9466ded6a633c93c07d/src/py/flwr/client/app.py#L189
>
> 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/009a91c2-3220-4d15-a9f4-7413a6d4e0cdn%40googlegroups.com.


[grpc-io] Re: GRPC latest release v1.56.0 - compile c++/rhel8 (gcc8.5.0) w/ cmake ; to create libprotobuf.so.** together with libgrpc.so.**

2023-07-04 Thread 'veb...@google.com' via grpc.io
Hey Bu,

You should be able to see generated protobuf so file with 
DgRPC_PROTOBUF_PROVIDER=module. I did it myself with the HEAD version of 
gRPC.
BTW, this is only to make gRPC development easy and not for package 
management. In general, using protobuf repo to generate protobuf so files 
is recommended. 

$ cmake -DBUILD_SHARED_LIBS=ON -DgRPC_INSTALL=ON 
-DgRPC_PROTOBUF_PROVIDER=module -DgRPC_BUILD_TESTS=OFF 
-DCMAKE_INSTALL_PREFIX=/tmp/a  ..
$ make -j 16 install
/tmp/a/lib$ ls *proto*
libabsl_log_internal_proto.so   libprotobuf-lite.so.23.1.0 
 libprotoc.so
libabsl_log_internal_proto.so.2301.0.0  libprotobuf.so 
 libprotoc.so.23.1.0
libprotobuf-lite.so libprotobuf.so.23.1.0

Regards,
Esun.

On Thursday, June 29, 2023 at 9:12:37 AM UTC+9 Bu Lu wrote:

> Hi,
> Forgot to mention previously, this is my cmake commands,  running under 
> grpc/cmake/build, set protobuf provider w/ value 'module' even though I 
> think it is default value, but still doesn't get what I expect.
> cmake -DBUILD_SHARED_LIBS=ON -DgRPC_INSTALL=ON 
> -DgRPC_PROTOBUF_PROVIDER=module -DgRPC_BUILD_TESTS=OFF ../..
>
> Thanks,
> -Wei
> On Wednesday, June 28, 2023 at 4:54:36 PM UTC-7 Bu Lu wrote:
>
>> Hello,
>> I downloaded the latest grpc v1.56.0 source code, following the 
>> instruction to build grpc.so** . My intention is also to build 
>> libprotobuf.so.** therefore I can create distribution package (RPMs).
>> Is this the right approach as I have impression that when git cloned the 
>> grpc repo including submodules, the dependences (such as protobuf) are 
>> included in grpc code structure, am I right?
>>
>> I use cmake/make option for my build.
>>
>> I also tried to run tools/buildgen/generate_projects.sh (with all tools 
>> installed) without error, while still not able to generate protobuf so 
>> files.
>>
>> Any insights what might be wrong? 
>>
>> Appreciate so much for your helps!
>> -Wei
>>
>>

-- 
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/4945b0f5-3edd-4728-b0b8-762b1b5c81cbn%40googlegroups.com.


[grpc-io] Multiple grpc connections using python

2023-07-04 Thread Saurav Pawar
Hi,

I want to create multiple grpc connections instead of one. I am using 
Flower which is a federated learning framework and it uses grpc for the 
communication. This (Link provided below) is the line where they are 
creating 1 grpc connection and I want to create 3. Can I please get some 
help?

Link to the line of code 
- 
https://github.com/adap/flower/blob/f139930bd9329ffce6b3c9466ded6a633c93c07d/src/py/flwr/client/app.py#L189

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/562c0d03-e762-4fb4-a576-fd25124f35ean%40googlegroups.com.


Re: [grpc-io] Re: Some gRPC releases are missing in Maven Central

2023-07-04 Thread 'Sanjay Pujare' via grpc.io
No. Based on my understanding of the CVEs, those vulnerabilities only exist
in the grpc C/C++ code base so there is no question of releasing patches
for grpc Java.

On Tue, Jul 4, 2023 at 3:02 AM Yaroslav Brahintes 
wrote:

> Thanks, my bad
>
> Is there a chance those security patches will be release for java version
> as well 1.54.2 and 1.52.2?
>
> On Sunday, 18 June 2023 at 18:46:38 UTC+3 sanjay...@google.com wrote:
>
>> Your links to v1.52.2 
>>  and v1.54.2  are for
>> the releases of grpc core (C/C++). For grpc-java (which is what you will
>> find on Maven central) you can find the releases at
>> https://github.com/grpc/grpc-java/releases. The "Grpc core" in Maven
>> central is just the grpc-core artifact of grpc-java and not to be confused
>> with the grpc core repository for C/C++.
>>
>> On Saturday, June 17, 2023 at 9:46:54 AM UTC-7 Yaroslav Brahintes wrote:
>>
>>> *Some gRPC releases are missing in Maven Central
>>> . For example:*
>>>
>>>- CVE-2023-32731  fixes
>>>that had been released in v1.54.2
>>>
>>>- CVE-2023-1428  fixes
>>>that had been released in v1.52.2
>>>
>>>
>>> Wondering if there's a specific reason why we shouldn't publish them to
>>> Maven? Also, could you recommend a good place for us to pull fixed patch
>>> versions without needing to upgrade minor versions
>>>
>> --
> 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/Y81gl6AP3Qw/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/1c0d755c-6ef7-4ccb-a238-2bd9bb9e1824n%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%2BPad6j5yC067Hoth6QpdNPyCT29f_0VCWY4w8yWwfjT4SUdSA%40mail.gmail.com.


[grpc-io] Re: Updates on gRPC C# (Grpc.Core) support

2023-07-04 Thread 'Jan Tattermusch' via grpc.io
FYI added some updates about the current status of Grpc.Core here: 
https://github.com/grpc/grpc/issues/32719#issuecomment-1620399357
On Wednesday, June 7, 2023 at 11:33:53 AM UTC+2 Zaphod Stardust wrote:

> @Jan Tattermusch:
> I understand  that now the "maintenance mode" of Grpc.Core is over.
> That means Grpc.Core is now officially deprecated, correct?
>
> What are the rules / support policies that apply now?
> -> No fixes (even for security) any more (besides contributed by open 
> source community)?
>
> Thanks for clarifying!
>
> Jan Tattermusch schrieb am Dienstag, 3. Mai 2022 um 11:25:07 UTC+2:
>
>> Hello gRPC C# Users!
>>
>> In May 2021 we announced  that 
>> Grpc.Core (the original C# implementation of gRPC) became "maintenance 
>> only" and that grpc-dotnet will be the recommended implementation going 
>> forward. We also announced that Grpc.Core will become deprecated in the 
>> future.
>>
>> While all the above is still the plan, we are making some adjustments 
>> based on the user feedback we received. We also wanted to publish more 
>> details about the plan and its technical execution. All the important 
>> updates are summarized in the following sections of this announcement.
>> Grpc.Core maintenance period will be extended by 1 more year (until May 
>> 2023)
>>
>> Originally we planned to deprecate the Grpc.Core implementation in May 
>> 2022, but the feedback we received from users has indicated that extending 
>> the maintenance period would make sense. Without going too much into the 
>> details, the main points of the feedback can be summarized as:
>>
>>- 
>>
>>The main blocker for deprecating Grpc.Core is the lack of support of 
>>the legacy .NET Framework in grpc-dotnet. The desire to migrate off the 
>>legacy .NET framework is often there, but migrating workloads from .NET 
>>Framework to .NET Core / .NET 6 simply takes time and effort.
>>- 
>>
>>Grpc.Core is a very important technology for enabling migration off 
>>.NET Framework (since it enables piece-by-piece migration by 
>>interconnecting components on newer .NET platforms with components that 
>>remain on .NET Framework), so supporting it for a little longer can 
>>(somewhat paradoxically) help users migrate off it faster.
>>
>>
>> As a result, we are delaying the deprecation of Grpc.Core until May 2023 
>> (1 year from now, and 2 years after the original announcement). Until 
>> then, Grpc.Core will remain to be supported in the "maintenance mode", as 
>> described below.
>>
>> Since the plan to deprecate Grpc.Core has been now publicly known for a 
>> while and since the main reason we are extending the maintenance period is 
>> to deal with the issues related to the legacy .NET Framework (and migration 
>> off it), we also want to clarify what exactly will be covered by the 
>> "Grpc.Core maintenance" going forward:
>>
>>- 
>>
>>The main goal of keeping Grpc.Core alive is to maintain the ability 
>>to run gRPC C# clients and servers on the legacy .NET Framework on 
>> Windows. 
>>This will be taken into account when considering issues / fixes.
>>- 
>>
>>We will only provide critical and security fixes going forward. This 
>>is to minimize the maintenance costs and reflects the fact that 
>> grpc-dotnet 
>>is the recommended implementation to use.
>>- 
>>
>>There will be no new features for Grpc.Core. Note that since 
>>Grpc.Core is moving to a maintenance branch (see section below), there 
>> will 
>>also be no new features coming from the native C-core layer.
>>- 
>>
>>There will be no new platform support and portability work. The focus 
>>will be on continuing support for the legacy .NET Framework on Windows 
>>(where there is no alternative implementation to use) and the list of 
>>supported platforms will not be expanded (e.g. we will not work towards 
>>better support for Unity, Xamarin, Alpine Linux etc.). We will likely 
>> drop 
>>support for platforms that have been so far considered as "experimental"  
>>(e.g. Unity and Xamarin), since they are also hard to test and maintain.
>>- 
>>
>>Work to support new .NET versions (.NET6, NET 7, …) will be kept to a 
>>minimum (or not done at all) since those .NET versions fully support 
>>grpc-dotnet.
>>- 
>>
>>No more performance work: Since the main purpose of Grpc.Core is to 
>>maintain interoperability with legacy .NET framework, there will be less 
>>focus on performance. We do not expect any significant performance drops, 
>>but performance may degrade over time if tradeoffs between performance vs 
>>maintainability are needed.
>>
>>
>> Grpc.Core moves to a maintenance branch in the grpc/grpc repository 
>> (while other actively developed packages move to grpc/grpc-dotnet 
>> repository)
>>
>> To simplify the maintenance of G

[grpc-io] Python: grpc aio server parallelism multicore

2023-07-04 Thread weide zhang
Hi, 

It seems from the documentation that the grpc aio server only uses one 
thread to do async io.  Does that mean for a multicore system, in order to 
leverage the performance of all the cores and using Async IO to achieve 
maximum performance , I have to spawn multiple thread or process each with 
its own aio server? 

My question is really how to leverage all the cores on one server in the 
meanwhile still using AIO to achieve maximum performance. 

Thank you,

Weide 

-- 
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/4cb9696d-af5f-422f-be66-921f17197db7n%40googlegroups.com.


[grpc-io] Re: Some gRPC releases are missing in Maven Central

2023-07-04 Thread Yaroslav Brahintes


Thanks, my bad

Is there a chance those security patches will be release for java version 
as well 1.54.2 and 1.52.2?

On Sunday, 18 June 2023 at 18:46:38 UTC+3 sanjay...@google.com wrote:

> Your links to v1.52.2 
>  and v1.54.2  are for 
> the releases of grpc core (C/C++). For grpc-java (which is what you will 
> find on Maven central) you can find the releases at 
> https://github.com/grpc/grpc-java/releases. The "Grpc core" in Maven 
> central is just the grpc-core artifact of grpc-java and not to be confused 
> with the grpc core repository for C/C++.
>
> On Saturday, June 17, 2023 at 9:46:54 AM UTC-7 Yaroslav Brahintes wrote:
>
>> *Some gRPC releases are missing in Maven Central 
>> . For example:*
>>
>>- CVE-2023-32731  fixes 
>>that had been released in v1.54.2 
>>
>>- CVE-2023-1428  fixes 
>>that had been released in v1.52.2 
>>
>>
>> Wondering if there's a specific reason why we shouldn't publish them to 
>> Maven? Also, could you recommend a good place for us to pull fixed patch 
>> versions without needing to upgrade minor versions
>>
>

-- 
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/1c0d755c-6ef7-4ccb-a238-2bd9bb9e1824n%40googlegroups.com.