[grpc-io] Can a GRPC Server instance have more than one port number.

[rohit nv]

Have scenario where I need to run a Grpc Server application module  
instance which should possess more than port number to handle different 
client requests. Is it possible?

-- 
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/5cd64e0b-ba92-4b3e-b042-41d54baf8f06n%40googlegroups.com.

[grpc-io] gRPC internal thread in C++

['Alex Zuo' via grpc.io]

I am trying to understand how many internal threads gRPC creates in async 
mode. I find some timer threads, and some threads in Executor. Are there 
any threads? Are there any short-lived thread?

Also are there any threads to receive bytes from socket and deserialize 
them?

-- 
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/707c5f11-1c0e-4654-8547-dfd33f1f31ecn%40googlegroups.com.

Re: [grpc-io] gRPC vs DBUS?

['Eric Anderson' via grpc.io]

On Wed, Jun 16, 2021 at 12:43 PM Jason Hihn  wrote:

> I am working on a project that currently uses DBUS and I am contemplating
> moving it to ProtoBuf/gRPC. (C++ based) Protobuf seems to have many
> advantages.


DBus is object-oriented; you can return data (a struct) or objects
(references to remote objects). It has a full type system and you can do
reflection on remote objects and it helps manage reference counting. Be
aware that gRPC only sends data (messages).

As a newcomer, there are a few questions I had about gRPC:
> 1. DBUS provides a session bus and a system bus services. gRPC provides a
> server implementation of sorts.
> 2. The documentation seems to be written with the assumption that messages
> to the server are client-server conversations (like HTTP). Is there
> anything preventing a client from writing a message to the server, then
> that message is then broadcast to all connected clients? (Like DBUS)
>

