怎么确认收发双方接收到消息

发表于 2017-11-25 03:34

非常简单，接收方发送应答即可，不管哪里出问题只要发送方收不到应答就重发，重发3次就超时

发表于 2017-11-25 09:49

硬件仿真！

发表于 2017-11-25 10:15

你这是没有分主从机才出现这种问题的。一般以T为主机，主机就要保证数据的从机已经接受成功了，响应等待超时或响应错误则按失败处理。该怎么处理主机说的算，重发还是显示线路错误，或者是重发多少次不成功才显示线路或通讯错误等。

发表于 2017-11-25 11:17

果然好多人思路进入了死循环。
读书的时候学计算机网络的时候有个TCP握手的时候，有个著名的通信兵问题的题目：
背景：敌军占领了高地，我和你在高地的左右两侧，只有同时进攻才能赢，单独进攻你我就game over了。
题设：我派通信兵可以给你发信，但是通信兵会有概率被他们拦截杀了。你收到信也可以给我回信，但是你的通信兵也可能被敌人抓住杀了。敌人不会伪造信件。
题目：怎么样通讯才能确保你我约定一起进攻？

如果方法不对，你发几十次确认也不行。

发表于 2017-11-25 12:22

用标准的国际通讯协议，如MODBUS,TCP,都是可靠通讯机制的。

发表于 2017-11-25 12:27

linqing171 发表于 2017-11-25 11:17
果然好多人思路进入了死循环。
读书的时候学计算机网络的时候有个TCP握手的时候，有个著名的通信兵问题的题 ...

这样处理，只少有一个结果，不通还是通，通信兵被杀，只能说处于BROAD模式，这是客端有处理的问题，如在报文中自相关，如CRC ,

发表于 2017-11-25 12:31

一种是通信层的网络层的正确传输，如TCP,跟应用层响应无关，另一层是应用层的正确命令响应，如MODBUS TCP,后者包含前者更能反应通信正确状态。

发表于 2017-11-25 13:19

握手就行了，发方是主动行为，它什么时候发出去它自己清楚，然后收到接收方的回应，也就是说数据走了一个来回就说明双方的收发都验证通过了，这就可以确认成功了

发表于 2017-11-25 14:50

linqing171 发表于 2017-11-25 11:17
果然好多人思路进入了死循环。
读书的时候学计算机网络的时候有个TCP握手的时候，有个著名的通信兵问题的题 ...

那你们后来怎么解决的呢

发表于 2017-11-25 14:59

题目就是和24楼说的一样，怎么能一起进攻。说TCP协议或者modbus的我不太清楚

发表于 2017-11-25 16:44

主从结构通信，主机和从机用I2C通信，不就是么！

一个发射器：T
一个接收器：R
怎么让 T 发给 R 的消息，双方都确认成功呢？
如果T收到响应，T知道R收到了，但是R不知道T有没有收到响应啊？
然后T又发了一次通知R，“我已经收到了” ，然后可以进入下一步发送消息这里，改变SDA电平跳变。
但是，SDA电平跳变了，R识别到了SDA跳变，说明T收到了，R已经收到了之后，T也不知道到底R有没有收到它的通知，然后继续。。。。

新手发言，勿喷啊！其实我觉得就是一个标志位问题嘛！同过SDA来标志嘛
。。

发表于 2017-11-25 16:53

未央工程师发表于 2017-11-25 16:44
主从结构通信，主机和从机用I2C通信，不就是么！

一个发射器：T

也就是说，本来T,R通信是SDA处于高平时，才可以通信，在最后一次，R问T，“你收到了么？”，T收到之后，啪，拉低SDA，这样R一看，SDA拉低了，就知道T收到了！大家看看这样对么？

发表于 2017-11-25 17:49

ckc1119 发表于 2017-11-25 14:50
那你们后来怎么解决的呢

这是课本的题目啊.
1 把进攻时间商量在十天以后.
2 不停的发同一封信, 让友军收到后也不停的发同一封信
3 友军收到后, 就必须十天后进攻, 这时候压力已经在友军了. 友军需要不停的发同一封信.
4 收到友军的回信后就不用再发了,第十天开始进攻就可以了.
5 如果不放心, 你可以不停的再给友军发一个确认, 实际上已经没有必要了.

你的实际问题是不限制时间的, 这个题目里面多了个十天的有效性,所以先忽略十天这个时效性的问题.

发表于 2017-11-25 18:09

假如AB不同频，B回答A：“收到”的同时，A也说“收到”，这样双方都明白。

发表于 2017-11-26 08:58

当时读大三，专业选修课。
当时设计的A和B一起去进攻C。
A先给B发，可能丢了，也可能成功了。
如果B收到，给A回复，可能被拦截了，也可能丢了。这个时候B心里还是打鼓，会不会A没有收到？我自己去不就送死了？信立说一定要收到A的确认。
A如果收到B的信（第一封回信），给B回复。此时轮到A比较迷茫了，B会不会收不到我的信？会不会我自己先去送死了。
B收到了A的第二封信，和第一封一样的感觉... ....
然后死循环了。

不考虑tcp实际的包序号、CRC、FEC、BIP8 等等校验手段在高误码率情况下的可靠性，不考虑无限的时间，不考虑... ...
一旦思路进入了死胡同，在死胡同里死循环了，就无解了。

发表于 2017-11-26 11:52

这就是TCP协议干的事
研究多了烧脑子
自己玩玩UDP包测试测试就可以了

发表于 2017-11-26 18:58

发送一组数据再返回这组数据或这组数据的校验码

发表于 2017-11-26 19:17

握手加CRC校验

发表于 2017-11-27 09:46

可以加一个帧号，每成功发一次数据，帧号要加1。
这样当收到下一帧数据时，看看帧号对不对，如果帧号对的，则说明应答信号已经成功收到了。
否则，则说明应答信号没有成功收到，当前收到的数据是之前一帧的重发。
可以参考USB的握手协议，里面有一个标志，每发送一包数据都会切换一次（你可以理解成一个只有1bit的帧号）。

发表于 2017-11-27 10:11

LZ，两军问题是被证明无解的，只能通过设计确认机制尽量避免错误，但是无法完全保证。

怎么确认收发双方接收到消息

评论

评论

浏览过的版块

以坛为家

技术奇才奖章

甘甜之泉水

常驻人口

希望之星奖章

技术导师奖章

沉静之湖泊

无冕之王奖章

七世轮回

突出贡献奖章

精英会员奖章

湍急之河流

精华达人奖章

涓涓之细流

技术新星奖章

社区建设奖章

永恒之光奖章

坚毅之洋流

偶尔光临