we have an RPC client server product that up to now exclusively makes use of synchronous RPC: Clients keep state on the server in the form of context handles and make synchronous calls into the server in a periodic fashion and retrieve new data. Our server works quite nicely with thousands of clients connected to it this way.
Now we would like to invert this model in order to serve needs of specific clients that need to be notified instantly of new data. I was thinking of the clients making an async rpc call into the server that the server keeps "parked" until it has data for the parked client, then completing the async rpc. That would notify the client that it now has updated data that it could now retrieve in an out-of-order fashion using the synchronous calls it has used as before.
However, I have no data how the rpc server would behave if it has thousands of outstanding, "parked" client calls lingering around that it might not complete for days, weeks or months. I have already read in the msdn section on async rpc over named pipes that this should be avoided. But I still have the nagging question how many clients a reasonably written rpc server (using ncacn_ip_tcp as the transport sequence) can handle that each has a parked async call on it. Will this drain any resources on the server significantly or is there a known practical upper limit for the number of concurrently placed async calls?
Is what I want a proper use case at all for async rpc or do I pervert the async rpc model this way?
TIA,
-- Stefan