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. Feb 12, 2019 at 14:50
  • 6
    @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, 2019 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, 2019 at 10:02
  • 1
    @TomFp actually polling is more scalable than signalr but signalr can update much faster. Feb 14, 2019 at 16:01
  • 1
    Your solution is as unatural as ordering a pizza and waiting on the phone till the delivery.
    – Laiv
    Feb 14, 2019 at 16:45

1 Answer 1


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).

  • +1 to the server providing with estimations. This would make the API more web firendly.
    – Laiv
    Feb 14, 2019 at 16:42
  • @JimmyJames I did the similar design in my long running REST API. But client should have a option to cancel the long running process. Could you suggest the standard way to implement this?
    – Mdumanoj
    Dec 16, 2020 at 14:14
  • 1
    @Mdumanoj The easiest way to accomplish this is if you have a main control loop for the process. You can then check for cancellation in that loop. If there's multithreading involved, it gets a bit more complicated but the general approach is the same, each thread needs a main control loop that checks for cancellation..
    – JimmyJames
    Dec 16, 2020 at 14:19

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