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.
Related
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.
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
I am building a website in PHP that handles the sessions in Redis in JSON format.
This way the session can be accessed by both the PHP interpreter and a node.js server.
What I am trying to do is now to add notifications in said website; the procedure I was thinking of is the following: (just figure it as a simple friend request to simplify it all)
user A sends friend request.
PHP uses cURL to say to node.js service to send notification
user B gets a notification because he is connected to node.js via socket.io
What are the general guidelines to achieve this? Because it looks clear to me that if user A and B are in different servers, it will be impossible to scale horizontally;
Thanks in advance.
Sounds like a you could make use of Web Sockets here with a Publication / Subscription protocol, architecture.
You get Server client functionality with web sockets.
Node is a perfect choice for a websocket server, lots of small IO.
See http://en.wikipedia.org/wiki/Web_sockets
I'm wouldn't think if the shared session is required for php - node communication, just have your clients push requests through the socket and handle the reposes as needed.
I think the approach you propose sounds quite reasonable. However, instead of doing a direct request to the service, you could consider using a message queue (zeromq, rabbitmq, whatever) which would allow you to scale it more easily as you can easily add logic to the queue processing to pass the message to the correct node instance.
I managed to get 1400 concurrent connections with socket.io on a cheap VPS with no special configuration so even with no tricks it should scale quite well. In my case most of these connections were also sending and receiving data almost constantly. It could probably have handled more than that, 1400'ish was simply the max number of users I happened to get.
Though I'd worry more about getting all those users first ;)
Use Redis's built in pub-sub capability. When the PHP server gets a request, it publishes it to a channel set up for that purpose. Each of your node servers subscribes to that channel and checks if the user involved is connected to it. If so, it sends the notification via socket.io. As a bonus, you avoid an extra network connection and your overall logic is simplified.
simply setup ur database as per required then whenever a activity is made just tell ur node js to transfer the related information through redis to php and make a process and in make a response back from php to node via channel keep checking the notification from table and show
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.
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.