I was trying to develop a web based chat system using PHP. I created one with the combination of jQuery and PHP but this setup is using lot of network bandwidth as it is continuously sending / receiving data to check whether a new message has been received or not (currently every 1 second). So I need to develop a system that will automatically display the message once a message is received from the other end without the need of sending a request to the server to see if there is a new message received.
I read in many places that this can be done using Jabber. I am really new to this jabber technology, so any help creating a new Jabber based chat using PHP will be greatly appreciated.
Jabber (also known as XMPP) is more of a protocol, so it's not really the solution you're looking for.
HTML 5 web sockets are a great new technology to achieve this. Rather than polling to see if there are any messages, the server can "push" new messages to the browser.
The client side code is JavaScript. The server side can be anything implementing the web socket protocol. There are probably some PHP libraries to write the server side code, but I have written a few Ruby web socket servers using EventMachine and em-websocket.
Related
I am trying to implement a very simple self-hosted (docker) pubsub client update system using websockets or SSE for my PHP application.
I would like that a specific javascript action on my website triggers a php server-side update (via ajax) which should then lead to an update to all subscribed devices for the particular channel/topic. The subscribed devices should use javascript listening to one channel each.
Do you know any simple PHP ws libraries which are capable of that? Can SSE be triggered in that way and also utilize channels? How about in-built PHP socket function? Ideally I would like to stick to PHP solution in order not to deal with translations and in-between REST APIs.
After researching this for days and going through solutions like RabbitMQ, Redis, Kafka, RatchetPHP, ZeroMQ, socket.io, RPC, SSE and etc I am completely lost. I need some guidance on which way to go.
Among all possible solutions here is how I would do it:
Install a web socket server, preferably implemented in PHP, on you Linux system.
Your web clients register with the server and listen for messages like broadcast from the server.
Your ajax script registers also with the server and sends a broadcast to the server if all work is done.
The server passes the broadcast to all registered clients.
You could use my implementation of such a web socket server that comes with all the needed client
libraries for JavaScript as well as for PHP that implement broadcast and feedback.
See https://github.com/napengam/phpWebSocketServer
I need to develop a realtime notification system. Load won't be high, about a dozen of events per hour. But I just want to make it scalable for future development.
My application is written entirely in PHP.
I have found different ways of implementing real-time applications. And I think the following architecture is quite simple and have a lot of benefits.
But I want to use the Faye library for implementing real time notifications, because it has fallbacks, and generally I am not going to use Websockets because my load is really low, and at first I will stick to the long-polling mechanism. Faye provides a convenient way for disabling and enabling different transport protocols.
Here is how my architecture is going to look
However I have one question regarding communicating back from a client.
Consider the following case.
Client loads a page through plain old HTTP request to a PHP app
Client side script opens a websocket/long polling connection
Another person sends notification via posting it through a simple AJAX request
This notification is saved to a database and assigned to a target recipient.
Notification is posted to a Redis database and consumed by Faye
Notification is sent to a client, everything is fine.
So far so good, but I need to some sort of back communication, for example when a client dismisses an event.
How should this be implemented, should I send this action back using Faye or this should be sent directly to the PHP application. In case of sending an event back using Faye I need to notify my PHP application that an event was seen and dismissed. Of course I can use the same database from a Ruby application as used by PHP app, but this makes these two application coupled.
Could you suggest a right way to implement this ?
I have a project were I am required to add push notification for Cordova AngularJS Push Notification using PHP on server side which gives JSON array as output. I can implement chat etc using this, but I want to know how to implement it in push notification or accessing native app API. Firstly I thought using Javascript SetInterval, but it slow downs the app, and checks the API everytime...
For Cordova push notification you can take a look here:
http://phonegappro.com/tutorials/apache-cordova-phonegap-push-notification-tutorial-part-1/
Still, let's review some other methods of sending data to the client using Web APIs:
Long polling - keep the connection open on the server side with no or long timeout, and return a result when you want to send a push notification.
Use WebSockets - open a steady TCP connection to the server and transmit messages in both directions (unlike HTTP's request/response model).
Use PushManager - this is an experimental technology that is not yet supported on mobile devices, so I guess this is a no-go for you.
Use simple polling - every now and then poll the server for a new message.
Long polling and Web Sockets will overload the server if you'll have a lot of concurrently open connections, so I wouldn't go there. Also Web sockets are mostly used for communicating between clients (server passes the client info to both clients, then they can communicate on their own without the sever intermediating between them).
PushManager is too new a technology not yet supported in mobile.
For what you want (mobile I guess, as you want to use Cordova), and without knowing what you are actually trying to achieve, I would say go with #4. I understand you already tried it, but perhaps try to lower the polling rate to every 30 seconds or so.
I understand that while debugging it doesn't seem nice to send something from the server then wait the better part of a 30 seconds period until it appears on the client, but if you think of it from the user's view point you'll see that the user doesn't know when the server sends the data, so it does appear immediate.
However, if you're writing a chat client, then I would go with web-sockets, using the server to connect the two (or more) clients in the chat and letting them pass the messages directly. If you want the chat to be server backed, just periodically send the transcript to the server using simple AJAX.
DIY vs Hosted Realtime Data Stream Network Service
If you do not expect to have more than a few thousand clients using your app, the DIY (do it yourself) sockets technologies (WebSockets, Socket.io, etc) is feasible. Beyond a few thousand (many of our customers say in the range of 5 to 10 thousand) you will experience difficulty (and large expense on server resources and scalable code) scaling your service.
Using a hosted realtime data stream network service like PubNub, Pusher, Ably, etc will be less costly and complex and it will just work. With some of the hosted services (PubNub for sure - which I work for - full disclosure) provides the ability to publish the message in realtime and include a push payload (for GCM, APNS and MPNS) that will also send the push notification if the app is in the background or not running.
With PubNub BLOCKS, you can also implement server side code that runs in the PubNub Network to inspect, manipulate or process the message without having your server do the work. This means you could send the message to other third party services: translate message to another language, use AI services for whatever reason, send an SMS/email/etc and much much more.
I'm new to websocket and realtime applications and I would need some clarifications.
I developed an application for a customer that involve some users and product data.
It is a PHP web application running on the internal apache server.
The client side of the app is based mainly on JQuery, and for some parts usable from tablet devices we used JQuery mobile / html5.
Now the customer is asking to add some messaging/notification feature in this way:
a user will be able to post a message about a product and the web console of the other users must be "showed" a realtime notification. We are thinking to add something for example in the header of the page to notify that new messages are present.
I made some research and as all the app is already built in PHP I was thinking to go for Ratchet. Is this a good idea?
If I understood this well, I will need to install on the server also the ratchet server components and use for client side integration something like AutobahnJS library; is it right?
Has anyone already built something like this?
Is there any problem communicating between Apache and Ratchet server?
That okie,
I tried use Ratchet/AutobahnJs Websocket, that's awesome. But I have (special?) problem :o in here.
In your case, I think you can use AJAX, it's simpler than Websocket. You can "zip" multi-notifications in to 1 response and request server every 5 seconds.
Yeah it's a good way to go about it, ajax leaves you with a lot of overheads. it's pretty simple to get going with ratchet and it will give you the ability to send notifications in real time, as well as the notifications it will allow you to edit the page as well, i.e change counters/ icons / message count etc, basically same as ajax only in realtime and no need to poll for new data.
It also means you'll be learning some new stuff which is always a bonus, for this alone i would do it.
I was looking at Kanaka's reply to a websockets question here.
If I want to write a native app in PHP to use a websocket based webservice, where do I start? Are there any client libraries available in PHP to write native linux clients?
Basically, my server can work on a RESTful architecture for 90% of the time. However, there is one reason for the server to alert the client, so REST won't work here. So I am wondering if websockets is an answer here for me as compared to periodic polling by client.
Why not write the 90% using normal REST and do the remaining part where notifications are sent to the client using web sockets?
Here is a github project that looks like it might be what you want https://github.com/nicokaiser/php-websocket