我正在使用python-2.7来处理IPv6和UDP套接字。我特别关注IPv6多播ff02::1
,其中每个链路本地地址设备(带有fe80::
)都响应来自中央服务器实体的查询。在
我把微控制器连接到这些设备上,它们需要一个.ihex
(intelhex)形式的程序。文件片段如下:
:103100005542200135D0085A8245381131400031EE
:103110003F4002000F9308249242381120012F8370
:103120009F4F1E390011F8233F4036000F930724AC
我认为解决这个问题的方法是使用struct
,并使用pack
和{
我能做点什么吗
^{pr2}$包装参数是什么?(对于十六进制文件,我应该执行!
或大小尾数>
还是<
?)在
我不能使用scp
或sftp
,因为这两种协议都适用于TCP并且不支持多播,而且我工作的环境中的网络损耗可能更高(无线介质)
另外,我是否应该将intelhex文件转换成二进制文件,然后打包成二进制文件?
使用UDP和多播来将一个文件发送给多个用户似乎充满了问题,除非整个文件都放在一个包中。UDP数据包可能由于多种原因被丢弃/丢弃,而且您已经说过网络是有损的。您需要有一种方法让每个消费者跟踪并通知发送方丢弃的数据包。在
话虽如此,这肯定是可行的。一个想法是:构造一个初始包,你可以多播几次,其间可能会有随机延迟(试图确保所有站点都能接收到它)。这个初始数据包的意思是“即将发送新程序-预期N个后续记录数据包”)。在
然后发送N个包,每个包可能两次。在每个数据包中放置一个识别序列号,让消费者跟踪他们收到的是哪一个。经过一段时间的延迟(或者当所有的数据包都收到了),让每个消费者用一个状态包来响应,要么说“我收到了所有N个数据包”或者“我没有得到记录5、98、144和3019”(或者基于丢失情况的任何合适的方案)。在
然后发送方可以收集这些丢失的记录id,并重新发送这些id,直到所有消费者都满意他们已经收到了整个文件。在
对于将它们打包到数据报中,我认为发送“intelhex”还是二进制并不重要。无论哪种情况,您都希望将它们作为字节流发送。二进制文件将更小,因此需要更少的包,但在发送过程中没有其他区别。出于同样的原因,您选择的字节顺序也不会产生任何影响。对于简单的字节流,根本不需要使用
struct
来打包它们。你可以直接寄过去。在但是,如果如上所述,您最终在每个数据包中发送一个序列号,那么该序列号将需要以某种方式进行格式化。您可以将数字格式化为ascii字符串,而不需要
struct.pack
。或者,如果您将其格式化为二进制,则需要选择打包格式。传统的网络数据包使用“网络字节顺序”(实际上与big-endian相同),但这只是一种约定。在如果我这样做的话,我可能会在每一个记录中:
然后您可以使用以下内容创建有效负载:
这里我们创建一个5字节的字符串,其中
struct.pack
包含“header”字段(使用网络字节顺序打包),然后简单地附加已经是字节字符串的记录数据。在相关问题 更多 >
编程相关推荐