: Support for the exchange of NN options in established state
PATCH 2/5 : Support for the exchange of NN options in established state
[DCCP]: Support for the exchange of NN options in established state
This patch introduces a variant of feature negotiation which differs from feature negotiation during connection setup in the following aspects.
* It is a restricted variant - only NN options can be exchanged;
* NN options are activated directly after validating them. The rationale is that a peer must accept every valid NN value (RFC 4340, 6.3.2), hence it will either accept the value and send a ConfirmR, or it will send an empty Confirm (which will reset the connection according to FN rules).
* An Ack is scheduled directly after activation to accelerate communicating the update to the peer.
The facility of exchanging NN options is currently only needed by CCID2's Ack Ratio (RFC 4341, 6.1.2). Although the code will in principle work for any NN option, this fact has been the reason for limiting the current use to Ack Ratio.
--- net/dccp/dccp.h | 1 + net/dccp/feat.c | 47 +++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 48 insertions(+)
net/dccp/dccp.h +1 -0
@@ -421,6 +421,7 @@ static inline int dccp_ack_pending(constinet_csk_ack_scheduled (sk); } +extern int dccp_feat_signal_nn_change (struct sock *sk,u8 feat,u64 nn_val);extern int dccp_feat_finalise_settings (struct dccp_sock *dp);extern int dccp_feat_server_ccid_dependencies (struct dccp_request_sock *dreq); extern int dccp_feat_insert_opts(struct dccp_sock*, struct dccp_request_sock*,
net/dccp/feat.c +47 -0
59 lines not on this page · raw message
Quoted 12 lines · Gerrit Renker
[DCCP]: Support for the exchange of NN options in established state
This patch introduces a variant of feature negotiation which differs from feature negotiation during connection setup in the following aspects.
* It is a restricted variant - only NN options can be exchanged;
* NN options are activated directly after validating them. The rationale is that a peer must accept every valid NN value (RFC 4340, 6.3.2), hence it will either accept the value and send a ConfirmR, or it will send an empty Confirm (which will reset the connection according to FN rules).
* An Ack is scheduled directly after activation to accelerate communicating the update to the peer.
Quoted 5 lines
The facility of exchanging NN options is currently only needed by CCID2's Ack Ratio (RFC 4341, 6.1.2). Although the code will in principle work for any NN option, this fact has been the reason for limiting the current use to Ack Ratio.
Signed-off-by Gerrit Renker <[email protected]>