Incremental modification test and (IP, TCP, UDP) algorithm research and implementation of __ algorithm

Source: Internet
Author: User
Tags rfc

/*

* Author:godbach

* e-mail:nylzhaowei@163.com

* This article can be reproduced freely, but please indicate the source, and ensure the integrity of this article.

*/

For testing and computing in packets, many of the books on TCP/IP protocols have been discussed, RFC1071 is a document that discusses computational tests and. The traditional calculation method is to sum up the data of the whole data (IP packet is the data of IP header).

However, in the actual application, there are several places to modify the received packets, and loopback to the sender or forwarding. This time, it involves the recalculation of the data packets and the test. The most common possibility is that the TTL field of the packets received will be reduced by 1 and forwarded. If the calculation is still in the traditional way, especially when the packet length is very large, in order to recalculate the data packet data to the side, the inverse code summation, the efficiency is certainly lower.

Implementation of Incremental modification test

The solution is to use incremental modification test and method. The method is proposed by RFC1141. Here's a simple workaround to list the incremental modification tests and formulas:

HC--The old test in the packet and

HC '--new test in the packet and

M--The value before a field (16-bit word) is modified in the packet

M '--the modified value of a field in the packet (16-bit word)

Then, the relationship between the checksum HC ' and hc,m and M ' After modifying a domain is as follows:

HC ' = HC + M + ~m ' (Formula 1)

The implementation of the C code is as follows:

[CPP]  View Plain  copy/*implemented according with rfc 1071 and1141*/       Static unsigned short csum_incremental_update (unsigned short old_ csum,                        unsigned short old_field,                        unsigned short new_ field)        {          unsigned long  csum = old_csum + old_field +  (~NEW_FIELD & 0XFFFF);          csum =  (csum >> 16)  +  (csum &  0XFFFF);          csum +=   (csum >>  16);           return csum;      }  

This time, if the IP head to modify the TTL value, will take the TTL field before the change of the value of the 16-bit Word is Old_field, modified for the New_field, and out of the test and old_csum, by calling the function can calculate a new test and.

Of course, the function can only compute one 16-bit word at a time, and if too many 16-bit words are modified in the packet, what will be its performance.

Test with TCP packets. And the TCP packet is a three-time handshake packet, with only the head, no data part. 8 different 16-bit words were modified for the packet, and the time required to call the function 8 times is still less than half of the traditional calculation method. Visible, the effect is suitable for obvious.

Second, the improvement of incremental modification test and

1. RFC1071 and 1141 The incremental modification test has a bug, that is, according to Formula 1 to calculate the new test and time, it is possible to calculate the result of the case 0xFFFF, you can see the example given by RFC1624. If checked and 0xFFFF, it means that all parts of the packet are added with the result 0x0000. It is impossible. Therefore, RFC1624 presents an improved approach to this bug, as shown in Formula 2:

HC ' = ~ (~HC + ~m + M ') (Formula 2)

Formula 2 takes the old test and the value of a field back, plus the new field value, and then the whole and again back to the new test and.

The implementation of the C code is as follows:

[CPP]  View Plain  copy/*implemented according with rfc 1624,modified the  algorithm from rfc 1071 and 1141*/       static unsigned  short csum_incremental_update_modified (unsigned short old_csum,                        unsigned  short old_field,                        unsigned short new_field)         {          unsigned long csum =  (~old_csum  & 0XFFFF)  +  (~OLD_FIELD &0XFFFF)  + new_field ;          csum =  (csum >> 16)  +  (csum &  0XFFFF);           csum +=   (csum >> 16);           return ~csum;      }  

The method and Formula 1 show that the method is more than two times to reverse operation, in the efficiency of the Formula 1 is not high, this also passed the actual test.

2. In this respect, RFC1624 has also given another way to ensure that both the bugs of RFC1071 and RFC1141 are corrected and the efficiency of execution is ensured, see Formula 3:

HC ' = HC-~m-m ' (Formula 3)

Formula 3 replaces the addition operation in public announcement 2 with subtraction.

The AT&T assembler code for implementation is as follows:

[CPP] view plain copy

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.