I have to create a little AJAX chat in my web application and I'm dealing with problem of real-time communication between javascript client and PHP server. I want my js client to be able to catch new messages from the server as quick as possible. My first idea was to create AJAX request for example each 5 sec. to see whether there are new messages. However, I'm not sure what happens if my application use for example 1000 people, it must be huge load to Apache httpd. I also know about technique called 'long-polling' request, but when I tried that locally on my server, I've completely shooted down my Apache (I've read sth about problems with apache and long-polling). The next way I know about is WebSocket. However, is it true that I have to be able to open port on webserver to use it? Because on regular web hosting, I thing it's not possible and I cant change any Apache/PHP settings on my hosting. Do you have any suggestions how to solve it?
Thank you and excuse my english please, I'm not native.
It is real time comments system. You can use it as chat
Real time chat
You should use php comet and push from the server instead of doing requests.
Check out this question also
Related
I don't know how it's called exactly, but I need that server send notices to frontend, that allow do not refresh page. Such as at the stackoverflow, that show serverside changes like new messages without page refresh. I can solve my problem with always monitoring the server side backend every 5 seconds for example, but it's a very load the server. Help me to solve this problem for PHP, maybe exists some third-party libs for this and tell me how they are called?
You can either go for Web Sockets or if you can use HTML5, use Server Side Events to get informed about certain events by remote party.
If you want to avoid polling the server for updates, what you're looking for is WebSockets.
I'm fairly new to XMPP and Openfire and am trying to get my head round the standard way of doing things.
I'd ideally like to send any messages received by a specific XMPP user, via POST, to a URL where a PHP script can then process the message. This would all happen on my local server / local Apache installation.
I've seen that with BOSH I can make a persistent connection listening for XMPP messages through PHP, however perhaps I'm mistaken, but it doesn't sound like a very stable way of doing things - I worry that I'd either end up with multiple persistent connections or my BOSH PHP script would time out and I wont realise. I also ideally wouldn't always have the browser open and running this script!
Can anyone point me in a sensible direction to start me off? Many thanks
Are you trying to create some chat using php, or want to intercept messages to certain user to do some custom work ?
Have you taken look at javascript for chat http://candy-chat.github.com/candy/
Maybe you will find there something that might help you move in right direction.
With all the buzz around WebSockets, it's pretty hard to find a good walkthrough on how to use them with an Apache server on Google.
We're developing a plugin, in PHP (symfony2), which will run from time to time kind of a chat instance. And we find WebSockets more interesting, standard and quick than AJAX for this matter. The thing is, we don't have much sysadmin ressources in our group and we find hard to gather good informations on the following matters:
Can we run a WebSocket instance on a traditional Apache, dedicated server, and if yes, do you have useful links for us?
If we need to mod the server, what kind of tools would you recommend knowing that we are not too skilled in sysadmin so we can't afford to have a high maintenance b*** on this.
Thank you very much,
ps: we'll link back to your blog/site as we'll make a technical/informational post on our devblog about this part of our app.
Thank you again!
As #zaf states you are more likely to find a standalone PHP solution - not something that runs within Apache. That said there is a apache WebSocket module.
However, the fundamental problem is that Apache wasn't built with maintaining many persistent connections in mind. It, along with PHP, is built on the idea that requests are made and responses are quickly sent back. This means that resources can very quickly be used up if you are holding requests open and you're going to need to look into horizontal scaling pretty quickly.
Personally I think you have two options:
Use an alternative realtime web technology solution and communicate between your web application and realtime web infrastructure using queues or short-lived requests (web services).
Off load the handling of persistent connections and scaling of the realtime web infrastructure to a realtime web hosted service. I work for Pusher and we fall into this category.
For both self-hosted and hosted options you can check out my realtime web tech guide.
One path is to use an independent installed web sockets server.
For PHP you can try:
http://code.google.com/p/phpwebsocket/ or http://github.com/Devristo/phpws/
There are some other projects which you can try as well.
Basically, you need to upload, unpack and start running the process.
On the frontend, you'll have javascript connecting to the server on the specific port.
Most websocket servers have a demo which echoes back whatever it hears, so this is a good place to write some test code. You may even find a rudimentary chat implementation.
The tricky part is to monitor the web socket server and to make sure it runs smoothly and continuously.
Try to test on as many browsers/devices as possible as this will decide on which websocket server implementation you choose. There are old and new protocols you have to watch out for.
I introduced another websocket server: PHP Ratchet (Github).
This is better and complete list of client & server side codes and browser support.
Please check this link.
Another Path is to use a dedicated websocket server.
Try Achex Websocket Server at www.achex.ca and checkout the tutorials.
OR
If you really want Apache, check out Apache Camel. (but you have to set it up and its a bit more complicated than achex server)
http://camel.apache.org/websocket.html
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.
How to make php client to client, like the chat way ? One client connects and sends something to the other client and only he recieve not all clients.
Your Question?
If I understand correctly you want one-to-one(private) messaging.
Socket Programming using PHP
You need to learn Socket programming with PHP. You could start by studying this tutorial. This has scaling problems written all over it, because PHP does not have non blocking IO, proper thread model. I advise you to just use it for fun little projects.
Non blocking IO using PHP
You could try and use PHP-MIO. I have not yet tried this, but I guess it might scale. But then again from Apache(PHP) side you will have the same problems. But when using this from both sides it could work...
long-polling(blocking IO) using PHP
P.S: got bored so I have not completely tested this ;)
Download
Below I present two solutions(prototypes) which do NOT scale. One solution uses Redis pubsub. For this you need to install(compile) redis. For this you a POSIX OS is desired, although some people have ported it to Windows. You can also use the free redistogo.com instance. The Redis solution is the prefered solution. I have put everything in an archive which you can download from here.
I also give a solution which uses named pipes. This solution does not require you to use Redis, but instead this approach needs access to the file system. I believe that this approach should also work on Windows(You have to change the filename to windows-style). I would like for somebody to try this out :). I can not test this anymore, because I have completely switched to POSIX OS(Ubuntu) a long time ago.
Requirements
At least PHP 5.3 and preferable a POSIX OS, redis.
How to use
To use both solutions you need to open two browsers(Browser A/B). I assume you are using localhost for development and that you can access files from http://localhost/6646733.
point browser A to http://localhost/6646733/redis?me=somebodyelse&to=alfred you should replace redis with pipe when trying out named pipes.
Point browser B to http://localhost/6646733/redis?me=alfred&to=somebodyelse
In browser A type a message into the textarea, which will be sent to browser B.
In browser B read the message just sent from browser A
Solutions not using PHP
The solutions below scale.
Pusher(Hosted)
With for example the hosted solution Pusher you can do chat/messaging without the scaling nightmare. Pusher even is generous to provide a free plan. But be aware that the cheap plans do NOT offer SSL so the messages can be intercepted. You should never sent private information over the wire, when not using SSL. Users/developers have provided a nice little library to use Pusher from PHP. The problem with this approach is that you are not in control, but pusher is, but then again you don't have to worry about any details.
Socket.io(open-source)
I really like socket.io, but there are off course a lot of other solutions like for example tornado. You could use Redis to efficiently communicate between PHP and the other solution(socket.io).
I don't fully understand what you are trying to do, but you can use some kind of database and have it store messages that is sent to each user, and then have your client page refresh the chat part with a AJAX kind of query to update the chat. It will then behave simular to the new Facebook chat, where all messages are stored even the ones sent in normal chat and mail. So clients can mail and chat each other at all times, when they are online it will show in their chat and when thy are offline it will show up in their inbox. But this might not be what you are trying to do.
For implementing best Chat application, use jabber server and write clients using js/flex
http://en.wikipedia.org/wiki/Extensible_Messaging_and_Presence_Protocol
If it's not like chat but you want to send messages over without a server, you need both clients be server as well. A server will listen on a port for incomming connections. Write a daemon that spawns a new thread each time a client connects. Within this thread you handle the messaging.
Client A opens a connection to the server (Client B) and they can talk to each other. Or you let Client A become server and let Client B connect.