Skip to contentSkip to conversation

: Support for the exchange of NN options in established state

PATCH In review Gerrit Renker 2 participants 2 messages Oct 4, 2007 – Oct 5, 2007 Networking

lore
Share & tools
lore
#0 lore raw

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(const
 	       inet_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

Acked-by on v1 2/5
#1 lore raw
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.