lmnosay-CSDN博客

原创 210读文件激活、激活确认、文件传输、文件传输确认

我会按照你提供的协议字段定义，逐字节解析这 4 个报文（读文件激活、激活确认、第一帧传输、第二帧传输），并验证关键字段的一致性和合法性。字节序规则：低字节在前（小端序），仅针对 4 字节字段（文件 ID、文件大小、数据段号）校验码算法：文件数据段的单字节模和运算（所有字节求和后取低 8 位）读文件协议报文完整解析（按协议格式拆解）四、3. 读文件数据传输（第一帧）解析。五、4. 读文件数据传输（第二帧）解析。三、2. 读文件激活确认报文解析。二、1. 读文件激活报文解析。文件数据 ASCII 还原。

2026-01-24 22:02:46 318

原创 210召唤目录及确认

目录召唤确认报文（含精准时间解析）全字段解析。最终完整小端序报文（十六进制，空格分隔）目录召唤确认（操作失败）报文全字段解析。

2026-01-24 17:03:37 20

原创 104文件传输210写文件

按你的核心要求（完整无省略、无后续帧、所有文件 ID 非空），生成 4 个步骤的完整测试报文，文件 ID 统一设为十进制 12345678（十六进制 0x12345678，低字节在前 = 78 56 34 12），数据传输帧后续标志 = 0（无后续），文件名20241027.log长度修正为 12 字节（0C），所有字段严格匹配文档约束。核心要求落地：文件 ID 全程非空（78 56 34 12）、数据传输帧后续标志 = 0（无后续）；步骤 3：主站→终端写文件数据传输（操作标识 = 9，无后续帧）

2025-12-08 21:03:29 207

原创 IEC 104 规约发送序号和接收序号偶数问题

104 规约的发送 / 接收序号是保障主从站通信可靠性的核心，核心规则为「偶数序号、步长 2、接收序号 = 已接收最大发送序号 + 1」，程序内部通过 “左移 / 右移 1 位” 实现 “逻辑序号↔帧内偶数序号” 的转换。接收序号 (nr) 是 “期望下一个接收的发送序号”，规则为：主站逻辑nr = 已正确接收的从站最大逻辑ns + 1。帧内序号必为偶数，程序内部用逻辑序号（+1），通过左 / 右移 1 位转换；从站：发送第 3 帧，逻辑 ns=3→帧内 6（06 00）→主站接收；

2025-12-05 16:11:40 156

原创 Docker 安装 TimescaleDB

验证数据库时区：docker exec -it timescaledb-iot psql -U postgres -c “SELECT current_setting(‘timezone’);数据安全：定期备份数据库（pg_dump -U postgres -d iot_db -f 备份文件.sql），避免数据丢失；修改端口映射（如-p 5433:5432），连接时指定新端口（如psql -p 5433）。版本管理：镜像标签固定为具体版本（如 2.11.0-pg15），避免升级导致兼容问题。

2025-11-26 17:22:36 1057

原创 104协议I帧S帧发送序号和接收序号交互流程

如果控制域是XX YY ZZ WW（4 字节）：补充：常见序号示例对比（快速上手）记住核心：前 2 字节是发送序号，后 2 字节是接收序号，小端序（低位在前）计算数值，下次遇到任何 I 帧控制域，直接套用这个规则就能快速解析！

2025-11-26 10:48:41 1102

原创 tcpdum http抓包实践

本次 400 问题的本质是：SpringBoot 的 RestTemplate 基于 JDK 的HttpURLConnection，自动添加了超长的Accept-Charset头，导致请求头总长度超过 Nginx / 服务端的默认限制，而 curl 请求因无冗余头、长度小，能正常通过校验。解决思路的核心是「精简程序请求头，对齐 curl 的极简风格」—— 要么在代码层移除冗余头，要么替换底层 HTTP 客户端，彻底杜绝自动添加超长头的问题。

2025-11-24 22:59:06 683

原创 nc 模拟http服务端

