技术比拼，udp的可靠传输！大家可以用udt或其他开源或自己的算法一起比较，包括飞鸽,该怎么解决
技术比拼，udp的可靠传输！大家可以用udt或其他开源或自己的算法一起比较，包括飞鸽
纯粹出于对技术的追求，希望有相同爱好的朋友，一起讨论切磋。
以前业余实现此算法，如今所在公司为流媒体公司，所以本算法有了更好的用武之地。
在原有基础上，增加了一些额外功能，比如，联接携带额外数据，及优先发送的命令数据报，支持流式，及包式传输，内置文件传输，支持断点续传。
为了让它更好，更适应现在中国各种网络环境，能充分有效的利用代宽，在考虑到，实时性，丢包率，cpu、内存占用，及代宽利用率的基础上研发出的此算法。
如果需要验证或交流的，可以与我联系，qq 24508609 msn wpllg@hotmail.com
当然热烈欢迎接分。
------解决方案--------------------
牛人
------解决方案--------------------
等你搞完了就是一个tcp了
------解决方案--------------------
很有意思。
------解决方案--------------------
看看，有无源码？
------解决方案--------------------
流媒体 有像pps一样的P2P系统吗
------解决方案--------------------
纯支持+纯接分
------解决方案--------------------
------解决方案--------------------
你能保证udp质量吗
------解决方案--------------------
真的 如果可以成功 你就等于多研发一种协议了
祝你成功
------解决方案--------------------
------解决方案--------------------
支持 不错
------解决方案--------------------
如果不作深入的了解初，初步的看法是：
做这项工作挺无聊或没有实用价值。 如果需要改变这种看法，请楼主给出相应的理由。
我的论据如下：
1. “世上没有万能药”，没有任何单一的方案能解决所有问题。也就是说，不存在某一个“算法”能适用于所有领域。每项算法都有适用和不适用的场合。
UDP, TCP, 共存内存(同一主机通讯）各有所长，也各有局限。
UDP适用于网络硬件资源很可靠和很富足的地方，比如局域网。
共存内存在同一台主机中不同进程之间通讯，肯定比socket强。
假设有一个算法a,实现了一个rudp，可以这样认为
当适用于udp的场合中，a比不上udp,
当适用tcp的场合中，a比不上tcp
2. 不存在“效率”都高的算法。
先得请教楼主“效率”指的是什么？
单一的吞吐量(throughtput)，单一的延迟(delay, latency)并不能反应出通讯性能的好坏。
吞吐量是否是越大越好？延迟是否为越小越好？
throughtput和latency往往是竞争的，此消彼长。
除了上述的指标外，延迟的抖动性(jitter) 也很重要。latency忽大忽小，也不是所期望的。
３. 结合2和1，在不同的时候选用不同的策略。
特定的应用有时想要低延迟和低抖动，比如命令和指挥系统；有时需要高吞吐量，比如大型数据备份。
有时应用程序不在乎丢掉几个包，比如游戏中角色位置的移动；有时应用程序需要很高的连接数，比如大型系统的用户管理服务；有时应用程序不要求长连接；等等。
------解决方案--------------------
新人接分
------解决方案--------------------
路过
------解决方案--------------------
如果没理解错的话就是
当某种条件下，“算法”变成 udp；
反之，
当另一种条件下，“算法”变成 tcp
如果是这样，做这样的事情就更没有价值了。
另外，“算法”由
1) 输入
2) 输出
3) 过程
组成。
给定一个输入，经过过程，得到确定的输出。
评价“算法”好坏是看Big O.
倘若“算法”还由“参数”来配置并影响结果，那所做的工作就超出了“算法”关注的范围了。
何不做一个框架呢？
如果这个框架做大了，不就成了中间件了吗？
====================
------解决方案--------------------
强人，继续比拼！
------解决方案--------------------
1、关于udp和tcp的使用场合问题，很多人都没注意这个问题，说明这不是问题
2、关于udp和tcp的各种效率问题，很多人都有自己的选择，说明这也不是问题
:)
------解决方案--------------------
关注
------解决方案--------------------
貌似 有点矛盾的话题～“UDP的可靠传输”是真命题么？ 怀疑并关注回帖
------解决方案--------------------
楼主要开源，就把源码上传到****吧，给个链接。
否则，本贴要移往非技术区。谢谢。
------解决方案--------------------
很好
------解决方案--------------------
还是帮顶下吧
------解决方案--------------------
------解决方案--------------------
纯支持+纯接分
------解决方案--------------------
支持，接分，学技术
------解决方案--------------------
支持+接分
------解决方案--------------------
Mark
------解决方案--------------------
jf
------解决方案--------------------
mark
------解决方案--------------------
个人感觉tcp就udp的安全模式.看你说的意思,有点像是给tcp 减肥.如果成功的话,希望能在发个通知.期待中.....
------解决方案--------------------
我现倒是有一个 还没有研究明白 明白了再来讨论
------解决方案--------------------
up
------解决方案--------------------
和我的UT比较下吧（类似BT协议的UDP版本改造，因为涉及到数据交互，因此比单纯的单向传输稍微要慢点
毕竟是PNP方式传输，但是在网络质量够好的10M LAN情况下，可以达到900KB-1MB/S ）
我的FtpAnywhere里携带了UT SDK包
此外还有一个TUDP协议，单纯的可靠UDP传输，可以达到TCP的效率，也包括在FAW中了
------解决方案--------------------
接分和顶。
另外，流媒体对实时性要求高，但能容忍一定程度丢包率，这看这些媒体采用什么编码。可靠UDP会比TCP快一些。
------解决方案--------------------
不错
------解决方案--------------------
jf
------解决方案--------------------
用UDP模拟tcp，好
------解决方案--------------------
过来学习一下。
------解决方案--------------------
UP
------解决方案--------------------
up
------解决方案--------------------
关注牛人讨论...
------解决方案--------------------
自主协议……
------解决方案--------------------
jf
------解决方案--------------------
没源码搞个屁啊，大伙不如去上sourceforge
------解决方案--------------------
没有源码只好纯接分+支持了
------解决方案--------------------
没有源码只好也纯接分+支持了
------解决方案--------------------
udt协议在某些流媒体和游戏中 用起来应该是比较好的。
推荐LZ看下Raknet，Raknet已经在udp的基础上实现了丢包重传、简单的流量控制、保活等功能，不过整体上做的还比较粗糙（当然是跟比较好的代码比较），据说作者已经在重新开发新的版本。
流媒体中的重传好像已经有协议规定了的，并且如果数据源是组播的，基于传输层的协议是没有办法解决的，只能采用冗余编码。
------解决方案--------------------
------解决方案--------------------
------解决方案--------------------
RUDP是有价值的。
在P2P网络中，在无线网络的优化中，都需要。
不过，在多媒体数据中也可以使用前向纠错等冗余技术，保证实时性和正确性。
------解决方案--------------------
看到这个结构
struct IUdxCfg
{
BOOL bPI; //for diff，动态计整阀值因子
double dbpi;
BOOL bCareLost; //带宽抢占的一个因子
BOOL bLimitSpeed; //事限制上传速度
DWORD limitspeed; //具体的限速
BOOL bSpeedThreshold;//是否临界速度
DWORD thresholdspeed;//我们比较关心的阀值 ，比如500kbps，当超过这个值 的时候，我们不必去争夺带宽
double dbLostRat;
};
我即使有兴趣也没兴趣了
还是应该多看点基础性的代码,练好基本功
这东西我自己实现了2个了，并没有什么高深的理论或者算法，直接模拟TCP算法，在时间调度上改正下就可以,没必要多耗费时间
纯粹出于对技术的追求，希望有相同爱好的朋友，一起讨论切磋。
以前业余实现此算法，如今所在公司为流媒体公司，所以本算法有了更好的用武之地。
在原有基础上，增加了一些额外功能，比如，联接携带额外数据，及优先发送的命令数据报，支持流式，及包式传输，内置文件传输，支持断点续传。
为了让它更好，更适应现在中国各种网络环境，能充分有效的利用代宽，在考虑到，实时性，丢包率，cpu、内存占用，及代宽利用率的基础上研发出的此算法。
如果需要验证或交流的，可以与我联系，qq 24508609 msn wpllg@hotmail.com
当然热烈欢迎接分。
------解决方案--------------------
牛人
------解决方案--------------------
等你搞完了就是一个tcp了
------解决方案--------------------
很有意思。
------解决方案--------------------
看看，有无源码？
------解决方案--------------------
流媒体 有像pps一样的P2P系统吗
------解决方案--------------------
纯支持+纯接分
------解决方案--------------------
------解决方案--------------------
你能保证udp质量吗
------解决方案--------------------
真的 如果可以成功 你就等于多研发一种协议了
祝你成功
------解决方案--------------------
------解决方案--------------------
支持 不错
------解决方案--------------------
如果不作深入的了解初，初步的看法是：
做这项工作挺无聊或没有实用价值。 如果需要改变这种看法，请楼主给出相应的理由。
我的论据如下：
1. “世上没有万能药”，没有任何单一的方案能解决所有问题。也就是说，不存在某一个“算法”能适用于所有领域。每项算法都有适用和不适用的场合。
UDP, TCP, 共存内存(同一主机通讯）各有所长，也各有局限。
UDP适用于网络硬件资源很可靠和很富足的地方，比如局域网。
共存内存在同一台主机中不同进程之间通讯，肯定比socket强。
假设有一个算法a,实现了一个rudp，可以这样认为
当适用于udp的场合中，a比不上udp,
当适用tcp的场合中，a比不上tcp
2. 不存在“效率”都高的算法。
先得请教楼主“效率”指的是什么？
单一的吞吐量(throughtput)，单一的延迟(delay, latency)并不能反应出通讯性能的好坏。
吞吐量是否是越大越好？延迟是否为越小越好？
throughtput和latency往往是竞争的，此消彼长。
除了上述的指标外，延迟的抖动性(jitter) 也很重要。latency忽大忽小，也不是所期望的。
３. 结合2和1，在不同的时候选用不同的策略。
特定的应用有时想要低延迟和低抖动，比如命令和指挥系统；有时需要高吞吐量，比如大型数据备份。
有时应用程序不在乎丢掉几个包，比如游戏中角色位置的移动；有时应用程序需要很高的连接数，比如大型系统的用户管理服务；有时应用程序不要求长连接；等等。
------解决方案--------------------
新人接分
------解决方案--------------------
路过
------解决方案--------------------
如果没理解错的话就是
当某种条件下，“算法”变成 udp；
反之，
当另一种条件下，“算法”变成 tcp
如果是这样，做这样的事情就更没有价值了。
另外，“算法”由
1) 输入
2) 输出
3) 过程
组成。
给定一个输入，经过过程，得到确定的输出。
评价“算法”好坏是看Big O.
倘若“算法”还由“参数”来配置并影响结果，那所做的工作就超出了“算法”关注的范围了。
何不做一个框架呢？
如果这个框架做大了，不就成了中间件了吗？
====================
------解决方案--------------------
强人，继续比拼！
------解决方案--------------------
1、关于udp和tcp的使用场合问题，很多人都没注意这个问题，说明这不是问题
2、关于udp和tcp的各种效率问题，很多人都有自己的选择，说明这也不是问题
:)
------解决方案--------------------
关注
------解决方案--------------------
貌似 有点矛盾的话题～“UDP的可靠传输”是真命题么？ 怀疑并关注回帖
------解决方案--------------------
楼主要开源，就把源码上传到****吧，给个链接。
否则，本贴要移往非技术区。谢谢。
------解决方案--------------------
很好
------解决方案--------------------
还是帮顶下吧
------解决方案--------------------
------解决方案--------------------
纯支持+纯接分
------解决方案--------------------
支持，接分，学技术
------解决方案--------------------
支持+接分
------解决方案--------------------
Mark
------解决方案--------------------
jf
------解决方案--------------------
mark
------解决方案--------------------
个人感觉tcp就udp的安全模式.看你说的意思,有点像是给tcp 减肥.如果成功的话,希望能在发个通知.期待中.....
------解决方案--------------------
我现倒是有一个 还没有研究明白 明白了再来讨论
------解决方案--------------------
up
------解决方案--------------------
和我的UT比较下吧（类似BT协议的UDP版本改造，因为涉及到数据交互，因此比单纯的单向传输稍微要慢点
毕竟是PNP方式传输，但是在网络质量够好的10M LAN情况下，可以达到900KB-1MB/S ）
我的FtpAnywhere里携带了UT SDK包
此外还有一个TUDP协议，单纯的可靠UDP传输，可以达到TCP的效率，也包括在FAW中了
------解决方案--------------------
接分和顶。
另外，流媒体对实时性要求高，但能容忍一定程度丢包率，这看这些媒体采用什么编码。可靠UDP会比TCP快一些。
------解决方案--------------------
不错
------解决方案--------------------
jf
------解决方案--------------------
用UDP模拟tcp，好
------解决方案--------------------
过来学习一下。
------解决方案--------------------
UP
------解决方案--------------------
up
------解决方案--------------------
关注牛人讨论...
------解决方案--------------------
自主协议……
------解决方案--------------------
jf
------解决方案--------------------
没源码搞个屁啊，大伙不如去上sourceforge
------解决方案--------------------
没有源码只好纯接分+支持了
------解决方案--------------------
没有源码只好也纯接分+支持了
------解决方案--------------------
udt协议在某些流媒体和游戏中 用起来应该是比较好的。
推荐LZ看下Raknet，Raknet已经在udp的基础上实现了丢包重传、简单的流量控制、保活等功能，不过整体上做的还比较粗糙（当然是跟比较好的代码比较），据说作者已经在重新开发新的版本。
流媒体中的重传好像已经有协议规定了的，并且如果数据源是组播的，基于传输层的协议是没有办法解决的，只能采用冗余编码。
------解决方案--------------------
------解决方案--------------------
------解决方案--------------------
RUDP是有价值的。
在P2P网络中，在无线网络的优化中，都需要。
不过，在多媒体数据中也可以使用前向纠错等冗余技术，保证实时性和正确性。
------解决方案--------------------
看到这个结构
struct IUdxCfg
{
BOOL bPI; //for diff，动态计整阀值因子
double dbpi;
BOOL bCareLost; //带宽抢占的一个因子
BOOL bLimitSpeed; //事限制上传速度
DWORD limitspeed; //具体的限速
BOOL bSpeedThreshold;//是否临界速度
DWORD thresholdspeed;//我们比较关心的阀值 ，比如500kbps，当超过这个值 的时候，我们不必去争夺带宽
double dbLostRat;
};
我即使有兴趣也没兴趣了
还是应该多看点基础性的代码,练好基本功
这东西我自己实现了2个了，并没有什么高深的理论或者算法，直接模拟TCP算法，在时间调度上改正下就可以,没必要多耗费时间