OTP gen_tcp 的奇怪行为，设置 {packet,4} 并使用 NodeJS“frame-stream”进行 TCP 通信

问题描述

我一直在努力让我的消息在我的 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： 标题：0 0 0 239

理论：

• 某些字符编码不匹配，因为它位于数字 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 ？这甚至不是一个字节序选项......？

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

亲切的问候

戴尔

解决方法

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

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

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