使用PHP / MySQL网站作为服务器创建桌面聊天应用程序

Question

Most desktop chat applications probably use a specific software running on a distant dedicated box. However, is there a way a chat application could be backed by a simple PHP/MySQL web site? If so, what general advice would you give in terms of logging in and sending/receiving text?

Answer 1

There are two problems with the architecture (PHP/MySQL) you propose.

1) Chat is two-way traffic. This means that you need some way to push a message to your users. One option is to have your clients poll constantly for new messages (generating a lot of traffic). Another way is to wait with answering a HTTP request until a message exists. This is dependent on the timeouts in the network (timeout from proxy server, timeout from HTTP server). But it would work.

2) You have to be able to communicate messages between PHP instances. When you load a HTTP page, a single PHP process is launched which transforms the PHP code into HTML. You are proposing to use MySQL as a common data store between those processes. This means that you would need to have your PHP code constantly poll the database. They also need to mark which messages have been transferred to the client and which haven't. Maybe messages are lost along the way, there is no way to be sure.

Because of these two problems, chat programs are better left to a specific architecture.

Answer 2

I myself have programmed a simple chat application using PHP and SQL databases. You can check it out here .

The way I did it was kept a database of messages. The user stays on one webpage. When the user types a message and presses enter, an AJAX POST request is made to a PHP script. This script then inserts a row into the database with the message data etc. Then, every 1 second, the newest 8 messages are requested (via AJAX), and then put into a div on the page. All this happens every minute.

There are a number of problems with this design.

The most obvious is bandwidth consumption. Regardless of whether there are new messages, they are requested every second anyway. I myself thought of a new concept. Every second, instead of requesting all messages, it requests the message count. It then compares the local count to the server count. If they are different, it requests the new messages. You could even go further by finding the difference between the message count's, and then requesting each new message in a for loop, and then inject them into the DOM.

Answer 3

Here's how I would go about doing it:

Create a mySQL database to act as a message history. But use another means of relaying messages. Such as memcache.

Since we're a little way off web sockets, a messenger system requires a browser to poll or long-poll / comet to get any new messages. You don't want to be polling mySQL for this. Instead - new messages go into a memcache entry which is polled by recipients.

If you then wanted to save these messages, you could periodically save them to mySQL.