gRPC is point-to-point, where DBus traffic goes through a broker
(dbus-daemon; let's ignore kdbus) which provides the bus. You can do the
bus-based approach with gRPC, but you'd then need to create that broker
daemon. It is certainly possible, and would be a service like Pub/Sub
 (although obviously not a hosted service).

Essentially I'm saying that DBus is actually several things which in gRPC
would be distinct. Protobuf is the message encoding, gRPC is the
communication, and some broker service actually provides the bus.

It is possible to make a bus in a peer-to-peer fashion without a central
broker (maybe in spirit to zeromq; although I've not looked at their
approach), but that's a slightly different discussion.

3. Can the above question be modified to have a publish/subscribe paradigm
> so that not all connected clients wake up for every message (limit
> CPU/battery usage).
>

I think that'd be a decision of the broker. Either the clients poll at
their preferred frequency or they establish a stream to the broker to be
woken up for messages. If the broker should "batch up" notifications for a
stream-based watch, the client would need to inform the broker of its
configuration.

4. Are there any examples of gPRC busses?
>

Pub/Sub is by far the most obvious. I think if you search around a bit
you'll see plenty of examples of using streams for notification.
Broadcasting buses do have their own complexities, like protecting the
broker if a subscriber reads too slowly, which you may find less
gRPC-specific details. But those issues are normal that have to be managed
when making a bus using any technology and the solution doesn't need to
depend on gRPC much.

-- 
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%2B4M1oMDq_q9tNK53U4Hqyp%3Dc2RtNwA6K8SHwuSopNOGinVM6Q%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

[grpc-io] gRPC vs DBUS?

[Jason Hihn]

I am working on a project that currently uses DBUS and I am contemplating 
moving it to ProtoBuf/gRPC. (C++ based) Protobuf seems to have many 
advantages.

As a newcomer, there are a few questions I had about gRPC:
1. DBUS provides a session bus and a system bus services. gRPC provides a 
server implementation of sorts.
2. The documentation seems to be written with the assumption that messages 
to the server are client-server conversations (like HTTP). Is there 
anything preventing a client from writing a message to the server, then 
that message is then broadcast to all connected clients? (Like DBUS)
3. Can the above question be modified to have a publish/subscribe paradigm 
so that not all connected clients wake up for every message (limit 
CPU/battery usage).
4. Are there any examples of gPRC busses? 

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/7984c23e-cca9-43d7-a8b0-b896aee68ff9n%40googlegroups.com.

Re: [grpc-io] Java grpc client behaviour on hitting H/2 max concurrent streams

['Eric Anderson' via grpc.io]

Yes, this is on purpose, and is actually expected per the HTTP/2 spec
. We recognize
there are situations where that is not the correct behavior and more
connections should be opened, although that point may be *before* hitting
MAX_CONCURRENT_STREAMS. Determining when to open more connections is a bit
involved as it depends on your load balancer approach. It isn't helped by
the fact that MAX_CONCURRENT_STREAMS can be dynamic and servers are allowed
to set MAX_CONCURRENT_STREAMS to 0 (momentarily); that's actually something
C core can do when under extreme memory pressure. Opening more connections
can make overload situations worse. Anyway, it is complicated. Clients that
just open more connections tend to assume high-scale internet load
balancers that can accept ~infinite number of connections and use
hard-coded MAX_CONCURREN_STREAMS.

Using a solution like ChannelPool (linked in Yuri's email) is the suggested
workaround in Java; it is a bigger issue in some other languages where you
don't have a small Channel interface that the stubs use.

On Tue, Jun 15, 2021 at 10:22 PM 'Gaurav Poothia' via grpc.io <
grpc-io@googlegroups.com> wrote:

> Hello!
> I have a situation where the server sets H/2 max concurrent streams
> intentionally low (e.g. 16 or 32) for good reason (that are somewhat
> orthogonal to gRPC so I will skip the details)
> The behavior I seem to be observing is that Java gRPC client stalls when
> it hits that limit and waits for streams to free up before issuing more
> requests.
> Is this the expected behavior?
>
> I was hoping for a knob that allows me to instruct gRPC to dial additional
> H/2 connections when it hits the limit. Turns out the .Net implementation
> has something exactly  like that
>
> https://docs.microsoft.com/en-us/aspnet/core/grpc/performance?view=aspnetcore-5.0#connection-concurrency
>
> Does Java gRPC stack have an equivalent?
>
> It would be pretty useful in seamlessly handling service to service
> communication where server can support a higher gRCP req/sec but only if
> the client were to dial more H/2 connections.
> I say "seamlessly" because of course we can write code to somehow dial
> more subchannels to server but we want the client to do this automatically
> without programmer picking hardcoded connection count.
>
> Thanks in advance!
> Gaurav
>
> --
> 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/a687afdc-6c52-449f-85ab-5c9d83543f08n%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%2B4M1oNt6N5B%2B6E_MLMo6EDWjA%2Boons2ZLe9dfJj9JXZ_wMssA%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

[grpc-io] Re: grpc.channel_ready_future throw inactive rpc error

['Richard Belleville' via grpc.io]

It seems that the client is failing to connect to the server:

"failed to connect to all addresses",

Are you sure that the server is listening on that port? Try running netstat 
on the server to verify. Are there firewall rules getting in the way? Try 
using nmap from the client to verify.

On Friday, June 4, 2021 at 9:05:47 PM UTC-7 sheikh...@gmail.com wrote:

> Hi Team,
>
> the below code throws exception
>
>
> with grpc.insecure_channel('192.168.0.176:1234') as channel:
>
> grpc.channel_ready_future(channel).start()
> except grpc.FutureTimeoutError:
> sys.exit('Error connecting to server')
>
>
>
>
>
> = EXCEPTION =
> Traceback (most recent call last):
>   File "/Users/sheikhjebran/Desktop/new/mySocket.py", line 53, in 
> advertising()
>   File "/Users/sheikhjebran/Desktop/new/mySocket.py", line 48, in 
> advertising
> response = stub.RequestAdvertisement(Nothing)
>   File 
> "/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/grpc/_channel.py",
>  
> line 946, in __call__
> return _end_unary_response_blocking(state, call, False, None)
>   File 
> "/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/grpc/_channel.py",
>  
> line 849, in _end_unary_response_blocking
> raise _InactiveRpcError(state)
> grpc._channel._InactiveRpcError: <_InactiveRpcError of RPC that terminated 
> with:
> status = StatusCode.UNAVAILABLE
> details = "failed to connect to all addresses"
> debug_error_string = 
> "{"created":"@1622865794.382882000","description":"Failed to pick 
> subchannel","file":"src/core/ext/filters/client_channel/client_channel.cc","file_line":3009,"referenced_errors":[{"created":"@1622865794.382874000","description":"failed
>  
> to connect to all 
> addresses","file":"src/core/ext/filters/client_channel/lb_policy/pick_first/pick_first.cc","file_line":398,"grpc_status":14}]}"
> >
>
>
>

-- 
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/8c5d35a9-4010-4fa7-bd1a-bc580811de9en%40googlegroups.com.

[grpc-io] Re: __call__() require one positional argument 'request'

['Richard Belleville' via grpc.io]

There's not a lot of information to go on here, but your error message is 
pretty clear in one respect:

TypeError: __call__() missing 1 required positional argument: 'request'

You need to supply a request when you invoke your stub (which is presumably 
what you're doing in this snippet).
On Friday, June 4, 2021 at 8:51:23 PM UTC-7 sheikh...@gmail.com wrote:

> Hi Team,
>
> I have created a proto file for a method which dont not take any argument 
> nor return back any thing,
>
> but when i run my code it throws the below exception
>
>
> Connected to pydev debugger (build 211.7442.45)
> 1041
> 1041
> Traceback (most recent call last):
>   File "/Applications/PyCharm 
> CE.app/Contents/plugins/python-ce/helpers/pydev/pydevd.py", line 1483, in 
> _exec
> pydev_imports.execfile(file, globals, locals)  # execute the script
>   File "/Applications/PyCharm 
> CE.app/Contents/plugins/python-ce/helpers/pydev/_pydev_imps/_pydev_execfile.py",
>  
> line 18, in execfile
> exec(compile(contents+"\n", file, 'exec'), glob, loc)
>   File "/Users/sheikhjebran/Desktop/new/mySocket.py", line 52, in 
> sample()
>   File "/Users/sheikhjebran/Desktop/new/mySocket.py", line 35, in sample
> stub.Reset()
> TypeError: __call__() missing 1 required positional argument: 'request'
> python-BaseException
>
> Process finished with exit code 1
>
>

-- 
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/0d89d7ba-9a5a-404b-b1f8-522b13b80f11n%40googlegroups.com.

[grpc-io] Re: Using async grpc streaming APIs

['yas...@google.com' via grpc.io]

> Does that mean there shouldn't be any outstanding Writes / Reads when 
this function is called? Or just that there shouldn't be a call to "Finish" 
when a call to "Read" or "Write" is in progress (as in multiple threads 
competing with each other)? I didn't see a problem with an outstanding read 
when I tested (by issuing a read, closing server side, closing client side 
in parallel) this, but just wanna confirm what’s ideal.

This has to do with API usage. It is not safe to call `Finish()` when a 
`Read()`/`Write()` operation is in progress (for example, if it is an 
asynchronous operation and the tag has not yet been received from the 
completion queue.)

> Does this mean that a call to "WritesDone" before calling "Finish" is 
optional and I can just directly call "Finish" instead? If yes, in what 
circumstances would one find calling "WritesDone" before "Finish" useful?

A `WritesDone()` would result in a half-close from the client and I can 
imagine cases where a half-close from the client is useful for the server 
to know (cases where there are still more messages to be read).

> The documentation for CompletionQueue::Next 

 says that for a client-side Read, a call to Next returns not-ok only when 
the "call is dead". What all does that exactly mean? What constitutes a 
"call"? I thought it could be not-ok if the server-side or client-side is 
already "Finish"-ed or if the underlying network was compromised.

A "call" here is an RPC or a stream from a HTTP2 perspective. When `Read()` 
fails on the client, it is a good signal that the RPC has ended one way or 
another, either through a proper status received from the server or some 
error (includes network errors). This status/error would be received when 
`Finish()` is called.

> Also, is it ok to invoke ClientAsyncStreamingInterface::Finish before the 
server has sent all its messages and before a AsyncReaderInterface::Read yields 
a not-ok tag? I see that the second point in documentation 

 for 
this "Finish" instructs exactly against such a usage, but I just wanted to 
confirm if it's an illegal usage and could result in run time errors 
(assert fails) from grpc code?

It is illegal usage of the API. I'm not sure if we have asserts in place 
for this though.

> Also, what's the accepted way to close the streams when it's not 
implicitly known that no more messages are to be received from the server? 

1. Invoking `WritesDone` is just a half-close and does not mean that the 
RPC is done. 
2. Waiting for `Read()` to fail is a sure-shot way of knowing that the RPC 
is done. 
3. It's not safe to invoke `Finish()` if we don't know that we are done 
reading. I believe the call would just get stuck here but I might be wrong 
as to the observable behavior here.
If we just want to end the RPC without caring about the server's status, 
then the client can also cancel the RPC with a `TryCancel()` on the 
ClientContext.



On Friday, June 4, 2021 at 8:42:02 PM UTC-7 Piyush Sharma wrote:

> *(Working with grpc async bidirectional streaming)*
>
>
>1. 
>
>For ClientAsyncStreamingInterface::Finish 
>
> 
>  
>and for ServerAsyncReaderWriterInterface::Finish 
>
> 
>  the 
>documentation says: 
>
>"Should not be used concurrently with other operations"
>
>Does that mean there shouldn't be any outstanding Writes / Reads when 
>this function is called? Or just that there shouldn't be a call to 
> "Finish" 
>when a call to "Read" or "Write" is in progress (as in multiple threads 
>competing with each other)? I didn't see a problem with an outstanding 
> read 
>when I tested (by issuing a read, closing server side, closing client side 
>in parallel) this, but just wanna confirm what’s ideal.
>
>2. 
>
>For ClientAsyncStreamingInterface::Finish the doc 
>
> 
>  
>says:
>
>"
>/// It is appropriate to call this method exactly once when both:
>/// * the client side has no more message to send
>/// (this can be declared implicitly by calling this method, or
>/// explicitly through an earlier call to the WritesDone method
>/// of the class in use, e.g. \a 
>ClientAsyncWriterInterface::WritesDone or
>/// \a ClientAsyncReaderWriterInterface::WritesDone).
>"
>
>Does this mean that a call to "WritesDone" before calling "Finish"

[grpc-io] Re: Use of insecure C functions/API(s)

['yas...@google.com' via grpc.io]

There is no roadmap to remove them that I am aware of. As for whether these 
functions are handled safely everywhere, that seems like an alternate way 
of asking if gRPC has bugs related to this. What I CAN tell you is that the 
code is continuously tested, and I would imagine that if there was a bug 
related to the usage, it would get fixed when found.

On Wednesday, June 2, 2021 at 2:31:26 AM UTC-7 Nilesh Gajwani wrote:

> Hi, 
> We had a penetration testing done for our iOS app, which uses gRPC-Core 
> pod.
> We received comments specifying that unsafe C functions (example: memcpy, 
> malloc, etc) are being used in the binary.
> On searching in the project directory for a example function (memcpy), I 
> can see the gRPC-Core files using this function.
> Can you give an confirmation if these functions are handled safely 
> everywhere, or is the removal of these in the roadmap?
> Please check for the example API call, memcpy for now, I can provide list 
> of all functions if needed
> Thanks and regards,
> Nilesh
>
>

-- 
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/c479856b-862e-4c7b-9851-d3e352097b0fn%40googlegroups.com.

[grpc-io] Re: What is the mechanism of Completion Queue?

['yas...@google.com' via grpc.io]

> However, HandleRpc() only call proceed() once,. It seems we always stay 
in the PROCESS state. Will it generate the memory leak?

No, the same CallData object is used multiple times as a completion queue 
tag, allowing the state to progress.

> What does it mean to have cq->next(&tag, &ok) return the out param ok as 
false? 

A `false` value for `ok` signifies a failure to read a successful event, 
but the documentation already mentions that. Do you have a more specific 
question that you have in mind?
On Sunday, May 30, 2021 at 12:44:25 PM UTC-7 Mohan Gyara wrote:

> What does it mean to have cq->next(&tag, &ok) return the out param ok as 
> false? 
> I appreciate if someone answer this. 
>
> Regards,
> Mohan
>
> On Thursday, 5 November 2015 at 08:48:33 UTC+5:30 hardy wrote:
>
>> Is there anyone familiar with CompleteQueue could tell me how the 
>> mechanism is? The only piece of codes I can found is 
>>
>>   void HandleRpcs() {
>> // Spawn a new CallData instance to serve new clients.
>> new CallData(&service_, cq_.get());
>> void* tag;  // uniquely identifies a request.
>> bool ok;
>> while (true) {
>>   // Block waiting to read the next event from the completion queue. 
>> The
>>   // event is uniquely identified by its tag, which in this case is 
>> the
>>   // memory address of a CallData instance.
>>   cq_->Next(&tag, &ok);
>>   GPR_ASSERT(ok);
>>   static_cast(tag)->Proceed();
>> }
>>   }
>>
>>
>> I really would like to know how I could response to different kinds of 
>> request? And will the loop keep iterating over the CompleteQueue again and 
>> again?
>>
>>

-- 
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/04221c3d-b036-4f33-be64-24e56e065c0fn%40googlegroups.com.

[grpc-io] Questions on unary RPC and error issues

[Diedrichs, Hugh]

I saw your pdf on using gRPC for long lived and streaming RPC and would like to 
ask some questions about RpcException and other issues we're getting issuing 
unary RPC commands from our c# server app to our localhost c++ app.

We replaced WCF with gRPC for our inter-process communication, so it's all just 
over localhost using the HTTP/2 transport. Our Platform runs in C# and needs to 
communicate with the Game (C++). Because some of the calls are Platform->Game, 
we have a Server set up game side, which the Platform C# client calls. And 
because some of the calls are Game->Platform, we have the opposite set up. Both 
servers are on different ports on localhost.

The RpcException is the most frequent and where we have the most information 
about. Usually, what we'll see is the C++ Server receives the RPC call and runs 
into an unknown frame type. Then the subchannel goes into shutdown and 
everything usually re-connects fine.

What we've seen with the unknown frame type, is that the C++ server parses the 
HEADERS, WINDOW_UPDATE, DATA, WINDOW_UPDATE and then gets a TCP: on_read 
without a corresponding READ and then tries to parse again. It's this parse 
where it looks like the parser is at the wrong offset in the buffer, because it 
gets the unknown frame type, incoming frame size and incoming stream_id all map 
to the middle of the RPC call that it just parsed.

We are sending info from c# server to c++ client at a high speed, like dozens a 
second. This maybe the issue. We also attempted a retry scheme to no effect. We 
also added waitforready in the server and client which settled down some of the 
issue but not all.

Any help would be appreciated.





IMPORTANT CONFIDENTIALITY NOTICE:

This e-mail (including any documents referred to in, or attached to, this 
e-mail) may contain information that is personal, confidential or the subject 
of copyright, privilege or other proprietary rights in favour of Aristocrat, 
its affiliates or third parties. This e-mail is intended only for the named 
addressee. Any privacy, confidentiality, legal professional privilege, 
copyright or other proprietary rights in favour of Aristocrat, its affiliates 
or third parties, is not lost nor waived if this e-mail has been sent to you in 
error.

If you have received this e-mail in error you should: (i) not copy, disclose, 
distribute or otherwise use it or its contents without the consent of 
Aristocrat or the owner of the relevant rights; (ii) let us know of the mistake 
by reply e-mail or by telephone (AUS +61 2 9013 6000 or USA +1-877-274-9661); 
and (iii) delete it from your system and destroy all copies.

Any personal information contained in this e-mail must be handled in accordance 
with applicable privacy laws.

Electronic and internet communications can be interfered with or affected by 
viruses and other defects. As a result, such communications may not be 
successfully received or, if received, may cause interference with the 
integrity of receiving, processing or related systems (including hardware, 
software and data or information on, or using, that hardware or software). 
Aristocrat gives no assurances and accepts no liability in relation to these 
matters.

If you have any doubts about the veracity or integrity of any electronic 
communication we appear to have sent you, please call (AUS +61 2 9013 6000 or 
USA +1-877-274-9661) for clarification.

-- 
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/DM5PR08MB3369F1CD887C85C10BA4DB2DF00F9%40DM5PR08MB3369.namprd08.prod.outlook.com.