Possibly other questions similar to this one have been asked, but I think this would be something different to those that have been asked so far.
Can we create a chat app especially in PHP/MySQL/jQuery/Apache without continuous requests to server i.e. apache for a new messages if there are any? I don't want to use Comet or NodeJS, just want to know if it is possible to have a chat application that uses only AJAX to request Apache for new message using PHP.
By the way, if the answer is no, then what is the best way to have a perfect chat application in combination with PHP/MySQL/jQuery/Apache only? I think there must be some chat applications exist.
I am curious as to why you want to avoid all the technologies and methods developed specifically for these types of use cases but web sockets are the only other way to do it if you want to avoid comet.
Your chat application needs to connect to the server the read the incoming chat messages.
You have two choices:
Polling
This is continuously firing a new request off to the server at regular intervals to check for the messages. this is the typical AJAX style.
Web Sockets
Web sockets open one long running connection to the server. For a chat application if you are only interested in the newer browsers this is the way to go. As a bit of random information. Stack Overflow uses Web Sockets to check for any notifications.
Related
I'm creating a mobile app with a server backend that will authenticate a user and continuously send them updates whilst listening for post data from the mobile app. These updates will be specific to the person, pulled from a database.
From my research it seems that I should use a websocket. I'm familiar with PHP so have tried Ratchet. I've created a simple chat script with Ratchet which queries a database onMessage and sends the data to the client.
My question is, are websockets right for this? When a server receives a connection it must query the db every 5 seconds and send updated info to the app. It must listen for messages that will change the db query. Everything in Ratchet's docs seems to be focussed on subscriptions to topics rather than treating each client individually, although I've gotten around this by using:
$client = $this->clients[$from->resourceId];
$client->send("whatever_message"):
Am I complicating things by using Ratchet? Or should I use a child process to handle each client?
I am sorry for a vague questions. I've researched as best I can but cannot establish whether I'm heading in the wrong direction! Thank you for any help.
That is a good formula. Sending post data from the apps while maintaining a socket connection is a good distribution of processes. However PHP might not be your best option for running the socket server.
The reason for this is PHP is a single threaded language which doesn't sport an elegant event system.
Take NodeJs as an alternative. It too is single threaded, however you can register events on socket servers allowing the software to run additional control processes while it waits for network activity.
This does not limit you to javascript however. Work can still be delegated to PHP processes from the NodeJs application (I use NodeJs as an example only, there are other options such as Java, Python, or good ol' native).
For moving work to PHP, you can either execute commands, or use a job server to enable synchronous and asynchronous tasks.
Here are a few resources you can combine to accomplish this:
http://nodejs.org/
http://socket.io/
http://gearman.org/
http://php.net/manual/en/book.gearman.php
And if you are using Symfony:
https://github.com/mmoreram/GearmanBundle
I am developing an picture sharing application with messages. Now want to know how to make it instant just like Viber or whatsapp. The timer of more than a minute is not a good idea the user will have to wait for a long time for the message to arrive. And HTTP request every second will have a lots of overload on the server.
I have heard about the socket programming but not sure if it is the best way. Also how to implement that?
So the question is What is the best way of implementing this kind of application?
I am using IOS and PHP as a server language.
There are two approaches:
You can use your own protocol over any kind of socket you want (most probably a TCP or SSL stream), and then you need a server at the other end that keeps these connections open and send notifications on the right connections when something happens (new message...). There are probably existing frameworks for this, though all I can think of right now are more geared towards integration with web applications rather than native ones. Note that this will only work as long as you app is active in the foreground. This also means you will get as many simultaneous connections to your server as there are apps running, so you may have a scalability issue.
or you can use Apple Push Notifications to send notifications to the app that there is something new happening. You may include all the relevant data in the payload, or you may trigger a connection by your app to fetch the rest of the data. This will work both in the background and the foreground, though slightly differently.
You may also mix both: use APNs when your app is in the background, and you own connection when it is in the foreground.
Only yesterday, I was asking a friend of mine how he would go about emulating direct communication channels between two clients through a web server, for the purpose of creating a chat application, but by using solely PHP/MySQL/JavaScript.
He told me that the best way to do this was by the use of SOCKETS, a term I had only heard of until then. This morning I started looking into it for the purpose of creating my chat application, but I'm quickly starting to believe that it's not as easy as I'd hoped.
So my question is this: if I don't have access to my own server (I have a domain hosted on a shared server that I also use for testing purposes), can I still use sockets to achieve my goal? If so, how exactly? (Please understand that I am completely new to the idea)
If not, what other way is there to accomplish the communication channels?
My only idea so far is to simply send periodic requests (AJAX) to the web server the application would be stored on and request any new messages, if any. But this does not seem very feasible.
Thanks in advance for your help!
I think what your friend is trying to get to is implementing Comet for your chat site.
Assuming he's getting you to use PHP sockets to act as a daemon, I highly doubt a shared hosting provider will let you do it.
You could try hanging the PHP script until there's data available. However, this will quickly consume resources on a CGI-based server since the PHP server can't tell if the client is still connected. I know this from experience.
For these kind of things, I highly recommend you get a dedicated server or VPS and write your backend in something like socket.io which automagically handles all your communication problems on both the client and server side. PHP, MYSQL and servers that fork to serve requests are usually the worst case scenarios for implementing Comet since they incur quite a bit of overhead and aren't scalable.
If you can't afford to run your own Comet server, then polling may be your only option. This will be the most resource intensive and least responsive.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I'm wondering what's the right way to code a chat application for thousands of users.
I'm just confused how will I be able to ping the server using AJAX every second or maybe less and check if there are new records in MySQL, etc with an acceptable amount of server(s) load.
I'm currently thinking about coding this using jQuery, PHP and MySQL.
Please advice. Your help would be greatly appreciated.
Client Side
For any program that needs to poll the server I would recommend WebSockets.
I wrote an extremely basic WebSocket tutorial. I also used the web-socket-js code to implement a FlashSocket that will make it work across Firefox, IE 8+, and Chrome, as well as any browser that supports WebSockets.
I don't believe that polling would be a good choice for a chat application. While it would work, the request overhead would be much higher then using a WebSocket. The tradeoff (benefit) is that more browsers support it.
Also, hitting a MySQL database to see if there are messages is going to incur a good deal of DB overhead. I would recommend using a MySQL database for chat logs, and only keep a limited number of "back" messages on hand for new connections. Then simply broadcast new messages to all connected clients. The frontend application would then take the message and append it to chat window.
Server Side
Node.js is an evented server-side JavaScript framework. While it is still young, several very interesting applications have been coded in it. The Node.js people setup a chat program (not WebSockets) the source of which has been made available. That would be a very good place to start if not wanting to write it from scratch.
There is a PHP WebSocket implementation. Depending on your requirements it could be used just fine. Having coded in both Node.js and PHP I would say I think Node.js is a better fit for this.
On the server side, you'll need a script that can tell whether or not there is new content (eg: messages) based on a timestamp (eg: last request). On the client side, you have two options:
Polling aka Periodic Refresh:
This basically means having your client poll the server in intervals to check whether or not there is new data. What you want is to keep your requests and responses as light as possible. It could also help if run the script handling these requests in a separate process.
It will be up to you to tweak the interval to one that's acceptable for both the server and the user. You can also use a Heartbeat to tell whether or not the user is still active, so you can stop polling the server if the user left the window open but is off the computer.
HTTP Streaming aka "Comet":
Using this will require some more setup; but this is basically a long-lived connection from the client to the server and the server can "push" content to the client when necessary.
Heres a simple looking websockets example: http://www.dashdashverbose.com/2010/02/nodejs-websockets-stoopid-easy-comet.html
I assume your max amount of users would depend mostly upon your connection and server software.
You could also try out IcePush - it is an ajax framework for pushing messages FROM the server TO the javascript client. This would be a perfect match for a chatclient!
If you are a java developer, you can use jwebsocket to implement the server. there are various examples on their site to start with as I'm also going through some of them.
Briefly from their website
jWebSocket is provided to you to create innovative HTML5 based streaming and communication applications on the web. HTML5 WebSockets will replace the existing XHR approaches as well as Comet services by a new flexible and ultra high speed bidirectional TCP socket communication technology. jWebSocket is an open source Java and JavaScript implementation of the HTML5 WebSocket protocol with a huge set of extensions.
I have an existing app written in PHP (using Kohana framework) and I want to do long polling. From some things I read it seems that doing long polling with PHP is not advisable and using something like nodejs is a better choice. My question is what's the best way to integrate nodejs (or some other well suited tool for long polling) with an existing application?
For clarification my app basically is a browser plugin that you can use to send data to groups of other people. When that data is sent, I want the recipients, if they are online and also have the browser plugin, to instantly receive that data and be notified.
Possibly the best way is to let node.js listen to a port and to let PHP send messages to that port.
In Node.js you can just open a socket for listening and in PHP you can use cURL to send messages. The messages can be in JSON-format.
If the Node.js-part receives a message, it can forward it, possibly after some processing, directly to the long-polling browser.
I am creating a small hack that would allow you to do this with ease. It is in a very early stage but it has enough code for it to work: https://github.com/josebalius/NodePHP
I plan on updating the readme later today.