关于对udp的可靠连接处理问题? 本帖最后由 VisualEleven 于 2012-06-18 18:04:49 编辑 解决方案 » 免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货 正常的话关键帧一般是用TCP，而且一定要有重传机制，比如收到包就给应答，如果发送方没有收到应答包，就当做是丢发处理，进行包重传，用UDP也是这样。最好是每个包有个包序号，这样比较好确认 我也知道可靠就用tcp啊 但是没看到前面的前提么 老话，改用UDX协议，也是一种类是UDT的协议。在传输视频方面还是非常不错的，我这里有UDX传输视频的例子。UDX协议是目前国内可数的几个比较优秀的UDP可靠传输协议之一。 能不能传一份代码给我 ，邮箱[email protected] udp也可以调用connect函数，不向对方发送建立连接的请求，只是指定目标方的ip地址和端口号. 正常。UDP不可靠的特性就在这里。有时网络很好，和TCP差不多，有时不好就麻烦一些。 你不用算次数的, 应该按时长, 只要是在允许尝试的时间内的, 就不断尝试就可以了, 初始时是会很慢的, 就像TCP的connect一样, 建立了连接之后, 就会快的了. UDP其实也有连接的, 就是在每层路由上开启的一个暂时性的端口, 但在最初还没有建立的时候, 很多个包都没回应是正常的. 同求例子啊！！！[email protected] 你可以自己实现一个UDP可靠传输协议，但是里里面加入不可靠传输我自己写的PHOENIX库就是这个设计实现，一个协议里可以支持可靠UDP传输，也可以支持不可靠UDP传输其实原理很简单可靠UDP，你肯定需要加序列号，校验来实现传输例如包头格式struct T_commonUdp{ unsigned char u_maxtrib[2];//报头识别 unsigned __int16 u_serial;//包序列号 ......//你自己定义的其他东西}假设 你定义的可靠包报头识别代码是 u_maxtrib[0]=0XE1 u_maxtrib[1]=0XC5那么你可以定义不可靠传输包的报头是 u_maxtrib[1]=0XC6这样当接到0XC6头的包，就不需要ACK一个确认，丢了也没关系,发送方直接SEND就可以接收方同样是直接处理在UDP包中封装可靠传输和不可靠传输，在现在的P2P编程中已经非常常见不过，一般视频流播放，采用的还是可靠传输，因为通常是流方式传输，而不是采用桢方式传输只有在视频直播方面，才有选择采用不可靠传输，因为采集的时候用的是桢，具备了不可靠传输的基础帧方式的不可靠传输，对节目源头的CPU和内存压力非常巨大，建议谨慎选择UVOD2是我用MFC封的一个P2P流播放程序[管道调用mplayer播放]，你可以参考一下这里面的P2P采用的是UT2 1对多可靠传输http://www.phoenixp2p.com/cn/download.htm 现在的情况是 服务器采集视频的时候 设置的是每隔2-3秒左右一个I帧 ，我这边有流量控制，就是宽带很差的时候 ，服务器只会传输I帧和少量的P帧 ，但是如果I帧丢一个包 就会导致后面的P帧没有作用，客户端接受的时候 也会无法解码，这样客户端显示的时候 就会出现4-6秒一个I帧画面 ， 这个情况正常么 。 测试宽带大概是2M-3M ，（这里设置了8路，也就是同时开启8个画面。如果熟悉视频监控的话 应该可以理解 ）一个I帧大概有30K- 40K，其实我也不满意 ，用的jrtplib库 ，但是好像没办法改进了 ，如果改进的话 好像把整个项目推倒从来 JRTPLIB不适合传输这个。特别是在公网上，可联系我，用UDX协议试试。多个监控公司都已经采用，在海思系列主板上也有应用。 看到jrtplib,我觉得楼主对UDP的应用理解有问题了，在这个场合，你的应用是典型的C/S框架，不是P2P，你目前的思路是用自己开发的UDP协议代替JRTPLIB的网络部分，这个是对的，但你这个是典型的C/S结构，无关P2P，至于防火墙方面，你完全可以参考FTP的主动和被动模式，只要有任何一方是公网，就可以连接，而你的项目完全具备这个条件。JRTPLIB的网络部分只能达到民用级，达不到商用级。你需要写自己的协议，分TCP和UDP两个连接处理逻辑是：while{ 采集 [这部分建议采用独立线程 加缓冲队列 要有丢的打算 可以参考CISCO路由对满负载的处理] 获取I桢 使用TCP连接传输 I 帧 iresult=send(...) 完成，记录clock_t 完成时间 计算剩余的TICK，例如TCP传输可能花 100ms , 也可能花了 50000ms 当clock_t 传输TICK超过你规定的每N秒一帧 ，那么放弃剩下的P帧传输 否则 for(i=0;i<p帧数量;i++) { 使用非阻塞UDP 发送 iresult=sendto(....) if(iresult!=....) { } //计算是否超时 也就是剩余的clock_t }}也就是，首先必须确保关键帧被传输，如果关键帧传输花费太多时间，那么直接放弃后面的P帧传输，这个关键就在于，次序不能错，也就是，不可以在I帧传输完成前，就同步发送P帧，这个会影响传输，反正P可以丢弃，所以用剩下的时间来发送P帧，不发送直接丢弃也没关系我见过16路视频通讯，用的就是这个技术，不过中间加了流压缩，其他一样，你这个才8路，而且视频帧不大，带宽也不错，应该比较容易实现,当然如果是网通--电信跨ISP商传输，只有上帝能帮你了 客户端和服务器都不是公网，比如客户在家里装了视频监控，服务器采集画面，然后客户在外地出差的时候 也想看到家里的画面 ，所以还是要P2P的吧 ，当初项目选择的时候，遗留下来的就是jrtplib库，如果一切从来就很麻烦了 现在基本上只是要保证I帧不丢包 但是前期已经采用了UDP了 P2P成功后，就应该采用可靠传输了，你先前使用UDT也为尝不是一种方案。 UDP穿透能力是比TCP好，但是这个前提是有一个公网的第三方中介存在，并不是说2个都在内网的点 [假设双方路由不支持UPNP自动映射到公网]，通过UDP就能打通一个连接，这个连接在P2P网络里，是通过P2P服务器进行握手打通的,但是对非透明网关，这种方式也是彻底无用，我很好奇，你如何可靠的实现双方都没有直接或者间接映射到公网端口实现连接和传输？jrtplib完全可以保留，要重写的只是jrtplib网络传输部分，工程量不大，这是很常见的改造，我估计你在开源站可以找到完整的替代实现。另一个方式就是采用UDT，在它里面添加你自己的不可靠包定义和读写过滤操作，这个代码量也不大。 已经实现了P2P了 有个p2p服务器放在公网上 我现在在改造jrtplib 联系我吧，QQ 24508609.一起讨论，CSDN上太慢了。 -------SVN出问题了------- vs08找不到达add windows message handler vc 删除ftp上文件夹 window上经常用到的一种列表，怎么实现，急急急！！ 32位浮点数怎么转换为十进制的数？ mempy函数怎么用？ 滑动窗口编程 请问用什么工具可以得到一个dll文件中的函数和参数（vc) 为啥测试结果 string 比 CString 快好多？？？ 关于线程内核对象句柄的简单问题 高手求救!!!!!! 问一个很菜的问题，高手莫笑 请问C语言如何操作远程服务器上的access数据库？
同求例子啊！！！
[email protected]
我自己写的PHOENIX库就是这个设计实现，一个协议里可以支持可靠UDP传输，也可以支持不可靠UDP传输其实原理很简单
可靠UDP，你肯定需要加序列号，校验来实现传输
例如包头格式
struct T_commonUdp
{
unsigned char u_maxtrib[2];//报头识别
unsigned __int16 u_serial;//包序列号
......//你自己定义的其他东西
}
假设 你定义的可靠包报头识别代码是 u_maxtrib[0]=0XE1 u_maxtrib[1]=0XC5
那么你可以定义不可靠传输包的报头是 u_maxtrib[1]=0XC6
这样
当接到0XC6头的包，就不需要ACK一个确认，丢了也没关系,发送方直接SEND就可以
接收方同样是直接处理在UDP包中封装可靠传输和不可靠传输，在现在的P2P编程中已经非常常见
不过，一般视频流播放，采用的还是可靠传输，因为通常是流方式传输，而不是采用桢方式传输
只有在视频直播方面，才有选择采用不可靠传输，因为采集的时候用的是桢，具备了不可靠传输的基础
帧方式的不可靠传输，对节目源头的CPU和内存压力非常巨大，建议谨慎选择UVOD2是我用MFC封的一个P2P流播放程序[管道调用mplayer播放]，你可以参考一下
这里面的P2P采用的是UT2 1对多可靠传输
http://www.phoenixp2p.com/cn/download.htm
处理逻辑是：
while
{
采集 [这部分建议采用独立线程 加缓冲队列 要有丢的打算 可以参考CISCO路由对满负载的处理]
获取I桢
使用TCP连接传输 I 帧
iresult=send(...)
完成，记录clock_t 完成时间
计算剩余的TICK，例如TCP传输可能花 100ms , 也可能花了 50000ms
当clock_t 传输TICK超过你规定的每N秒一帧 ，那么放弃剩下的P帧传输
否则
for(i=0;i<p帧数量;i++)
{
使用非阻塞UDP 发送
iresult=sendto(....)
if(iresult!=....)
{
}
//计算是否超时 也就是剩余的clock_t
}}也就是，首先必须确保关键帧被传输，如果关键帧传输花费太多时间，那么直接放弃后面的P帧传输，这个关键就在于，次序不能错，也就是，不可以在I帧传输完成前，就同步发送P帧，这个会影响传输，反正P可以丢弃，所以用剩下的时间来发送P帧，不发送直接丢弃也没关系我见过16路视频通讯，用的就是这个技术，不过中间加了流压缩，其他一样，你这个才8路，而且视频帧不大，带宽也不错，应该比较容易实现,当然如果是网通--电信跨ISP商传输，只有上帝能帮你了
UDP穿透能力是比TCP好，但是这个前提是有一个公网的第三方中介存在，并不是说2个都在内网的点 [假设双方路由不支持UPNP自动映射到公网]，通过UDP就能打通一个连接，这个连接在P2P网络里，是通过P2P服务器进行握手打通的,但是对非透明网关，这种方式也是彻底无用，我很好奇，你如何可靠的实现双方都没有直接或者间接映射到公网端口实现连接和传输？
jrtplib完全可以保留，要重写的只是jrtplib网络传输部分，工程量不大，这是很常见的改造，我估计你在开源站可以找到完整的替代实现。另一个方式就是采用UDT，在它里面添加你自己的不可靠包定义和读写过滤操作，这个代码量也不大。