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 grpc-io+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@googlegroups.com.
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.

Reply via email to