networking - TCP header option: SACK-permitted (Selective Acknowledgments) negotiation -


i'm doing research project, needs split tcp connection. have pecular questions, may happen in development. problem understanding of tcp sack-permitted negotiation. read rfc , can't find answer there.

for 3-way tcp handshake between 2 tcp programs: , b. if send tcp syn b sack-permitted, b surely respond syn/ack packet sack-permitted? if b reply tcp syn/ack without sack-permitted, mean

1) sack-permmited enabled on a. can selectively acknowledge tcp packets a, can't selectively acknowledge tcp packets b.

or

2) sack-permmited not enabled on both , b

if sends tcp syn b without sack-permitted, may b respond syn/ack packet sack-permitted?

besides, why sack-permitted allowed or disallowed? depends on operating system or kernel setting or else? possible control it? thanks!

the following should you: tcp selective acknowledgements

to answer question though (possible control it), depends on "what have control over." e.g., windows can control however, have enable it. if you're controlling both ends of tcp session, answer yes. obviously, if don't control other end, nothing can do. imagine enable on end (controllable) destination (let's website) not honoring sacks, ends being waste of time extent.

most operating systems allow turn if off , on. on freebsd (my current desktop) on default, in variants of linux, on default.


Comments

Popular posts from this blog

c# - Operator '==' incompatible with operand types 'Guid' and 'Guid' using DynamicExpression.ParseLambda<T, bool> -