You could either do this using the server-client model you described (both have an server implemented and use the other as client) or you can use a bidirectional stream, implementing an observer pattern. One example can be found with the GRPCLB proto: https://github.com/grpc/grpc/blob/master/src/proto/grpc/lb/v1/load_balancer.proto
The client A calls the BalanceLoad method on the server B. It will send the InitialLoadBalanceRequest directly after connecting. Server B knows that and expects the first message in the stream to be that message. After it got that message, it's responding by sending the message InitialLoadBalanceResponse back to A, which is waiting (a)synchronously for that. After that initialization, A can send ClientStats messages to B as async events and B can send ServerList to A as async events. But you always are able to just wait for the response synch is you know this will come directly as response as shown with the InitialLoadBalance Req/Rsp. pair. Am Mittwoch, 31. Januar 2018 08:57:04 UTC+1 schrieb Dave Rabelink: > > > Hello, > > I'm trying to implement grpc to be a bridge between a JAVA application (A) > and a C# (.NET) server application (B) (always running on the same machine). > > *1)* The client A should be able to call synchronous service methods on > the server B (request->reply). > *2)* The server B should be able to throw synchronous "events" back to > the client A and wait for the response (request->reply). > > > The synchronous calls from the client was easy to implement. > The server is running on port X, the client connect to it and calls the > defined methods in the service. > > But I have trouble finding the best way to implement (2) where the server > is calling the client and waiting for the response. > > It seems that bidirectional streams is not the way to do this as the > messages are asynchronous and will not wait for the receiver to respond > while blocking the server. > It should really be a blocking call. > > > Let me explain with an example. > > The server has to notify the client at a certain moment to ask for the > status of the client. So the server has to send a message to the client and > wait for it to respond giving the status as reply data back. > > I could not find a clear sample anywhere (maybe I'm not using the correct > words in my search actions), so I'm not sure what the best implementation > would be. > > Personally I came up with this solution: The client A is at the same time > also a server. And the server B is at the same time a client. > > So, client A will connect to server B using port X > The client will call the server inidicating it subcribes for events from > the server by starting a server object on port Y. > The server will then connect to the client on port Y. > > When the server then needs to notify the client it calls a method of the > client on port Y which is synchronous and blocking. > The client calls methods on the server using port X. > > Would this be a valid way to implement these requirements or is there a > better way to do this? > Any help is appreciated, to have the best conceptual view on such an > architecture. > > > Can someone indicate this would be a valid sulution for the requirement > -- 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 [email protected]. To post to this group, send email to [email protected]. 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/7f218b22-9adc-4da9-b1f9-5d99af2c3005%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
