Geek Answers Handbook

What is the best way to notify a non-web application of a change on a web page?

Let's say I have two applications that should work to a certain extent.

  • Web application (PHP, Ruby on Rails, ...)
  • Desktop application (Java, C ++, ...)

The desktop application should be notified from the web application, and the delay between sending and receiving the notification should be short. (<10 seconds)

What are the possible ways to do this? I can think of polling in a 10 second interval, but it will cause a lot of traffic if many desktop applications need to be notified. On a local network, I would use UDP broadcasting, but unfortunately this is not possible ...

I appreciate any ideas you could give me.

+4
source share
4 answers

I think the “best practice” here will depend on the number of desktop clients you expect to serve. If there is only one desktop to be notified, then a survey may well be a great approach - yes, a poll is a lot more overhead than an event-based notification, but it will certainly be the easiest solution to implement.

If the overhead of the survey is really unacceptable, I see two main alternatives:

  • Maintain a persistent connection between the desktop and the web server (maybe a comet web request or a raw socket web connection)
  • Open the service from the desktop application and register the service address on the web server. Thus, the web server can access the desktop as needed.

Be warned though - both alternatives are full of interception. A few highlights:

  • Keeping an open connection can be tricky because you want your web servers to be a hot swap.
  • Calling an external service (such as the desktop) from a web server is dangerous because this request may hang. You want to move this notification to a separate stream so as not to bind the web server.

To mitigate some of the problems, you can separate the untrusted desktop from the web server by introducing an interim notification server - the web server can post the update somewhere, and the desktop can poll / connect / register there to be notified. To avoid wheel reuse here, this may include some MessageQueue system ... This, of course, adds to the complexity of having to support a new middleman.

Again, all of these approaches are probably quite complicated, so I would say that the survey is probably the best choice.

+3
source

I see two ways:

  • Your desktop application checks the web application.
  • Your web application notifies the desktop application

Your web application may publish an RSS feed, but your desktop application will still have to poll the feed every 10 seconds.

The traffic doesn't have to be huge: if you use HTTP HEAD , you will get a small packet with the date of the last modification (conveniently called Last-Modified).

+3
source

I don’t know exactly what to do to complete your task, but I can offer to create a Windows service on PC to PC.

This service checks the web application every time interval for new changes and, if there are changes, it can start the desktop application with a notification that there are changes in the web application and in the web application, when any change occurs, you can reply with confirmation

I hope this can be useful, I have not tried it for sure, but I suggest using this idea.

+1
source

A syndication layer will help reduce the size of the system.

The desktop application can register itself using the "publisher" service (runs on one or more machines). This publisher service receives a “notification” from your web application that something has changed, and immediately begins to notify all of its registered subscribers.

The number of publishers you need will increase with the number of users.

Edit: Forgot to mention that the desktop application will need to listen on the socket.

+1
source

More articles:


All Articles