我使用 python-2.7 使用 IPv6和UDP套接字。我特别关注 IPv6多播 ff02::1
,其中每个链路本地地址设备(fe80::
)都响应来自中央服务器实体的查询。
我将微控制器连接到这些设备,这些设备需要.ihex
( Intel Hex )形式的程序。该文件的片段如下:
:103100005542200135D0085A8245381131400031EE
:103110003F4002000F9308249242381120012F8370
:103120009F4F1E390011F8233F4036000F930724AC
我的方法是使用struct
并使用pack
和unpack
等功能,但我不确定是否发送了这样的 ihex 大小为 Kbs 的文件可以解决目的。
我可以这样做:
#!/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..
包装参数是什么? (对于Hex文件,我应该!
或大或小Endian >
或<
吗?)
我无法使用scp
或sftp
,因为这两个协议都适用于 TCP ,并且不支持多播,而且我在一个环境中工作网络可能更高(无线媒体)
我是否应该按照此query的建议将 Intel Hex 文件转换为二进制文件,然后打包二进制文件?
答案 0 :(得分:1)
使用UDP与多播向多个消费者发送文件似乎充满了问题 - 除非整个文件适合单个数据包。 UDP数据包可能由于多种原因被丢弃/丢弃,并且您已经说过网络是有损的。您需要为每个消费者提供一种方法来跟踪并通知发件人有关丢弃的数据包。
话虽如此,但它确实可行。一个想法:构建一个多播多次的初始数据包,可能在两者之间有随机延迟(试图确保所有站都接收它)。这个初始数据包实际上就像&#34;关于发送新程序 - 期望N个后续记录数据包&#34;)。
然后发送N个数据包,可能每次两次。在每个数据包中放置一个识别序列号,让消费者跟踪他们收到的序列号。经过一段时间的延迟(或收到所有延迟后),让每个消费者回复一个状态包,说“&#34;我得到所有N个包&#34;或者&#34;我没有得到5,98,144和3019&#34; (或基于损失的任何适当的方案)。
然后发件人可以收集这些丢失的记录ID并重新发送,直到所有消费者都满意他们已收到整个文件。
为了将它们打包到数据报中,我认为你是否发送&#34; intel hex&#34;或二进制。在任何一种情况下,您都希望将它们作为字节流发送。二进制文件会更小,因此需要更少的数据包,但在发送它们的过程中没有其他区别。出于同样的原因,您选择的字节顺序不会产生影响。对于简单的字节流,您根本不需要使用struct
打包它们。你可以发送它们。
注意:python3区分
bytes
和str
类型,因此您需要在&#34; binary&#34;中打开文件。使用python3保持此模式。
但是,如果如上所述,您最终在每个数据包中发送序列号,则需要以某种方式格式化该序列号。您可以将数字格式化为ascii字符串,不需要struct.pack
。或者如果您将其格式化为二进制格式,则需要选择打包格式。传统上,网络数据包使用&#34;网络字节顺序&#34; (这实际上与big-endian相同)但这只是一种惯例。
如果我这样做,我可能会用以下内容构建每条记录:
然后您可以使用以下内容创建有效内容:
payload = struct.pack("!BHH", record_type, record_id, len(record_data))
+ record_data
我们在这里创建一个包含&#34;标题&#34; struct.pack
的5字节字符串。字段(使用网络字节顺序打包),然后简单地附加已经是字节字符串的record_data。