Wei, Wei Yongjun wrote: >>> 1. If invalid Dccp-DataAck packets is received in the REQUEST state, the >>> socket just send back Dccp-Rest with invalid packet error, but the >>> socket is not reset, Dccp-Request will be continue retranmitted. The >>> procedure is like this: >>> >>> Endpoint A Endpint B >>> <----------------- Request >>> DataAck -----------------> <----------------- Reset (invalid >>> packet) >>> <----------------- Request (retranmit) >>> >>> >> This is not a bug but as far as I know correct behaviour. The DataAck >> could be from a previous incarnation of the same connection, or it could >> be an erratic packet. RFC 4340, 5.6 says about this error code >> "Packet Error" >> A valid packet arrived with unexpected type. For example, a >> DCCP-Data packet with valid header checksum and sequence numbers >> arrived at a connection in the REQUEST state. >> >> The client keeps on retransmitting the Request since this is a >> requirement from 8.1.3; the number of retransmissions is limited >> by net.dccp.default.request_retries. >> >> Hence this case is in principle correct. > > This case is correct. 7.5.6 has an final example demonstrates recovery > from a half-open connection. The difference is that Dccp-Sync is > received in REQUEST state. > This make me confusion. When to sent reset not close the connection, > when to sent reset and need close the connection? A sequence-valid Reset would close the connection. The easiest way to see this based on the specification (as opposed to the Linux code) is to follow the pseudocode in Section 8.5 of RFC4340. This pseudocode also makes clear that on some error conditions that generate a Reset, the socket should not be closed. Eddie -- To unsubscribe from this list: send the line "unsubscribe dccp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
