Thanks Benjamin for this info. I decided to implement Client/Server model on both sides. This is working as expected.
Op woensdag 31 januari 2018 12:50:54 UTC+1 schreef Benjamin Krämer: > > 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/1c8860a9-b1b5-4e34-9635-9691d92894f4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
