在Node.js第一次出现不久,Socket.io第一个版本也出现啦。在此之前,很长一个时间段,我一直子寻找一个框架可以容易的是我能够从服务器端推送数据到客户端,甚至尝试了从服务器端的javascript的途径。
在同时,主要的注意力集中于一个类似于在标准化进程中的websocket api 上面。我很幸运的收到很多反馈在会议上,包括node.js的创造者。这使我意识到这件事情的重要性。
Socket.io现在已经成为web的发射器。今天主要介绍socket.io 1.0版本。
1、New Engine
2、Binary support
3、Automated testing
4、Scalability
5、Integration
6、Better Debug
7、Streamlied Apis
8、CDN delivery
9、Future innovation
10、Credits
New engine
现在Socket.io代码库已经不在处理网络传输层和浏览器兼容性问题了。这个工作已经转移到一个新模块。这个模块叫做Engine.io.这个模块我们已经在不断完善好几个月啦。
Engine.io实现了一个类似websocket 的api.
Engine.io模块的分离允许我们完善网络传输层。在我最喜欢的改进是我称之为 传输层特性探测的思想。 transport feature detection.
在web 开发中,去探测User agent 来决定什么API去使用或者什么行为去使用是非常普遍的。为了最大化可靠性,javascript 代码量变大更复杂、量更大是很明显的。
例如:简单的检查JSON全局对象是否存在不代表JSON.stringfy可以使用、甚至不存在。这只是一味着用户自己定义了他们自己的JSON 全局对象、或者运行时环境以及破坏了JSON对象的实现。
Socket.io 从不假设websocket 可以工作,因为实践证明websocket 根本不工作。我们通过XHR 或者jsonp 来建立一个链接,然后尝试升级链接到websocket.
Binary Support
用户已经要求socket.io 具有发送二进制数据的能力,尤其websocket 把这能力增加到api中之后。
主要的问题是如果我们在websocket api之后,在socket.io 中模块化这个功能,那么websocket 中有用的api会被完全的限制。websocket 需要设置binary mode 或者string mode .
这是一个低级api,现在engine.io已经支持。但是,应用开发者不仅仅发送blob 或者被编码为blob,类型的。
现在socket.io 执行发射Buffer ,Blob, ArrayBuffer 甚至file 作为数据结构。
Automated Testing
在向Socket.io代码库中提交任何代码时,都会触发自动化测试,多达25个浏览器.包括ios和android
Integration
已经存在的应用程序使用多个语言框架来编写是很有利的,不仅仅局限于Node.js .即使,整个开发全部使用Node.js ,你可以把你的程序分离成不同的进程。
其中一个进程可以管理Socket.io 服务端,接受链接,执行验证 等等,另外一个进程可以在后面来管理生产消息。
为了这样,可以使用socket.io-emitter 可以在任何地方发射事件到浏览器中。
这样可以把已经存在的应用程序编程一个实时的双向通信的实时应用。
Better Debug
Socket.io 使用一个Debug库。https://github.com/visionmedia/debug
debug 是一个node.js 和浏览器debug 工具包。
链接:
introduction socket.io 1.0
http://socket.io/uncategorized/introducing-socket-io-1-0/#integration