UDT协议实现分析——UDT数据收发的可靠性保障

不管是数据的发送还是数据的接收,大体的流程我们基本上是都理了一下,还分析了数据收发过程中用的数据结构,接下来就看一些UDT中数据收发更精细的一些控制。

UDT数据收发的可靠性保障

来看一下UDT中数据收发的可靠性保障。

接收包丢失列表CRcvLossList

先来看一下CRcvLossList的定义:

1class CRcvLossList { 2 public: 3 CRcvLossList(int size = 1024); 4 ~CRcvLossList(); 5 6 // Functionality: 7 // Insert a series of loss seq. no. between "seqno1" and "seqno2" into the receiver's loss list. 8 // Parameters: 9 // 0) [in] seqno1: sequence number starts. 10 // 1) [in] seqno2: seqeunce number ends. 11 // Returned value: 12 // None. 13 void insert(int32_t seqno1, int32_t seqno2); 14 15 // Functionality: 16 // Remove a loss seq. no. from the receiver's loss list. 17 // Parameters: 18 // 0) [in] seqno: sequence number. 19 // Returned value: 20 // if the packet is removed (true) or no such lost packet is found (false). 21 bool remove(int32_t seqno); 22 23 // Functionality: 24 // Remove all packets between seqno1 and seqno2. 25 // Parameters: 26 // 0) [in] seqno1: start sequence number. 27 // 1) [in] seqno2: end sequence number. 28 // Returned value: 29 // if the packet is removed (true) or no such lost packet is found (false). 30 bool remove(int32_t seqno1, int32_t seqno2); 31 32 // Functionality: 33 // Find if there is any lost packets whose sequence number falling seqno1 and seqno2. 34 // Parameters: 35 // 0) [in] seqno1: start sequence number. 36 // 1) [in] seqno2: end sequence number. 37 // Returned value: 38 // True if found; otherwise false. 39 bool find(int32_t seqno1, int32_t seqno2) const; 40 41 // Functionality: 42 // Read the loss length. 43 // Parameters: 44 // None. 45 // Returned value: 46 // the length of the list. 47 int getLossLength() const; 48 49 // Functionality: 50 // Read the first (smallest) seq. no. in the list. 51 // Parameters: 52 // None. 53 // Returned value: 54 // the sequence number or -1 if the list is empty. 55 int getFirstLostSeq() const; 56 57 // Functionality: 58 // Get a encoded loss array for NAK report. 59 // Parameters: 60 // 0) [out] array: the result list of seq. no. to be included in NAK. 61 // 1) [out] physical length of the result array. 62 // 2) [in] limit: maximum length of the array. 63 // Returned value: 64 // None. 65 void getLossArray(int32_t* array, int& len, int limit); 66 67 private: 68 int32_t* m_piData1; // sequence number starts 69 int32_t* m_piData2; // sequence number ends 70 int* m_piNext; // next node in the list 71 int* m_piPrior; // prior node in the list; 72 73 int m_iHead; // first node in the list 74 int m_iTail; // last node in the list; 75 int m_iLength; // loss length 76 int m_iSize; // size of the static array 77 78 private: 79 CRcvLossList(const CRcvLossList&); 80 CRcvLossList& operator=(const CRcvLossList&); 81};

这个容器的定义,看起来与CSndLossList还是蛮相似的。

构造和析构

但这个数据结构更具体的内容则还是需要通过成员函数的定义来厘清。先来看构造函数和析构函数(src/list.cpp):

1CRcvLossList::CRcvLossList(int size) 2 : m_piData1(NULL), 3 m_piData2(NULL), 4 m_piNext(NULL), 5 m_piPrior(NULL), 6 m_iHead(-1), 7 m_iTail(-1), 8 m_iLength(0), 9 m_iSize(size) { 10 m_piData1 = new int32_t[m_iSize]; 11 m_piData2 = new int32_t[m_iSize]; 12 m_piNext = new int[m_iSize]; 13 m_piPrior = new int[m_iSize]; 14 15 // -1 means there is no data in the node 16 for (int i = 0; i < size; ++i) { 17 m_piData1[i] = -1; 18 m_piData2[i] = -1; 19 } 20} 21 22CRcvLossList::~CRcvLossList() { 23 delete[] m_piData1; 24 delete[] m_piData2; 25 delete[] m_piNext; 26 delete[] m_piPrior; 27}

构造函数和析构函数主要还是在分配内存与释放内存,仍然没有办法将这个数据结构看的太清晰。

插入元素insert

接着来看CRcvLossList::insert():

1void CRcvLossList::insert(int32_t seqno1, int32_t seqno2) { 2 // Data to be inserted must be larger than all those in the list 3 // guaranteed by the UDT receiver 4 5 if (0 == m_iLength) { 6 // insert data into an empty list 7 m_iHead = 0; 8 m_iTail = 0; 9 m_piData1[m_iHead] = seqno1; 10 if (seqno2 != seqno1) 11 m_piData2[m_iHead] = seqno2; 12 13 m_piNext[m_iHead] = -1; 14 m_piPrior[m_iHead] = -1; 15 m_iLength += CSeqNo::seqlen(seqno1, seqno2); 16 17 return; 18 } 19 20 // otherwise searching for the position where the node should be 21 int offset = CSeqNo::seqoff(m_piData1[m_iHead], seqno1); 22 int loc = (m_iHead + offset) % m_iSize; 23 24 if ((-1 != m_piData2[m_iTail]) && (CSeqNo::incseq(m_piData2[m_iTail]) == seqno1)) { 25 // coalesce with prior node, e.g., [2, 5], [6, 7] becomes [2, 7] 26 loc = m_iTail; 27 m_piData2[loc] = seqno2; 28 } else { 29 // create new node 30 m_piData1[loc] = seqno1; 31 32 if (seqno2 != seqno1) 33 m_piData2[loc] = seqno2; 34 35 m_piNext[m_iTail] = loc; 36 m_piPrior[loc] = m_iTail; 37 m_piNext[loc] = -1; 38 m_iTail = loc; 39 } 40 41 m_iLength += CSeqNo::seqlen(seqno1, seqno2); 42}

1. 与 CSndLossList 的insert()有点类似,也是首先处理了 最简单的向空链表中插入元素的case。

这个结构同样是将丢失packet的区间组织成一个链表,但不是单向链表,而是双向链表,相同位置处的m_piData1,m_piData2,m_piNext和m_piPrior的元素共同描述了一个链表中的节点,其中m_piData1的元素描述了区间的起始SeqNo,它总是一个有效的SeqNo;m_piData2的元素描述了区间的结束SeqNo,当这个值为-1时,表示区间里只有一个元素,否则表示区间的结束SeqNo;m_piNext的元素描述了下一个节点的位置,m_piPrior的元素描述前一个的位置。

对于这种case的处理,主要就是插入一个节点,更新链表头指针m_iHead,尾指针m_iTail,和丢失包的个数m_iLength字段就退出。

2. 对于CRcvLossList中之前已经有了节点的情况下,插入丢失packet区间的处理,相比于CSndLossList的insert()中对应部分的处理还是要简单很多。

对于CSndLossList来说,要insert()的case较多,比如接收到了接收端发回来的NAK Loss Report,或者是一个packet超过应有的时间都没有ACK过来等,这样造成的后果就是插入的区间可能是无序的,比如,第一次插入了[8, 10],第二次要插入的区间可能是[3, 5],也可能是[13, 17]。

但在CRcvLossList中就只有在接收到一个数据packet,发现新收到的packet的SeqNo大于(之前接收到的最大的SeqNo + 1)时才去执行insert(),因而总是向链表尾部插入元素,就可以保证链表中的节点总是以区间的起始SeqNo的升序排列的。

在4个数组中节点之间位置的相对关系,同CSndLossList中的一样,节点之间的位置差值等于它们的起始SeqNo之间的差值。

这里的处理过程也正是向链表尾部插入节点的过程。向链表尾部插入时,又要分为两种情况来处理,一是新插入的这个区间起始SeqNo == (原来的尾部节点结束SeqNo + 1),即新插入的区间要与尾部节点合并的情况,此时主要是更新尾部节点的结束SeqNo字段为新插入的这个区间的结束SeqNo,原来的那段code貌似写成下面这样要更好一点吧:

1if ((-1 != m_piData2[m_iTail]) && (CSeqNo::incseq(m_piData2[m_iTail]) == seqno1)) { 2 // coalesce with prior node, e.g., [2, 5], [6, 7] becomes [2, 7] 3 m_piData2[m_iTail] = seqno2; 4 } else {

另一种情况就是要完全插入一个新节点的情况,此时则主要是创建一个新节点插入链表尾部,然后更新链表的尾指针m_iTail。

3. 更新丢失包的个数m_iLength字段然后退出。

移除元素remove

然后来看用于移除元素的remove()函数。CRcvLossList提供了两个remove函数,一个用于移除一整个丢失接收packet区间,另一个用于移除单独的一个packet。这里先来看一下用于移除packet区间的remove()函数:

1bool CRcvLossList::remove(int32_t seqno1, int32_t seqno2) { 2 if (seqno1 <= seqno2) { 3 for (int32_t i = seqno1; i <= seqno2; ++i) 4 remove(i); 5 } else { 6 for (int32_t j = seqno1; j < CSeqNo::m_iMaxSeqNo; ++j) 7 remove(j); 8 for (int32_t k = 0; k <= seqno2; ++k) 9 remove(k); 10 } 11 12 return true; 13}

在这个函数中,seqno1为要移除的packet区间的起始SeqNo,seqno2则为结束SeqNo。

在这里主要分成两种情况来处理,一是seqno1小于等于seqno2,此时认为这两个值都没有因为超出了SeqNo的最大限制值,而被绕回到SeqNo取值空间的开始位置处,则一个一个的移除这个区间中的没一个值;二是seqno1大于seqno2,此时认为seqno2是由于超出了SeqNo的最大限制值而被绕回到SeqNo取值空间的开始位置处了,则将要移除的拆分成两个来处理,一是[seqno1, m_iMaxSeqNo),二是[0, seqno2],然后分别移除这两个区间中每一个值。

最后返回true。

接着再来看一下移除单个packet的remove()函数:

1bool CRcvLossList::remove(int32_t seqno) { 2 if (0 == m_iLength) 3 return false; 4 5 // locate the position of "seqno" in the list 6 int offset = CSeqNo::seqoff(m_piData1[m_iHead], seqno); 7 if (offset < 0) 8 return false; 9 10 int loc = (m_iHead + offset) % m_iSize; 11 12 if (seqno == m_piData1[loc]) { 13 // This is a seq. no. that starts the loss sequence 14 15 if (-1 == m_piData2[loc]) { 16 // there is only 1 loss in the sequence, delete it from the node 17 if (m_iHead == loc) { 18 m_iHead = m_piNext[m_iHead]; 19 if (-1 != m_iHead) 20 m_piPrior[m_iHead] = -1; 21 } else { 22 m_piNext[m_piPrior[loc]] = m_piNext[loc]; 23 if (-1 != m_piNext[loc]) 24 m_piPrior[m_piNext[loc]] = m_piPrior[loc]; 25 else 26 m_iTail = m_piPrior[loc]; 27 } 28 29 m_piData1[loc] = -1; 30 } else { 31 // there are more than 1 loss in the sequence 32 // move the node to the next and update the starter as the next loss inSeqNo(seqno) 33 34 // find next node 35 int i = (loc + 1) % m_iSize; 36 37 // remove the "seqno" and change the starter as next seq. no. 38 m_piData1[i] = CSeqNo::incseq(m_piData1[loc]); 39 40 // process the sequence end 41 if (CSeqNo::seqcmp(m_piData2[loc], CSeqNo::incseq(m_piData1[loc])) > 0) 42 m_piData2[i] = m_piData2[loc]; 43 44 // remove the current node 45 m_piData1[loc] = -1; 46 m_piData2[loc] = -1; 47 48 // update list pointer 49 m_piNext[i] = m_piNext[loc]; 50 m_piPrior[i] = m_piPrior[loc]; 51 52 if (m_iHead == loc) 53 m_iHead = i; 54 else 55 m_piNext[m_piPrior[i]] = i; 56 57 if (m_iTail == loc) 58 m_iTail = i; 59 else 60 m_piPrior[m_piNext[i]] = i; 61 } 62 63 m_iLength--; 64 65 return true; 66 } 67 68 // There is no loss sequence in the current position 69 // the "seqno" may be contained in a previous node 70 71 // searching previous node 72 int i = (loc - 1 + m_iSize) % m_iSize; 73 while (-1 == m_piData1[i]) 74 i = (i - 1 + m_iSize) % m_iSize; 75 76 // not contained in this node, return 77 if ((-1 == m_piData2[i]) || (CSeqNo::seqcmp(seqno, m_piData2[i]) > 0)) 78 return false; 79 80 if (seqno == m_piData2[i]) { 81 // it is the sequence end 82 83 if (seqno == CSeqNo::incseq(m_piData1[i])) 84 m_piData2[i] = -1; 85 else 86 m_piData2[i] = CSeqNo::decseq(seqno); 87 } else { 88 // split the sequence 89 90 // construct the second sequence from CSeqNo::incseq(seqno) to the original sequence end 91 // located at "loc + 1" 92 loc = (loc + 1) % m_iSize; 93 94 m_piData1[loc] = CSeqNo::incseq(seqno); 95 if (CSeqNo::seqcmp(m_piData2[i], m_piData1[loc]) > 0) 96 m_piData2[loc] = m_piData2[i]; 97 98 // the first (original) sequence is between the original sequence start to CSeqNo::decseq(seqno) 99 if (seqno == CSeqNo::incseq(m_piData1[i])) 100 m_piData2[i] = -1; 101 else 102 m_piData2[i] = CSeqNo::decseq(seqno); 103 104 // update the list pointer 105 m_piNext[loc] = m_piNext[i]; 106 m_piNext[i] = loc; 107 m_piPrior[loc] = i; 108 109 if (m_iTail == i) 110 m_iTail = loc; 111 else 112 m_piPrior[m_piNext[loc]] = loc; 113 } 114 115 m_iLength--; 116 117 return true; 118}

在这个函数中执行的过程如下:

1. 检查List是否为空,若为空,直接返回false推出,否则继续执行。

2. 计算头节点所表示的丢失packet范围的起始SeqNo与参数seqno的offset,若offset小于0,表明要移除的SeqNo已经不在CRcvLossList中了,则直接退出,否则继续执行。

3. 计算可能以seqno作为起始SeqNo字段的节点的位置loc。

4.处理传入参数seqno为某个节点的起始SeqNo值的case,这个case下又分了多个子case来处理:

对于这些case中每种的具体处理,此处不再赘述。

处理完之后就返回true。

5. 传入参数seqno不是某个节点的起始SeqNo值的情况,则需要先找到可能包含了参数seqno的节点。这里是从loc开始,通过一个循环,向loc逐渐减少的方向,依次检查m_piData1数组值来查找的,找到位置小于loc,且距离loc最近的节点。

这种方法不同于CSndLossList::remove()中采用的,从链表的头部开始查找的过程。两种方法自然是各有优劣,这里的方法对于节点非常多,每个节点描述的区间比较小的情况比较高效,而实际上由于接收到的data packet顺序的随机性,CRcvLossList形成这样的链表的可能性还是蛮大的。而CSndLossList::remove()中采用的方法,则对于那种节点数不多,每个节点表示的区间比较长,节点之间距离较远的情况比较高效。

6. 检查找到的节点是否包含参数seqno,若不包含说明seqno不在丢失packet列表CRcvLossList中,则直接返回false退出。

7. 找到的节点表示的范围包含了传入的参数seqno,又可以分为3中case来处理。

case 1:传入的参数seqno是找到的节点的结束SeqNo值,且找到的节点表示的范围中只包含了2个SeqNo,此时需要将该节点的结束SeqNo值置为-1。

case 2:传入的参数seqno是找到的节点的结束SeqNo值,且找到的节点表示的范围中只包含了超过3个的SeqNo,此时则需将该节点的结束SeqNo值置为CSeqNo::decseq(seqno)。

case 3:传入的参数seqno是找到的节点表示的区间中间的某个值,此时则需要将原来的节点一分为2。

8. 递减m_iLength。

9. 返回true。

接收端只有在接收到DropMsg消息时才会执行移除丢失packet区间的remove(int32_t seqno1, int32_t seqno2)。每次接收到一个数据packet时,若其SeqNo不大于m_iRcvCurrSeqNo,都会尝试通过移除单个packet的remove(int32_t seqno)将相应的packet从m_pRcvLossList中移除。

Getters

最后再来看几个getter函数:

1int CRcvLossList::getLossLength() const { 2 return m_iLength; 3} 4 5int CRcvLossList::getFirstLostSeq() const { 6 if (0 == m_iLength) 7 return -1; 8 9 return m_piData1[m_iHead]; 10} 11 12void CRcvLossList::getLossArray(int32_t* array, int& len, int limit) { 13 len = 0; 14 15 int i = m_iHead; 16 17 while ((len < limit - 1) && (-1 != i)) { 18 array[len] = m_piData1[i]; 19 if (-1 != m_piData2[i]) { 20 // there are more than 1 loss in the sequence 21 array[len] |= 0x80000000; 22 ++len; 23 array[len] = m_piData2[i]; 24 } 25 26 ++len; 27 28 i = m_piNext[i]; 29 } 30}

getLossLength()用于返回CRcvLossList中包含的丢失packet的总个数。

getFirstLostSeq()用于返回CRcvLossList中最小的SeqNo值。

getLossArray()则返回一个用于NAK消息的丢失packet列表。这里可以一窥NAK消息中,丢失packet是怎么表示的。在丢失packet列表中,一个最高位为1,其余位表示一个合法SeqNo的值,及其后紧紧跟着的一个合法SeqNo值表示一个丢失packet区间,一个单独的SeqNo值项则表示一个单独的丢失的packet。

对于CRcvLossList的分析就到这里。

NAK

如我们前面在CUDT::processData()中看到的,在发现接收到的packet的SeqNo大于CSeqNo::incseq(m_iRcvCurrSeqNo)时,会在将[CSeqNo::incseq(m_iRcvCurrSeqNo), CSeqNo::decseq(packet.m_iSeqNo)]区间插入m_pRcvLossList之后,就立即向数据的发送端发送一个NAK report。

NAK消息的发送

这里先来看一下NAK消息的发送,在CUDT::sendCtrl(int pkttype, void* lparam, void* rparam, int size)中(src/core.cpp):

1void CUDT::sendCtrl(int pkttype, void* lparam, void* rparam, int size) { 2 CPacket ctrlpkt; 3 4 switch (pkttype) { 5 case 2: //010 - Acknowledgement 6 { 7。。。。。。 8 9 case 3: //011 - Loss Report 10 { 11 if (NULL != rparam) { 12 if (1 == size) { 13 // only 1 loss packet 14 ctrlpkt.pack(pkttype, NULL, (int32_t *) rparam + 1, 4); 15 } else { 16 // more than 1 loss packets 17 ctrlpkt.pack(pkttype, NULL, rparam, 8); 18 } 19 20 ctrlpkt.m_iID = m_PeerID; 21 m_pSndQueue->sendto(m_pPeerAddr, ctrlpkt); 22 23 ++m_iSentNAK; 24 ++m_iSentNAKTotal; 25 } else if (m_pRcvLossList->getLossLength() > 0) { 26 // this is periodically NAK report; make sure NAK cannot be sent back too often 27 28 // read loss list from the local receiver loss list 29 int32_t* data = new int32_t[m_iPayloadSize / 4]; 30 int losslen; 31 m_pRcvLossList->getLossArray(data, losslen, m_iPayloadSize / 4); 32 33 if (0 < losslen) { 34 ctrlpkt.pack(pkttype, NULL, data, losslen * 4); 35 ctrlpkt.m_iID = m_PeerID; 36 m_pSndQueue->sendto(m_pPeerAddr, ctrlpkt); 37 38 ++m_iSentNAK; 39 ++m_iSentNAKTotal; 40 } 41 42 delete[] data; 43 } 44 45 // update next NAK time, which should wait enough time for the retansmission, but not too long 46 m_ullNAKInt = (m_iRTT + 4 * m_iRTTVar) * m_ullCPUFrequency; 47 int rcv_speed = m_pRcvTimeWindow->getPktRcvSpeed(); 48 if (rcv_speed > 0) 49 m_ullNAKInt += (m_pRcvLossList->getLossLength() * 1000000ULL / rcv_speed) * m_ullCPUFrequency; 50 if (m_ullNAKInt < m_ullMinNakInt) 51 m_ullNAKInt = m_ullMinNakInt; 52 53 break; 54 }

发送NAK消息的过程大体为:

1. 要发送的NAK消息可分为两种类型。一种如我们前面在CUDT::processData()中看到的,针对单个packet或单个packet区间的NAK消息;第二种是在定时器中发送,包含了CRcvLossList中尽可能多的丢失packet或区间的NAK。

(1). 对于第一种类型,如我们前面在CUDT::processData()中所见,CUDT::sendCtrl()的rparam参数是一个两元素的int32_t数组,其中第一个元素为丢失packet的SeqNo区间的首个SeqNo,且最高位会被置为1,第二个元素为区间的最后一个SeqNo,参数size用来描述区间中是有1个SeqNo还是有多个。通过前面对CRcvLossList::getLossArray()的分析,实在不难理解为什么rparam的第一个int32_t元素的最高位会被置1,应该说这个是UDT协议消息规范的一部分。

在这里会首先根据size参数的值,将SeqNo或SeqNo区间pack进packet。对于单个packet的情况,不难理解rparam中的两个int32_t中的SeqNo部分都是一样的,只是第一个int32_t的最高位被置为了1。接着是设置packet的目标SocketID为PeerID,之后便是通过发送队列m_pSndQueue发送packet,然后还会更新用于统计的字段m_iSentNAK和m_iSentNAKTotal。

(2). 对于第二种类型,则会分配一块接近m_iPayloadSize大小的数据缓冲区data,接着通过CRcvLossList::getLossArray()将尽可能多的丢失packet或packet区间读进缓冲区data,然后在实际读到了丢失packet或packet区间的情况下,将data pack进packet,并通过发送队列m_pSndQueue发送packet,然后还会更新用于统计的字段m_iSentNAK和m_iSentNAKTotal。最后delete掉前面分配的数据缓冲区data。

在CUDT::checkTimers()中可以看到下面的这段被注释掉的code:

1// we are not sending back repeated NAK anymore and rely on the sender's EXP for retransmission 2 //if ((m_pRcvLossList->getLossLength() > 0) && (currtime > m_ullNextNAKTime)) 3 //{ 4 // // NAK timer expired, and there is loss to be reported. 5 // sendCtrl(3); 6 // 7 // CTimer::rdtsc(currtime); 8 // m_ullNextNAKTime = currtime + m_ullNAKInt; 9 //}

可以看到,UDT的开发者认为,不再需要在定时器中发送重复的NAK消息了,在CUDT::processData()中首次发现有丢包时发送针对单个packet或单个packet区间的NAK消息就足够了。

因而前面我们讨论的第二种类型的NAK消息的发送实际是不work的,因而相关的部分也都变成了历史遗留问题了。

2. 在实际发送NAK消息之后,还会更新m_ullNAKInt。这个变量原本主要用于控制定时器中对于NAK消息的发送,但目前也是成为了历史遗留问题,而不再起实际作用了。

NAK消息本身的发送大体如此。

NAK消息的接收与处理

接着再来看一下数据发送端在接到NAK消息的处理。NAK消息如同数据消息一样,也是在建立之后才能收发的。因而其dispatch可以参考数据的接收部分的分析,只是作为一种控制消息,它会被dispatch给CUDT::processCtrl(),这里就来看一下数据发送端对于NAK消息的处理:

1void CUDT::processCtrl(CPacket& ctrlpkt) { 2 // Just heard from the peer, reset the expiration count. 3 m_iEXPCount = 1; 4 uint64_t currtime; 5 CTimer::rdtsc(currtime); 6 m_ullLastRspTime = currtime; 7 8 switch (ctrlpkt.getType()) { 9 case 2: //010 - Acknowledgement 10 { 11 12。。。。。。 13 14 case 3: //011 - Loss Report 15 { 16 int32_t* losslist = (int32_t *) (ctrlpkt.m_pcData); 17 18 m_pCC->onLoss(losslist, ctrlpkt.getLength() / 4); 19 CCUpdate(); 20 21 bool secure = true; 22 23 // decode loss list message and insert loss into the sender loss list 24 for (int i = 0, n = (int) (ctrlpkt.getLength() / 4); i < n; ++i) { 25 if (0 != (losslist[i] & 0x80000000)) { 26 if ((CSeqNo::seqcmp(losslist[i] & 0x7FFFFFFF, losslist[i + 1]) > 0) 27 || (CSeqNo::seqcmp(losslist[i + 1], m_iSndCurrSeqNo) > 0)) { 28 // seq_a must not be greater than seq_b; seq_b must not be greater than the most recent sent seq 29 secure = false; 30 break; 31 } 32 33 int num = 0; 34 if (CSeqNo::seqcmp(losslist[i] & 0x7FFFFFFF, m_iSndLastAck) >= 0) 35 num = m_pSndLossList->insert(losslist[i] & 0x7FFFFFFF, losslist[i + 1]); 36 else if (CSeqNo::seqcmp(losslist[i + 1], m_iSndLastAck) >= 0) 37 num = m_pSndLossList->insert(m_iSndLastAck, losslist[i + 1]); 38 39 m_iTraceSndLoss += num; 40 m_iSndLossTotal += num; 41 42 ++i; 43 } else if (CSeqNo::seqcmp(losslist[i], m_iSndLastAck) >= 0) { 44 if (CSeqNo::seqcmp(losslist[i], m_iSndCurrSeqNo) > 0) { 45 //seq_a must not be greater than the most recent sent seq 46 secure = false; 47 break; 48 } 49 50 int num = m_pSndLossList->insert(losslist[i], losslist[i]); 51 52 m_iTraceSndLoss += num; 53 m_iSndLossTotal += num; 54 } 55 } 56 57 if (!secure) { 58 //this should not happen: attack or bug 59 m_bBroken = true; 60 m_iBrokenCounter = 0; 61 break; 62 } 63 64 // the lost packet (retransmission) should be sent out immediately 65 m_pSndQueue->m_pSndUList->update(this); 66 67 ++m_iRecvNAK; 68 ++m_iRecvNAKTotal; 69 70 break; 71 }

可以看到处理过程为:

1. 在CUDT::processCtrl()开始处,会统一地复位超时计数器m_iEXPCount,并将当前时间读进m_ullLastRspTime。

2. 从packet中获取丢失packet或packet区间列表losslist。

3. 执行拥塞控制器的onLoss()回调。

4. 执行CCUpdate()。这个操作主要用于控制发送窗口的大小,及发包的频率。后面在研究拥塞控制时再来研究它。

5. 通过一个循环从loss list中解码出丢失的packet或packet区间列表。

(1). 循环体中首先是处理的packet区间的情况。

对于这种情况,会先对SeqNo的有效性进行检查。区间的起始SeqNo必须小于等于结束SeqNo值,且结束SeqNo必须小于等于m_iSndCurrSeqNo才是合法的。若发现出现了不合法的SeqNo区间,则认为这是一个攻击packet,会将secure置为false,并直接跳出对于loss list的解码。否则继续执行。

在丢失packet区间的起始SeqNo大于等于m_iSndLastAck时,将解码到的整个区间插入发送丢失列表中。

在在丢失packet区间的起始SeqNo小于m_iSndLastAck,而结束SeqNo大于m_iSndLastAck时,将区间[m_iSndLastAck, losslist[i + 1]]插入发送丢失列表中。

对于其它情况,也即丢失packet区间的结束SeqNo小于m_iSndLastAck的情况,则表明这个丢失packet区间中的packet都已经滑出了发送窗口了,因而不再向发送丢失列表中插入元素。

更新m_iTraceSndLoss,m_iSndLossTotal这两个用于做统计的字段。

递增循环计数i,以跳过丢失packet区间的结束SeqNo。

(2). 处理单个packet的情况。

只有SeqNo大于m_iSndLastAck,NAK消息才有处理的必要,这里也主要针对这种情况。

同样先对SeqNo的有效性进行检查,SeqNo小于等于m_iSndCurrSeqNo才是合法的。若发现出现了不合法的SeqNo,则认为这是一个攻击packet,会将secure置为false,并直接跳出对于loss list的解码。否则继续执行。

向发送丢失列表中插入SeqNo。

更新m_iTraceSndLoss,m_iSndLossTotal这两个用于做统计的字段。

6. 若发现收到了不secure的控制消息,则将m_bBroken置为true,复位m_iBrokenCounter,并退出对于NAK消息的处理。否则继续执行。

7. 执行m_pSndQueue->m_pSndUList->update(this),以便于能够尽可能快地重新发送丢失的包。

8. 更新m_iRecvNAK和m_iRecvNAKTotal这两个用于统计的字段。

由此可见发送数据的端在收到NAK消息之后,不会Ack这个NAK,因而NAK消息本身的传输不是可靠的。

NAK的发送处理过程,大体如此。

ACK

接着来看一下UDT中的ACK机制。

数据接收端ACK消息的发送

UDT中的ACK消息,其packet type为2,在UDT中,只有CUDT::checkTimers()在发送这一类型的控制消息。这里先来看一下在CUDT::checkTimers()中对于ACK消息的发送(src/core.cpp):

1void CUDT::checkTimers() { 2 // update CC parameters 3 CCUpdate(); 4 //uint64_t minint = (uint64_t)(m_ullCPUFrequency * m_pSndTimeWindow->getMinPktSndInt() * 0.9); 5 //if (m_ullInterval < minint) 6 // m_ullInterval = minint; 7 8 uint64_t currtime; 9 CTimer::rdtsc(currtime); 10 11 if ((currtime > m_ullNextACKTime) || ((m_pCC->m_iACKInterval > 0) && (m_pCC->m_iACKInterval <= m_iPktCount))) { 12 // ACK timer expired or ACK interval is reached 13 14 sendCtrl(2); 15 CTimer::rdtsc(currtime); 16 if (m_pCC->m_iACKPeriod > 0) 17 m_ullNextACKTime = currtime + m_pCC->m_iACKPeriod * m_ullCPUFrequency; 18 else 19 m_ullNextACKTime = currtime + m_ullACKInt; 20 21 m_iPktCount = 0; 22 m_iLightACKCount = 1; 23 } else if (m_iSelfClockInterval * m_iLightACKCount <= m_iPktCount) { 24 //send a "light" ACK 25 sendCtrl(2, NULL, NULL, 4); 26 ++m_iLightACKCount; 27 }

可以看到,ACK消息分为两种,一种是常规ACK,在ACK定时器超时或ACK间距到来时发送;另一种是“light” ACK,在(m_iSelfClockInterval * m_iLightACKCount)小于等于m_iPktCount时发送。

m_ullNextACKTime描述ACK timer的超时时间,用于控制ACK发送在时间上的频率。在CUDT::open()中这个值初次被设置为一个有效值:

1const int CUDT::m_iSYNInterval = 10000; 2 3 m_ullCPUFrequency = CTimer::getCPUFrequency(); 4 5 // set up the timers 6 m_ullSYNInt = m_iSYNInterval * m_ullCPUFrequency; 7 8 uint64_t currtime; 9 CTimer::rdtsc(currtime); 10 11 m_ullNextACKTime = currtime + m_ullSYNInt;

在CUDT::open()之后,m_ullSYNInt同样为一个常量值。

在接收数据packet的CUDT::processData()中,若发现接收到的是一个Msg的结束packet,会将当前时间读进m_ullNextACKTime,以便于CUDT::checkTimers()在下次执行时,就能立即发送ACK消息给发送端。

m_iPktCount描述自上次常规ACK消息发送之后,已经接收到的数据packet的个数。

m_pCC->m_iACKInterval用于控制每接收多少个数据packet要发送一个ACK消息,在默认的拥塞控制器CUDTCC中这个变量值为0,它主要用于自定义拥塞控制器的场景。

m_iSelfClockInterval为内部时钟的ACK发送间隔,是一个常量值(src/core.cpp):

const int CUDT::m_iSelfClockInterval = 64;

m_iLightACKCount为“light” ACK自上次常规ACK消息发送以来的发送次数。

回到CUDT::checkTimers()中ACK消息的发送过程:

1. 首先检查ACK定时器超时时间是否到达或ACK发送间距是否到来,若到来则进入常规ACK发送的过程,否则继续执行。常规ACK的发送过程为:

(1). 调用sendCtrl(2)发送常规ACK消息给调用者。

(2). 获取当前时间currtime。

(3). 检查m_pCC->m_iACKPeriod是否为大于0的有效值,若是则基于m_pCC->m_iACKPeriod更新m_ullNextACKTime。若不是则基于m_ullACKInt更新m_ullNextACKTime。

m_pCC->m_iACKPeriod为拥塞控制器中用来控制ACK消息发送时间周期的成员,可以看下这个变量在默认拥塞控制器中的初始化(src/ccc.cpp):

1const int CUDT::m_iSYNInterval = 10000; 2 3。。。。。。 4 5CCC::CCC() 6 : m_iSYNInterval(CUDT::m_iSYNInterval), 7 m_dPktSndPeriod(1.0), 8。。。。。。 9 10void CUDTCC::init() { 11 m_iRCInterval = m_iSYNInterval; 12 m_LastRCTime = CTimer::getTime(); 13 setACKTimer(m_iRCInterval); 14。。。。。。 15 16 17void CCC::setACKTimer(int msINT) { 18 m_iACKPeriod = msINT > m_iSYNInterval ? m_iSYNInterval : msINT; 19}

m_pCC->m_iACKPeriod为一个常量值。

m_ullACKInt为CUDT内部控制ACK消息发送时间频率的成员。同样在CUDT::open()中设置:

1const int CUDT::m_iSYNInterval = 10000; 2。。。。。。 3 m_ullCPUFrequency = CTimer::getCPUFrequency(); 4。。。。。。 5 // set up the timers 6 m_ullSYNInt = m_iSYNInterval * m_ullCPUFrequency; 7。。。。。。 8 m_ullACKInt = m_ullSYNInt;

这里可以看到,就ACK消息发送的时间频率控制而言,拥塞控制器的控制优先级要高于CUDT内部的控制。

(4). 复位m_iPktCount为0,m_iLightACKCount为1。

2. 检查(m_iSelfClockInterval * m_iLightACKCount)是否小于等于m_iPktCount,若条件成立,则表明发送“light” ACK消息的时间到了,于是发送一个“light” ACK消息,并递增“light” ACK消息发送计数m_iLightACKCount。在没有常规ACK消息发送的情况下,大概每接收到64个数据packet会发送一次ACK消息。由此可见“light” ACK大概应用于带宽比较高的情况,或者发送端发送数据packet速度过快的情况。

总结一下在CUDT::checkTimers()中对于ACK消息发送频率的控制。可以看到主要通过m_ullNextACKTime,拥塞控制器m_pCC的m_iACKInterval来控制常规ACK消息的发送。m_iSelfClockInterval用来控制“light” ACK的发送频率。

接着再来看一下在CUDT::sendCtrl()中ACK消息发送的具体过程:

1void CUDT::sendCtrl(int pkttype, void* lparam, void* rparam, int size) { 2 CPacket ctrlpkt; 3 4 switch (pkttype) { 5 case 2: //010 - Acknowledgement 6 { 7 int32_t ack; 8 9 // If there is no loss, the ACK is the current largest sequence number plus 1; 10 // Otherwise it is the smallest sequence number in the receiver loss list. 11 if (0 == m_pRcvLossList->getLossLength()) 12 ack = CSeqNo::incseq(m_iRcvCurrSeqNo); 13 else 14 ack = m_pRcvLossList->getFirstLostSeq(); 15 16 if (ack == m_iRcvLastAckAck) 17 break; 18 19 // send out a lite ACK 20 // to save time on buffer processing and bandwidth/AS measurement, a lite ACK only feeds back an ACK number 21 if (4 == size) { 22 ctrlpkt.pack(pkttype, NULL, &ack, size); 23 ctrlpkt.m_iID = m_PeerID; 24 m_pSndQueue->sendto(m_pPeerAddr, ctrlpkt); 25 26 break; 27 } 28 29 uint64_t currtime; 30 CTimer::rdtsc(currtime); 31 32 // There are new received packets to acknowledge, update related information. 33 if (CSeqNo::seqcmp(ack, m_iRcvLastAck) > 0) { 34 int acksize = CSeqNo::seqoff(m_iRcvLastAck, ack); 35 36 m_iRcvLastAck = ack; 37 38 m_pRcvBuffer->ackData(acksize); 39 40 // signal a waiting "recv" call if there is any data available 41#ifndef WIN32 42 pthread_mutex_lock(&m_RecvDataLock); 43 if (m_bSynRecving) 44 pthread_cond_signal(&m_RecvDataCond); 45 pthread_mutex_unlock(&m_RecvDataLock); 46#else 47 if (m_bSynRecving) 48 SetEvent(m_RecvDataCond); 49#endif 50 51 // acknowledge any waiting epolls to read 52 s_UDTUnited.m_EPoll.update_events(m_SocketID, m_sPollID, UDT_EPOLL_IN, true); 53 } else if (ack == m_iRcvLastAck) { 54 if ((currtime - m_ullLastAckTime) < ((m_iRTT + 4 * m_iRTTVar) * m_ullCPUFrequency)) 55 break; 56 } else 57 break; 58 59 // Send out the ACK only if has not been received by the sender before 60 if (CSeqNo::seqcmp(m_iRcvLastAck, m_iRcvLastAckAck) > 0) { 61 int32_t data[6]; 62 63 m_iAckSeqNo = CAckNo::incack(m_iAckSeqNo); 64 data[0] = m_iRcvLastAck; 65 data[1] = m_iRTT; 66 data[2] = m_iRTTVar; 67 data[3] = m_pRcvBuffer->getAvailBufSize(); 68 // a minimum flow window of 2 is used, even if buffer is full, to break potential deadlock 69 if (data[3] < 2) 70 data[3] = 2; 71 72 if (currtime - m_ullLastAckTime > m_ullSYNInt) { 73 data[4] = m_pRcvTimeWindow->getPktRcvSpeed(); 74 data[5] = m_pRcvTimeWindow->getBandwidth(); 75 ctrlpkt.pack(pkttype, &m_iAckSeqNo, data, 24); 76 77 CTimer::rdtsc(m_ullLastAckTime); 78 } else { 79 ctrlpkt.pack(pkttype, &m_iAckSeqNo, data, 16); 80 } 81 82 ctrlpkt.m_iID = m_PeerID; 83 m_pSndQueue->sendto(m_pPeerAddr, ctrlpkt); 84 85 m_pACKWindow->store(m_iAckSeqNo, m_iRcvLastAck); 86 87 ++m_iSentACK; 88 ++m_iSentACKTotal; 89 } 90 91 break; 92 }

1. 首先要做的就是计算到底要ACK哪些数据packet,记为ack。

如果接收丢失数据packet列表m_pRcvLossList为空,则ACK CSeqNo::incseq(m_iRcvCurrSeqNo),若不为空则ACK首个丢失的数据packet。

2. 检查ACK的目标SeqNo是否已经被ACK过,且确定数据发送端已经收到了该ACK消息,若已经被ack过,且确定数据发送端已经收到了该ACK消息,则后面发送ACK消息的过程都没有必要了,而需要直接退出。否则继续执行。

检查方法就是比较前一步计算的ack与m_iRcvLastAckAck是否想等。若相等,则要ACK的SeqNo已经被ack过,且确定数据发送端已经收到了该ACK消息。

3. size == 4表示要发送的是“light” ACK,则发送“light” ACK消息,并退出,否则继续执行。

可以看到“light” ACK消息的数据部分只包含了要ACK的SeqNo。

4. 获取当前时间currtime。

5. 根据第一步计算的ACK目标SeqNo,分为3中情况来进行的发送ACK消息的前奏曲:

case 1:在上次常规ACK发送之后,有新的连续的数据包被接收,即CSeqNo::seqcmp(ack, m_iRcvLastAck) > 0。此时会计算要新ACK的数据packet的个数acksize,更新m_iRcvLastAck为ack,ACK接收缓冲区m_pRcvBuffer中的acksize个数据packet,然后唤醒在m_RecvDataCond上等待读取接收到的数据的线程程。

case 2:上次发送的ACK消息的超时重传。可见超时周期为((m_iRTT + 4 * m_iRTTVar) * m_ullCPUFrequency),若超时时间未到,则退出执行。

case 3:CSeqNo::seqcmp(ack, m_iRcvLastAck) < 0的情况,一种本不应该出现的异常的情况。退出执行。

6. 发送常规ACK消息。

先来看一下经过了前面的那些步骤走到这一步时,m_iRcvLastAck,m_iRcvLastAckAck和ack之间的关系:

(ack > m_iRcvLastAckAck && ack == m_iRcvLastAck)

这里做的检查提供了更强的保证。

(1). 构造一个常规的ACK packet。一个常规的ACK packet会包含m_iRcvLastAck,也就是ACK的目标SeqNo,m_iRTT,m_iRTTVar,和接收缓冲区的可用大小。如果距离上次AckTime超过了m_ullSYNInt,还会携带接收时间窗口的packet接收速率和带宽等信息。

ACK消息有一套自己的SeqNo系统,m_iAckSeqNo用于记录最近发送的ACK消息的SeqNo。

(2). 发送常规ACK packet。

(3). 将m_iAckSeqNo和m_iRcvLastAck保存进ACK Window。

(4). 更新用于做数据统计的m_iSentACK和m_iSentACKTotal。

数据发送端ACK消息的接收与处理

接着来看在数据发送端接收到ACK消息的处理:

1void CUDT::processCtrl(CPacket& ctrlpkt) { 2 // Just heard from the peer, reset the expiration count. 3 m_iEXPCount = 1; 4 uint64_t currtime; 5 CTimer::rdtsc(currtime); 6 m_ullLastRspTime = currtime; 7 8 switch (ctrlpkt.getType()) { 9 case 2: //010 - Acknowledgement 10 { 11 int32_t ack; 12 13 // process a lite ACK 14 if (4 == ctrlpkt.getLength()) { 15 ack = *(int32_t *) ctrlpkt.m_pcData; 16 if (CSeqNo::seqcmp(ack, m_iSndLastAck) >= 0) { 17 m_iFlowWindowSize -= CSeqNo::seqoff(m_iSndLastAck, ack); 18 m_iSndLastAck = ack; 19 } 20 21 break; 22 } 23 24 // read ACK seq. no. 25 ack = ctrlpkt.getAckSeqNo(); 26 27 // send ACK acknowledgement 28 // number of ACK2 can be much less than number of ACK 29 uint64_t now = CTimer::getTime(); 30 if ((currtime - m_ullSndLastAck2Time > (uint64_t) m_iSYNInterval) || (ack == m_iSndLastAck2)) { 31 sendCtrl(6, &ack); 32 m_iSndLastAck2 = ack; 33 m_ullSndLastAck2Time = now; 34 } 35 36 // Got data ACK 37 ack = *(int32_t *) ctrlpkt.m_pcData; 38 39 // check the validation of the ack 40 if (CSeqNo::seqcmp(ack, CSeqNo::incseq(m_iSndCurrSeqNo)) > 0) { 41 //this should not happen: attack or bug 42 m_bBroken = true; 43 m_iBrokenCounter = 0; 44 break; 45 } 46 47 if (CSeqNo::seqcmp(ack, m_iSndLastAck) >= 0) { 48 // Update Flow Window Size, must update before and together with m_iSndLastAck 49 m_iFlowWindowSize = *((int32_t *) ctrlpkt.m_pcData + 3); 50 m_iSndLastAck = ack; 51 } 52 53 // protect packet retransmission 54 CGuard::enterCS(m_AckLock); 55 cout << "Receive ack " << ack << endl; 56 57 int offset = CSeqNo::seqoff(m_iSndLastDataAck, ack); 58 if (offset <= 0) { 59 // discard it if it is a repeated ACK 60 CGuard::leaveCS(m_AckLock); 61 break; 62 } 63 64 // acknowledge the sending buffer 65 m_pSndBuffer->ackData(offset); 66 67 // record total time used for sending 68 m_llSndDuration += currtime - m_llSndDurationCounter; 69 m_llSndDurationTotal += currtime - m_llSndDurationCounter; 70 m_llSndDurationCounter = currtime; 71 72 // update sending variables 73 m_iSndLastDataAck = ack; 74 m_pSndLossList->remove(CSeqNo::decseq(m_iSndLastDataAck)); 75 76 CGuard::leaveCS(m_AckLock); 77 78#ifndef WIN32 79 pthread_mutex_lock(&m_SendBlockLock); 80 if (m_bSynSending) 81 pthread_cond_signal(&m_SendBlockCond); 82 pthread_mutex_unlock(&m_SendBlockLock); 83#else 84 if (m_bSynSending) 85 SetEvent(m_SendBlockCond); 86#endif 87 88 // acknowledde any waiting epolls to write 89 s_UDTUnited.m_EPoll.update_events(m_SocketID, m_sPollID, UDT_EPOLL_OUT, true); 90 91 // insert this socket to snd list if it is not on the list yet 92 m_pSndQueue->m_pSndUList->update(this, false); 93 94 // Update RTT 95 //m_iRTT = *((int32_t *)ctrlpkt.m_pcData + 1); 96 //m_iRTTVar = *((int32_t *)ctrlpkt.m_pcData + 2); 97 int rtt = *((int32_t *) ctrlpkt.m_pcData + 1); 98 m_iRTTVar = (m_iRTTVar * 3 + abs(rtt - m_iRTT)) >> 2; 99 m_iRTT = (m_iRTT * 7 + rtt) >> 3; 100 101 m_pCC->setRTT(m_iRTT); 102 103 if (ctrlpkt.getLength() > 16) { 104 // Update Estimated Bandwidth and packet delivery rate 105 if (*((int32_t *) ctrlpkt.m_pcData + 4) > 0) 106 m_iDeliveryRate = (m_iDeliveryRate * 7 + *((int32_t *) ctrlpkt.m_pcData + 4)) >> 3; 107 108 if (*((int32_t *) ctrlpkt.m_pcData + 5) > 0) 109 m_iBandwidth = (m_iBandwidth * 7 + *((int32_t *) ctrlpkt.m_pcData + 5)) >> 3; 110 111 m_pCC->setRcvRate(m_iDeliveryRate); 112 m_pCC->setBandwidth(m_iBandwidth); 113 } 114 115 m_pCC->onACK(ack); 116 CCUpdate(); 117 118 ++m_iRecvACK; 119 ++m_iRecvACKTotal; 120 121 break; 122 }

在这里,可以看到处理过程为:

1. 处理“light” ACK packet,然后退出。

处理方式就是在ACK的目标SeqNo ack满足CSeqNo::seqcmp(ack, m_iSndLastAck) >= 0时,减小m_iFlowWindowSize,并更新m_iSndLastAck。

这里貌似CSeqNo::seqcmp(ack, m_iSndLastAck) == 0时也是什么都不需要做的。

2. 开始处理常规ACK。先是获取ACK消息的SeqNo,然后读取当前时间。

3. 发送ACK acknowledgement,也就是ACK2消息。可以看到,ACK2消息的发送个数可以少于ACK的消息个数。m_iSYNInterval为ACK2消息发送的最小时间间隔,即自上一次发送ACK2消息以来,经过的时间超过了m_iSYNInterval,在接到ACK消息时会发送ACK2消息。

另一种情况就是ack == m_iSndLastAck2,这可能表示上次发送的ACK2,数据接收端还没有收到。

这里在发送ACK2消息之后还会更新m_iSndLastAck2和m_ullSndLastAck2Time。

顺便来看一下CUDT::sendCtrl()中对于ACK2消息的发送:

1case 6: //110 - Acknowledgement of Acknowledgement 2 ctrlpkt.pack(pkttype, lparam); 3 ctrlpkt.m_iID = m_PeerID; 4 m_pSndQueue->sendto(m_pPeerAddr, ctrlpkt); 5 6 break;

4. 获取ACK消息中要ACK的目标数据packet的SeqNo存于ack。

5. 检查CSeqNo::seqcmp(ack, CSeqNo::incseq(m_iSndCurrSeqNo))是否大于0,若是则表明接收到的这个ACK消息在ACK从未发送过的数据packet,则说明这个消息可能是一个攻击或bug,于是m_bBroken置为true,复位m_iBrokenCounter并退出。

6. CSeqNo::seqcmp(ack, m_iSndLastAck) > 0时表明这个消息要ACK一些之前没有被ACK过的数据packet,从ACK packet读取信息更新Flow Window Size,及m_iSndLastAck。

7. 计算m_iSndLastDataAck到ack的偏移值offset,若offset小于等于0,表明接收到的这个ACK消息要ACK的目标SeqNo已经被其它ACK消息给ACK过了,因而无需再执行其它动作,退出执行。

8. 前面计算的m_iSndLastDataAck到ack的偏移值offset大于0,则ACK发送缓冲区m_pSndBuffer中的offset个packet。

9. 更新m_llSndDuration,m_llSndDurationTotal和m_llSndDurationCounter。m_llSndDuration,m_llSndDurationTotal用于统计SeqNo在ack之前的所有packet发送并得到ACK所用的时间。

10. 更新发送变量m_iSndLastDataAck为ack,并将SeqNo在m_iSndLastDataAck之前的所有SeqNo从发送丢失列表中移除出去。

11. 唤醒在等待发送数据的线程。ACK会使发送窗口向前移动。

12. 如果本socket不在snd 列表的话,将本socket插入snd列表。

13. 如我们前面在ACK的发送过程中所看到的,常规ACK消息还会携带许多用于同步的信息。这里正是将消息中的这些信息解出,并修改本地的一些用于控制数据收发的字段。

14. 执行拥塞控制器的回调m_pCC->onACK(ack),执行CCUpdate()以更新用于控制发送缓冲区及数据packet发送频率的一些字段。

15. 更新用于统计的字段m_iRecvACK和m_iRecvACKTotal。

数据接收端ACK2消息的接收与处理

接着来看下数据接收端在收到了ACK2消息之后会如何处理,在CUDT::processCtrl()中:

1case 6: //110 - Acknowledgement of Acknowledgement 2 { 3 int32_t ack; 4 int rtt = -1; 5 6 // update RTT 7 rtt = m_pACKWindow->acknowledge(ctrlpkt.getAckSeqNo(), ack); 8 if (rtt <= 0) 9 break; 10 11 //if increasing delay detected... 12 // sendCtrl(4); 13 14 // RTT EWMA 15 m_iRTTVar = (m_iRTTVar * 3 + abs(rtt - m_iRTT)) >> 2; 16 m_iRTT = (m_iRTT * 7 + rtt) >> 3; 17 18 m_pCC->setRTT(m_iRTT); 19 20 // update last ACK that has been received by the sender 21 if (CSeqNo::seqcmp(ack, m_iRcvLastAckAck) > 0) 22 m_iRcvLastAckAck = ack; 23 24 break; 25 }

1. 在这里会向ACKWindow acknowledge前面发送的ACK消息,获得那个ACK消息对应的目标数据packet SeqNo ack,并计算rtt值。

2. 根据前一步计算的rtt值,计算m_iRTTVar值与m_iRTT值。

3. 将m_iRTT值设置给拥塞控制器。

4. 在CSeqNo::seqcmp(ack, m_iRcvLastAckAck) > 0时更新m_iRcvLastAckAck。

ACK2消息的处理比较简单,大体如此。

超时重传

再来看一下UDT中的超时重传机制,在CUDT::checkTimers()中:

1uint64_t next_exp_time; 2 if (m_pCC->m_bUserDefinedRTO) 3 next_exp_time = m_ullLastRspTime + m_pCC->m_iRTO * m_ullCPUFrequency; 4 else { 5 uint64_t exp_int = (m_iEXPCount * (m_iRTT + 4 * m_iRTTVar) + m_iSYNInterval) * m_ullCPUFrequency; 6 if (exp_int < m_iEXPCount * m_ullMinExpInt) 7 exp_int = m_iEXPCount * m_ullMinExpInt; 8 next_exp_time = m_ullLastRspTime + exp_int; 9 } 10 11 if (currtime > next_exp_time) { 12 // Haven't receive any information from the peer, is it dead?! 13 // timeout: at least 16 expirations and must be greater than 10 seconds 14 if ((m_iEXPCount > 16) && (currtime - m_ullLastRspTime > 5000000 * m_ullCPUFrequency)) { 15 // 16 // Connection is broken. 17 // UDT does not signal any information about this instead of to stop quietly. 18 // Application will detect this when it calls any UDT methods next time. 19 // 20 m_bClosing = true; 21 m_bBroken = true; 22 m_iBrokenCounter = 30; 23 24 // update snd U list to remove this socket 25 m_pSndQueue->m_pSndUList->update(this); 26 27 releaseSynch(); 28 29 // app can call any UDT API to learn the connection_broken error 30 s_UDTUnited.m_EPoll.update_events(m_SocketID, m_sPollID, UDT_EPOLL_IN | UDT_EPOLL_OUT | UDT_EPOLL_ERR, 31 true); 32 33 CTimer::triggerEvent(); 34 35 return; 36 } 37 38 // sender: Insert all the packets sent after last received acknowledgement into the sender loss list. 39 // recver: Send out a keep-alive packet 40 if (m_pSndBuffer->getCurrBufSize() > 0) { 41 if ((CSeqNo::incseq(m_iSndCurrSeqNo) != m_iSndLastAck) && (m_pSndLossList->getLossLength() == 0)) { 42 // resend all unacknowledged packets on timeout, but only if there is no packet in the loss list 43 int32_t csn = m_iSndCurrSeqNo; 44 int num = m_pSndLossList->insert(m_iSndLastAck, csn); 45 m_iTraceSndLoss += num; 46 m_iSndLossTotal += num; 47 } 48 49 m_pCC->onTimeout(); 50 CCUpdate(); 51 52 // immediately restart transmission 53 m_pSndQueue->m_pSndUList->update(this); 54 } else { 55 sendCtrl(1); 56 } 57 58 ++m_iEXPCount; 59 // Reset last response time since we just sent a heart-beat. 60 m_ullLastRspTime = currtime; 61 }

1. 在这里首先是计算超时时间,拥塞控制器对于超时时间控制的优先级要高于CUDT内部的控制。

2. 与Peer端没有进行任何消息与数据的通信的时间过长时,会认为连接已经断开了。此时会将m_bClosing和m_bBroken置为true。释放所有的锁,然后退出。

3. 数据发送端和接收端有不同的处理。对于发送端,将最后一次接收到的确认消息之后发送的所有的packets都加进发送者的丢失packet列表中。对于接收者,则发送一个keep-alive消息。

4. 更新m_iEXPCount和m_ullLastRspTime。

发送端在将packet加如它的丢失packet列表之后,则在下次执行发送动作时,被认为丢失的packets会被重新发送。

Done。

点赞
收藏

评论区

加载中...

相关推荐

MySQL:[Err] 1292 - Incorrect datetime value: ‘0000-00-00 00:00:00‘ for column ‘CREATE_TIME‘ at row 1

文章目录问题用navicat导入数据时,报错:原因这是因为当前的MySQL不支持datetime为0的情况。解决修改sql\mode:sql\mode:SQLMode定义了MySQL应支持的SQL语法、数据校验等,这样可以更容易地在不同的环境中使用MySQL。全局s

Oracle 分组与拼接字符串同时使用

SELECTT.,ROWNUMIDFROM(SELECTT.EMPLID,T.NAME,T.BU,T.REALDEPART,T.FORMATDATE,SUM(T.S0)S0,MAX(UPDATETIME)CREATETIME,LISTAGG(TOCHAR(

UDT协议实现分析——bind、listen与accept

UDTServer启动之后,基于UDT协议的UDP数据可靠传输才成为可能,因而接下来分析与UDTServer有关的几个主要API的实现,来了解下UDTServer是如何listening在特定UDP端口上的。主要有UDT::bind(),UDT::listen()和UDT::accept()等几个函数。bind过程通常UDTSe

UDT协议实现分析总结

UDT的整体结构UDTSocket是UDT中的核心,同时它也是一座桥梁,它将UDT的使用者应用程序与内部实现部分对于数据结构的管理、网络数据的传输连接起来。应用程序通过它将数据放进发送缓冲待发送,或者借由它来获取从网络接收数据。而与网络进行交互的部分,则从它那里拿到要发送的数据进行发送,或者在收到packet时将packetdi

UDT协议实现分析——数据的接收

看了UDT中数据发送的部分之后,我们转换一个角度,来看一下接收端发生的故事。如我们前面在UDT协议实现分析——连接的建立(http://my.oschina.net/wolfcs/blog/505253)一文中看到的那样,CUDT在connect()的后半场,会通过调用CRcvQueue::removeConnector()把它自己从它的CCha

UDT协议实现分析——UDT初始化和销毁

UDT协议是一个用于在高速Internet上传输大量数据的基于UDP的可靠传输协议。我们可以将UDT协议的实现看作一个比较复杂的状态机。更准确的说,是一个主状态机,外加多个子状态机。主状态机是指协议实现中全局唯一、全局共享的状态与数据结构,主要对应于CUDTUnited类。子状态机则是对于一次UDT连接或一个Listening的UDTServer的抽象