亚洲欧美第一页_禁久久精品乱码_粉嫩av一区二区三区免费野_久草精品视频

? 歡迎來到蟲蟲下載站! | ?? 資源下載 ?? 資源專輯 ?? 關于我們
? 蟲蟲下載站

?? udplite.txt

?? linux 內核源代碼
?? TXT
字號:
  ===========================================================================                      The UDP-Lite protocol (RFC 3828)  ===========================================================================  UDP-Lite is a Standards-Track IETF transport protocol whose characteristic  is a variable-length checksum. This has advantages for transport of multimedia  (video, VoIP) over wireless networks, as partly damaged packets can still be  fed into the codec instead of being discarded due to a failed checksum test.  This file briefly describes the existing kernel support and the socket API.  For in-depth information, you can consult:   o The UDP-Lite Homepage: http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/       From here you can also download some example application source code.   o The UDP-Lite HOWTO on       http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/files/UDP-Lite-HOWTO.txt   o The Wireshark UDP-Lite WiKi (with capture files):       http://wiki.wireshark.org/Lightweight_User_Datagram_Protocol   o The Protocol Spec, RFC 3828, http://www.ietf.org/rfc/rfc3828.txt  I) APPLICATIONS  Several applications have been ported successfully to UDP-Lite. Ethereal  (now called wireshark) has UDP-Litev4/v6 support by default. The tarball on   http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/files/udplite_linux.tar.gz  has source code for several v4/v6 client-server and network testing examples.  Porting applications to UDP-Lite is straightforward: only socket level and  IPPROTO need to be changed; senders additionally set the checksum coverage  length (default = header length = 8). Details are in the next section.  II) PROGRAMMING API  UDP-Lite provides a connectionless, unreliable datagram service and hence  uses the same socket type as UDP. In fact, porting from UDP to UDP-Lite is  very easy: simply add `IPPROTO_UDPLITE' as the last argument of the socket(2)  call so that the statement looks like:      s = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDPLITE);                      or, respectively,      s = socket(PF_INET6, SOCK_DGRAM, IPPROTO_UDPLITE);  With just the above change you are able to run UDP-Lite services or connect  to UDP-Lite servers. The kernel will assume that you are not interested in  using partial checksum coverage and so emulate UDP mode (full coverage).  To make use of the partial checksum coverage facilities requires setting a  single socket option, which takes an integer specifying the coverage length:    * Sender checksum coverage: UDPLITE_SEND_CSCOV      For example,        int val = 20;        setsockopt(s, SOL_UDPLITE, UDPLITE_SEND_CSCOV, &val, sizeof(int));      sets the checksum coverage length to 20 bytes (12b data + 8b header).      Of each packet only the first 20 bytes (plus the pseudo-header) will be      checksummed. This is useful for RTP applications which have a 12-byte      base header.    * Receiver checksum coverage: UDPLITE_RECV_CSCOV      This option is the receiver-side analogue. It is truly optional, i.e. not      required to enable traffic with partial checksum coverage. Its function is      that of a traffic filter: when enabled, it instructs the kernel to drop      all packets which have a coverage _less_ than this value. For example, if      RTP and UDP headers are to be protected, a receiver can enforce that only      packets with a minimum coverage of 20 are admitted:        int min = 20;        setsockopt(s, SOL_UDPLITE, UDPLITE_RECV_CSCOV, &min, sizeof(int));  The calls to getsockopt(2) are analogous. Being an extension and not a stand-  alone protocol, all socket options known from UDP can be used in exactly the  same manner as before, e.g. UDP_CORK or UDP_ENCAP.  A detailed discussion of UDP-Lite checksum coverage options is in section IV.  III) HEADER FILES  The socket API requires support through header files in /usr/include:    * /usr/include/netinet/in.h        to define IPPROTO_UDPLITE    * /usr/include/netinet/udplite.h        for UDP-Lite header fields and protocol constants  For testing purposes, the following can serve as a `mini' header file:    #define IPPROTO_UDPLITE       136    #define SOL_UDPLITE           136    #define UDPLITE_SEND_CSCOV     10    #define UDPLITE_RECV_CSCOV     11  Ready-made header files for various distros are in the UDP-Lite tarball.  IV) KERNEL BEHAVIOUR WITH REGARD TO THE VARIOUS SOCKET OPTIONS  To enable debugging messages, the log level need to be set to 8, as most  messages use the KERN_DEBUG level (7).  1) Sender Socket Options  If the sender specifies a value of 0 as coverage length, the module  assumes full coverage, transmits a packet with coverage length of 0  and according checksum.  If the sender specifies a coverage < 8 and  different from 0, the kernel assumes 8 as default value.  Finally,  if the specified coverage length exceeds the packet length, the packet  length is used instead as coverage length.  2) Receiver Socket Options  The receiver specifies the minimum value of the coverage length it  is willing to accept.  A value of 0 here indicates that the receiver  always wants the whole of the packet covered. In this case, all  partially covered packets are dropped and an error is logged.  It is not possible to specify illegal values (<0 and <8); in these  cases the default of 8 is assumed.  All packets arriving with a coverage value less than the specified  threshold are discarded, these events are also logged.  3) Disabling the Checksum Computation  On both sender and receiver, checksumming will always be performed  and cannot be disabled using SO_NO_CHECK. Thus        setsockopt(sockfd, SOL_SOCKET, SO_NO_CHECK,  ... );  will always will be ignored, while the value of        getsockopt(sockfd, SOL_SOCKET, SO_NO_CHECK, &value, ...);  is meaningless (as in TCP). Packets with a zero checksum field are  illegal (cf. RFC 3828, sec. 3.1) will be silently discarded.  4) Fragmentation  The checksum computation respects both buffersize and MTU. The size  of UDP-Lite packets is determined by the size of the send buffer. The  minimum size of the send buffer is 2048 (defined as SOCK_MIN_SNDBUF  in include/net/sock.h), the default value is configurable as  net.core.wmem_default or via setting the SO_SNDBUF socket(7)  option. The maximum upper bound for the send buffer is determined  by net.core.wmem_max.  Given a payload size larger than the send buffer size, UDP-Lite will  split the payload into several individual packets, filling up the  send buffer size in each case.  The precise value also depends on the interface MTU. The interface MTU,  in turn, may trigger IP fragmentation. In this case, the generated  UDP-Lite packet is split into several IP packets, of which only the  first one contains the L4 header.  The send buffer size has implications on the checksum coverage length.  Consider the following example:  Payload: 1536 bytes          Send Buffer:     1024 bytes  MTU:     1500 bytes          Coverage Length:  856 bytes  UDP-Lite will ship the 1536 bytes in two separate packets:  Packet 1: 1024 payload + 8 byte header + 20 byte IP header = 1052 bytes  Packet 2:  512 payload + 8 byte header + 20 byte IP header =  540 bytes  The coverage packet covers the UDP-Lite header and 848 bytes of the  payload in the first packet, the second packet is fully covered. Note  that for the second packet, the coverage length exceeds the packet  length. The kernel always re-adjusts the coverage length to the packet  length in such cases.  As an example of what happens when one UDP-Lite packet is split into  several tiny fragments, consider the following example.  Payload: 1024 bytes            Send buffer size: 1024 bytes  MTU:      300 bytes            Coverage length:   575 bytes  +-+-----------+--------------+--------------+--------------+  |8|    272    |      280     |     280      |     280      |  +-+-----------+--------------+--------------+--------------+               280            560            840           1032                                    ^  *****checksum coverage*************  The UDP-Lite module generates one 1032 byte packet (1024 + 8 byte  header). According to the interface MTU, these are split into 4 IP  packets (280 byte IP payload + 20 byte IP header). The kernel module  sums the contents of the entire first two packets, plus 15 bytes of  the last packet before releasing the fragments to the IP module.  To see the analogous case for IPv6 fragmentation, consider a link  MTU of 1280 bytes and a write buffer of 3356 bytes. If the checksum  coverage is less than 1232 bytes (MTU minus IPv6/fragment header  lengths), only the first fragment needs to be considered. When using  larger checksum coverage lengths, each eligible fragment needs to be  checksummed. Suppose we have a checksum coverage of 3062. The buffer  of 3356 bytes will be split into the following fragments:    Fragment 1: 1280 bytes carrying  1232 bytes of UDP-Lite data    Fragment 2: 1280 bytes carrying  1232 bytes of UDP-Lite data    Fragment 3:  948 bytes carrying   900 bytes of UDP-Lite data  The first two fragments have to be checksummed in full, of the last  fragment only 598 (= 3062 - 2*1232) bytes are checksummed.  While it is important that such cases are dealt with correctly, they  are (annoyingly) rare: UDP-Lite is designed for optimising multimedia  performance over wireless (or generally noisy) links and thus smaller  coverage lengths are likely to be expected.  V) UDP-LITE RUNTIME STATISTICS AND THEIR MEANING  Exceptional and error conditions are logged to syslog at the KERN_DEBUG  level.  Live statistics about UDP-Lite are available in /proc/net/snmp  and can (with newer versions of netstat) be viewed using                            netstat -svu  This displays UDP-Lite statistics variables, whose meaning is as follows.   InDatagrams:     Total number of received datagrams.   NoPorts:         Number of packets received to an unknown port.                    These cases are counted separately (not as InErrors).   InErrors:        Number of erroneous UDP-Lite packets. Errors include:                      * internal socket queue receive errors                      * packet too short (less than 8 bytes or stated                        coverage length exceeds received length)                      * xfrm4_policy_check() returned with error                      * application has specified larger min. coverage                        length than that of incoming packet                      * checksum coverage violated                      * bad checksum   OutDatagrams:    Total number of sent datagrams.   These statistics derive from the UDP MIB (RFC 2013).  VI) IPTABLES  There is packet match support for UDP-Lite as well as support for the LOG target.  If you copy and paste the following line into /etc/protocols,  udplite 136     UDP-Lite        # UDP-Lite [RFC 3828]  then              iptables -A INPUT -p udplite -j LOG  will produce logging output to syslog. Dropping and rejecting packets also works.  VII) MAINTAINER ADDRESS  The UDP-Lite patch was developed at                    University of Aberdeen                    Electronics Research Group                    Department of Engineering                    Fraser Noble Building                    Aberdeen AB24 3UE; UK  The current maintainer is Gerrit Renker, <gerrit@erg.abdn.ac.uk>. Initial  code was developed by William  Stanislaus, <william@erg.abdn.ac.uk>.

