5

I'm currently experimenting with WebSockets in a bid to reduce / remove the need for constant AJAX requests in a potentially low bandwidth environment. All devices are WebSocket compliant so there's no issue there, and I'm trying to keep it to native PHP WebSockets, no node.js or other frameworks / libraries (Which so far has been fine).

What I'm looking to do is to decide how to go about notifying connected clients about an update to a database by another Client. The use case in question is a person pressing a button on their device, which then alerts that persons manager(s) to that press. So the two options I have though of are as follows:

1. Looping a Database Query (PHP)

My first thought was to insert a query into the WebSocket server that is effectively saying "Has the alert field changed? If so, notify the manager(s)". Whilst this is the most straightforward and sensible approach (That I can think of), it seems wasteful to have a PHP script designed to reduce strain on the server, that is now running a query every second, however, at least this would ensure that when a Database update is detected, the update is sent.

2. Sending a notification from the Client

Another thought I had, was that when the client updates the Database, they could in fact send a WebSocket notification themself. This has the advantage of reducing any intensive and looped queries, but also means that I'd need to have a WebSocket message being sent every time I want to change any data, such as:

$.post("AttemptDatabaseUpdate.php", {Data}).function(Result) // Don't worry about the semantics of this, it's not actual code
{
    if(Result == "Successful")
    {
        SendWebSocketNotification(OtherData);
    }
}

Maybe this is the best option, as it is the most efficient, but I worry that there is a chance the connection may drop between updating the Database, and sending the WebSocket notification, which may create a need for a fallback check in the PHP file, much like the one in the first solution, albeit at a longer interval (Say every 30 seconds).

3. MySQL Trigger?

This is purely a guess, but perhaps another option is to create a MySQL trigger, which can somehow notify the server.php file directly? I've no idea how this would work, and would hazard a guess that this may end up with the same or similar Query requirements as solution #1, but it's just a though...

Thank you in advance for your help :)

EDIT: Solution possibility 4

Another thought has just popped into my head in fact, whereby the PHP file used to update the database could in fact have a WebSocket message built into it. So that when the PHP file updates the database, the WebSocket server is notified via PHP, is this possible?

Duncan McArdle
  • 501
  • 5
  • 14
  • Have you considered using SSE (Server Side Event)? – Aaron Gong Nov 01 '13 at 11:09
  • Not before now, have just looked them up and while they do have potential, I feel like having an event listener in place would be less efficient than just pushing a single notification? Especially as the system evolves with potential for many similar use cases all running though one system. Or is there some way of having the SSE carry out the "On MySQL DB update, notify WebSocket server" aspect? – Duncan McArdle Nov 01 '13 at 11:11
  • 1
    for one-way, SSE seems easier to implement and manage, and reading from some articles, their performance seem to be similar. Ithink the script that handles the update can also be used to push the update out upon successful update in the DB. – Aaron Gong Nov 01 '13 at 11:18

2 Answers2

1

If you use websockets, you should use notifications from client. That's one of their main use cases.

If you're worried about inconsistencies due to connection dropping or something changing in-between, you could implement a system similar to HTTP ETags, where client would send a hash code that you can respond on server side if there is a conflict in updating.


Update: I guess I understood your initial issue a bit wrong. If I understand your use case correctly: you are sending database updates from a client and after that all connected clients need to be updated. In that case, I think server should send the update messages after DB updates have been done, so I agree with solution 4. I am assuming here that your websocket server is the same server running PHP and doing the DB updates.

However, depending on your use case, client should still send a hash value on the next request identifying its "view of the world", so you would not be doing identical updates multiple times if a connection gets broken.


Update 2: so it was now understood that you indeed use a separate, standalone websocket server. Basically you have two different web servers on the server side and are having an issue on how to communicate between the two. This is a real issue, and I'd recommend only using one server at a time - either take a look at using Apache websocket support (experimental and not really recommended) or migrating your php scripts to the websocket instance.

Neither PHP or Apache was really build with websockets in mind. It is quite easy to set up a standalone websocket server using only PHP, but it might not be so easy then to migrate the rest of the PHP stack to it if the code is relying on Apache/web server on. Apache websocket support also is hardly optimal. For a real websocket solution, unfortunately, best practice would be using a technology that is built for it from the ground up.

eis
  • 51,991
  • 13
  • 150
  • 199
  • It is not so much a conflict in updating that worries me, but more that if the user updated the DB, then their connection drops out, the DB would have the alert set, but the client would not have notified those connected via WebSocket. As per your first point, I would still be using WebSockets to notify the Client, I'd simply be initiating the original notification via the server, as that notification is already coming from the server as is (Solution #4). It seems like this resolves the potential for connection drops inbetween? – Duncan McArdle Nov 01 '13 at 11:22
  • @Redgie ok, then I guess I understood your initial issue a bit wrong. I added some details to my answer. – eis Nov 01 '13 at 12:02
  • Yeah that makes a bit more sense now, though I still need to find a way to have the PHP file that updates the DB communicate with the WebSocket server! – Duncan McArdle Nov 01 '13 at 12:58
  • @Redgie "I am assuming here that your websocket server is the same server running PHP and doing the DB updates." - is this a different or the same server? Or do you have DB updates somewhere else than your WebSocket server? Why is the database update not done on the websocket server, if they are different? – eis Nov 01 '13 at 13:58
  • Yes they are running on the same server. Converting the system to have all queries run on from within the websocket file would be a pretty complex process as there are varying amounts of static and dynamically generated queries! – Duncan McArdle Nov 04 '13 at 08:56
  • if they are already on the same server, I don't understand what converting would be needed :) There's some big thing missing here that I don't grasp. your PHP is running on apache, is that correct? so is your websocket server running on apache as well, or is it a standalone server? – eis Nov 04 '13 at 08:58
  • Well the WebSocket stuff is running it's own server effectively, though this is simply written in PHP and thus must I assume be going through Apache... – Duncan McArdle Nov 04 '13 at 09:09
  • @Redgie that's an incorrect assumption. Running it with PHP does not mean it is going through apache. Websocket servers are usually running standalone, and I suspect that you're running standalone PHP Websocket server here which doesn't have knowledge of Apache in any way. – eis Nov 04 '13 at 09:54
  • Ahh, apologies, yes you're right then it is a standalone PHP WebSocket server written by myself based on the various PHP implementations available online. – Duncan McArdle Nov 04 '13 at 11:51
  • Thanks, this clarifies things. I've updated my answer based on this information. – eis Nov 04 '13 at 12:18
1

The better answer is to send notification through Server side when database is updated by PHP script, so that script have to add options of web sockets to directly send notification to all web socket clients registered.

User send content->Php script process content and save data according to true condition->check database is updated by checking return of mysql_query/other alternative->if true than use web-socket and send notification to all users

now this is more easy/handy/bandwidth saver.

Ravinder Payal
  • 2,884
  • 31
  • 40
  • Interesting, how different is this to my Option #2? – Duncan McArdle Apr 29 '14 at 07:42
  • its different in many ways you say that when the client update something it also send a notification to websocket server but in my question there no requirement to send an another request to server and if you are saying that what if connection dropped than i want to tell you that there is a trigger in js websockets and you can call a function again to connect with websocket server like the gtalk inside gmail does(the count down starts when a connection is dropped to connect again or try to connect again). okayand i am just 15 yearls old so i dont have much experience in all these okay – Ravinder Payal Apr 29 '14 at 08:14