关于UDP广播中如何提高可靠性

scutan

广播的内容是在变化，不过每次发送之间的时间间隔还是有的，足够让数据都发送完。

嗯，是的，接收端必须保证每一个包都不能丢失。（所以我感觉必须自己进行某种检验）

所以的机器都是已经开机了，在内部网中的。

scutan

原帖由 bobozhang 于 2008-8-22 20:29 发表
你要传送的电脑越多，你的数据量越大，用udp广播比起tcp越高效吧
当然麻烦的是你要自己实现重传机制如果数据包不可以丢失的话

嗯，点对点的UDP和重传倒还好办，不过一对多的方式感觉有点吃力。

H264

RTP ,RTCP.

bobozhang

rtp本来就不要求重传的吧，它主要用于视频音频，所以重传用出也不是很大

要实现重传的话，可能要客户端用某种方式定期向服务器报告它还在那里

scutan

先谢谢，不过这两个协议感觉太复杂了一点，RTP还在RCTP层之上。因为本身就是为了提高效率，所以如果有更简单一点的流量控制方面的方法就更好了。
Thanks again.

scutan

原帖由 system888net 于 2008-8-22 20:52 发表


那建议考虑这样:
  1. 发送方用广播的方式,而且包中有发送序号SNsend,并且打开一个UDP端口 Psr 进行接收反馈信号.
  2. 接收方在收到数据包后,向发送方的psr端口发送确认信号,确认信号里有SNsend和本机的 ...

嗯，谢谢。这是一个好方法，我觉得每次发送的数据包的大小应该小于UDP的SO_RCVBUF。是吧？
其实我觉得不用发送序号SNsend吧？因为是每一个包一次反馈。你觉得呢？

system888net

原帖由 scutan 于 2008-8-22 20:57 发表


嗯，谢谢。这是一个好方法，我觉得每次发送的数据包的大小应该小于UDP的SO_RCVBUF。是吧？
其实我觉得不用发送序号SNsend吧？因为是每一个包一次反馈。你觉得呢？

如果状态好,可以连续发送几个时,那么序号就有用了.

scutan

原帖由 system888net 于 2008-8-22 20:52 发表


那建议考虑这样:
  1. 发送方用广播的方式,而且包中有发送序号SNsend,并且打开一个UDP端口 Psr 进行接收反馈信号.
  2. 接收方在收到数据包后,向发送方的psr端口发送确认信号,确认信号里有SNsend和本机的 ...

谢谢，学习了。

shanehan

补充问一下:
广播的内容是在实时的变化吗?
还有接收端是要保证每一个包都不丢失?
或者说对后来(其它 ...
system888net 发表于 2008-08-22 20:25

    如果有后来开启的接受端，怎么办？