总结一下,基本思路都是把大文件(图片)拆成多个小包传,而且配有报头,现在需要确定的是报头就最开始传一次就好了,还是每个小包都配有一个报头,严格来讲,还是每个小包都配一个数据头好些。
清楚了这些再去写协议就可以灵活自如了,细节上可以有些小不同但是你清楚他们的利弊。
===========================
UDP分批传图就是这么传的,是啊,现在感觉UDP传输大文件应该有通用的代码。
https://blog.csdn.net/qq_36852276/article/details/90761122
https://www.cnblogs.com/whkzm/p/11707567.html
https://www.cnblogs.com/gengfenglog/p/14295399.html
我看很多博文都把前面先发的这一部分叫报头。也有的叫文件头
https://www.lmlphp.com/user/16517/article/item/584108/
这个真正讲清楚了struct的作用,不过几乎所有文章都是说TCP才需要用这个,UDP不需要。
https://www.cnblogs.com/believepd/p/9690487.html
我感觉就像串口发送不定长数据的时候,就在报文里面加上一个长度,这样让接收者知道这一帧的长度是多少。本质可能是一样的。
fhead = struct.pack('4i',imgFlag,imgLen,imgPackUnit,imgpackNum) 里面4i的意思应该是这四个合起来是4个int。
或者我觉得可以这么理解,报头 一种是为了避免TCP粘包 另一种是为了传大文件准备的,传大文件也是必须要有一个报头,提前告诉要传输文件的大小,这个角度里面UDP用struck.pack生成报头。
这里证实了我的猜想,这个用UPD传图就用到了struct.pack
https://blog.csdn.net/qq_36852276/article/details/90761122
之前不是实现过视辉吊舱的http传图么,我觉得本质原理是一样的。
https://gitee.com/maxibooksiyi/gimbal_control/blob/droneyee-vsheen/src/gimbal_vsheen_http.cpp
这个是用C++实现的,策略是类似的
https://blog.csdn.net/qq_41672557/article/details/103076545
这个UDP传图片也是要分包组包。
https://blog.csdn.net/caoshangpa/article/details/52681572
https://www.bilibili.com/video/av625038835
https://www.bilibili.com/video/av754896008
需要注意的一点就是后面每次发一部分图片的时候,都是要先发报头的,报头不是发一次就完了的。不然你那个第几次发根本体现不出来啊,我也是刚刚看了上面几篇文章才明白过来,之前的理解不对。而且报头或者包头基本都是一个结构体组成的。
https://blog.csdn.net/caoshangpa/article/details/52681572
https://www.bilibili.com/video/av625038835
https://blog.csdn.net/qq_41672557/article/details/103076545
这篇文章是发一次报头,然后循环发图片。但是这种方法下面有人评论了,这样没有考虑到数据包无序的问题。确实是这样的,是存在这样的隐患的。所以严格地来说应该是要发一次报头发一次数据体。每次数据体都有报头,这样才是个比较严谨的做法。
https://blog.csdn.net/qq_36852276/article/details/90761122
https://zhidao.baidu.com/question/12666944.html
这里也说UDP易出现乱序的问题,解决办法就是在数据段中加入数据报序号。拍自《Linux网络编程》第2版 宋敬彬 P284
要是每包数据都有报头+数据体,那个包头的结构的项就要更多一些。