一个月前打算写一个web版本的IM，杂事缠身，出差/部门PK，断断续续用零碎时间开发，到今天为止，才分别用node.js和php完成了两个版本。代码都在github上（nodejs版，php版），对于这种需要实时获取状态变更的web应用，用nodejs特别合适。第一个版本使用nodejs实现后，奈何市面上便宜的虚拟空间都是LAMP的，只得写一个php版本的。LAMP不适合支持long polling，因此使用正常polling实现。
Web版本的好处就是不用下载部署客户端，直接在PC、手机上都可以使用。PC上Chrome浏览器版本快照：
android手机快照：
还比较简单，不支持多个朋友，但基本的消息转发，在线通知，消息发送、清空、刷新功能有了。
后续打算把点对点的语音通话功能添加上去。今天研究了一下STUN（RFC3489、RFC5389），点对点通信的关键是NAT穿透，一般比较可靠的穿透方法是UDP打洞（hole punching），而语音通话对实时性的要求大于不丢包的要求，也适合使用UDP协议。
这样就要求有一个public的UDP Server，目前的LAMP空间肯定不行了，需要申请一个虚拟服务器。另外，客户端需要使用UDP通信，要么不使用B/S架构，开发一个客户端应用，要么继续使用B/S，不过使用java或flash去创建UDP点对点连接。实际上，W3C的WebRTC规范就是为这一目的构建的，WebRTC定义了一系列接口，能够通过可靠信令平面（signalling plane），使用STUN等NAT穿透协议，方便的在两个browser之间构建点对点的媒体平面（media plane）连接。可惜的是这一规范还处于draft阶段，还不知何年何月才能落地。
考虑到广泛的部署支持，还是选择B/S架构。当前可行的方案就是考虑flash/java了。这种方式虽然被WebRTC工作组诟病，需要浏览器插件支持，但目前没有其他更好的办法了。
值得一提的是，Chrome浏览器已经支持WebRTC了，还有一个应用可以用来测试，可惜天朝访问不了。
java web start比较厚重，考虑flash。
经过简单的搜索，除了java之外，好像flash、silverlight这些最流行的browser插件都不支持单播UDP（flash支持RTMFP实现browser间点对点通信，silverlight支持多播UDP），原因如这篇文章所述，容易引起安全问题。话说回来，互联网上的NAT一方面是提供更多IP，另一方面也是保护了脆弱的客户端，只要少数一些对外提供服务的服务器专心考虑安全问题就行了。而服务器的安全性已经有大量研究了，客户端如果对外能够直接暴露确实危险的很。
难道只能使用java了？？？不甘心，再看看。
看了一下flash的RTMFP资料，这个协议完全可以满足我的要求。下一步就是好好分析一下RTMFP是否在各个PC、Mobile设备的浏览器上都支持了。