时间戳

首页 > 解决方案 > 带有设置 {packet,4} 并使用 NodeJS“帧流”进行 TCP 通信的 OTP gen_tcp 的奇怪行为

node.js - 带有设置 {packet,4} 并使用 NodeJS“帧流”进行 TCP 通信的 OTP gen_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 上： HEADER: 0 0 0 239 <----- 这应该是 128 帧长度 239 <----- 这应该是 128

理论：

来自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 ？这甚至不是字节序选项...？

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

亲切的问候

戴尔

标签： node.jstcperlangerlang-otpgen-tcp

解决方案

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

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

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

推荐阅读