Online chat is deceptively difficult due to the stateless nature of http and the web in general, causing such hurdles as session timeouts, users opening multiple windows and different accounts being signed in on one browser window. There is also the problem of users closing the browser window and logging out and such things, which make dealing with undelivered messages quite tricky.
Are there any good articles that describe how others have solved these problems elegantly?
Please feel free to write your own thoughts on how an IM like facebook or gmail's can be achieved with maximum robustness.
Is there any decent code base / writeup for integrating with a locally hosted jabber server to achieve this?
Edit:
The site will be one on one chat between any member of the site - as in bob can talk to carol and bob can talk to jim at the same time in a separate chat popup. This does make it a good candidate for jabber/xmpp.
I will gladly accept the answer that is most helpful within the next 4 days.
I'm curious what sort of system you're planning on using this for. Is it for a small-scale chat system between users on a tiny project, or are you envisioning a BIG system? The biggest problem with online IM systems is reliability — take facebook, for example. Their chat system is notoriously buggy, and it's maintained by a large fleet of professional developers with tons of resources at their disposal.
You might want to start by looking at the XMPP organization's list of XMPP clients; there's a section for web clients. If there are any which are open-source, you could probably work with that some. Again, it's hard to say without knowing exactly what the system is intended to do. One possibility could be using Google Apps for your Domain if it's an internal sort of thing. If worse comes to worse, and you have a LOT of time on your hands, maybe you could write your own implementation of the LibPurple library for web use (google it; I don't have enough reputation points yet to post a second hyperlink).
Hope that gives some ideas of where to start. I've never done this before, just giving some hopefully helpful tips. Good luck!
Related
We have developed a web application for an office management, the plan is to provide a hosting server.
Therefor due to some circomstences an important part of our targeted portential clients, wouldn't want there work online on the web (even if many security measurment are to be implemented), so we offer a LAN installation for these clients.
This is causing a real headaches for the team, since we don't want someone with enought skills to access our sources code, since if they do, they can try and find a way to hack our online sytem.
So, the question is how can we protect our work from beeing accessible, and only allow its execution, obfusticating the PHP code is one way, but its not enough, while seaching I've come accross a way where we can make a Vitrual machine, but this is not the most optmal solution since it will require some hardware configuration (memory and other stuff)
Does anybody know a way out from our misery ? It would be wonderful if its a free solution, but if not, it can be okay with a cheap one :)
This is a FAQ here and the received wisdom is that you can't do anything. This makes sense if you think about it as ultimately there is nothing you can do to stop someone reading what their computer is doing. If your computer is going to run code, it must be in a computer-acceptable format which means that no matter how you try to hide it, it can be decoded and displayed as in order for your computer to understand it, it must meet certain inviolable standards which are published and well known.
You can make if difficult for people who would not know what to do with the code anyway, but anyone who could use your code will be able to get it if they want to.
Is your stuff so remarkable and innovative that you really think it is worth stealing?
For instance, it took me almost 10 minutes to work out how Google did it's nifty suggest thing and another 20 to replicate it. By SO standards that is extremely slow. I use the idea along with almost everyone else but I have never seen their code and it would be boring if they showed it.
Why not just bind users with a non-reverse-engineering contract? This, after all is how MS protects its IP. Windows is easy enough to copy if you want to. MS makes it worth paying for their product by providing updates only to licenced users. Perhaps you could do the same.
Ask yourself if it is REALLY necessary to have the code hosted locally. When did the internet last fail you? 3 years ago I experienced a major earthquake. No power, water or sewage for 2 weeks but the internet both wired and mobile kept working. My computer didn't as I had no power but 3g was just fine. The infrastructure is incredibly robust and there is really very little need for local data duplication. My experience has been that anything that knocks out the internet more than transiently is more than likely going to knock out any local solution too.
Finally, if your clients want a locally hosted solution, ask yourself if they are worth the trouble. The best way to help them to mature is to let them see what they are missing.
Caveat - I do actually duplicate some data on some local systems but this is a useful feature of backup - I allow clients a view of the backed up data in the event of catastrophic internet failure, but I don't allow them to modify the locally held data as it negates the 'one true record' principle which is why we use the cloud in the first place.
I have added a chat capability to a site using jquery and PHP and it seems to generally work well, but I am worried about scalability. I wonder if anyone has some advice. The key area for me I think is efficiently managing awareness of who is onine.
detail:
I haven't implemented long-polling (yet) and I'm worried about the raw number of long-running processes in PHP (Apache) getting out of control.
My code runs a periodic jquery ajax poll (4secs), that first updates the db to say I am active and sets a timestamp.
Then there is a routine that checks the timestamp for all active users and sets those outside (10mins) to inactive.
This is fairly normal from my research so far. However, I am concenred that if I allow every active user to check every other active user and then everyone update the db to kick off inactive users, then I will get duplicated effort, record locks and unnecessary server load.
So I have implemented an idea of the role of a 'sweeper'. This is just one of the online users, who inherits the role of the person doing the cleanup. Everyone else just checks whether there is a 'sweeper' in existence (DB read) and carries on. If there is no sweeper when they check, they make themselves sweeper (DB write for their own record). If there are more than one, make yourself 'non-sweeper', sleep for a random period and check again.
My theory is that this way there is only one user regularly writing updates to several records on the relevant table and everyone else is either reading or just writing to their own record.
So it works OK, but the problem possibly is that the process requires a few DB reads and may actually be less efficient than just letting everyone do the cleanup as with other research as I mentioned.
I have had over 100 concurrent users running OK so far, but the client wants to scale up to several 100's, even over 1,000 and I have no idea of knowing at this stage whether this idea is good or not.
Does anyone know whether this is a good approach or not, whether it is scalable to hundreds of active users, or whether you can recommend a different approach?
AS an aside, long polling / comet for the actual chat messages seems simple and I have found a good resource for the code, but there are several blog comments that suggest it's dangerous with PHP and apache specifically. active threads etc. Impact minimsed with usleep and session_write_close.
Again does anyone have any practical experience of a PHP long polling set up for hundreds of active users, maybe you can put my mind at ease ! Do I really ahve to look to migrate this to node.js (no experience) ?
Thank you in advance
Tony
My advice would be to do this with meteor framework, which should be pretty trivial to do, even if you are not an expert, and then simply load such chat into your PHP website via iframe.
It will be scalable, won't consume much resources, and it will get only better in the future, I presume.
And it sure beats both PHP comet solutions and jquery & ajax timeout based calls to server.
I even believe you could find on github more or less a completed solution that just requires tweaking.
But of course, do read the docs before you implement it.
If you worry about security issues, read security with meteor
Long polling is indeed pretty disastrous for PHP. PHP is always runs with limited concurrent processes, and it will scale great as long as you optimize for handling each request as quickly as possible.
Long polling and similar solutions will quickly fill up your pipe.
It could be argued that PHP is simply not the right technology for this type of stuff, with the current tools out there. If you insist on using PHP you could try ReactPHP, which is a framework for PHP quite similar to how NodeJS is built. The implication with React is also that it's expected to run as a separate deamon, and not within a webserver such as apache. I have no experience on the stability of this, and how well it scales, so you will have to do the testing yourself.
NodeJS is not hard to get into, if you know javascript well. NodeJS + socket.io make it really easy to write the chat-server and client with websockets. This would be my recommendations. When I started with this is, I had something nice up and running within several hours.
If you want to keep your application stack using PHP, you want the chat application running in your actual web app (not an iframe) and your concerned about scaling your realtime infrastructure then I'd recommend you look at a hosted service for the realtime updates, such as Pusher who I work for. This way the hosted service handles the scaling of the realtime infrastructure for you and lets you concentrate on building your application functionality.
This way you only need to handle the chat message requests - sanitize/verify the content - and then push the information through Pusher to the 1000's of connected clients.
The quick start guide is available here:
http://pusher.com/docs/quickstart
I've a full list of hosted services on my realtime web tech guide.
I'm working on a small private site for a group of 10 people. It's essentially a tiny social network just for us. We currently also use Windows Live Messenger for real-time chatting but we're looking to create an alternative since the MSN clients out there for Mac, Linux and smartphones do not support the recently added group features in MSN, which we use.
I've been reading up a little on push technology to see how I'd go about creating a web based chat room that suits our very limited needs. I gather that Apache is not really suited for long polling at all, and that using something like APE would be a better idea. However, we're running on a fairly cheap but very good shared host so we simply don't have the ability to install any server side software.
To my question.
Since we are, after all, just a handful of users, and most of the time only half of us will be online, is is likely that simple PHP long polling could work? The chat is going to be open pretty much every day from early afternoon to late at night, but not all users will be active all the time. Still, on average probably five or six users will be online without leaving for a whole day, every day. When we're the most active, there will be times when a lot of messages are sent in a short period of time, but it's hard to estimate how many.
Would it be worth looking into the use of Websockets using the PHP server implementation of those and with a Flash fallback (for desktop use we're fine since we all use Chrome, basically, but we'd be happy to be able to use Android devices as well).
I also stumbled upon www.pusher.com and their free alternative looks quite suitable, with 20 connections and 100 000 messages per day (we won't nearly reach that much even in a week). Would you recommend we simply go down that road instead?
I know there are loads of questions here regarding push technology with PHP and Apache, but I haven't found anything addressing a situation where there will be such limited use of the application. Any tips and suggestions would be greatly appreciated. I pretty much know how I'd write the chat itself, I just need to know the best method to use, and if any of the above will work.
I'm creating a social network website, and I need a IM/chat solution for it.
The conversations are only one-on-one, with the users being able to chat only with their friends (i.e. Facebook chat - no channels, no rooms ...).
The website is made in CodeIgniter(PHP) with MySQL database. Probably will be put on VPS (Linux), so I might have control on the environment. Also, it is expected to have more than 100 000 users.
So, I need some ideas about how to make the chat.
My ideas so far:
Ajax poll on every X seconds (not good solution for website this size)
Implementing Jabber/XMPP system (I have no info about this, nor is it possible)
Using 3rd party service (like Pusher.com)
creating the chat in Node.js and socket.io, and having it independent from the other part of the website
After some research and reading some answers here on SO
https://stackoverflow.com/a/11362929/928540
https://stackoverflow.com/a/5654487/928540
I really like to go with the idea of Node.js and socket.io, so I would like to hear some opinions about it, and maybe some guidance, links, help, tutorial ...
Also, it is expected to have more than 100 000 users
I think the question also is how many active users/connections.
Ajax poll on every X seconds (not good solution for website this size).
True that. This is a bad idea.
Implementing Jabber/XMPP system (I have no info about this, nor is it possible)
Something like Ejabberd with BOSH is pretty popular. I played with prosody because it is very easy to install and strophe.js as BOSH client(javascript in browser).
Using 3rd party service (like Pusher.com)
The easiest to implement(no scaling problems), but could get expensive. 5000 simultaneous connections will cost you 199 dollar per month(too expensive) which I think you might need? Then again you have about 5000 active connections so it is profitable(?).
creating the chat in Node.js and socket.io, and having it independent
from the other part of the website
Very popular solution, but right now I believe some users are experiencing memory leaks(but this might have been solved). It might be only problem with websockets transport. Also it might not really be a leak, but just high memory usage because of lazy GC. I would advice to profile before fully commiting.
Meteor might be a solution you could use. It's designed to create "live" applications and I bet building a one-on-one messaging system is a breeze.
I know it isn't PHP, but you mentioned using Node.js and I figured if you could use Node.js then you could use this.
I am interested in a really good way of doing instant messaging like meebo and facebook and myspace all have, also for notifications on a page. Example on my site now, when a user receives a new mail message, photo comment, profile comment, friend request, some other things, they will receive a notification message and link on the page they are on using jQuery and AJAX.
I believe on a large scale that this is not the best way to do it though as my jquery code will have to basically run a PHP script to query the mysql table every 30 seconds or so for every user who has the page open with this script running. I would like to eventually add in some sort of instant messaging like facebook has in a chat bar at the bottom of the screen if I can find out an efficient way of doing it.
I have heard the terms Comet and HTML5 WebSockets but I am not sure if these are the solutions I should be looking at for such a feature? I would like to keep bandwidth at a minimum and running a query every few seconds does not seem very efficient on a high traffic site.
If you know some good solutions, please explain how they work a little bit please
You're looking for a "comet" server. Since you're talking PHP, your best solution would be a SaaS solution, such as WebSync On-Demand, since PHP has issues with scaling when it comes to large numbers of concurrent connections being held open. See also this question.
I think Facebook uses XMPP for their chat, so have a look at it.
XMPP is
an open technology for real-time communication, which powers a wide range of applications including instant messaging, presence, multi-party chat, voice and video calls, collaboration, lightweight middleware, content syndication, and generalized routing of XML data.
You'd install a separate server to handle messaging and in your app you'd implement a client with one of the available libraries.
Could you have a shared message queue that ajax can query? Maybe its a php script that stores a majority of the message in memcached (and possibly write to db in case of failure).
Not sure, but curious to hear other solutions ...
The basic problem is that you need to implement a Comet server (ie implement Server Push). The standard web hosts and apache don't readily allow you to do this easily. Another hosted solution (apart from Web Sync) is Goldfish Server. Currently free.