依据项目请求，上位机软件依然保存，咱们使用协定嗅探工具对于上位机发送的报文入行了嗅探，患上到了上位机报文的结构如表一所示。
表一 上位机报文结构
上位机发出的每一条报文由三二个字节组成，第0位为版本信息。第一……一二位为竞赛信息以及运动员教练信息，是报文的关键信息部门，一三……二二位为服务器端以及客户端的IP地址及端口号信息，二三位是上位机对于客户端的操纵指令代码，二四位是相干重发机制的代码，三0以及三一两位是CheckSum，用来保证数据传输的准确。上位机采取的重发机制是1种上位机依照固定重发次数多次发送统1关键内容报文的机制，其第二四位重发机制位被分为高四位以及低四位两部门，高4位的内容是当前发送的报文的索引号，每一次发送1条新内容的报文时索引号自增一，索引号的取值规模在0x00—0xFF规模内轮归自增。低4位是重发编号，表示统1索引号的报文正在被第几归重发，固定的重发次数由上位机初始化时设定。
四.三 嵌进式客户端的试验程序设计
针对于报文结构，咱们对于接管端编写试验程序代码，代码的主要功能是从上位机接管报文，将计算出的CheckSum校验以及与收到的校验以及对于比断定报文是否是准确，然后从准确报文中取出主要信息并依照报文中的上位机指令码入行输出。其结构流程图如图三所示。
试验程序经编码、调试后在交叉编译环境中交叉编译，天生arm-Linux环境下可履行文件，在目标板上履行。经测尝尝验程序能够准确接管上位机发来的报文，对于报文解码，并能依据上位机命令对于关键信息做输出处理。
四.四 对于上位机重发次数的钻研
入行UDP协定通信时，发送端以及接管端的状况是相对于于独立的，发送端不与接管端树立连接，而是不停向接管端发送，为了确保不丢失报文，上位机采纳了按固定次数重发相同内容报文的机制。但是这类机制当然可以有效确保报文不丢失，然而大量冗余数据报被发送，网络资源运用率不高。重发次数越多，冗余数据报越多，效率越低。要想有效保证数据报正确发送的同时又不发生过量冗余数据报，那么重复发送的次数的肯定就成为题目的关键。下列给出1种肯定上位机重发次数的法子。
假定当前网络状态下，每一次报文发送被丢失的概率为p，系统答应接管端报文关键内容丢失概率为q,那么如何肯定以上重发机制中的重发次数k呢？
特殊情况下若报文重发次数为二，分别在每一条报文重发机制位注明1个索引号以及1个重发编号，发送端发送报文的秩序序应形如 一.一 ,一.二 ,二.一 ,二.二 ,三.一 ,三.二……其中索引号相同的报文关键内容相同，重发编号不同代表统1关键内容报文的不同次发送。于是只有出现连续两次丢失数据报的情况下，报文关键内容才可能丢失。出现连续两次丢失的情况有二种，当x.一 , x.二丢失，此时索引号为x的报文关键信息将全体丢失。当x.二,(x+一). 一丢失，丢失报文的索引号不同，此时不会产生报文关键信息丢失，于是报文关键内容丢失的概率q=p二/二。
当报文重发次数为三,依然在每一条报文的重发机制位注明索引号以及重发号，发送报文的秩序序应为一.一 ,一.二 ,一.三 ,二.一 ,二.二 ,二.三 ,三.一 ,三.二……。只有出现连续三次丢失数据报的情况报文关键信息才可能丢失，列出连续三次丢失报文的情况有三种，当x.一 , x.二 , x.三丢失，此时索引号为x的报文信息全体丢失。当x.二 , x.三 ,(x+一).一或者x.三 ,(x+一).一 ,(x+一).二丢失机不影响报文的正确传递。于是此时报文关键内容丢失的概率q=p三/三。
推行至1般情况易得上当报文重发次数为k时，报文关键内容丢失的概率q=pk/k，移项有kq=pk。因而咱们患上到求重发次数k的法子
一) 依据网络状态获取报文丢失概率p；
二) 依据客户需求取患上报文关键内容的答应丢失率规模q；