0

我正在使用python-2.7处理IPv6 和 UDP 套接字。我特别关注IPv6 多播,其中每个本地链路地址设备(带有)都响应来自中央服务器实体的查询。 ff02::1fe80::

我将微控制器连接到这些需要.ihex英特尔十六进制)形式的程序的设备。该文件的片段如下:

:103100005542200135D0085A8245381131400031EE
:103110003F4002000F9308249242381120012F8370
:103120009F4F1E390011F8233F4036000F930724AC

我认为解决方法是使用struct和使用类似的功能packunpack但我不确定发送这样一个大小为几Kbs的ihex文件是否能解决问题。

我可以做类似的事情:

#!/usr/bin/env python

from struct import pack, unpack
import socket
.   # Create a UDP socket and Bind it..
.
myHexCode = open("Filename.ihex")
dataToSend = struct.pack('Paramaters for packing', myHexCode)
.
. Send data to socket..

包装参数是什么?(我应该!做大端还是小端>还是<十六进制文件?)

笔记

  • 我不能使用scp也不能使用,sftp因为这两种协议都在TCP上工作并且不支持多播,而且我在网络中的损失可能更高的环境中工作(无线介质

  • 我还应该按照此查询的建议将Intel Hex文件转换为二进制文件,然后打包二进制文件吗?

4

1 回答 1

1

使用 UDP 和多播将文件发送给多个消费者似乎充满了问题——除非整个文件适合单个数据包。由于多种原因,UDP 数据包可能会被丢弃/丢弃,并且您已经说过网络有损。您需要为每个消费者提供一种方法来跟踪并通知发送者丢弃的数据包。

话虽如此,这当然是可行的。一个想法:构建一个初始数据包,您可以多次多播,可能在两者之间有随机延迟(以确保所有站点都接收它)。这个初始数据包实际上说的是“即将发送新程序 - 期望 N 个后续记录数据包”)。

然后发送 N 个数据包,每个数据包可能两次。在每个数据包中放置一个识别序列号,并让消费者跟踪他们收到的数据包。经过一段时间的延迟(或全部收到后),让每个消费者回复一个状态数据包,说“我收到了所有 N 个数据包”或“我没有收到记录 5、98、144 和 3019”(或任何方案基于损耗是合适的)。

然后发送者可以收集这些丢失的记录 ID 并重新发送这些 ID,直到所有消费者都满意他们已收到整个文件。

为了将它们打包到数据报中,我认为发送“intel hex”还是二进制并不重要。无论哪种情况,您都希望将它们作为字节流发送。二进制会更小,因此需要更少的数据包,但在发送它们的过程中没有其他区别。出于同样的原因,您选择的字节顺序不会产生影响。对于简单的字节流,你根本不需要使用struct来打包它们。您可以发送它们。

注意:python3 区分bytesstr类型,因此您需要以“二进制”模式打开文件才能在 python3 中保持正确。

但是,如果如上所述,您最终在每个数据包中发送了一个序列号,则该序列号将需要以某种方式格式化。您可以将数字格式化为 ascii 字符串,struct.pack不需要。或者,如果您将其格式化为二进制,则需要选择一种打包格式。传统的网络数据包使用“网络字节顺序”(实际上与大端相同),但这只是一个约定。

如果我这样做,我可能会用以下方式构建每条记录:

  • 记录类型(二进制,一个字节——区分这是一个数据包)
  • 记录 ID(二进制,两个字节 - 序列号 [或更大,取决于文件的大小])
  • 记录数据长度(二进制,两个字节表示记录数据字段的长度)
  • 记录数据(二进制,N字节)

然后,您可以使用以下内容创建有效负载:

payload = struct.pack("!BHH", record_type, record_id, len(record_data))
          + record_data

在这里,我们创建了一个 5 字节的字符串,struct.pack其中包含“标题”字段(使用网络字节顺序打包),然后简单地附加已经是一个字节字符串的 record_data。

于 2016-03-31T16:18:18.077 回答