我一定是错过了一些非常明显的东西,但我不能正常工作。
握手是正确的,但是当我发送一条数据时,我没有在服务器上得到正确的数据。
服务器:stream.on("data", function(data) {
if(!handshake) return doHandshake(); // no problems with handshake
console.log(data);
});
客户:ws = new WebSocket("ws://localhost:12345");
ws.onopen = function() {
ws.send(String.fromCharCode(parseInt("89", 16)));
}
我在node.js控制台看到的:
<Buffer 81 82 ed 68 ae 67 2f e1>
则密钥为ed 68 ae 67
,编码数据为2f e1
。使用xor解码,解码后的数据显示为c2 89
。由于某种未知的原因,c2
被前置- 89
是正确的。
其他字符也会发生奇怪的事情:
ws.send(String.fromCharCode(parseInt("ab", 16)));
我:
<Buffer 81 82 ff 8e 45 34 3d 25>
解码后的数据是c2 ab
而不是ab
。
我使用新的帧格式(Chrome 15)和Windows版本的node (node.exe
)。
- 出什么问题了?
- 是否有可能看到Chrome发送的内容,以便看到问题所在?
试试Chrome 13(当前稳定通道)
Chrome 14+使用新版本的Web Sockets规范,这可能不会在您的版本节点websocket服务器中实现。
更多信息,参见旧版本的规范和http://chromestatus.com。
此外,当前版本的Chrome,即使是那些实现了新的规范(Chrome 14和15在这个时候)不允许发送二进制数据
结果是它将所有内容都转换为UTF-8。
根据维基百科,127到2047(以10为基数)之间的所有内容都将被编码为两个字节:
110bbbaa 10aaaaaa
例如:89
:
base 16 - 89
base 10 - 137
base 2 - 10001001 so bbb = 000, aaaaaaaa = 10001001
以10为基数大于127。因此,它将被编码为:
110bbbaa 10aaaaaa
11000010 10001001
以16为基数:
c2 89
令人沮丧,但至少我现在知道问题出在哪里了…
我在MacOS x上使用Chrome 14.0.835.186 .刚刚由于Chrome的WebSockets变化而导致我的应用程序中断。
我切换到:https://github.com/Worlize/WebSocket-Node
如作者所说:
警告:这个库只实现了WebSocket协议的最新草案。在支持它的新版本发布之前,它不能在生产浏览器上工作。
这是一个内部应用程序,所以我有强迫人们使用Chrome 14的奢侈,但有一个hack来支持其他草案https://gist.github.com/1219165。我也只使用纯文本