I am developing a website which has a chat feature and requires instant notifications when a user receives a new message. I am trying to decide whether to use a Ratchet server or implement a long polling system with AJAX. I have currently implemented a basic Pub/Sub Ratchet server which works fine when delivering notifications while a user remains on the "Chat" page on my site. My problem here is that the connection is closed whenever the user moves to any other page, and I need to re-create a connection to the server. I am aware that there are possible solutions such as having the websocket connection exist within an IFrame which is always displayed, however I do not want to go down this path if I do not have to. Would a better approach be to implement long polling with AJAX? I am concerned that if I continually re-create a users connection to the Ratchet server whenever they change pages within the site, it will add too much overhead when the site is under heavy usage (thousands of users at a time). Does anyone have experience in this area with Ratchet servers?
Thanks.
As a disclaimer I'm not very knowledgeable in this area, but you should not use long polling. You say you need "instant notifications," which means with AJAX you would have to be making very frequent requests, whereas with websockets you simply establish the connection and wait for data.
I haven't done any sort of testing, but it seems like establishing and maintaining one websocket connection per browser tab would be less overhead than constantly making AJAX requests, not to mention that you can't truly have "instant notifications" with AJAX because you'd have to make requests at an unsustainable rate to achieve that.
So open a websocket connection for each browser tab the user has. If they open a new tab, or browse to a different page, simply open the connection again.
Related
I am designing an app that will have to periodically check a web address for updates.
The updates will be in a MySQL database tables.
I know the idea way to do this, is to create a service that is constantly running and trying to check for an update periodically (lets say 10 seconds).
Below are some questions that are unclear to me as I start my quest to accomplish this task.
Do I need to manually do the check for an update everytime from the client to server ? (that is, take a value on the client side, send it to server side, and do a head to head comparison), OR, the php/MySQL server can send a notification that there is an update that took place.
I came across a RSS feature in several posts in SO, however those tend to be NEWS applications, mine is not anything like that. Does it help to use RSS feeds in here ?
I'm planning on doing the check every 10 seconds. This means that upon the install of the app and since the app is on the device (and as long as there is internet connectivity) I will keep on fetching the server. This tends to be bandwidth and ram/cpu consuming for the client side. How do big apps like Viber, WhatsApp manage to do so ?
Just thinking out loud - , in order to avoid such a hassle, I was thinking with each update on the server, send a notification to the user with a certain code, and do the math inside the onReceive, if the code was something related to an update, 1-not show the notification to the user, 2-run the server update check thing.
ideas ?
The trouble is traditional php/html systems are client centric (the client has to initiate all communications).
You might want to look into websockets, or node.js. These technologies will allow you to create a persistent connection between the server and its clients. This in turn will allow you to 'push' data to the client when appropriate, without the client having to ask for it every x amount of minutes.
Node.js Chat Example
Node.js info
I'm writing a website using PHP / MySQL. The website should allow users browsers to be automatically updated when a table is updated in a database (which is caused by someone inserting something though the PHP site). Basically, if the state of the table changes other users on the website should immediately see the changes.
I'm relatively new to PHP / AJAX and other web technologies. The only way I can think of doing this is to have the clients manually recheck the database every second or two via a timer (but this seems like a lot of wasted bandwidth). Is there some way to have the users automatically notified when the database changes?
Thank you!
You already had the solution in mind. You can use ajax to automatically check for changes.
It's not possible for the server to contact you when something has changed. It doesn't have to be bandwidth intensive when you lower the retrieval intervals. You can have Ajax check for a blank page with as little as possible text. That way the bandwidth usage wont be too bad.
Facebook does it this way too.
1) AJAX Polling.
As you say, use ajax to call the PHP on the server side to get
updates.
2) HTML5 Websockets.
Websockets are a new feature of HTML5 which allow the browser to keep a bi-directional TCP connection open to the server, where data can be transmitted both ways without polling. Currently this isn't as widely supported as ajax polling is.
3) Java Applet/ActiveX control.
Generally the most undesirable solution because of the user having to install third party software.
The challenge I'm facing is simulating a communication channel between two users of a website (e.g. gaming site), by using solely the technologies mentioned in the title.
Recently I've developed an online chess website where, the idea behind which was to give users the chance to play "live" matches too, not just lengthy games where you would make a move, then come back in 1-15 days to see if your opponent has responded. And the way this game engine works implies sending asynchronous requests to the server, both to update the info related to the game (in case you make a move), but also to verify if anything has changed (if you are waiting for the opponent to move).
To better explain this... the player whose turn it is (the browser of course) sends an async. request to update the game info, exactly when he makes his move. Meanwhile, the opponent sends PERIODIC requests, "asking" if anything has changed. If anything does change, the roles switch after the board updates.
Timers are behind the functionality of the engine, so my question to you is this: How would you go about simulating a com channel between two players, while trying not to put too much stress on the server, but also having games update as fast as possible, in order to maintain the "live" feeling to it. This is most important in 1 minute games (one of the available categories). Because in that case, requests NEED to take place VERY often (at least 1 second). But server responses could delay, there would be much stress on the server when having hundreds of games available at the same time etc... so you see my problem.
I look forward to hearing from you guys and picking your brain if you have any good ideas :)
Cheers!
Andrei
PS: In case you want to try it, the name is e-chess960.com
you would want to builds a socket server. node.js would be a good javascript based library to use for a socket server. each client would create a socket connection to the socket server, then when a client sends a message to the socket server, the socket server could immediately send the message back out to its subscribers without having to store it anywhere.
socket servers require socket access, which usually requires a vps instead of a shared server.
to make the solution work, you would require that the clients have the ability to create socket connections to your server. some browsers already can as part of html5, but not all yet. you could also use Flash as a way to create a socket connection.
What you actually want is not pulling the server every second, but instead keep a connection open and use the observer-pattern to distribute updates to the specific clients (in other words: push instead of pull). That way, your server resources will not get swamped by a new connection for every second and every client. A library to accomplish that is the Comet Library. Check out this nice tutorial for a sample application.
I'm planning a chat-like web application, where whenever one user posts something, all other users (that is, people with their browser pointing to that site) would get instant updates. The common choice for this is comet-style messaging using long-polling AJAX requests. Writing the client-side part with jQuery isn't much of a problem.
But I wonder how to best implement the server-side part in PHP. The posts/messages will be stored in MySQL and the question is: After writing a new post to the database, how do I notify all waiting requests, that data is available for them without using polling? Polling would work, but it's ugly and wasting resources, thus, this is what I do not want:
while (timeout not reached) {
if ($database->has_changes())
break;
sleep(1);
}
handle_changes_if_any();
Is there some kind of MySQL feature that would help me here? Would some kind of IPC help? The server runs Apache.
You already mentioned one possible solution, which is to use AJAX polling to query a script periodically for updates. Polling would be done on the client side, and has nothing to do with the server side.
Another option would be to use a comet server such as Meteor. With this approach, your PHP script can notify the comet server of the new messages and the connected clients will receive the updates. Then it's just up to you to write the JavaScript to display the update to the user.
Am not sure if what I am doing is absolutely correct. But here goes:
User logins into chat via web-based interface
User is informed of updates via Comet
User enters details which goto a PHP file which further connects to a Jabber server
Now the problem is that when the user wants to send a message, it's simple, run php in which i connect to jabber server and send the message. The problem arises when I am waiting for a message. Cause if I login and check messages and disconnect, on the other users end I will show up as disconnected.
Am I approaching this problem in a wrong way? Should I directly connect to the Jabber server (via javascript) instead of a PHP layer in between? How to recieve messages via PHP?
I haven't tried it out, but you might want to look at xmpphp. Secondly, you might want to consider keeping the user logged in to the XMPP server (aka a Jabber server) for as long as they're logged in to your website. You probably want to have a timeout of some kind in case they leave your website and don't come back.
As for whether or not you should connect via JavaScript, I don't see why you couldn't. I would suggest that you go for whatever seems the simplest to you. You might want to check out Strophe, which I hear good things about, for that case.
The only XMPP library that I've used extensively though is headstock, but that requires using python and Kamaelia.
this is an inherent problem (or feature) with http - there are no lasting connections (not really). you need a workaround, there is no real solution.
you could do it with java or flash, but that's not really nice (javascript 4tw!).
the other possibility would be to create an intermediate client what translates connections between the browser and the webserver to connections between the webserver and the jabber server. messy, but possible.
or maybe there is an API that helps with this.
directly connecting to the jabber server via javascript
i possibly slept through the latest ajax-inventions, but afaik you can only communicate with the host the source-html file comes from (ignoring greasmonkey and addons). no different domains, no different ports, period. unless you're going to teach your jabber server how to serve your chatpage-html to the browser, this will get problematic. moreover, staying connected doesn't even work, because that would require multipart-responses. those are only supported by mozilla, and this is why the ugly duckling COMET even exists in the first place. comet itself is a workaround to avoid the inability to hold connections while transfering data.
So the issue, as far as I can tell, is that when the Jabber user on the other end responds. The problem there, at least in part, is that the user is responding to another user on the Jabber server, yet you want the php script to be aware that this response has taken place without holding the connection open (which makes sense since the script is no longer running, probably).
One option, albeit a really silly one, is:
Have a php script that can broker a connection to the Jabber server for both sending and receiving for the user on your page,
Use AJAX to send messages for the user (the AJAX would point to the above script, the script would send the message.)
Have a Javascript infinite loop that pings the same script ever 10 seconds or so, checking in to see if there are messages. If there are, they get passed back to the client and output to the user.
There are only two issues with the above:
1) If the user isn't connected when the message is transmitted, will the php script still see/get the message?
2) A client side loop that makes ajax requests every 3 seconds would probably be a huge drain.
Solution 2:
OpenFire jabber server. It comes with a web chat client built in, and it has an addon called Fastpath, which is meant to handle HTML-based chats on the client end (like the "chat with an agent now!" feature on too many support pages.)
We use this at work and it is very customizable, can be integrated with other scripts (for instance, if you want a script that fills in the user details from their login, or adds some custom avatar, or whatever), and it (OpenFire) has tons of other extensions and addons that, if this isn't what you want, they probably have what you are looking for.