- DCCP_OPEN = TCP_ESTABLISHED,
- DCCP_REQUESTING = TCP_SYN_SENT,
- DCCP_PARTOPEN = TCP_FIN_WAIT1, /* FIXME:
- This mapping is horrible, but TCP has
- no matching state for DCCP_PARTOPEN,
- as TCP_SYN_RECV is already used by
- DCCP_RESPOND, why don't stop using TCP
- mapping of states? OK, now we don't use
- sk_stream_sendmsg anymore, so doesn't
- seem to exist any reason for us to
- do the TCP mapping here */
- DCCP_LISTEN = TCP_LISTEN,
- DCCP_RESPOND = TCP_SYN_RECV,
- DCCP_CLOSING = TCP_CLOSING,
- DCCP_TIME_WAIT = TCP_TIME_WAIT,
- DCCP_CLOSED = TCP_CLOSE,
- DCCP_MAX_STATES = TCP_MAX_STATES,
+ DCCP_OPEN = TCP_ESTABLISHED,
+ DCCP_REQUESTING = TCP_SYN_SENT,
+ DCCP_LISTEN = TCP_LISTEN,
+ DCCP_RESPOND = TCP_SYN_RECV,
+ /*
+ * States involved in closing a DCCP connection:
+ * 1) ACTIVE_CLOSEREQ is entered by a server sending a CloseReq.
+ *
+ * 2) CLOSING can have three different meanings (RFC 4340, 8.3):
+ * a. Client has performed active-close, has sent a Close to the server
+ * from state OPEN or PARTOPEN, and is waiting for the final Reset
+ * (in this case, SOCK_DONE == 1).
+ * b. Client is asked to perform passive-close, by receiving a CloseReq
+ * in (PART)OPEN state. It sends a Close and waits for final Reset
+ * (in this case, SOCK_DONE == 0).
+ * c. Server performs an active-close as in (a), keeps TIMEWAIT state.
+ *
+ * 3) The following intermediate states are employed to give passively
+ * closing nodes a chance to process their unread data:
+ * - PASSIVE_CLOSE (from OPEN => CLOSED) and
+ * - PASSIVE_CLOSEREQ (from (PART)OPEN to CLOSING; case (b) above).
+ */
+ DCCP_ACTIVE_CLOSEREQ = TCP_FIN_WAIT1,
+ DCCP_PASSIVE_CLOSE = TCP_CLOSE_WAIT, /* any node receiving a Close */
+ DCCP_CLOSING = TCP_CLOSING,
+ DCCP_TIME_WAIT = TCP_TIME_WAIT,
+ DCCP_CLOSED = TCP_CLOSE,
+ DCCP_PARTOPEN = TCP_MAX_STATES,
+ DCCP_PASSIVE_CLOSEREQ, /* clients receiving CloseReq */
+ DCCP_MAX_STATES