1

For a site I'm planning, I need the server to be able to send commands to a logged-in user's browser.

Simplic example: When a call center rep gets a call, I want to automatically pull up the lead who is calling in.

I've got the rest of the technology sorted out and I need to get a sketch together of how the actual communication to the browser will work.

From my research so far, this is often done with desktop software or plugins, but that feels pretty old school at this point. I know it can be done with javascript, either by writing something that constantly polls the server for commands (this could work, but it feels a little wasteful and brute force-y) or by some other technique that gives the server a way to call out to the client.

Something like whatever mechanism stackoverflow uses to tell you new answers have arrived on the current question would probably do the trick.

So is there a known best practice? What worked for you?

Brian MacKay
  • 31,133
  • 17
  • 86
  • 125
  • Well you wouldn't really be **sending** the commands with JavaScript unless your server is written in JavaScript, right? Anyway, google for "long polling" and "web sockets". – Pointy Oct 02 '11 at 21:32
  • Not sending them with JavaScript, but receiving them on the client with JavaScript. :) – Brian MacKay Oct 02 '11 at 21:38
  • A possible framework solution is [Angular.js](http://angularjs.org). It does two way data binding and a few other things too. And since it is a completely client side library it does not depend on a particular server side technology. – hradac Oct 03 '11 at 16:15

5 Answers5

3

WebSockets and long polling may be a good answer for you, as the other answers suggest. But also be sure to investigate the sw needed to support either on the backend (the non-browser, big iron part of your system.) If an always open file descriptor is needed per browser, that can add up. -- there are ways to add support for more file descriptors, but decide if that's the road you want to take.

From a total system viewpoint, it may (or may not) be easier to set up a polling system. There's nothing wrong with polling the server, especially a specialized low overhead, "I've got nothing for you now"-type server.

Remember that you want your solution to be robust. It should smoothly handle client disconnects, reboots, intermittent network failure, etc.

Remember to test all of the above....

Larry K
  • 47,808
  • 15
  • 87
  • 140
2

I believe that this is what the new web sockets html 5 standard is attempting to create, opening a connection between server and client to allow two way communication. But before that standard takes hold I'm not aware of any way other than polling at the moment.

samjudson
  • 56,243
  • 7
  • 59
  • 69
  • there are libraries available, which try to "abstract" websockets, to make things "cross browser". one such library for example is Socket.io -- http://socket.io/ – aurora Oct 02 '11 at 21:35
  • @Harald: Sweet, does this by any chance actually work? Or do you know? :) – Brian MacKay Oct 02 '11 at 21:39
  • @brian: yes, it really works ... personally only did some experimentation with it, but i know of at least one company using this already in production. – aurora Oct 02 '11 at 21:43
  • Yes, socket.io does work. Here is an [article.](http://blog.programmableweb.com/2011/09/29/building-a-real-time-location-based-urban-geofencing-game-with-socket-io-redis-node-js-and-sinatra-synchrony/) – Larry K Oct 02 '11 at 21:44
  • 2
    the socket.io link seems very nice because it has fallback mechanisms... but I don't trust the security of all these mechanisms or the way they are implemented, as they may allow javascript injection if the caller is compromised; seems like something one might use after auditing the code (ah, it also gives a name to the technique I mentioned as a sidenote in my answer, "Forever Frame") – ninjagecko Oct 02 '11 at 21:49
2

The server can not usually call the client. In order to do that, there must be a server software installed on the client side that would listen and respond. In case of a web browser there is no such thing. So the only thing you can do is to poll the server and check if you have something new.

EDIT:

I made a little test to see how stackoverflow works with this. My conclusion is periodic polling with the following system. When you want to add an answer, a post request is sent to the server, maybe to start a counter. After that at some intervals, requests are sent to /posts/ID/editor-heartbeat/edit sending the draft (what you managed to type until then) and the respons is a josn containing the success status of your request and the number of messages that where posted until then. If that number is different than 0 than the bar is shown to alert you.

Dan Bizdadea
  • 1,292
  • 8
  • 15
  • why did i get a -1 ? websockets are not a standard, and are not an elegant solution and in my opinion they are not a solution at all – Dan Bizdadea Oct 02 '11 at 21:39
  • I didn't give you the -1, but saying `no such thing` is not true. JS on the browser works fine as a "server"--responding to requests. – Larry K Oct 02 '11 at 21:48
  • +1 because you may be right to assume that it's not a good idea to use them. I suspect it would be costly and prone to problems related to browser/spec changes. Right now I'm thinking hard about polling. – Brian MacKay Oct 02 '11 at 21:49
  • Although... A lot of people are saying that web sockets are being used with success. Might want to do a little clarification to avoid more down votes. – Brian MacKay Oct 02 '11 at 21:50
  • okay, i was trying to explain that no standard elegant solution exist, because enabling this comportament in a web browser has potential security issues and also making sure it works with proxies or firewall or other obstacles can lead to problems. – Dan Bizdadea Oct 02 '11 at 21:52
  • @DanBizdadea: That is some really useful research, I hope people vote this one way up. – Brian MacKay Oct 03 '11 at 16:26
1

Websockets are what you want.

hvgotcodes
  • 118,147
  • 33
  • 203
  • 236
1

The traditional way to do this has been with periodic XHRequests from the client, asking "do you have a new message for me?"

There are fancier ways, which involve not closing a TCP connection and/or iframes; if you are interested you can google for how GMail does it.

Websockets are a fairly new technology which is only implemented on the absolutely latest browsers, though I might risk it.

ninjagecko
  • 88,546
  • 24
  • 137
  • 145
  • The sweet thing about my scenario is that I can decree that henceforth the call center must use Firefox or whatever. So it might be a safer risk, although it is a little scary that I could wake up one day and a patch might break my stuff. Hmm. – Brian MacKay Oct 02 '11 at 21:43
  • well, if you have complete control on users browsers then you can try and go ahead experimenting. using websockets may even be a success, so in this case you can ignore my answer. – Dan Bizdadea Oct 02 '11 at 21:55
  • @DanBizdadea: It's still a valuable answer for other people who might find this question. :) – Brian MacKay Oct 03 '11 at 02:35
  • @DanBizdadea: Also... Even for my scenario, I think polling is probably the approach I need to take, with the idea that Websockets will replace that technology in a year or whenever they're more mature. – Brian MacKay Oct 03 '11 at 02:37