What I'm looking for is a pattern for the client triggering a server process, then the server process signalling the client when its finished.

preferably with examples available in .NET or dotnetcore

My application is accessed through a REST api. I have a full-featured windows client (WPF) and a smaller web client.
Sometimes a server process is requested that takes too long for C# await HttpClient.GetAsync(REST Url) - the server process continues, but the client times out and throws an exception.

So my temporary fix is to catch the exception, and inform the client "process taking longer than expected, results may be available if you refresh in a few minutes" - but this is far from satisfactory.

I dont want to go so far as creating a microservice with messaging and queues

And I'd rather not have client polling the server to check for updates.

Ideally the solution could then be used to refresh the client with percentage complete or expected time left data

  • Look at SignalR for web socket communication, it would work with web client, I have never used with windows client so not sure about that aspect. – Scott Mildenberger Feb 12 '19 at 14:50
  • 5
    @TomFp Can you elaborate why you don't want polling? It's the simplest and most reliable solution for something like this. – JimmyJames Feb 12 '19 at 16:35
  • @JimmyJames I rejected polling simply because of scalability. If multiple clients are sending status update requests it will tie up server resources accepting and routing those requests. And If I want to change polling behaviour its a client update for Windows clients. It looks like SignalR is the way to go, – TomFp Feb 14 '19 at 10:02
  • @TomFp actually polling is more scalable than signalr but signalr can update much faster. – Esben Skov Pedersen Feb 14 '19 at 16:01
  • 1
    Your solution is as unatural as ordering a pizza and waiting on the phone till the delivery. – Laiv Feb 14 '19 at 16:45

You say you want to avoid polling but I think it's likely that you are over-engineering this a bit. Websockets use and hold server resources whereas a status request will only use resources while the request is being handled. In addition, they introduce a number of failure modes that you don't have to worry about with polling.

If you are able to estimate the time to complete, you can simply provide that in the original response and code the client to check again around that time. If your estimation is good, this will limit the number of status updates to a handful for each time you need to do this. A websocket is likely to use more server resources than this.

Your status checks should be very quick in order to reduce concurrency with other requests. If you are doing complex queries or computations in these status checks, then that's where you should focus your efforts. For example, you could have a thread-safe in-memory dictionary that you update when the background processing completes. The status update is then simply a read from that dictionary which should take on the order of a millisecond (or less).

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.