aboutsummaryrefslogtreecommitdiffstats
path: root/net/dccp/dccp.h
diff options
context:
space:
mode:
authorGerrit Renker <gerrit@erg.abdn.ac.uk>2008-12-08 04:19:06 -0500
committerDavid S. Miller <davem@davemloft.net>2008-12-08 04:19:06 -0500
commit6fdd34d43bff8be9bb925b49d87a0ee144d2ab07 (patch)
tree547cf602983db37d573d3d191ac11660f1698e8f /net/dccp/dccp.h
parent4098dce5be537a157eed4a326efd464109825b8b (diff)
dccp ccid-2: Phase out the use of boolean Ack Vector sysctl
This removes the use of the sysctl and the minisock variable for the Send Ack Vector feature, as it now is handled fully dynamically via feature negotiation (i.e. when CCID-2 is enabled, Ack Vectors are automatically enabled as per RFC 4341, 4.). Using a sysctl in parallel to this implementation would open the door to crashes, since much of the code relies on tests of the boolean minisock / sysctl variable. Thus, this patch replaces all tests of type if (dccp_msk(sk)->dccpms_send_ack_vector) /* ... */ with if (dp->dccps_hc_rx_ackvec != NULL) /* ... */ The dccps_hc_rx_ackvec is allocated by the dccp_hdlr_ackvec() when feature negotiation concluded that Ack Vectors are to be used on the half-connection. Otherwise, it is NULL (due to dccp_init_sock/dccp_create_openreq_child), so that the test is a valid one. The activation handler for Ack Vectors is called as soon as the feature negotiation has concluded at the * server when the Ack marking the transition RESPOND => OPEN arrives; * client after it has sent its ACK, marking the transition REQUEST => PARTOPEN. Adding the sequence number of the Response packet to the Ack Vector has been removed, since (a) connection establishment implies that the Response has been received; (b) the CCIDs only look at packets received in the (PART)OPEN state, i.e. this entry will always be ignored; (c) it can not be used for anything useful - to detect loss for instance, only packets received after the loss can serve as pseudo-dupacks. There was a FIXME to change the error code when dccp_ackvec_add() fails. I removed this after finding out that: * the check whether ackno < ISN is already made earlier, * this Response is likely the 1st packet with an Ackno that the client gets, * so when dccp_ackvec_add() fails, the reason is likely not a packet error. Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk> Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net/dccp/dccp.h')
-rw-r--r--net/dccp/dccp.h3
1 files changed, 1 insertions, 2 deletions
diff --git a/net/dccp/dccp.h b/net/dccp/dccp.h
index e0759d098b9a..0bc4c9a02e19 100644
--- a/net/dccp/dccp.h
+++ b/net/dccp/dccp.h
@@ -98,7 +98,6 @@ extern int sysctl_dccp_retries2;
98extern int sysctl_dccp_feat_sequence_window; 98extern int sysctl_dccp_feat_sequence_window;
99extern int sysctl_dccp_feat_rx_ccid; 99extern int sysctl_dccp_feat_rx_ccid;
100extern int sysctl_dccp_feat_tx_ccid; 100extern int sysctl_dccp_feat_tx_ccid;
101extern int sysctl_dccp_feat_send_ack_vector;
102extern int sysctl_dccp_tx_qlen; 101extern int sysctl_dccp_tx_qlen;
103extern int sysctl_dccp_sync_ratelimit; 102extern int sysctl_dccp_sync_ratelimit;
104 103
@@ -434,7 +433,7 @@ static inline int dccp_ack_pending(const struct sock *sk)
434 const struct dccp_sock *dp = dccp_sk(sk); 433 const struct dccp_sock *dp = dccp_sk(sk);
435 return dp->dccps_timestamp_echo != 0 || 434 return dp->dccps_timestamp_echo != 0 ||
436#ifdef CONFIG_IP_DCCP_ACKVEC 435#ifdef CONFIG_IP_DCCP_ACKVEC
437 (dccp_msk(sk)->dccpms_send_ack_vector && 436 (dp->dccps_hc_rx_ackvec != NULL &&
438 dccp_ackvec_pending(dp->dccps_hc_rx_ackvec)) || 437 dccp_ackvec_pending(dp->dccps_hc_rx_ackvec)) ||
439#endif 438#endif
440 inet_csk_ack_scheduled(sk); 439 inet_csk_ack_scheduled(sk);