0

我一直在努力让我的消息在我的 NodeJS 服务器和我的 erlang gen_tcp 服务器之间正确构建。在我不得不发送大数据消息并需要切换到消息大小框架之前，我一直在成功使用 {packet,line}。

我将 gen_tcp 设置为{packet,2}

我正在使用来自： https ://github.com/davedoesdev/frame-stream 的库 用于 NodeJS tcp 解码端。它也设置为数据包大小选项 2，我尝试了数据包大小选项 4。

我看到任何长度低于 127 个字符的消息，此设置运行良好，但任何超过此长度的消息都有问题。

我通过从 gen_tcp 发送越来越长的消息来运行测试，然后读出 NodeJS 端收到的前四个字节：

在消息 127 上：标题：0 0 0 127 帧长度 127

在消息 128 上： HEADER: 0 0 0 239 <----- 这应该是 128 帧长度 239 <----- 这应该是 128

理论：

  • 一些字符编码不匹配，因为它在数字 128 上（可能？）
  • gen_tcp 或库中的一些错误（极不可能？）
  • 巫毒魔咒让我在人权日工作（很可能）

来自wireshark的数据显示如下：

标头字节由 gen_tcp 正确编码超过 128 个字符，因为十六进制值按如下方式进行：

[00][7e][...]  (126 length)
[00][7f][...]  (127 length)
[00][80][...]  (128 length)
[00][81][...]  (129 length)

所以一定是NodeJS端的库调用Node readUInt16BE(0)或者readUInt32BE(0)函数的时候出错了。但是我检查了endieness，两者都是big-endian。

如果标头字节为 [A,B]，则在二进制中，此错误发生在 [00000000 01111111] 之后

换句话说， readUInt16BE(0) 将 [000000000 10000000] 读取为 0xef ？这甚至不是字节序选项...？

感谢您对如何解决此问题的任何帮助。

亲切的问候

戴尔

4

1 回答 1

1

我想通了，问题是由于将套接字设置为以 UTF-8 编码接收而引起的，该编码支持最高 127 的 ascii。

不要这样做：socket.setEncoding('utf8')。

现在看起来很明显，但是很难发现一行代码。

于 2021-03-22T21:21:50.237 回答