0

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

Stefan Kuhr
  • 13
  • 5
  • Maybe I should mention, that this is a question about MSRPC on Windows, in case that wasn't clear from the tags used. – Stefan Kuhr Mar 26 '17 at 12:31
  • clients can exit without notify server about this (comp random shutdown or internet break) - but server will still mantain handle for this client (if not do periodic ping for every client, but this return you to first model). then count of connected clients at time will be much more, compare when clients connect on very short time, ask some data and disconnect. every connection of course take certain amount of kernel and user memory on server.not sure, but think this not very good idea – RbMm Mar 26 '17 at 13:56
  • with at first you will be have problem with "zombie" clients. at second - let you have`N` clients online. so you will be have `N` connections every time. in case every client with period `T` make short call wich take time `t` - will be `N * t/ T` connections per time. when `t/T` can be usually say ~ `1/1000` (say t=1 sec, T=20min). and when data will be updated on server - you at once need be call to `N` clients to notify it. say `N == 10000` - you at once send 10000 packets? – RbMm Mar 26 '17 at 14:36
  • do you have thousands of clients? Or you only expect thousands of requests by limited number of clients? – Sergei Vorobiev Mar 27 '17 at 05:01
  • @RbMm I do not have to worry about any "zombie clients" because, as I wrote, I am using context handles and the rpc runtime caters for clients getting lost, in that case it will invoke the rundown routine for the client on the server, polling is what the rpc runtime does for me for free. – Stefan Kuhr Mar 27 '17 at 18:21
  • @Sergei Vorobiev We currently have up to sort of like 8000 clients concurrently connected to the rpc server and everything is working nicely there. I wonder whether having in addition 8000 "parked" async calls, one per each client is feasible at all, as I do not have expertise right now regarding the effects of having many, many outstanding parked calls on the rpc server for a long time. Does using async calls have noticeable detrimental effect on an rpc server with regards to system resources, such as the number of threads, kernel memory, handle count, CPU load etc. ? – Stefan Kuhr Mar 27 '17 at 18:26
  • `and the rpc runtime caters for clients getting lost` - how can rpc runtime know that some remote client exit without correct close connection ? only if it do periodic ping for client. not sure are it do this or not – RbMm Mar 27 '17 at 18:31
  • @RbMm Yes indeed this is the case: Using context handles, the rpc runtime lifts the burden from you to do a keep-alive scheme yourselves for state that the client has on the server. This is one of the most astounding features of the rpc runtime and it works super reliably. Now back to my original question about the burden that parked async calls in the thousands for a long time without getting completed by the server puts the server. Any experience with that? – Stefan Kuhr Mar 28 '17 at 15:55

0 Answers0