Ian McDonald | 98069ff | 2005-11-10 13:04:33 -0800 | [diff] [blame] | 1 | DCCP protocol |
| 2 | ============ |
| 3 | |
Ian McDonald | 98069ff | 2005-11-10 13:04:33 -0800 | [diff] [blame] | 4 | |
| 5 | Contents |
| 6 | ======== |
| 7 | |
| 8 | - Introduction |
| 9 | - Missing features |
| 10 | - Socket options |
| 11 | - Notes |
| 12 | |
| 13 | Introduction |
| 14 | ============ |
| 15 | |
| 16 | Datagram Congestion Control Protocol (DCCP) is an unreliable, connection |
| 17 | based protocol designed to solve issues present in UDP and TCP particularly |
| 18 | for real time and multimedia traffic. |
| 19 | |
| 20 | It has a base protocol and pluggable congestion control IDs (CCIDs). |
| 21 | |
| 22 | It is at draft RFC status and the homepage for DCCP as a protocol is at: |
| 23 | http://www.icir.org/kohler/dcp/ |
| 24 | |
| 25 | Missing features |
| 26 | ================ |
| 27 | |
| 28 | The DCCP implementation does not currently have all the features that are in |
| 29 | the draft RFC. |
| 30 | |
| 31 | In particular the following are missing: |
| 32 | - CCID2 support |
| 33 | - feature negotiation |
| 34 | |
| 35 | When testing against other implementations it appears that elapsed time |
| 36 | options are not coded compliant to the specification. |
| 37 | |
| 38 | Socket options |
| 39 | ============== |
| 40 | |
| 41 | DCCP_SOCKOPT_PACKET_SIZE is used for CCID3 to set default packet size for |
| 42 | calculations. |
| 43 | |
Gerrit Renker | 00e4d11 | 2006-09-22 09:33:58 +0100 | [diff] [blame] | 44 | DCCP_SOCKOPT_SERVICE sets the service. The specification mandates use of |
| 45 | service codes (RFC 4340, sec. 8.1.2); if this socket option is not set, |
| 46 | the socket will fall back to 0 (which means that no meaningful service code |
| 47 | is present). Connecting sockets set at most one service option; for |
| 48 | listening sockets, multiple service codes can be specified. |
Ian McDonald | 98069ff | 2005-11-10 13:04:33 -0800 | [diff] [blame] | 49 | |
Gerrit Renker | 6f4e5ff | 2006-11-10 17:43:06 -0200 | [diff] [blame^] | 50 | DCCP_SOCKOPT_SEND_CSCOV and DCCP_SOCKOPT_RECV_CSCOV are used for setting the |
| 51 | partial checksum coverage (RFC 4340, sec. 9.2). The default is that checksums |
| 52 | always cover the entire packet and that only fully covered application data is |
| 53 | accepted by the receiver. Hence, when using this feature on the sender, it must |
| 54 | be enabled at the receiver, too with suitable choice of CsCov. |
| 55 | |
| 56 | DCCP_SOCKOPT_SEND_CSCOV sets the sender checksum coverage. Values in the |
| 57 | range 0..15 are acceptable. The default setting is 0 (full coverage), |
| 58 | values between 1..15 indicate partial coverage. |
| 59 | DCCP_SOCKOPT_SEND_CSCOV is for the receiver and has a different meaning: it |
| 60 | sets a threshold, where again values 0..15 are acceptable. The default |
| 61 | of 0 means that all packets with a partial coverage will be discarded. |
| 62 | Values in the range 1..15 indicate that packets with minimally such a |
| 63 | coverage value are also acceptable. The higher the number, the more |
| 64 | restrictive this setting (see [RFC 4340, sec. 9.2.1]). |
| 65 | |
Ian McDonald | 98069ff | 2005-11-10 13:04:33 -0800 | [diff] [blame] | 66 | Notes |
| 67 | ===== |
| 68 | |
| 69 | SELinux does not yet have support for DCCP. You will need to turn it off or |
| 70 | else you will get EACCES. |
| 71 | |
| 72 | DCCP does not travel through NAT successfully at present. This is because |
| 73 | the checksum covers the psuedo-header as per TCP and UDP. It should be |
| 74 | relatively trivial to add Linux NAT support for DCCP. |