|
|
|
|
  无差错的传输，到底用tcp还是udp？ - whone23 [ 2005-01-24 10:27 | 621 byte(s)]
Re: 无差错的传输，到底用tcp还是udp？ - hoyt [ 2005-01-25 08:32 | 134 byte(s)]
Re: 无差错的传输，到底用tcp还是udp？ - whone23 [ 2005-01-25 08:38 | 197 byte(s)]
Re: 无差错的传输，到底用tcp还是udp？ - mechgouki [ 2005-01-24 11:24 | 114 byte(s)]
Re: 无差错的传输，到底用tcp还是udp？ - whone23 [ 2005-01-24 11:33 | 292 byte(s)]
Re: 无差错的传输，到底用tcp还是udp？ - alula [ 2005-01-25 14:44 | 184 byte(s)]
Re: 无差错的传输，到底用tcp还是udp？ - whone23 [ 2005-01-25 20:00 | 70 byte(s)]
Re: 无差错的传输，到底用tcp还是udp？ - alula [ 2005-01-26 15:58 | 57 byte(s)]
Re: 无差错的传输，到底用tcp还是udp？ - suowei1979 [ 2005-01-26 17:59 | 69 byte(s)]
Re: 无差错的传输，到底用tcp还是udp？ - gxcooo [ 2005-01-26 10:45 | 489 byte(s)]
Re: 无差错的传输，到底用tcp还是udp？ - whone23 [ 2005-01-26 11:16 | 176 byte(s)]
Re: 无差错的传输，到底用tcp还是udp？ - zzzz [ 2005-01-25 10:03 | 80 byte(s)]
Re: 无差错的传输，到底用tcp还是udp？ - whone23 [ 2005-01-25 11:04 | 126 byte(s)]
Re: 无差错的传输，到底用tcp还是udp？ - zzzz [ 2005-01-25 14:24 | 74 byte(s)]
Re: 无差错的传输，到底用tcp还是udp？ - dl_dht [ 2005-01-25 12:58 | 597 byte(s)]
Re: 无差错的传输，到底用tcp还是udp？ - whone23 [ 2005-01-25 13:59 | 585 byte(s)]
|
|
|
|
[Original]
[Print]
[Top]
|
简单的说就是保证传送数据万无一失的过程。
理论上说tcp比较合适了，是一个面对连接的过程。但是我不太清楚一旦将数据包write到协议栈后，如果对方没有收到，我能不能得到没有收到的状况，我如果知道对方没有收到，我会重新发送，一直到成功为止，或者等到网络恢复，再从刚才没有发送的地方开始重发。
还有一个方法就是在udp上用简单的停等协议了，发一个包，等回应或者超时，没有收到回应或者超时就重新发，这样控制起来比较简单，但是效率很低了。
当然我指的都是在传输层（TCP/UDP）来做到了，对于上层是透明的。我没有看过ftp的代码，但是我估计ftp保证文件无差错的传输是借助了在应用层的一些控制。
|
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
但是我现在还不确信，我是否能知道TCP发送数据包的状态。
比方说：write一个包到了协议栈的缓冲区，这时候网络断了，包就停在协议栈的缓冲区内，没有发出去，而发送包的程序在数据包转到协议栈的缓冲区的时候就正常返回准备发下一个了。在没有应用层检查的情况下，这个包是不是就没法找回来了？
|
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
如果不作处理当然不可能万无一失。所以要加控制嘛。
tcp协议实现了这些，但是在应用程序中无法准确获得一个包的状态（是否到达目的地），所以正如你说的要自己控制了，停等协议了，复杂点滑动窗口了....
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
>> 动态计算超时 ?
那么如果两次测量的RTT差别较大, 你怎么处理 ? TCP 的RTO估计器是比较复杂的. 如果你的超时重传估计过低那么将导致过多的重复分组, 过高使传输效率下降.
如果传输时分组到达顺序不同, 如何处理 ? 如果网络发生拥塞如何处理 ?
我认为如果要可靠传输文件一定要用TCP, 除非使用组播, TCP协议栈会为你作一切, 在实践中, 使用网络的传输文件都是应用TCP, ftp, http, ssh, rsync, wget...
写入协议栈的数据不能发送出去, 只能说明网络有问题, 对方没有接收缓冲区, 这种情况在UDP中也会出现, 而且TCP这时会block在内核, 而使用UDP则不会block.
|
|
|
----
鸡声茅店月, 人迹板桥霜.
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
unpv1上有个简单的增加udp传输可靠性的例子，就在那个基础上改了。
效率肯定没法和tcp相比，但是现在的要求是要保证每个包都到达目的，没有到达要记住，等着下次从那个位置开始继续发，用udp加一点简单的控制（停等协议），可以做到。
》写入协议栈的数据不能发送出去, 只能说明网络有问题, 对方没有接收缓冲区, 这种情况在UDP中也会出现, 而且TCP这时会block在内核, 而使用UDP则不会block.
block在协议栈的缓冲区中，发送程序没法知道啊，那这个包不是掉了。还有一种情况，发送程序所在计算机的IP变化了，原来建立的连接无效，又要建立新的，在接收程序里比较难办吧。
|
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
whone23说的是对的
tcp可能会丢失数据，但丢失数据肯定会导致连接出错，最后导致断开，这个程序是可以知道的。
假设我们发送100M给对端，如果我们已经发送到第99M了tcp没有出错，那我们可以确定（98M-tcp内部此socket发送缓存中的有效数据-对方机器上的tcp内部的socket接收缓存中有效数据)对方应用程序已经收到.但实际上我们是无法知道对方的socket在tcp内部的缓存是多大，所以我们也就无法确切知道对方应用程序收到了多少数据，只能估计个大概
而udp是不可以这样的
|
|
|
----
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
其实ftp实现的挺好的，把ftp那一套实现代码搬来传输的那部分，估计也可以，而且效率高。
udp要提高效率实际上也是要实现那些滑动窗口啊，动态调整rto等等，也很麻烦的。
|
|
[Original]
[Print]
[Top]
|
|
|
声明: 本页内容为中国Linux论坛的内容镜像，文章的版权以及其他所有的相关权利属于中国Linux论坛和相应文章的作者，如果转载，请注明文章来源及相关版权信息。