?? 快捷鍵說明

復制代碼 Ctrl + C
搜索代碼 Ctrl + F
全屏模式 F11
切換主題 Ctrl + Shift + D
顯示快捷鍵 ?
增大字號 Ctrl + =
減小字號 Ctrl + -
亚洲欧美第一页_禁久久精品乱码_粉嫩av一区二区三区免费野_久草精品视频
久久99精品久久久久久国产越南| 懂色av中文一区二区三区| 麻豆中文一区二区| 97精品电影院| 久久综合av免费| 亚洲福利一二三区| 99在线精品一区二区三区| 欧美一区二区在线观看| 亚洲天堂2016| 国产aⅴ精品一区二区三区色成熟| 欧美偷拍一区二区| 亚洲品质自拍视频| 成人黄色一级视频| 久久精品亚洲精品国产欧美| 七七婷婷婷婷精品国产| 欧美在线free| 亚洲蜜臀av乱码久久精品蜜桃| 国产精品伊人色| 精品人在线二区三区| 日本最新不卡在线| 欧美日韩精品系列| 亚洲午夜精品网| 日本韩国精品在线| 亚洲欧洲日产国码二区| 成人久久18免费网站麻豆| 久久久久99精品一区| 久久电影国产免费久久电影| 欧美一区二区日韩一区二区| 亚洲一区在线观看免费| 在线观看日韩国产| 亚洲高清久久久| 欧美精品 日韩| 婷婷开心激情综合| 欧美精品在线视频| 蜜桃视频免费观看一区| 日韩一级视频免费观看在线| 美日韩一区二区三区| 欧美一区二区在线看| 蜜臀久久99精品久久久画质超高清 | 欧美成人精品3d动漫h| 日日夜夜免费精品视频| 欧美一激情一区二区三区| 日韩成人精品视频| 欧美变态tickling挠脚心| 国产在线视频一区二区| 国产日韩欧美一区二区三区综合 | 亚洲在线观看免费视频| 欧洲色大大久久| 丝袜亚洲精品中文字幕一区| 日韩一区和二区| 国产一区二区三区精品视频| 国产日韩欧美精品在线| 成人少妇影院yyyy| 亚洲综合一区在线| 欧美一卡二卡在线| 国产成人免费视频网站| 国产精品女主播av| 精品视频一区二区不卡| 久草这里只有精品视频| 中文文精品字幕一区二区| 91在线视频网址| 午夜国产精品一区| 久久久www免费人成精品| 91捆绑美女网站| 麻豆精品一二三| 国产精品久久久久久久午夜片| 欧美亚洲国产一区在线观看网站| 秋霞国产午夜精品免费视频| 久久久久久久久蜜桃| 在线观看日韩毛片| 国产美女一区二区| 一区二区三区四区中文字幕| 日韩视频在线你懂得| 91在线无精精品入口| 久久狠狠亚洲综合| 亚洲精品乱码久久久久| 2020国产精品久久精品美国| 91亚洲精品乱码久久久久久蜜桃| 日本视频一区二区| 中文字幕亚洲电影| 精品国内二区三区| 欧美色视频在线观看| 国产91丝袜在线播放| 日韩成人一区二区| 最新国产の精品合集bt伙计| 日韩免费看网站| 在线国产亚洲欧美| 成人国产精品视频| 麻豆免费精品视频| 五月激情综合色| 亚洲欧美视频在线观看| 精品国产91九色蝌蚪| 欧美日韩黄色影视| 日韩欧美电影在线| 在线观看三级视频欧美| 成人手机在线视频| 国产一区在线精品| 美女在线观看视频一区二区| 亚洲成人精品影院| 亚洲激情在线播放| 中文字幕佐山爱一区二区免费| 精品国产91乱码一区二区三区| 欧美日韩亚洲丝袜制服| 91福利视频久久久久| 97se亚洲国产综合在线| av男人天堂一区| 成人免费黄色在线| 国产成人精品亚洲777人妖 | 一区二区欧美在线观看| 日韩一区中文字幕| 中文在线一区二区| 亚洲国产精品99久久久久久久久| 久久综合九色综合97婷婷女人| 日韩一区二区不卡| 日韩欧美一级精品久久| 日韩一区二区电影在线| 日韩欧美国产综合| 精品国产伦一区二区三区观看体验 | 国产东北露脸精品视频| 国产精品99久久久久久宅男| 麻豆成人av在线| 久久国产精品99久久人人澡| 蜜臀av性久久久久av蜜臀妖精 | 欧美日韩国产天堂| 欧美日韩中字一区| 欧美一级理论性理论a| 91麻豆精品国产91久久久久久 | 欧美精品三级日韩久久| 欧美日韩国产另类不卡| 777色狠狠一区二区三区| 日韩欧美高清在线| 国产欧美精品一区aⅴ影院| 国产精品美日韩| 一二三区精品视频| 日韩在线一区二区| 国产精品综合网| 成人免费看的视频| 在线观看区一区二| 日韩欧美综合一区| 国产女人18毛片水真多成人如厕| 国产欧美日韩一区二区三区在线观看| 国产精品动漫网站| 亚洲高清免费视频| 国产经典欧美精品| 色嗨嗨av一区二区三区| 91麻豆精品国产无毒不卡在线观看| 精品国产伦一区二区三区观看方式| 国产婷婷一区二区| 一级日本不卡的影视| 激情综合色丁香一区二区| gogo大胆日本视频一区| 91超碰这里只有精品国产| 欧美精品一区在线观看| 中文字幕中文乱码欧美一区二区 | 欧美aaa在线| 成人性生交大片免费看中文| 日本精品一区二区三区高清| 精品久久久影院| 亚洲综合自拍偷拍| 国产激情视频一区二区三区欧美| 色狠狠一区二区| 久久综合久久综合久久综合| 亚洲四区在线观看| 精品午夜久久福利影院| 在线亚洲免费视频| 久久久影院官网| 奇米影视7777精品一区二区| 91网页版在线| 久久久久国产成人精品亚洲午夜| 亚洲线精品一区二区三区| 国产一区二区美女诱惑| 欧美浪妇xxxx高跟鞋交| 亚洲欧洲日韩一区二区三区| 国模一区二区三区白浆| 在线播放中文一区| 一区二区三区在线观看国产 | 国产欧美精品国产国产专区| 亚洲国产va精品久久久不卡综合| 成人午夜伦理影院| 欧美成人三级在线| 日本女人一区二区三区| 在线欧美日韩国产| 亚洲视频免费在线观看| 成人一区在线看| 久久精品一区二区三区四区| 免费观看一级特黄欧美大片| 欧美午夜精品理论片a级按摩| 国产精品美女www爽爽爽| 久久99国产精品尤物| 91精品国产综合久久蜜臀| 亚洲一区二区欧美日韩| 日本电影亚洲天堂一区| 综合久久久久久| 不卡一区在线观看| 国产精品美女www爽爽爽| 成人性生交大片免费| 中文字幕第一区综合| 粉嫩aⅴ一区二区三区四区五区 | 亚洲欧洲色图综合| 91网站黄www|