dccp: Clean up slow-path input processing
authorGerrit Renker <gerrit@erg.abdn.ac.uk>
Sun, 3 Jul 2011 15:49:16 +0000 (09:49 -0600)
committerGerrit Renker <gerrit@erg.abdn.ac.uk>
Mon, 4 Jul 2011 18:36:33 +0000 (12:36 -0600)
commitc0c2015056d7bd69f3554208271407e7e2ee69e5
tree8144a35fcb508fe6e9a24442ceb013ad9dda2bad
parent31fcb99d9958bdf04e84224e202f69e6cdac893b
dccp: Clean up slow-path input processing

This patch rearranges the order of statements of the slow-path input processing
(i.e. any other state than OPEN), to resolve the following issues.

 1. Dependencies: the order of statements now better matches RFC 4340, 8.5, i.e.
    step 7 is before step 9 (previously 9 was before 7), and parsing options in
    step 8 (which may consume resources) now comes after step 7.
 2. Sequence number checks are omitted if in state LISTEN/REQUEST, due to the
    note underneath the table in RFC 4340, 7.5.3.
    As a result, CCID processing is now indeed confined to OPEN/PARTOPEN states,
    i.e. congestion control is performed only on the flow of data packets. This
    avoids pathological cases of doing congestion control on those messages
    which set up and terminate the connection.
 3. Packets are now passed on to Ack Vector / CCID processing only after
    - step 7  (receive unexpected packets),
    - step 9  (receive Reset),
    - step 13 (receive CloseReq),
    - step 14 (receive Close)
    and only if the state is PARTOPEN. This simplifies CCID processing:
    - in LISTEN/CLOSED the CCIDs are non-existent;
    - in RESPOND/REQUEST the CCIDs have not yet been negotiated;
    - in CLOSEREQ and active-CLOSING the node has already closed this socket;
    - in passive-CLOSING the client is waiting for its Reset.
    In the last case, RFC 4340, 8.3 leaves it open to ignore further incoming
    data, which is the approach taken here.

Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
net/dccp/input.c