2

Basically, I have a remote hosted server somewhere https://nnn.com

And then I have the NNN Desktop Client.

The Desktop Client shows information X.

I change information X from the remote hosted server.

How can I make it so that the displayed information X in Desktop Client is automatically updated?

At first I thought that the solution was web-hooks, but from what I understand, the Desktop Client would then need a url.

And then I thought of the Desktop client calling an endpoint from the remote hosted server, checking if there are any updates. Polling, basically. But I don't know if that's the right way. And if it is, do I check every 5 seconds? 1 minute? That I do not know.

Any help or guidance is appreciated.

Rigo Sarmiento
  • 177
  • 1
  • 5
  • 2
    This question looks like a duplicate of this one: https://softwareengineering.stackexchange.com/questions/289664/pushing-data-from-server-to-client-without-a-client-request – Phil N DeBlanc Dec 05 '18 at 09:33
  • -ish? kinda. i do think it's taking me in the right direction. thanks! – Rigo Sarmiento Dec 06 '18 at 05:47
  • The client needs to talk to the server to get updates. Would websockets be an option? – Thorbjørn Ravn Andersen Dec 26 '20 at 09:11
  • Go for web sockets but keep in mind that that implies a load in your backend that must be handled/scaled properly. Also you can do long pooling if you can asume a more delayed communication and don’t need it to be real-time, and less vi-diriractional – X.Otano Aug 22 '21 at 19:34

2 Answers2

2

There's several options available to you, but first we need to discuss what the requirements are for updates on screen. As far as human perception is concerned, there's a nice write up by the Nielson Norman Group on response times. Basic gist is when a user performs an action:

  • 100 milliseconds is perceived as instantaneous
  • 1 seconds or less won't interrupt train of thought
  • More than 10 seconds feels like something is broken

That said, if changes from the back end aren't changing more frequently than once every 5 seconds, there's no reason to send updates more often then that. Without further information, I would recommend push updates to have an interval between 1-10 seconds.

Second thing to consider is network controls you'll need to worry about. For example, in corporate environments, it's pretty common to lock down external communications to standard internet ports, and may prevent externally originated traffic (i.e. users must initiate a request from inside to get data back).

Polling

This is easy to understand, and you'll need to consider gaps in communications. For example, the client may not be able to make a request in the interval you want because communications were temporarily down. That's easily overcome by specifying the time frame that you are requesting for updates.

  • Pros: it works with standard web interactions, and won't be blocked by firewalls
  • Cons: if updates aren't that frequent you could be using bandwidth for no benefit

WebSockets

WebSockets essentially keep the connection open and allow the server to push updates. It's used by quite a number of highly interactive sites. It's also a standard web technology so it's not blocked by default on a number of firewalls. However, proxies don't always play nicely with WebSockets.

  • Pros: you only consume bandwidth when there is information to send, and there is a lot of language support for writing the server side
  • Cons: keeping sockets open can tie up your server more quickly, if you have a microservice architecture you have to take extra care to allow the WebSockets through your API gateway (i.e. reverse proxy)

Custom Sockets

You can always come up with your own permanent socket to exchange data. It sounds harder than it is, but unless you have custom needs it's not really recommended. For example, this would be warranted for a game server where latency is a key consideration. It wouldn't be advisable for a corporate application due to the firewall and proxy considerations.

  • Pros: you have full control over the protocol
  • Cons: does not play well with some infrastructure, it's custom so there is higher cost of upkeep

Bottom Line

There are even more options that I haven't mentioned. The important part is that you identify what the real constraints are. What is the rate of change of the data you want to present on screen? How quickly do you expect users to interact with those changes? How long will you need to keep updating the screen? Answering those questions will help you choose what the most appropriate solution is for your application.

Berin Loritsch
  • 45,784
  • 7
  • 87
  • 160
0

You want to keep a persistent socket connection open so that the desktop client can subscribe to a channel of messages the server publishes. Roughly the model is to connect to your server (whether through a load balancer, a cloud provider, whatever) and keep that connection alive as long as the client is interested in receiving updates. The client has to periodically check to see if it has recieved any data (though some libraries like Boost's Asio make use of OS-level features to make this asynchronous, too) and then act on it.

For example, in the web world, it is easy to do this with WebSockets, which also have good client libraries available for every major language.

It would also be advantageous to avoid polling on the server side. For instance, Postgres has asynchronous notification built into it. What you do, exactly, will depend on the particulars of your data management solution.

Alex Reinking
  • 1,607
  • 11
  • 16
  • 1
    If on. Net, signalr is built specifically for this use case. – Andy Sep 03 '19 at 00:49
  • SignalR [operates over WebSocket](https://docs.microsoft.com/en-us/aspnet/signalr/overview/getting-started/introduction-to-signalr#signalr-and-websocket), in fact. – Alex Reinking Sep 03 '19 at 00:55
  • It can, yes, but it can also use other methods and gracefully fallback to them if needed, something requiring much more effort in a roll your own approach. – Andy Sep 03 '19 at 00:57