(大约)有 3 个用于创建聊天应用程序的选项:
插座
前端使用 flash/java 和套接字,后端使用支持套接字的编程语言。对于后端,我建议使用 java 或 python,因为它们具有多线程和 NIO 功能。使用 PHP 可以做到这一点(但 php 不能真正做到高效的多线程,而且通常不适合这个)。如果您需要高性能,这是一个选项,可能不是您想要的。
使用 ajax 并拉取
在这种情况下,所有客户端都会不断(例如每 2 秒)轮询是否发生了新情况。感觉很奇怪,因为您只会在这些时间间隔收到回复。此外,它会给您的服务器和带宽带来相当大的压力。您知道应用程序使用这种技术是因为浏览器会不断刷新。这是一个次优的解决方案。
使用 ajax 并推送
这适用于多部分响应,并且在后端有长时间运行的(php-)脚本。不是最好的解决方案,但在大多数情况下,它比拉动要好,而且它可以工作并用于几个知名的聊天应用程序。这种技术有时被称为COMET。
我的建议:如果您需要用于生产用途的聊天应用程序,请安装现有的。编程聊天应用程序并不容易。
如果您只是想学习它,请从一个简单的 ajax/pull 应用程序开始,然后尝试使用 ajax 和 push 编写一个程序。
是的,很可能你需要一个数据库,我成功地实现了一个非常简单的 ajax/pull 解决方案,它可以与文本文件一起工作(但我肯定不会在生产中使用它!)。
(据我所知,但我很确定)没有服务器端后端(仅使用前端 javascript)就不可能创建聊天应用程序!
更新
如果您想知道数据推送是如何完成的,请查看此处的来源:http ://wehrlos.strain.at/httpreq/client.html 。异步多部分是你想要的:)
function asSendSyncMulti() {
var httpReq = new XMLHttpRequest();
showMessage( 'Sending Sync Multipart ' + (++this.reqCount) );
// Sync - wait until data arrives
httpReq.multipart = true;
httpReq.open( 'GET', 'server.php?multipart=true&c=' + (this.reqCount), false );
httpReq.onload = showReq;
httpReq.send( null );
}
function showReq( event ) {
if ( event.target.readyState == 4 ) {
showMessage( 'Data arrives: ' + event.target.responseText );
}
else {
alert( 'an error occured: ' + event.target.readyState );
}
}
每次数据到达时都会调用 showReq ,而不仅仅是像在常规 ajax 请求中那样调用一次(我在这里没有使用 jquery 或原型,所以代码有点肥胖 - 这真的很旧:))。
这是服务器端部分:
<?php
$c = $_GET[ 'c' ];
header('Content-type: multipart/x-mixed-replace;boundary="rn9012"');
sleep( 1 );
print "--rn9012\n";
print "Content-type: application/xml\n\n";
print "\n";
print "Multipart: First Part of Request " . $c . "\n";
print "--rn9012\n";
flush();
sleep( 3 );
print "Content-type: application/xml\n\n";
print "\n";
print "Multipart: Second Part of Request " . $c . "\n";
print "--rn9012--\n";
?>
更新2
关于数据库:如果你在后端有一个没有共享的架构,比如 mod_php/cgi,你肯定需要某种外部存储,比如数据库或文本文件。但是:您可以通过编写自己的 http 服务器来依赖内存(可以使用 php,但我不建议将其用于认真的工作)。这并不是很复杂,但可能有点超出你的问题的范围^^
更新3
我犯了一个错误!把一切都搞混了,因为我真的做了很长时间了。以下是更正:
多部分响应仅适用于 Mozilla 浏览器,因此用途有限。COMET 并不意味着多部分响应。
COMET 意味着:传统的单部分响应,但在有可用数据之前保持(无限循环和睡眠)。因此浏览器对每个操作都有 1 个请求/响应(在最坏的情况下),而不是每 x 秒一个请求,即使没有任何值得响应的事情发生。