I have a game site with some grids. More than one player can play the same game at a time.
If any user clicks a single grid, i need to convert that particular grid to active state for all the user those who are playing the game now. For that, i made the ajax call for every seconds to make the selected grids active. But it slows the process, since it access the database for every time.
Please help me to do this task in any other way without slow
Use WebSocket in that case and you don't need a database.
With WebSocket you can easily push data to all your connected clients in realtime.
And you have the nice ability to push new data directly from server to client.
The client doesn't need to send every x second a call to the server. There is a persistent connection.
A good WebSocket Library written in PHP you can find here: http://socketo.me
Related
I have to update the state of a div, the thing is like this. On 2 computers, the same web page must be open, and I have to be able to change the state of a div in one and automatically update it in the other without having to reload, I think that Ajax alone is not enough, since I do not want to put one kind of timer that reloads the div s automatically, if not, when clicking on a button on computer A, it will update on counter B Obviously using mysql and php. It's possible?
You're right, AJAX alone isn't enough.
What really serves your purpose is WebSockets.
In short:
The WebSocket API is an advanced technology that makes it possible to
open a two-way interactive communication session between the user's
browser and a server. With this API, you can send messages to a server
and receive event-driven responses without having to poll the server
for a reply.
Of course, understanding how WebSocket works is mandatory, but it would be a waste of time to use the interface directly and deal with it (unless for learning purposes), so i suggest using Puhser JS Library for this purpose.
Now, here's the flow of the steps:
Get the free API keys of Pusher
Include the client channels library
Open a connection to channels
Subscribe to a channel
Listen for events
Trigger events from your server
I want to focus on steps 5 and 6:
You make an AJAX request from one page and this request is sent to the server, now instead of making the server responds directly you just trigger the responsible event for <div> element update, that what needs to happen in step 6.
Since all the browsers are subscribed to the responsible event and are listening, when step 6 trigger this event all browsers recieves it , at this step 5 you would perform DOM manipulation to update the <div> element.
I'm sorry if my explanation is bad, but don't worry because it's easier than it looks, the documentation explains it in an excellent way.
I have a page where user can Add/Update records. Code is written in Laravel 5.2
Let's say I opened the that add/update page in chrome and same url in FireFox. So, if user create a new record in Chrome browser, info should be received immediately to Firefox. So, that I don't need to send ajax based reqeust to server to show complete list.
My question is, where should I start for this? Is there any blog that I can go through step by step ?
You definitely need to use WebSockets to achieve it. There a couple of good links in the tiagoRL's answer. But also, since you said you are using Laravel 5.2 I strongly recommend you to broadcast events. If you are a Laracasts user, take a look to the related videos.
Basically this is the main link:
https://laravel.com/docs/5.2/events#broadcasting-events
Also to simplify the server-side stuff, I'd go for Pusher
To have this kind of realtime messaging between two or more clients you'll need to use sockets. One option is to use AJAX pooling, but if you want to be real time, then use sockets.
With sockets you can create connection tunnels between many clients, however you will still need a server implementation. Due the this nature of persistent connections, you'll need a server architecture that can support many connections open at the same time, that's why NodeJS non-blocking IO comes in hand, using less resources than PHP would, for example.
More about this can be found here: http://www.html5rocks.com/en/tutorials/websockets/basics/
On the client side, there are websockets, which is a feature implemented in HTML5 compliant browsers.
References:
Here is a tutorial: https://blog.kaazing.com/2012/08/08/a-step-by-step-tutorial-of-building-a-simple-peer-to-peer-websocket-app-part-1/
One server implementation is available for NodeJS called Socket.IO http://socket.io/
The video here shows exactly what can be done with it: http://tutorial.kaazing.com/
Another good reference: https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API
This is a very normal thing to do and is achieved via AJAX background polling. You can do
Assumption
If user must be authenticated to see the page, in both browsers the same user is logged in.
Demand is low, so server load will be minimal.
If this is not true, look into web sockets.
Structure
Route for page (that you already have)
Route to return rows
all rows
rows starting from certain point
So the page loads and retrieves all rows, either server side or client side. Set the last row ID as a JavaScript variable. Then set an AJAX call to a timer. The AJAX call sends the last row already on the page, if there are new rows they are returned and the last row variable is updated. Alternatively you can use timestamps to track which rows are new.
There is no way of sharing session or cookies across different browsers.
Your problem is also unrelated to the programming language / framework in which your project is written.
The way I recommend you is to make periodical ajax calls to fetch newly added rows only in order to prepend or append them to the current list.
This way, you save lots of resources and time not refreshing the whole list.
Although I have never used it, if you prefer a persistent connection than socket I/O is the way you should follow.
You can check the following page for more info on ajax or socket I/O comparison.
http://www.cubrid.org/blog/cubrid-appstools/nodejs-speed-dilemma-ajax-or-socket-io/
I hope it helps you.
You can start with this:
Step by Step Guide to Installing Socket.io and Broadcasting Events with Laravel 5.1 using Laravel Homestead
This example shows you how use real time events.
The idea in your case is to send an event when a new record is saved or updated, and when the others receives this event, refresh the list of records.
I'm creating a messaging app using jQuery, PHP and MySQL. Every time a user enters a message, I store it in a MySQL table. On the receiving users end, I basically just added a Javascript timer to check the database every X number of seconds for new messages.
The system works well but is this going to be a performance problem? For example, let's say I have 1000 users and I'm hitting a MySQL table every 5 seconds for each user.
Can anyone suggest a better method?
With your actual architecture, your SGBD will get a heart attack :)
The solution reside on implementation of Web Socket
in back-end only 1 instance of PHP check if there is a new update on database, if there is, PHP can invoke a web service to your Web-Socket Server (like NodeJS), and Server send the message to the client
I'm trying to figure out the best way possible to notify my web-application of database changes. The way I'm doing it now, is that I've got separate MySQL table with a counter.
Now, when some database action happens in table Foo, a trigger is adding up the counter.
The web-app then polls every 5 seconds the server to check out, if something has happened (counter number has changed) and if so, refresh the data in app.
What I would like, is that I would be able to do callback/notify from MySQL to the server and from there to the web-app so that I don't need to poll the server frequently. Is this possible somehow?
How does facebook, gmail send the real time notification?
You can't notify your application directly from MySQL, but there are some solutions to save bandwith and load of your server.
one way of handling this - would be to either implement the observer pattern yourself or simply use a pubsub messaging option (ZMQ/AMQ/RabbitMQ/Redis etc) - when the initial database action takes place (ensure that the transaction has committed), publish the message to the topic on the pubusb tool - your application can subscribe to the pubsub tool and receive messages when there is a DB change.
Hope it helps.
I'm building a prototype where on one page A I have a controller. Imagine a TV remote. On another page B, independent of form A -- it can be a different screen/computer -- with some elements X, Y, and Z that are going to be animated by the remote on page A.
My first idea would be:
Remote on page A saves an action wanted and sends JSON.
I create a listener on page B that reads the JSON to listen to what action to trigger.
I wonder if this the right direction.
It is just for a prototype so it doesn't have to be a production-perfect idea.
You can use web sockets for this.
Let's assume you're using 2 computers, both pointed at the website, as this technique could work in both scenarios.
If it's just a prototype, you could just simply have your page B poll the server every 5 seconds to look for updates that were submitted by page A.
However, in reality, for a production app with thousands of users, this could consume lots of bandwidth and put a heavy load on your server. To compensate for the load and bandwidth usage, you could increase the polling rate to 10 seconds, or 30 seconds, but in response to this change your users would experience delays while they wait for the browser to request an update from the server.
In a production app, many developers are turning to Comet as a solution. Comet is basically a term given by Alex Russell for a technique that involves using the request/response cycle to simulate server-push.
The general idea is that the browser makes a request to the server, and the server holds that connection open indefinitely. The connection remains open until another user posts an update to the server, in which case, the server then sends a response to the connected users.
The Dojo and Jetty team have demonstrations where they show that this technique can scale to 20,000 connections, when using continuations.
While I think you can carry out your experiment just fine with a database and/or some session variables, if your want to learn more about Comet on PHP, check out How to Implement Comet with PHP. Good luck!
UPDATE:
I also wanted to say that you definitely have the right idea for how to conceptually think about your message passing with JSON:
I create a listener on page B that reads the JSON to listen to what action to trigger.
I really like how you are thinking about passing a message that then tells the page what action to trigger. If you think about it, you could reuse your message passing concept to call other commands so that you avoid reinventing the wheel when a new command comes along that you need to call. Regardless of whether you poll, use Comet, or use WebSockets, it's a great idea to think about abstractions and generic, reusable data transports.
You could do this either with polling (having page B constantly poll for updates from the server) or use a server push technology like server sent events or websockets.
Yes, that would work. You could also just make it the same way you would make a vector line animation. Send the "commands" for movement to a server and record them (in a database, file, whatever) the client program can then request and redraw the movement smoothly any time and anywhere.
Using a cron job to execute Page B for every x unit time will make you check for any latest updated json (queried/returned output according your logic) from Page A. This way, you can use new updated json from page A and do your further task...