nc（netcat）可以轻松模拟极简但可控的 HTTP 服务端—— 核心是监听 TCP 端口，捕获客户端的原始 HTTP 请求报文，并返回符合 HTTP 规范的响应（支持自定义 200/400 等状态码）。这种方式能裸看客户端请求的所有细节（无任何封装），是排查「程序调用 400、curl 正常」的核心手段。HTTP 是基于 TCP 的文本协议，只要服务端返回的响应报文符合「状态行 + 响应头 + 空行 + 响应体」的格式（换行必须是\r\n），客户端就会识别为合法 HTTP 响应。

2025-11-24 21:37:40 548

原创 mqtt不同场景下QoS 和 Retained 的配置

若需删除某主题的 Retained 消息，可发布一条 “空 payload” 的 Retained 消息（message.setPayload(new byte[0]) + message.setRetained(true)），Broker 会自动清理旧 Retained 消息；：QoS 等级越高，网络带宽和 Broker 负载越大（QoS 2 > QoS 1 > QoS 0），需避免 “过度设计”（如普通传感器用 QoS 2，会浪费资源）；一、普通传感器数据：QoS=0，Retained=0。

2025-09-30 11:35:17 660

原创 mqtt topic 通配符使用

MQTT 协议定义了两种通配符，用于订阅主题时匹配多个相关主题（通配符仅用于订阅，不能用于发布消息）。两种通配符分别是单级通配符（+）和多级通配符（#），它们基于主题的 “层级结构” 工作（主题通过 / 分隔层级，例如 sensor/room1/temp 包含 3 个层级）。

2025-09-28 14:34:31 411

原创 16进制转10进制有符号和无符号解析工具

16进制转10进制有符号和无符号解析工具。

2025-09-12 19:40:16 384

原创 Spring Boot HTTPS 实战

本文通过完整的代码实战，覆盖了 Spring Boot HTTPS 服务端和客户端的核心配置：服务端：实现 HTTPS 部署和 HTTP 自动转 HTTPS，关键是 server.ssl 配置和 HttpToHttpsConfig 连接器；客户端：实现证书认证调用，关键是信任库加载、SSL 上下文初始化和 RestTemplate 配置；联调：明确启动顺序和测试步骤，快速验证功能；避坑：针对常见问题给出解决方案，降低调试成本。

2025-09-09 18:48:13 913

原创 https密钥库（KeyStore）的类型

特点：跨平台的标准密钥库格式（由 RSA 实验室定义），被所有主流操作系统（Windows、macOS、Linux）和浏览器支持。特点：基于 JCE（Java 加密扩展）的增强型密钥库，支持更强的加密算法（如 AES、3DES）。特点：Java 原生的密钥库格式，是 JDK 早期默认的密钥库类型（JDK 8 及之前默认）。优势：密钥存储在硬件中，无法被导出，安全性极高，适合存储核心敏感密钥（如根证书私钥）。PKCS12 绝大多数生产环境（跨平台、高兼容性、高安全性） ★★★★★。

2025-09-09 16:09:43 575

原创 kafka压缩配置

Kafka 的压缩逻辑仅在生产者（Producer）端执行，消费者（Consumer）端自动解压（无需额外配置），中间 Broker 仅 “透传压缩后的消息”，不参与压缩 / 解压过程，避免重复计算开销。生产者批次化压缩：生产者将多条消息累积成一个「消息批次（Batch）」，对整个批次的二进制数据进行压缩（而非单条消息），压缩效率更高（批次越大，重复数据越多，压缩率越高）；适用场景：消息本身已压缩（如图片、视频、压缩后的二进制文件）、业务要求 “零压缩延迟”（如金融高频交易数据）。

2025-09-01 18:35:45 1003

原创 docker 安装mysql5.7 mysql开启binlog mysql忽略大小写设置

12、查看是否忽略大小写：show global variables like ‘%lower_case%’;8、进入容器 docker exec -it 0be4d499443b /bin/bash。11、查看binlog是否开启：show variables like ‘log_%’;3、运行mysql --privileged=true这个赋予容器操作权限。9、进入mysql : mysql -u root -p。2、创建lm2路径，用于映射容器中mysql数据。6、编辑mysql配置文件。

2023-05-31 17:53:29 1952 1

weixin_44314242的博客