#grpc

(I'd have talked sooner, but got out of my routine so wasn't watching.)

I do think #8398 is the right one to watch. ericgribkoff has been messing with this more recently.

Can grpc have the server send ssomething to a client without a request from it (Start from the server?

Or keep a stream from the server to the client open for a long time and then have the client "Hook" a function for each element received in a non-blocking way

And, is it possible for the server to keep data/context for a connection through many messages? Like a login/auth

Sorry if these questions are stupid, I'm not sure if grpc is what I'm looking for yet

so, no, the server can't send anything to the client without an initial request, but what you said next is true: you can do long lasting streaming calls

Nick_64_: The client must always start with a request. The client could start an RPC and leave it open for a long time. The "hook"ing you'd make yourself. Non-blocking depends on the language.

where the client sends one initial request

hah

https://github.com/grpc/grpc/issues/14101 is related, with a POC implementation in Java.

But could i make it so it ends up working as if the server was sending stuff?

Like, can i trigger some code whenever the open stream gets data in the client?

Like a hook function or something

Instead of using ->Next() in cpp which seems to be blocking

When the open stream receives data, you could choose what to do with it.

Say I have a game. I want to recieve messages from a server. Could i make it so i connect to the server, send a request, keep an open stream and a function (Or something equivalent) is called every time the server sends something through that stream?

For the last question, no I strongly discourage doing connection-based state. Lots of things break it. Instead, I'd suggest the client send the information every request and use a cache or similar on server-side.

Nick_64_: in C++, yes. That'd be the async API (vs blocking). |Pixel| would be able to point you to details.

I saw an async example for the route thing in cpp

But iirc it did something like while(stream->Next()) to read from the result/response stream

And that Next seemed to be blocking

so

there's often confusion on the notion of async and whatnot with regards to C++

gRPC is its own event loop

so while you can send multiple requests in parallel

and be able to get their answers asynchonously from each other

you are still going to go inside grpc's event loop to process them

Mhm

if you use the completion queue mechanism, without any deadline, yes, you will wait forever until something happens there

Is there something to check if theres unread/new data in a stream?

So i could just run that in my main loop

if you are writing a video game however, and wants to process other things while maxing out the CPU, then on each "frame" of your game, you can call into grpc's completion queue with a deadline of 0

I mean I'd have a "message sent by the server" which I wouldnt need anywhere, it would just trigger some action client-side

making sure that you will return immediately whatever happens

check greeter_async_client.cc

the change in this one code for the mode I am talking about would be

rpc->Finish(&reply, &status, (void*)1);

Changing that to a 0?

no :)

that's your tag; typically you want a pointer here

this line:

GPR_ASSERT(cq.Next(&got_tag, &ok));

blocks

and is the main event loop / dispatcher

you want to change it to call AsyncNext instead

with a deadline of 0

so that it returns immediately

Oh right makes sense, completionQueue.Next

basically, when you call Finish, you pass a "tag", here we say 1, but usually people would create an object in memory

and pass the pointer of that object to Finish for context

then when the completion queue returns with a tag, cast that tag back to a pointer of that type of object to continue the context

internally the type for "tag" is a uintptr, so it's guaranteed to fit any sort of pointer safely

(well, most sorts of pointers...)

So, if i called std::unique_ptr<ClientReader<MessageType> >->Read(&item) with a stream response using AsyncNext

It would not return true until the server sent something, and the main event loop wouldnt block

along these lines, yes :)

Thanks a lot, I think I can use grpc for what i wanted :)

What does rpc->Finish fill reply with here btw https://github.com/grpc/grpc/blob/master/exampl... ?

If it still hasnt run cq.Next

it's not filled yet at that point

Finish here is to say you're done with writing the request object

Oh, basically adds it to the queue?

and that grpc can start reading your request object to send it down the wire

yes

In the next cq.Next call

kinda

and when Next (or AsyncNext) returns

reply is filled

THEN and only then your reply is filled

Also

If i have an open stream, and I wanna keep it alive

Is there any way for the server to kill/stop it

https://github.com/grpc/grpc/blob/master/exampl... Like here

errr, I think so

If i was using an async cq.AyncNext then I wouldnt want to call Finish right

I was just wondering when the stream would die/end in that case

trying to remember the exact sequence of events; sorry been a while since I put my hands in that part of the project :P

An async example with streams would be nice

yeah, I guess I could also poke at someone else who's a bit more familiar with these specifics

Hello. I'm getting issues with the netty transport of my grpc service. Getting Transport failed... I'm using grpc 1.9 and netty-all:4.1.17.Final

what should I check otherwise?

nvm, got it. I had wrongly configured my channel to use ssl.